Following our framework for evaluating Aave’s infrastructure and the positive signaling from the community on the forum, we present an analysis of the Soneium 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 Soneium ecosystem.
Report
1. Introduction to Soneium
Soneium is an L2 that uses the Optimism OP Stack and operates as an Optimistic Rollup and part of the Superchain.
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.
| Soneium Network | Oracle Infrastructure available | Info/Links |
|---|---|---|
| Chainlink Price Feeds |  |
Soneium docs |
| L2 Sequencer Uptime Feed | |
Chainlink docs |
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 Soneium can be found at https://soneium.blockscout.com/, which is an instance of Blockscout.
Other explorer instances can be found in the official Soneium documentation here.
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 Soneium in this case.
Soneium 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.
Soneium 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.
Soneium HAS an official endpoint at https://rpc.soneium.org/
Third-party RPCs like Alchemy are also available and can be found in the official Soneium 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 id1868for Soneium not clashing with any other. - Currently, Soneium supports the Shanghai EVM version.
- Some opcodes (
COINBASE,PREVRANDAO,ORIGIN,CALLER) behave differently from L1. See the Soneium opcode docs. - 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 the Soneium network 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, Soneium 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.
Soneium does not have support an on the official instance of the Safe{Wallet} contracts.
However, an alternative interface for accessing Soneium Safe contracts is the Optimism Superchain Safe interface.
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 Soneium:
- Tenderly has support for Soneium.
- Phalcon simulator does not have support for Soneium.
- Foundry and Hardhat are supported on Soneium.
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.
Soneium HAS integration and is supported by TheGraph.
Soneium is not supported on Dune at the moment.
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 supported assets can be sent through Superbridge from the mainnet and other rollups that are part of the Superchain. Superbridge connects the canonical, native bridges of the networks that are part of the Superchain through the UI.
The team has also deployed the Standard USDC Bridge for OP Stacks, which allows the bridged USDC to be upgraded to native, preventing asset fragmentation problems across chains.
Generic messaging: Soneium 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 Soneium’s default bridging mechanism, Chainlink CCIP infrastructure is also available on Soneium, and 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, Soneium is an optimistic rollup using the OP stack that still inherits Ethereum’s base security. It also uses a modular architecture, separating its executor settlement and data availability components into independent layers.
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, Soneium 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)
Soneium controls the upgradability of the Standard USDC Bridge for the OP Stack L2OpUsdcBridgeAdapterProxy (contract) through a Safe 2-of-4 contract (on both mainnet and the L2).
Regarding the assets, USDC is also upgradable by the same Safe 2-of-4, while wstETH and stETH are by the OptimismBridgeExecutor.
The team has confirmed that they’re following the standard USDC bridge deployment procedures. The ownership of the bridge and USDC will be transferred to Circle once Soneium qualifies for native USDC support.
Regarding the OP stack contracts on the L2, Soneium controls the upgradeability through the ProxyAdmin, which is owned by an EOA (0x6B1B…4E3b) that belongs to the OP security council. This ownership model is followed across the Superchain ecosystem. More information can be found in the OP ProxyAdmin documentation here.
While this setup doesn’t use timelocks for upgradability, given the technology’s early stage, it is relatively similar to other L2 networks.
3.12.3. Security audits
Soneium audits can be referred to the OP audit reports as part of the superchain ecosystem. Apart from those, the security review of the USDC bridge can be found here.
3.12.4. Commitment to security incidents
A communication channel will be maintained between Soneium and the assigned technical team of the Aave community (e.g., BGD) for any necessary updates concerning the network and, consequently, Aave on Soneium.
3.12.5. Transaction Lifecycle
Soneium 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.6. Data availability
As Soneium 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, Soneium 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 Soneium, it is clear that it is similar to other OP chains, such as Optimism itself and Base, because it is part of the Superchain.
Soneium uses a stable version of the op-geth release 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.
Soneium submits transactions using a single sequencer, as the OP Stack currently allows only one active sequencer at a time.
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.
Soneium recently underwent the Minato Pectra upgrade of its Testnet (Soneium Minato), which aligns with Ethereum’s Pectra hard fork on Ethereum Sepolia. The upgrade on the mainnet is to be defined as soon as it goes live on the Ethereum mainnet, which shows Soneium’s commitment to the Superchain alignment.
Given its infrastructure components, we can conclude that Soneium’s behavior would be very similar to Optimism, with minimal to no differences from it.
4. Summary
From our analysis, we conclude that Soneium, even in a relatively early stage, is an acceptable network candidate in terms of technical requirements, with no current hard blockers for the Aave v3 (v3.3) protocol to work properly.
An expansion of Aave to Soneium 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.