BGD. Aave <> Mantle. Infrastructure/technical evaluation

[bgdlabs]

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:

1. Verifiable smart contract code visualization.
2. Read/write interface with smart contracts.
3. 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 chainId behavior is appropriate, with the id 5000 for 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 TLOAD and TSTORE (EIP-1153), MCOPY (EIP-5656), BLOBHASH (EIP-4844), and BLOBBASEFEE (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:

1. Users send signed transactions through available RPC nodes.
2. 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.
3. op-proposer obtains the state root of packed blocks through the sequencer and sends it to the relevant contract L2OutputOracle on L1.
4. 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.

[mathman314]

Thank you for the thorough evaluation. If it matters, another consideration may be Mantle’s move from an optimistic rollup to a ZK validity rollup/validium which uses Succinct’s SP1.

https://www.mantle.xyz/blog/announcements/mantle-network-advances-technical-roadmap-as-the-first-zk-validity-rollup-with-succincts-sp1

Testnet has already launched.
https://www.mantle.xyz/blog/announcements/op-succinct-mantle-network-testnet

[bgdlabs]

BGD. Aave <> Mantle Infrastructure/technical re-evaluation

Following the recent Everest and Skadi upgrades on the Mantle network, we have re-evaluated the network as we approach closer to the deployment timeline. There are no hard blockers for the deployment of the Aave protocol (v3.6), but crucial to consider the following changes:

3.3. Compatibility with Ethereum RPC standard (Update)

With the recent Skadi hardfork, there have been adjustments to the logic of the eth_maxPriorityFeePerGas RPC method to provide more dynamic and accurate fee suggestions. In addition, there is a new RPC method, optimism_safeHeadAtL1Block, that allows developers to query the safe head state at a specific Ethereum L1 block. Both changes are positive for the protocol.

3.6. Custom behaviour (lack of) of the execution layer (Update)

The opcodes, which were previously not supported, including TLOAD, TSTORE (EIP-1153), MCOPY (EIP-5656), BLOBHASH (EIP-4844), and BLOBBASEFEE (EIP-7516), are now supported with the latest hardfork. In addition, Mantle plans to add support for the CLZ opcode via Limb Upgrade soon, which is already live on the Mantle Sepolia testnet, to align with the Osaka EVM Ethereum spec, which is positive.

3.13. Network security/technical model (Update)

Following the network upgrade on September 16, 2025, Mantle transitioned to a ZK validity Layer 2 from Optimistic rollup via OP Succinct. OP Succinct is a project by Succinct Labs that helps OP Stack rollups migrate to a zkEVM rollup using SP1 with minimal changes. The only notable change in the technical model is in the op-proposer component of the OP Stack, which posts a state root to Ethereum at regular intervals to capture the L2 state; the rest is the same.

3.13.4. Transaction lifecycle

Following the transaction to ZK validity proofs using OP Succinct, the transaction lifecycle is similar to the previous, with the only notable change being that:

• op-proposer instead of obtaining the state root of packed blocks through the sequencer and sending it to the L2OutputOracle now sends it to the MantleSuccinctL2OutputOracle contract alongside the ZK validity proofs.

Below you can see the change in the transaction workflow, with the only change in the op-proposer component:

3.14. 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 Mantle, it shares foundational similarities with OP Stack chains while introducing unique architectural features:

• Mantle uses a fork of op-geth as its execution client, while ensuring compatibility with OP Stack chains like Optimism, Base, and the broader Superchain ecosystem.

• Pre-compiled contracts and cross-chain communication addresses follow OP Stack standards, with no custom behavior expected for smart contract execution.

• The sequencer model follows the current OP Stack pattern of a single active sequencer.

• 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.

• Block generation is transaction-independent with a fixed 2-second block time, consistent across OP Stack chains.

Key differences from OP Stack:

• ZK Validity Rollup: Following the network upgrade, Mantle transitioned from an optimistic rollup to a ZK validity rollup using OP Succinct. The ZK validity proofs reduce withdrawal finalization from 7 days to approximately 12 hours on the canonical bridge.

• Independent Data Availability: Unlike most OP Stack chains that post data to Ethereum via blobs, Mantle uses EigenLayer’s EigenDA as the DA layer.

• Native Token Architecture: MNT operates as a native L2 asset rather than a bridged ERC-20 token. This differs from most OP Stack chains where the native token is typically ETH.

• Fee Optimization: Mantle implements a fee optimization strategy using the tokenRatio parameter to adjust the impact of using MNT as transaction fees, with optimized estimateGas function for total transaction cost estimation.

Given its infrastructure components, we can conclude that Mantle’s behavior would be similar to Optimism, with minimal differences from it.

From our re-evaluation, we conclude that Mantle, following the network upgrade to OP Succinct, in regard to technical requirements, is an acceptable network candidate with the only changes to analysis as mentioned above.