Following our framework of Aave’s infrastructure evaluation and the positive signaling by the community on forum, we present the analysis of the Mantle network, regarding its suitability to deploy an instance of the Aave v3 (v3.3) protocol.
DISCLOSURE. This is an independent assessment of different technical components that we consider important for the Aave software to run optimally, not a categorical analysis stating the network is “good” or “bad”, and no kind of “requirement” for Aave to be deployed on the candidate network. That decision is up to the Aave governance, no matter our opinion.
In addition, currently, we have no financial/investment/services-engagement/any kind of interest in the Mantle ecosystem.
Report
1. Introduction to Mantle
Mantle is a Layer 2 blockchain built in a modular architecture, using an Ethereum-anchored optimistic rollup architecture but a separate data availability layer to provide cheaper and faster transactions while inheriting Ethereum’s L1 security.
High-level characteristics of Mantle are:
- Inherits Ethereum security from its optimistic rollup nature.
- Mantle separates the execution transaction, consensus, settlement, and storage from the same network layer into individual modules as a modular chain.
- It provides independent DA modules, such as Mantle DA, powered by EigenLayer’s EigenDA technology.
2. Our methodology
This report is not trying to be a full analysis of the Mantle network, instead focusing on the aspects important to the Aave community should it decide 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. But 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, amongst others.
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 that having Chainlink providing oracles, especially for prices, is a must for any deployment, with alternatives only considered on an ad-hoc basis, given the additional complexity added on evaluation/integration.
3.1.1. Price feeds
Used by the Aave protocol to price listed assets
Mantle HAS Chainlink price feeds as for now.
There are other oracle providers but we would only recommend launching with Chainlink oracles.
3.1.2. L2 Sequencer Uptime feed
A “flag” parameter indicating in real-time to the Aave protocol if the sequencer of a rollup (or any network involving some centralisation on sequencing of transactions) is properly running.
Mantle HAS Chainlink L2 sequencer uptime feed.
3.1.3. Proof-of-Reserve feeds
Component indicating to the Aave protocol if the reserves backing an asset are healthy.
Mantle DOESN’T HAVE Proof-of-Reserve feeds at the moment.
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 Mantle can be found at https://mantlescan.xyz/, and it is a white-labeled instance of Etherscan.
Also, there are Blockscout, Routescan and Socialscan instances available.
3.3. Compatibility with the 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 Mantle in this case.
Mantle HAS compatibility, with the main node being op-geth and two custom methods. It’s worth mentioning that eth_getAccounts and eth_sendTransaction are not supported for security reasons, needing an external wallet service and using eth_sendRawTransaction as an alternative, respectively.
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 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.
Mantle 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.
Mantle HAS an official endpoint at https://rpc.mantle.xyz.
Third-party RPCs are also available by DRPC, Allnodes, 1RPC, QuickNode, ZAN node and Alchemy.
3.6. Custom behaviour (lack of) of the execution layer
Whenever a network has custom/extended behavior concerning Ethereum, it is important to be aware of it and evaluate if it has any impact on the Aave protocol.
Examples of this potential behavior are the presence of new pre-compiles (compared with Ethereum or similar rollups like Optimism), EVM opcodes, native account abstraction/meta-transactions, chainId definition out of the norm, etc.
- The
chainIdbehavior is appropriate, with the id5000for Mantle not clashing with any other. - Currently, Mantle doesn’t support the Cancun EVM version. The Mantle Team has confirmed that it is expected to support it within this year (2025).
- Some opcodes (
COINBASE,DIFFICULTY,NUMBER,TIMESTAMP,ORIGIN,CALLER) behave differently from L1. See in the Mantle opcode docs. - The opcodes
TLOADandTSTORE(EIP-1153),MCOPY(EIP-5656),BLOBHASH(EIP-4844), andBLOBBASEFEE(EIP-7516) are not supported by Mantle. - Block generation is transaction-independent and has a fixed time (2s) to generate blocks.
3.7. Support of wallet providers
Wallet products like Rabby, Metamask, Ledger, Coinbase Wallet, and others, are fundamental pieces of the infrastructure for 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, Mantle is supported by the majority of chain-agnostic EVM wallets.
3.8. On-chain multi-signature infrastructure
The permissions on the Aave ecosystem are directly held by on-chain governance smart contracts or scheduled to be like that once cross-chain governance infrastructure can be applied across all the networks.
However, different protection/emergency mechanisms, like the capability of canceling cross-chain governance proposals, or pausing an Aave asset/pool, depend on the Aave Guardian, who is capable of acting faster than the governance process.
Consequently, having on-chain multi-signature contracts is a requisite to have Aave on a different network, with a high preference for industry-standard tools like Gnosis Safe.
Mantle HAS an official instance of the Gnosis Safe contracts on-chain, supported natively inside the official 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 good part of the tooling around Aave depends on simulations by using different libraries/frameworks like 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 Mantle:
- Tenderly has support for Mantle.
- Phalcon simulator has support for Mantle.
- Foundry and Hardhat are supported on Mantle.
3.10. Chain data/indexing solutions
For different projects and entities integrating Aave, and even if not a blocker for deployment, it is important that solutions like TheGraph or Dune are operating on the candidate network, to avoid building from scratch data pipelines.
Mantle is supported on multiple data-indexing solutions, including Dune. However, it does not support TheGraph.
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.
Mantle has proper bridge infrastructure for both transferring assets and generic messaging. Concerning the functionality of Governance V3 and a.DI, their native bridge supports cross-chain messaging, and other bridges such as LayerZero and Hyperlane.
3.12. Commitment in security-incidents
Having proper mechanisms and procedures to prevent and react to security incidents is something quite fundamental for any platform and application, and networks like Mantle are no exception.
A private channel of communication will be kept between the Mantle network and the assigned technical team of the Aave community (e.g., BGD) for any necessary updates concerning the network and, consequently, Aave on Mantle.
3.13. 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 the control over the network; decentralization degree).
Regarding its morphology/type, Mantle is an optimistic rollup 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.13.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.
Mantle Network has designed the Forced Transaction Inclusion mechanism. In extreme situations where the system encounters insurmountable issues, the Forced Transaction Inclusion allows a secure rollback to L1, ensuring the safety of user assets. More about the mechanism can be found HERE.
3.13.2. Upgradeability and control model (decentralisation)
Mantle controls the upgradeability of the core contracts, and message and asset bridges, through a proxy admin controlled by their 6-of-13 Council multisig. This setup is not protected by any timelocks, which we believe represents a significant point of centralization within the system. The addresses can be found here.
Given the early stage of the technology, this control is relatively similar to other L2 networks.
3.13.3. Security audits
Mantle security audits can be found HERE.
3.13.4. Transaction lifecycle
Mantle provides extensive documentation regarding the transaction lifecycle that can be found here. But summarizing:
- Users send signed transactions through available RPC nodes.
- The sequencer receives transactions and packs them into blocks. op-batcher obtains data from the sequencer, performs encoding and compression, sends it to the DA module, and submits data validity information to the L1 contract.
- op-proposer obtains the state root of packed blocks through the sequencer and sends it to the relevant contract L2OutputOracle on L1.
- Rollup transaction data is stored on Mantle DA.
3.13.5. Data availability
Mantle uses EigenLayer for data availability. Compressed transaction data is stored and made accessible to Ethereum validators for verification. This is achieved through the re-staking mechanism using their staked ETH as collateral and complying with additional performance conditions.
4. Summary
From our analysis, we conclude that Mantle, even if in a pretty early stage, is an acceptable network candidate regarding technical requirements, with no current hard blocker for the Aave v3 (v3.3) protocol to work properly.
An expansion of Aave there will imply allocating some development resources for both the initial setup, together with some overhead of maintenance and monitoring over time, similar to other networks.
Same as with other rollups, there is an important degree of centralization, but this is expected given the early stage of this technology.
As the Chainlink oracles on Mantle still need to be deployed, we recommend waiting for them to be deployed for a safe integration.