Following our framework for evaluating Aave’s infrastructure and the positive signaling from the community on the forum, we present an analysis of the BOB network regarding its suitability for deploying an instance of the Aave v3 (v3.3) protocol.
DISCLOSURE. This is an independent assessment of different technical components that we consider important for Aave software to run optimally. It is not a categorical analysis stating the network is “good” or “bad”, and it does not impose any requirements for Aave to be deployed on the candidate network. That decision is up to Aave governance, regardless of our opinion.
In addition, we currently have no financial, investment, services, or engagement interest in the BOB ecosystem.
Report
1. Introduction to BOB
BOB is an L2 that uses the OP stack, operating as an Optimistic Rollup and part of the Superchain. It is under development to become a Hybrid L2 that will inherit security from the Bitcoin blockchain and Ethereum.
2. Our methodology
Methodology and scoring details
This report does not attempt to provide a full, detailed analysis of the Soneium network. Instead, it focuses on the high-level aspects necessary for the Aave community to decide whether to deploy the Aave v3 (v3.3) liquidity protocol there.
In addition to being extensive, this report tries to be simple enough for all participants in Aave governance to understand. However, given its technical nature, it is unavoidable to assume a certain familiarity with some relevant concepts, such as rollups, oracles, RPC nodes, or blockchain explorers, among others.
In order to simplify the interpretation of this report, we will evaluate each key component for Aave separately, and assign simplified “grades”, defined as follows:
Optimal. Fulfilling all minimal requirements, and with extra positive aspects.
Good. Fulfilling the requirements, but improvements can be made.
Acceptable. Fulfilling the requirements, but with “buts”.
Needs improvement. Mandatory requirements were not fulfilled at all. Aave will not work properly
3. Evaluation
3.1. Oracle Infrastructure
The Aave protocol uses different types of oracles in a standalone blockchain. We consider it a must to have Chainlink providing oracles, especially for prices, in any deployment, with alternatives only considered on an ad-hoc basis due to the additional complexity added during evaluation and integration.
In the case of rollups, we evaluate fully optimal by having two important aspects: The price feeds infrastructure and the L2 sequencer uptime feed, which indicates to the Aave protocol if the sequencer of a rollup (or any network involving some centralization on transaction sequencing) is properly running.
| BOB Network | Oracle Infrastructure available | Info/Links |
|---|---|---|
| Chainlink Price Feeds |  * |
TBA: Oracles | BOB - Build on Bitcoin |
| L2 Sequencer Uptime Feed | |
- |
- Chainlink price feeds are not available at the moment of writing. However, the BOB team has confirmed that price feeds will be available for the Aave deployment.
3.2. Blockchain explorer
For Aave, as for any other blockchain project, block explorers like Etherscan are a fundamental component, specifically for the following:
- Verifiable smart contract code visualization.
- Read/write interface with smart contracts.
- Basic data analysis tool for miscellaneous aspects, like token holders.
The official blockchain explorer of BOB can be found at https://explorer.gobob.xyz/, which is an instance of Blockscout.
3.3. Compatibility with Ethereum RPC standard
Basic compatibility with the Ethereum nodes RPC de-facto standard (eth_, web3_) is quite an important requirement for Aave or any other protocol, given that it helps to have tools built for Ethereum (or other similar networks) working out-of-the-box just by plugging them to a node, of BOB in this case.
BOB HAS compatibility and uses Optimism OP Stack and its op-geth execution client.
3.4 Compatibility with Ethereum account format (addresses)
One of the strengths of non-Ethereum networks (e.g., Polygon, Avalanche C-Chain, etc.) is their compatibility with Ethereum’s private/public keys of accounts. This allows existing account holders on those networks to use the others without creating an ad-hoc wallet for it.
BOB IS fully compatible with the Ethereum account format.
3.5. RPC public endpoints and providers
Basic and reliable public RPC infrastructure is a must for Aave, as it is the way to connect to the network, both for data reading and transaction submission.
BOB HAS an official endpoint at https://rpc.gobob.xyz/.
Third-party RPCs like dRPC and Tenderly are also available and can be found in the official BOB documentation here.
3.6. Custom behaviour (lack of) of the execution layer
Whenever a network has custom or extended behavior concerning Ethereum, it is important to be aware of it and evaluate whether it has any impact on the Aave protocol.
Examples of this potential behavior include the presence of new pre-compiles (compared to Ethereum or similar rollups like Optimism), EVM opcodes, native account abstraction and meta-transactions, and chainId definitions that are out of the norm, etc.
- The
chainIdbehavior is appropriate, with the id60808for BOB not clashing with any other. - Currently, BOB supports the Pectra EVM version.
- Some opcodes (
COINBASE,PREVRANDAO,ORIGIN,CALLER) behave differently from L1. This is similar across OP stack chains. More details can be found in the Optimistic docs here. - Block generation is transaction-independent and has a fixed time of 2 seconds to generate blocks.
- As part of an extra security procedure, we deployed a test instance of the Aave v3.3 protocol on BOB and performed end-to-end tests on core protocol functionalities. We found no issues during testing, and the protocol behaved consistently with deployments on other networks.
3.7. Support of wallet providers
Wallet products like Rabby, MetaMask, Ledger, Coinbase Wallet, and others are fundamental pieces of infrastructure that allow users to access the Aave protocol. So it is a strong requirement for a network to be supported by a subset of them.
Given its major EVM compatibility, BOB IS supported by the majority of chain-agnostic EVM wallets.
3.8. On-chain multi-signature infrastructure
The permissions in the Aave ecosystem are directly held by on-chain governance smart contracts or are scheduled to be like that once cross-chain governance infrastructure can be applied across all networks.
However, different protection and emergency mechanisms, such as the ability to cancel cross-chain governance proposals or pause an Aave asset or pool, depend on the Aave Guardian, who can act faster than the governance process.
Consequently, having on-chain multi-signature contracts is a prerequisite for having Aave on a different network, with a high preference for industry-standard tools like Gnosis Safe.
Also, having alternative interfaces ensures continuous access and functionality in the case the official one is inaccessible for any circumstance.
BOB does not have support on the official instance of the Safe{Wallet} contracts. However, an alternative interface for accessing BOB Safe contracts is available at https://safe.gobob.xyz/new-safe/create?chain=bob
3.9. Transactions simulation infrastructure (fork)
Lately, a really important development experience component is the ability to execute test transactions (simulations) on forked production networks.
A significant part of the tooling around Aave depends on simulations using different libraries and frameworks, such as Hardhat, Foundry, or Tenderly. This way, it is possible to rapidly prototype new developments, get extra assurances on governance proposals and protocol upgrades, change risk parameters, etc.
In terms of tooling that can be used for simulation supporting BOB:
- Tenderly has support for BOB.
- Phalcon simulator has support for BOB.
- Foundry and Hardhat are supported on BOB.
3.10. Chain data/indexing solutions
For different projects and entities integrating Aave, even if it’s not a blocker for deployment, solutions like TheGraph or Dune must be operating on the candidate network to avoid building data pipelines from scratch.
At the moment, Goldsky is an alternative data indexer available on BOB.
The team has confirmed that TheGraph is working on an integration with BOB, with deployment estimation to be defined.
3.11. Bridging infrastructure: assets, messages
Given the central role of Ethereum in the DeFi and Aave ecosystems, proper bridging infrastructure to/from is a must for any candidate network.
Assets bridging: ETH and major assets can be sent through the canonical BOB Bridge (OP L2StandardBridge) from the mainnet and other L2s and networks.
The BOB Bridge UI also allows to choose between third-party bridges like Superbridge, Orbiter finance, and Stargate.
Additionally, BTC can be bridged to BOB through the BOB Gateway, which verifies Bitcoin transaction proofs with an on-chain light client (the same infrastructure created and used by the tBTC team on the mainnet).
Generic messaging: BOB supports bi-directional generic message passing, with the exact mechanism as Optimism. This is especially important for Aave in order to activate cross-chain governance.
In addition to BOB’s default bridging mechanism, third-party bridges, such as LayerZero or Hyperlane, are present.
3.12. Network security/technical model
At the core of any candidate network analysis are its morphology (which type of network it is) and security model (which parties are involved in controlling the network, its degree of decentralization, mechanisms, and procedures for preventing and responding to security incidents).
Regarding its morphology/type, in its phase 1, BOB is an optimistic rollup using the OP stack that still inherits Ethereum’s base security, while keeping track of the Bitcoin blockchain through stateless SPV proofs. It also uses a modular architecture, separating its executor settlement and data availability components into independent layers.
In phase 2, BOB will implement the BitVM2, making it a hybrid L2 that inherits both Bitcoin and Ethereum-based security.
Regarding its security/operational model, we verified multiple points:
3.12.1. Sequencer and Proposer Downtime
In situations where the sequencer refuses to execute your transaction requests or experiences prolonged downtime, a mechanism known as forced withdrawal or forced transaction inclusion becomes essential to better safeguard user funds.
As part of the OP Stack, BOB users can force transactions by sending them directly through the OptimismPortal contract on the L1. This bypasses the sequencer and automatically includes the transaction in the L2.
3.12.2. Upgradeability and control model (decentralisation)
BOB has detailed the privileged roles of the core contracts in their documentation, which can be found here. But summarizing:
- BOB has control of the L1 ProxyAdmin contract, that can upgrade core contracts, through a Safe 4-of-6.
- BOB has control of the L1 SystemConfig contract used to manage BOB’s configuration, through a Safe 4-of-6.
- BOB has control of the L2 ProxyAdmin contract, that can upgrade L2 core contracts, through a Safe 4-of-6.
- The Standard USDC bridge contract is upgradeable through a Safe 4-of-6.
- For ERC20 tokens:
- USDC is upgradeable by a Safe 3-of-6. This allows Circle to upgrade the asset to native minting on BOB.
- tBTC is upgradable by a Safe 2-of-4. This allows Keep to upgrade the asset to native minting on BOB.
- wstETH is upgradable by the OptimismBridgeExecutor. This allows Lido to take over control of the asset on BOB via the L1.
While this setup doesn’t use timelocks for upgradability, given the technology’s early stage, it is relatively consistent with other L2 networks of the same stack.
3.12.3. Security audits
BOB audits can be referred to the OP audit reports as part of the superchain ecosystem. Apart from those, the BOB Gateway has undergone audits by Cure3, Common Prefix, and Pashov that can be found here. Other audits, like the Standard USDC Bridge, can be found here.
3.13.4. Security programs (e.g., bug bounty)
BOB has an ongoing bug bounty program on Remedy, with rewards ranging from $1,000 for low-severity findings to $250,000 for critical findings.
3.12.5. Commitment to security incidents
A communication channel will be maintained between BOB and the assigned technical team of the Aave community (e.g., BGD) for any necessary updates concerning the network and, consequently, Aave on BOB.
3.12.6. Transaction Lifecycle
BOB follows the same rollup transaction lifecycle explained in the Optimism documentation. But summarizing:
- Users send signed transactions through available RPC nodes.
- The sequencer receives transactions and packs them into blocks.
op-batcherobtains data from the sequencer, performs encoding and compression, and submits the data to the L1 contract to ensure availability and integrity. - The
op-proposerobtains the state root of packed blocks through the sequencer and sends it to the relevant L2OutputOracle contract on L1.
3.12.7. Data availability
As BOB uses the OP stack, all the transaction data is submitted to Ethereum, so data availability boils down to Ethereum, which can be considered the highest standard at the moment.
Also, as part of the Superchain, BOB can configure its DA provider, but currently, there is no available node software that can reconstruct the state from the L1 data.
3.13. Comparison with similar Networks: characteristics and differences
As Aave expands to new blockchains, those networks end up sharing different aspects in their layers, which can influence the protocol’s behaviour. By understanding these similarities, we can have a high-level preview during and after its implementation, which facilitates the protocol’s general usability and maintenance.
In the case of BOB, it is very similar to other OP chains, such as Optimism itself, Base, and other chains that are included in the Superchain.
- BOB uses a recent stable version of the
op-gethrelease with no custom changes. The pre-compiled contracts and addresses that facilitate cross-chain communication with the L1 are the same, with no custom behaviour expected. - BOB submits transactions using a single sequencer, as the OP Stack currently allows only one active sequencer at a time.
- BOB is also currently tracking the Bitcoin Blockchain through its Gateway via stateless SPV proofs, keeping it in sync when users bridge BTC to BOB.
- The infrastructure’s control model also mirrors the early stage of other OP stack chains, with some level of centralization around its upgradability, handled by safe wallets controlled by the team.
- BOB recently underwent the Isthmus Upgrade, which upgraded nodes and aligned with Ethereum’s Pectra hard fork on the mainnet.
- Although it is not active yet, it is worth mentioning that in its Phase 2, BOB will become a hybrid L2 that also utilizes optimistic computation on the Bitcoin blockchain. This will increase the overall security of the L2 but will not introduce any custom behaviour.
Given its infrastructure components, we can conclude that BOB’s behavior would be very similar to Optimism, with minimal to no differences from it.
4. Summary
From our analysis, we conclude that BOB, even at a relatively early stage, is an acceptable network candidate in terms of technical requirements, with no inherent blockers preventing the Aave v3 (v3.3) protocol from functioning properly. However, the absence of Chainlink price feeds remains a blocker for deploying Aave on the network. The BOB team is currently in discussions with Chainlink to enable the required feeds, and as agreed, deployment will proceed once the feeds are live.
An expansion of Aave to BOB will imply allocating some development resources for both the initial setup, as well as some overhead for maintenance and monitoring over time, similar to other networks.
Similar to other rollups, there is an important degree of centralization, but this is expected given the early stage of this technology.