[ARFC] Onboard MNT, mETH, cmETH as collateral assets on Aave v3 Mantle Instance

[ACI]

[ARFC] Onboard MNT, mETH, cmETH as collateral assets on Aave v3 Mantle Instance

Author: ACI & Tokenlogic

Date: 2025-04-11

---

Summary:

We propose listing Mantle (MNT), Mantle Staked ETH (mETH), Mantle Restaked mETH (cmETH) tokens as collateral assets on Aave v3 instance on Mantle Network.

Motivation:

This would enable Mantle’s core users to leverage their assets, borrowing familiar assets that are key to the Mantle ecosystem to participate in DeFi activities. Listing these assets as collateral is expected to drive increased borrowing activity and user engagement on Mantle Network.

We believe that listing Mantle’s core ecosystem assets are crucial in the success and future growth of Aave’s native deployment on Mantle Network. Deploying with these Mantle-native markets will enable Aave to effectively tap into a whole new Asian market segment and new APAC user flows coming in from both Mantle Network and Bybit.

Chain to be listed:

Aave V3 Mantle Instance.

Specification

Risk Parameters and final configuration will be updated by Risk Service Providers and ARFC will be updated accordingly.

Disclaimer:

ACI is independent and has not received any form of compensation from related parties for the drafting of this proposal.

Next Steps:

1. Publication of a standard ARFC, collect community and service provider feedback before escalating the proposal to the ARFC Snapshot stage.
2. If the ARFC Snapshot outcome is positive, publish an AIP vote for final confirmation and enforcement of the proposal.

Copyright:

Copyright and related rights waived under CC0.

[LlamaRisk]

Summary

As this ARFC onboards 3 assets at once, LlamaRisk has conducted 3 separate asset reviews. Each is detailed in full below.

WMNT

LlamaRisk supports listing WMNT on Aave. MNT—the token wrapped by WMNT—serves as Mantle’s gas and governance tokens. Its L1 contract is controlled by a 6‑of‑13 multisig that can mint up to 2% of supply annually and transfer ownership without a timelock. The base token has an OpenZeppelin audit, yet the wMNT wrapper diverges from canonical WETH, is unaudited, and lacks bug‑bounty coverage.

Liquidity is constrained. A single $2.5 M swap moves price about 10%, far shallower than other L2 gas‑token markets, and nearly all depth sits in two USDe pools (Merchant Moe and Agni) funded almost entirely by Mantle Treasury. Although withdrawals require a DAO vote, this concentration could still trigger a sudden liquidity shock and hinder liquidations.

Given these access‑control, contract, and liquidity risks, WMNT should launch with low supply and borrow caps, tight liquidation settings, and periodic reviews that scale exposure only as Mantle decentralizes and market depth improves.

mETH and cmETH

LlamaRisk recommends postponing the onboarding of mETH and cmETH until Mantle’s liquidity and overall maturity improve. A 200 mETH swap moves the price by more than 5%, while 150 cmETH results in about 20%; most depth sits in a single Merchant Moe pool, and one address supplies nearly 80% of cmETH liquidity. Although Ethereum mainnet holds roughly three times more volume, that liquidity would still need to be bridged before it could backstop Mantle‑side liquidations.

Both tokens are governed by custom, un‑timelocked 6‑of‑13 multisigs whose relationship to the largely unused COOK governance token remains opaque. mETH has five audits and a $500K Immunefi bounty, but cmETH lacks a bounty and adds extra restaking complexity through PositionManagers, EigenLayer, Karak, Symbiotic, and off‑chain reward handlers.

Until on‑chain depth expands significantly and governance protections mature, listing these assets would expose Aave to outsized market and counterparty risk.

Detailed assessments

MNT Review

MNT Review

1. Asset Fundamental Characteristics

1.1 Asset

wMNT is an ERC20-compatible representation of the native MNT token at address 0x78c1b0C915c4FAA5FffA6CAbf0219DA63d7f4cb8. This contract was deployed in July 2023, close to when the network went live. This asset similarly wraps the native MNT token to how WETH wraps ETH, allowing it to be used in smart contracts. MNT is the native token of the Mantle network, which is used to pay for gas on the L2. In this way, it, too, is analogous to ETH on Mainnet. This network-specific native asset class and the wrapper are widely onboarded across Aave instances.

1.2 Architecture

Users may wrap MNT or unwrap WMNT at any time 1:1 and zero cost. This makes the wrapped asset essentially analogous to MNT. MNT is the native gas token of the Mantle network and is used to vote in Mantle governance.

1.3 Tokenomics

This asset is a 1:1 wrapper of $MNT, so it inherits its tokenomics. The $MNT token started as $BIT, which was migrated to $MNT on the launch of the Mantle network. Half of $ MNT’s 6,219,316,794 supply is circulating, with the other half held in Mantle DAO’s treasury.

1.3.1 Token Holder Concentration

Source: WMNT Token Holder Distribution, MantleScan, April 11th, 2025

WMNT is highly concentrated, with four addresses controlling almost 80% of the supply. When looking at these holders, these large holders are smart contracts. The leading holder is a Merchant Moe liquidity pool, the second largest is an AGNI pool, and the third largest is a Lendle lending pool. This reduces the risk somewhat, as these large holders are not owned by individual EOAs that may exit in size rapidly.

2. Market Risk

2.1 Liquidity

Source: wMNT-USDT swap, Odos, April 11th, 2025

Neither WMNT nor MNT is highly liquid, with a $2.5M trade resulting in almost 10% price impact. This presents a risk to Aave and results in a constrained supply cap recommendation.

2.1.1 Liquidity Venue Concentration

As detailed above, much liquidity is held on either Agni or Merchant Moe. Most of this route is equally balanced between the two DEXs and routed largely through USDe. This presents risks regarding whether USDe liquidity should dry up or whether these DEXs should suffer an incident under which they no longer function. This asset’s generally low liquidity level presents a risk to Aave.

2.1.2 DEX LP Concentration

WMNT LP concentration is very high, with the majority supplied by just two EOAs across the two main pools. This concentration poses a significant risk, as a sudden withdrawal by either entity could trigger a liquidity shortfall. Below is the breakdown (as of April 17, 2025):

• Merchant Moe USDe/WMNT ($7.7M TVL): 100% of the pool’s liquidity is supplied by an EOA. Mantle’s treasury controls this EOA.
• Agni Finance USDe/WMNT ($5.7M TVL): The top liquidity provider is another EOA, holding 99.99% of the pool’s liquidity. Mantle’s treasury also controls this address.

The nature of these addresses (DAO treasury) means that liquidity is unlikely to be pulled, but given that it is theoretically possible that it may risk is still present. This liquidity would likely only be removed after a lengthy DAO approval process, giving Aave sufficient time to adjust markets accordingly.

2.2 Volatility

Source: Mantle Token, Coingecko, April 11th, 2025

Mantle and WMNT experience an elevated level of volatility, with large swings within a relatively tight $1.50 to $0.25 range being documented. Large intraday price increases and drops are displayed, indicating high volatility.

2.3 Exchanges

Source: Mantle Token, Coingecko, April 11th, 2025

Mantle is available on a wide number of Asia-based centralized exchanges. It enjoys significant volume.

2.4 Growth

Source: Mantle Token, Coingecko, April 11th, 2025

Mantle’s market capitalization has maintained a ±$2B valuation for its duration, with some volatility in between. It is a direct function of the token’s price, as new tokens are not being introduced through inflation.

WMNT has an onchain market capitalization of 22.5M MNT, which has been slowly increasing as Mantle’s DeFi network continues to mature.

3. Technological Risk

3.1 Smart Contract Risk

No smart contract audits are documented for WMNT. There are substantial contract differences between WETH and WMNT. Smart contract risk is, therefore, difficult to verify, meaning it is moderate on the MNT contract on ETH L1, the OpenZeppelin audited deployment, which found only low severity issues. This lowers smart contract risk.

3.2 Bug Bounty Program

No bug bounty program for WMNT or MNT is detailed.

3.3 Price Feed Risk

An MNT/USD Chainlink feed is available. It is a market price feed. Since WMNT and MNT are 1:1 redeemable at all times for free, this is a suitable oracle for this use case.

3.4 Dependency Risk

The wrapper contract for this asset is the sole dependency introduced by adding WMNT. MNT is a core pillar of the Mantle network, so its use as collateral on Aave presents a limited incremental risk to the protocol. If Aave is deployed on Mantle, it already assumes significant dependency on the network and, therefore, the MNT token. The incremental dependency risk posed by MNT itself is, therefore, low.

4. Counterparty Risk

4.1 Governance & Regulatory Risk

MNT is both the native gas token of Mantle Network and the governance token of the Mantle DAO. The overall governance framework is described in MIP‑31, yet practical participation is still light, with major decisions to date centering on high‑profile proposals such as the Enhanced Index Fund in MIP‑32.

Despite having a published structure, the documentation does not delineate which subjects must be decided by token‑holders and which remain at the discretion of the core team. Nor is there a well‑defined mechanism for token‑holders to originate and shepherd new proposals through the process. This lack of clarity leaves room for unexpected policy shifts or governance deadlock. Either scenario could impair the perceived utility and, therefore, the market value of MNT—and, by extension, WMNT—introducing collateral risk to Aave if the token is abruptly repriced.

The legal analysis conducted as part of Aave v3’s initial deployment review ([ARFC] Deploy Aave v3 on Mantle - #3 by LlamaRisk) is still valid. To strengthen our regulatory assessment, we have requested from Mantle any legal opinions, non‑action letters, or comparable confirmations regarding MNT, mETH, and cmETH. Once these materials are received, our team will evaluate them and circulate the findings to all relevant stakeholders.

4.2 Access Control Risk

The WMNT contract does not employ access controls. The MNT mainnet token contract (where the token was deployed) employs access controls on critical token parameters.

4.2.1 Contract Modification Options

The MNT contract owner may modify the following functions:

• Contract ownership
• Token supply via minting additional tokens within a yearly mint cap (hardcoded to <2% of existing supply)

These are significant potential changes that may result in the value of an individual token being repriced rapidly should they be utilized without due process and clear communication.

4.2.2 Timelock Duration and Function

No timelock is documented on the MNT contract. This presents risk given the above change capacities - especially upgradeability.

4.2.3 Multisig Threshold / Signer identity

The MNT contract is owned by a 6/13 Safe with the following signers:

• 0xf73546Da2F971bD0Ed1b3c5F9C01092180Db5089
• 0x61Af7a48B0EeA8481E5A055A35f829d0e8505fE3
• 0x50dCf0B40E593301aA75DcB54f36f379607595CE
• 0xA3C8f55BE8aF7402d5192b343E8BfE4BB9795C2F
• 0xdC3644e172813ADbF6D130262e2416975Ac48Af3
• 0x4A42577Bf6e51127c490F3639F5c8B90Ec53f5B1
• 0x4b6CFecA60f8BDF8AbCEE10f033f17cb2a928498
• 0x3Dc5FcB0Ad5835C6059112e51A75b57DBA668eB8
• 0xf5b16239f88B54894e03e0293d3d7FDdEb9f9070
• 0xe75D7324d6BC4E70A200c5E268160332F43b2d2B
• 0x3000BE80ad204D327990eB403654aCd1Eaa8eCeb
• 0xc4143711aA5bd6d37F1b0A690120AA5859e32A93
• 0x915dc866e2e5E64f912A5ac1D40E3be4597F172a

Given the large number of signers with a non-majority threshold and the lack of timelock on a contract with significant modification options, it is fair to say that MNT (not WMNT) has significant access control risk.

mETH Review

mETH Review

1. Asset Fundamental Characteristics

1.1 Asset

Mantle ETH (mETH) is a liquid-staked Ether token. It is an ERC20 compliant token deployed in October 2023 with an onchain market cap of ±367,300 ETH. It was deployed natively on mainnet, with stakers receiving a receipt token for the ETH staked on the L1. It was then migrated to Mantle network. This token is non-rebasing, meaning the number of tokens a holder keeps in an address will not increase. Instead, it will increase in value as it entitles a holder to a fixed share of the ETH staked through Mantle validators.

1.2 Architecture

Source: mETH Architecture, mETH Docs

Users send or receive ETH / mETH to a staking contract, which programmatically transfers the ETH to the Ethereum Beacon chain to be distributed to node operators. A ConsensusLayer Receive and an ExecutionLayer Receiver contract aggregate revenue generated by the staked ETH and pass it to the Staking Contract. This increases the value of the ETH held in the staking contract, thereby increasing the exchange rate. Of note are security roles included in the diagram, such as the pausers, guardians, and Mantle Security Roles.

1.3 Tokenomics

As a non-rebasing token, Aave protocol should face no risk from onboarding this type of token. The vault to which users own shares increases in a predictable way similar to that of stETH or RETH, who have successfully onboarded to the mainnet core.

mETH is controlled by governance token COOK with a current circulating supply of 960,000,000 of 5,000,000,000. Currently, there is no visibility on mETH governance processes, making the utility of COOK difficult to verify. Uncertainty is introduced without clarity on what aspects of this LST COOK may change and how those changes are made.

1.3.1 Token Holder Concentration

Source: mETH holders, MantleScan, April 14th, 2025

Mantle ETH is relatively distributed should you ignore two holders controlling more than 50% of the supply. The largest holder is a ByBit CEX address, and the second largest holder is also an address controlled by ByBit. ByBit is unlikely to own all of this mETH, meaning ownership is more fragmented than this chart may indicate.

2. Market Risk

2.1 Liquidity

Source: mETH to USDe, Odos Router, April 15th, 2025

mETH liquidity is extremely limited, with a 200 mETH swap resulting in more than 5% price impact.

2.1.1 Liquidity Venue Concentration

This liquidity is relatively fragmented, with the majority of the mETH swapped through the Merchant Moe mETH-WETH pool, which has $580K TVL.

Source: mETH/WETH, Merchant Moe, April 17, 2025

This liquidity situation is hampered by pool balance, which decreases trading efficiency and, therefore, incentives to provide liquidity.

Source: mETH DEX pools, GeckoTerminal, April 17, 2025
Leading pools include Agni ($200K 24H volume), Merchant Moe ($325K 24H volume), and Cleopatra ($52K 24H volume).

2.1.2 DEX LP Concentration

Source: mETH/cmETH Merchant Moe pool concentration, Debank, April 17 2025

DEX liquidity on the mETH/WETH pool is very distributed, with the largest users supplying no greater than 12% of the pool. This reduces risk, as all liquidity is unlikely to be removed and cause a liquidity shortfall event. This is unlikely to jeopardize the profitable liquidation of Aave in its current state.

2.2 Volatility

Source: mETH/wETH, DexScreener, April 17 2025

mETH has continued to appreciate in a predictable fashion relative to the price of ETH, which is expected. A brief, significant depeg event was noted in late February 2025, where the asset fell to a ratio of 1.02 mETH per WETH, though this was quickly arbitraged.

This degree of irregular volatility presents some degree of risk to the protocol, especially should leverage looping be one of the primary use cases of this asset.

2.3 Exchanges

Source: Coingecko Exchanges, Coingecko, April 15 2025

mETH is traded on ByBit and a variety of Mantle-specific decentralized exchanges

2.4 Growth

Source: mETH Protocol, Mantle-xyz via Dune, April 15, 2025

The amount of mETH is decreasing, especially on the Mantle network. Roughly 40,000 mETH are currently on the network, down from a peak of ±160,000.

3. Technological Risk

3.1 Smart Contract Risk

Mantle ETH has been audited multiple times.

• Hexens (August 2023) found 3 high, 6 medium, and 5 low severity issues
• Hexens (September 2023) found 3 high and 4 low severity issues
• MixBytes (November 2023) found 3 high and 4 medium severity issues
• Secure3 (October 2023) found 1 critical, 20 medium, and 12 low severity issues
• Secure3 (October 2023) found 2 critical, 3 medium, and 6 low severity issues
• Verilog (November 2023) found 2 low severity issues

The number of these audits and the slight decrease in the frequency of detected issues indicates a serious approach to smart contract security, which helps mitigate risk.

3.2 Bug Bounty Program

mETH is covered by a $500K bug bounty program. This lowers smart contract risk.

3.3 Price Feed Risk

While Chainlink feeds currently operate on this network, mETH does not yet have a price feed solution. Querying the value of 1 mETH on the L2 is complicated as the staking vault is on the ETH mainnet, and the actual ETH itself is on the Beacon chain. The mainnet mETH contract does not have a ratio function to call. The mETH Oracle contract has a function "latestRecord "that may be called to price the asset.

The relative complexity of the setup across different networks results in a system not without risk.

3.4 Dependency Risk

This architecture presents few incremental dependencies that Aave is not already exposed to given it is live on Mantle and has onboarded many LSTs.

Key incremental risks introduced focus on the security roles (more in section 4) and the node operators selected by Mantle. Their continued compliance is important, so dependency risk is high when onboarding this asset.

4. Counterparty Risk

4.1 Governance and Regulatory Risk

mETH is governed by the governance token COOK, which is deployed to the mainnet. It is not evident that COOK has been used in a vote at this time, calling into question its utility as a governance token. With unclear governance procedures come uncertainties, which in turn produces risk. With no clarity on how governance functions for this asset, it is difficult to evaluate governance risk.

The documentation mentions Guardians but declines to elaborate on their roles or capacities. This puts significant control into the hands of the mETH team and places large dependencies on their continued competence and compliance. This risk is mitigated by limited contract modification options (see next section), but the limited transparency and lack of clear framework results in risk.

4.2 Access Control Risk

mETH access control configurations are complex and unique in structure. Their unclear layout is nonstandard, which may result in reviewers missing potential vulnerabilities. This increases risk in an area that ideally has none.

4.2.1 Contract Modification Options

Mantle has produced a high-quality document that outlines different modification options and explains their relevance.

This mETH contract owner may:

• Upgrade the contract of mETH on L1 and L2
• Change ownership of the contract
• Modify Oracle roles
• Pause the contract
• Modify the stake operators
• Unstake the ETH

These are significant permissions that present a high risk.

4.2.2 Timelock Duration and Function

A timelock is documented. Unfortunately, it is not in use with the "getMinDelay " function set to 0. This does nothing to decrease the level of risk, which is considerable.

4.2.3 Multisig Threshold / Signer Identity

mETH ownership multisig signers are listed in Mantle documentation. This page is of excellent quality, and other projects would do well to emulate it.

Two multisigs control the most critical of roles:

• MSEC Council 1 - a 6/13 Safe with one proposer.
• MSEC Council 2 - a 6/13 Safe (which is unverified on Mantle, limiting transparency into ownership).

MSEC Council 1 is responsible for upgrading the oracle, owning the pause contracts, controlling the staking operation, and upgrading the L1 mETH token. MSEC Council 2 is responsible for upgrading mETH on L2.

The mainnet MSEC Council 1 consists of the following signers:

• 0xf73546Da2F971bD0Ed1b3c5F9C01092180Db5089
• 0x61Af7a48B0EeA8481E5A055A35f829d0e8505fE3
• 0x50dCf0B40E593301aA75DcB54f36f379607595CE
• 0xA3C8f55BE8aF7402d5192b343E8BfE4BB9795C2F
• 0xdC3644e172813ADbF6D130262e2416975Ac48Af3
• 0x4A42577Bf6e51127c490F3639F5c8B90Ec53f5B1
• 0x4b6CFecA60f8BDF8AbCEE10f033F17cb2a928498
• 0x3Dc5FcB0Ad5835C6059112e51A75b57DBA668eB8
• 0xf5b16239f88B54894e03e0293d3d7FDdEb9f9070
• 0xe75D7324d6BC4E70A200c5E268160332F43b2d2B
• 0x3000BE80ad204D327990eB403654aCd1Eaa8eCeb
• 0xc4143711A5bd6d37F1b0A690120AA5859e32A93
• 0x915dc866e2e5E64f912A5ac1D40E3be4597F172a

cmETH Review

cmETH Review

1. Asset Fundamental Characteristics

1.1 Asset

cmETH is Mantle Restaked ETH. It is an ERC20-compliant restaked ETH token deployed in August 2024. It was deployed natively on the mainnet network, with stakers returning a receipt token for the mETH restaked on the L1. It was then migrated to the Mantle network.

Yield is reportedly generated in the following ways:

• Yield from ETH Proof-of-Stake validation (provided via the underlying $mETH)
• Yield from restaking protocols (e.g., EigenLayer, Symbiotic, Karak, etc.)
• Yield from Actively Validated Services (AVS)
• $COOK rewards (multiple seasons)
• Other technology partner rewards
• Yield from L2 dApps and Protocol Integrations

This token is non-rebasing, meaning the number of tokens a holder keeps in an address will not increase. Instead, it will increase in value as it entitles a holder to a fixed share of the ETH staked through Mantle validators.

This is a familiar asset to the Aave network and presents a limited incremental risk to the protocol. Restaked assets are often high-risk assets and should be parameterized accordingly.

1.2 Architecture

Source: Architecture, cmETH documentation

Users move from mETH to cmETH either through a DEX or a restaking contract on the mainnet. cmETH uses Veda’s BoringVault architecture, similar to EtherFi. After sending mETH to this vault, it is then allocated to a PositionManager, who restake the mETH for various uses.

In exchange, they receive not only native ETH staking yield but also yield generated by the PositionManager’s selected revenue strategies. This architecture introduces significant dependencies that the PositionManager selects. The limited visibility of these strategies results in architectural risk.

1.3 Tokenomics

cmETH is paired 1:1 with mETH, meaning users must collect rewards independently (as opposed to how ETH rewards are streamed to a vault that mETH holders are entitled to a share of). This straightforward accounting structure results in limited tokenomic risk.

cmETH, like mETH, is controlled by $COOK. Currently, there is no visibility on mETH governance processes, making the utility of COOK difficult to verify. Uncertainty is introduced without clarity on what aspects of this LST COOK may change and how those changes are made. This, in turn, introduces risk.

1.3.1 Token Holder Concentration

Source: cmETH token holder distribution, Mantlescan, April 16, 2025

On the Mantle, cmETH is moderately distributed. Large holders include rewards distributors, Staking contracts, and ByBit exchange addresses.

This level of fragmentation results in limited incremental risk.

2. Market Risk

2.1 Liquidity

Source: cmETH to USDe swap, Odos, 16 April, 2025

cmETH is extremely illiquid. A 150 cmETH to USDe trade results in a 20% price impact. This presents a significant risk to liquidators attempting to cover the liquidity deficit.

Source: cmETH / USDe tick distribution, Merchant Moe, April 16, 2025

This is despite the cmETH pool having $8M of TVL. Unfortunately, the LP positions are out of range so that no trades may be facilitated.

2.1.1 Liquidity Venue Concentration

Source: cmETH DEX pools, GeckoTerminal, April 17, 2025

This routing is relatively distributed, with Merchant Moe V2.2 facilitating most of the trade. Agni also facilitates a smaller percentage, with other minor DEXs helping out.

Interestingly, an FBTC / cmETH pool on Merchant Moe has a relatively high $82K 24H volume for unlike assets, which are (re)staked.

The lack of volume outside of Merchant Moe presents a risk, resulting in dependency on a single, smart contract suite.

2.1.2 DEX LP Concentration

Source: mETH/cmETH Merchant Moe pool concentration, Debank, April 17 2025
DEX liquidity on the cmETH/mETH pool is somewhat concentrated, with one address supplying 78% of liquidity. This presents a risk, as it may be removed and cause a liquidity shortfall event, jeopardizing the profitable liquidation of Aave.

2.2 Volatility

Source: cmETH/mETH, DexScreener, April 17, 2025

cmETH is currently pegged to the price of mETH on the most liquid network-specific trading pool. Minimal depeg events (greater than 0.1%) are documented between the two assets, indicating low volatility risk.

2.3 Exchanges

Source: cmETH Exchanges, coingecko, April 16, 2025

cmETH is traded exclusively on DEXs and Bybit.

2.4 Growth

/S1RVHwp0kl.png)
Source: cmETH Market Cap, coingecko, April 16, 2025

cmETH is currently experiencing a market capitalization shrinkage, roughly in line with ETH’s after a significant rise and fall in mid-December 2024.

3. Technological Risk

3.1 Smart Contract Risk

cmETH has five audits publicly available:

• Verilog (October 2024) found 2 medium and 2 low severity issues
• QuantStamp (September 2024) found 1 medium and 3 low-severity issues
• BlockSec (October 2024) found no potential issues
• Secure3 (September 2024) found 1 medium issue
• Hexens (August 2024) found 1 high, 2 medium, and 2 low severity issues.

This number of audits helps to reduce smart contract risk.

3.2 Bug Bounty Program

cmETH is not covered by a bug bounty program. Related repositories are private, which results in high risk. This is elevated given the amount of different contracts cmETH restakes the mETH into to generate yield.

3.3 Price Feed Risk

There is no Chainlink feed for cmETH; only the fundamental rate is available.

3.4 Dependency Risk

As a restaking protocol, cmETH introduces the following incremental dependencies:

• The PositionManager contract and the various selected restaking strategies (currently using Karak, Symbiotic, Eigen Validator A41, and Eigen Validator P2P) - notably, neither Karak nor Symbiotic restaked assets are currently onboarded to Aave.
• The RewardHandler relies on off-chain computing, which allows users to claim rewards generated through Merkle Trees that must be regularly posted.
• The operators in the LRT systems that choose which AVSs to secure and run the risk of slashing (shortly) should they irresponsibly allocate the assets.

Source: cmeETH PositionManager, cmMETH docs

There are significant dependency risk assumptions introduced with limited visibility on the framework with which underlying mETH is being allocated.

4. Counterparty Risk

4.1 Governance and Regulatory Risk

cmETH, just like mETH, is governed by the governance token COOK, which is deployed to mainnet. It is not evident that COOK has been used in a vote at this time, calling into question its utility as a governance token. With unclear governance procedures come uncertainties, which in turn produces risk. With no clarity on how governance functions for this asset, it is difficult to evaluate governance risk. It is reasonable to presume all cmETH is managed by the Mantle team, placing significant counterparty risk on the asset.

4.2 Access Control Risk

As with mETH, cmETH’s access control configurations are complex and unique in structure. Their unclear layout is nonstandard, which may result in reviewers missing potential vulnerabilities. This increases risk in an area that ideally has none.

4.2.1 Contract Modification Options

cmETH roles and modification abilities are listed.
Key changes that may be made include:

• Any aspect of the restaking vault, including strategies the mETH is allocated to
• The L1 and L2 cmETH contracts itself, including the owner and delegator
• The L1-L2 messaging contracts, including pauser, owners, upgraders, managers, and so on

This introduces the potential for any changes across various cmETH core functionalities. This presents a significant risk.

4.2.2 Timelock Duration and Function

cmETH does not document a visible timelock, and even if it did, it may be set to 0, as with mETH. With this in mind, it is reasonable to say that cmETH’s considerable access control regime is delayed by a timelock. There is mention of an MLSPTimelockL1 , but this is not visible on block explorers.

4.2.3 Multisig Threshold / Signer identity

Core functionalities are largely similar to mETH, with the following roles:

Two multisigs control the most critical of roles:

• MSEC Council 1 - a 6/13 Safe with one proposer.
• MSEC Council 2 - a 6/13 Safe (which is unverified on Mantle, limiting transparency into ownership).

MSEC Council 1 is responsible for upgrading the oracle, owning the pause contracts, controlling the staking operation, and upgrading the L1 cmETH token. MSEC Council 2 is responsible for upgrading cmETH on L2.

The mainnet MSEC Council 1 consists of the following signers:

• 0xf73546Da2F971bD0Ed1b3c5F9C01092180Db5089
• 0x61Af7a48B0EeA8481E5A055A35f829d0e8505fE3
• 0x50dCf0B40E593301aA75DcB54f36f379607595CE
• 0xA3C8f55BE8aF7402d5192b343E8BfE4BB9795C2F
• 0xdC3644e172813ADbF6D130262e2416975Ac48Af3
• 0x4A42577Bf6e51127c490F3639F5c8B90Ec53f5B1
• 0x4b6CFecA60f8BDF8AbCEE10f033F17cb2a928498
• 0x3Dc5FcB0Ad5835C6059112e51A75b57DBA668eB8
• 0xf5b16239f88B54894e03e0293d3d7FDdEb9f9070
• 0xe75D7324d6BC4E70A200c5E268160332F43b2d2B
• 0x3000BE80ad204D327990eB403654aCd1Eaa8eCeb
• 0xc4143711A5bd6d37F1b0A690120AA5859e32A93
• 0x915dc866e2e5E64f912A5ac1D40E3be4597F172a

Source: cmeETH Security roles, Mantle docs

For the strategies used in restaking, both Veda and Mantle individuals manage the allocations. This is in conjunction with a variety of smart contracts. This careful mapping indicates a responsible attitude to access control ownership but introduces risk through the incremental surface area.

---

Note: This assessment follows the LLR-Aave Framework, a comprehensive methodology for asset onboarding and parameterization in Aave V3. This framework is continuously updated and available here.

Aave V3 Specific Parameters MNT

Parameters will be presented jointly with @ChaosLabs.

Price feed Recommendation

For WMNT, we recommend using the Chainlink MNT/USD market feed.

Disclaimer

This review was independently prepared by LlamaRisk, a community-led decentralized organization funded in part by the Aave DAO. LlamaRisk is not directly affiliated with the protocol(s) reviewed in this assessment and did not receive any compensation from the protocol(s) or their affiliated entities for this work.

The information provided should not be construed as legal, financial, tax, or professional advice.

[ChaosLabs]

Overview

Chaos Labs supports listing WMNT on Aave’s Mantle deployment. We do not recommend listing mETH or cmETH at this time. Below, we provide our analysis and recommendations.

Mantle Network Overview

Mantle Network is an Ethereum Layer 2 scaling solution developed by BitDAO, the decentralized initiative supported by the centralized exchange Bybit. It utilizes Optimistic Rollups and a modular architecture to enhance scalability, reduce transaction fees, and maintain Ethereum compatibility. This design separates execution, settlement, and data availability layers, allowing for independent upgrades and improved performance. For a more detailed explanation of the Mantle Network and its architecture, you can refer to our previous analysis.

MNT

MNT is the native utility and governance token of the Mantle ecosystem. It serves a dual purpose:

• Gas Fees: Used to pay for transactions on the Mantle Network.
• Governance: Holders can participate in decision-making processes within the DAO.

Market Capitalization

The MNT token was originally deployed on Ethereum Layer 1 on June 20, 2023, as specified in MIP-23, with a total supply of 6,219,316,768. The DAO retains the option to mint additional MNT in the future to support the continued growth of the ecosystem.

The DAO Treasury currently holds 2,795,022,409.2 MNT (45% of the total supply). Any distribution of MNT from the Treasury requires explicit authorization, primarily through budget proposals.

MNT is one of the top 100 crypto tokens by market capitalization, currently holding a market cap of $2.2 billion and a FDV of $4.1 billion. Over the past 17 months, its market cap has fluctuated between $2 billion and $4.5 billion.

To date, a net total of 318,959,600 MNT has been bridged from Ethereum to the Mantle network, representing 5.1% of the total supply and 9.3% of the circulating supply. This number is expected to grow, particularly with the deployment of protocols like Aave on Mantle Network.

Liquidity

More than 90% of MNT’s on-chain liquidity is managed by the protocol’s treasury. This means Mantle actively oversees protocol-owned liquidity for MNT on both Ethereum and the Mantle Network. All addresses managing these liquidity positions can be found in the Treasury Holdings section of their documentation.

Historically, most of MNT’s on-chain liquidity was paired with ETH on Ethereum. In late February 2025, Mantle migrated its protocol-owned liquidity to the MNT-USDe pair and simultaneously reduced the amount of liquidity deployed on Ethereum and migrated most of the liquidity to Mantle Network.

As a result, MNT’s on-chain liquidity on the Mantle network increased to $15.5 million. Of this amount, $11 million is composed of MNT tokens, leaving just $4.5 million in buy liquidity, which is mostly concentrated in stablecoins—primarily USDe.

With the migration of protocol-owned liquidity to the Mantle network, it’s now possible to trade $2 million worth of MNT into stablecoins with less than 10% price impact. This gives the MNT token deeper liquidity on Mantle compared to Ethereum mainnet. Since this liquidity is owned by the protocol, it also provides a more reliable and sustainable trading environment.

It’s also important to note that MNT’s price discovery primarily occurs on centralized exchanges, with over 90% of its trading volume taking place on platforms like Bybit and MEXC. Together, these two major exchanges offer approximately $2 million in liquidity within a ±2% price range. This setup creates opportunities for CEX-DEX arbitrageurs, who can help deepen on-chain liquidity by capitalizing on price discrepancies between markets.

Volatility

The volatility of the MNT token has been moderately high; however, when compared to other alternative Layer 1 and Layer 2 tokens such as S, AVAX, OP, and ARB, MNT has shown greater price stability over the same period.

Among the group, MNT recorded the lowest maximum drawdown at 13.02%, whereas the others experienced drawdowns ranging from 16.6% to 20.21%.

MNT also exhibited the lowest 30-day daily annualized volatility at 49.23%, while the other tokens’ volatility ranged between 92% and 129%.

This relative stability is particularly notable given MNT’s thinner on-chain liquidity. A key factor contributing to its resilience is the strong backing from Bybit, one of the largest centralized exchanges in Asia. Major market makers operating on Bybit and other CEXs provide deep liquidity and facilitate efficient price discovery, which helps anchor MNT’s market behavior despite limited on-chain liquidity.

Bridging

The MNT token is natively minted exclusively on Ethereum Layer 1. Once minted, it can be transferred to the Mantle Network (Layer 2) via Mantle’s canonical bridge.

Deposits from Ethereum to Mantle are processed through standard rollup mechanisms and typically finalize within approximately 12 minutes, enabling users to access and interact with the Mantle ecosystem with minimal delay.

Withdrawals from Mantle back to Ethereum, however, are subject to a challenge period—a core security feature of Optimistic Rollups. This period, which can last up to 7 days, allows time for the submission of fraud proofs in the event of any invalid state transitions. While this mechanism ensures a trustless and secure bridging process, it also introduces a delay before assets become fully accessible on Ethereum Layer 1.

Supply Cap and Borrow Cap

Although on-chain liquidity for MNT is limited, it is protocol-owned and relatively stable. The token’s price volatility has been moderately lower compared to other alternative Layer 1 and Layer 2 tokens. This relative stability is largely attributed to strong support from Bybit and active market-making by its designated market makers, which help maintain deep liquidity in centralized exchange order books.

Based on these considerations, we recommend setting the MNT supply cap at 15 million.

We also recommend setting the borrow cap slightly above the supply cap’s Uoptimal level, at 7 million MNT.

Oracle/Pricing

We recommend using the MNT/USD Chainlink Price Feed for pricing MNT.

mETH Protocol Overview

The mETH Protocol is a permissionless, vertically integrated solution designed to simplify ETH staking and extend its utility through restaking. Built on Ethereum, the protocol enables users to stake ETH and receive mETH, a liquid staking token that accrues rewards over time.

mETH serves as the base layer of the protocol offering straightforward staking. Redemption (unstaking) of mETH typically involves a ~4-day wait period and carries no fees. However, this wait time is not fixed and can vary depending on network conditions at the Ethereum consensus layer. Specifically, if the global validator exit queue becomes congested—such as during periods of mass exits across the network—the redemption process may take longer. This is because the Beacon Chain currently limits exits to 8 validators per epoch (approximately every 6.4 minutes), meaning large-scale exits can create delays beyond the standard expectation. Regardless of conditions on the Mantle Network, mETH redemption times are fundamentally tied to Ethereum’s consensus-layer dynamics. Additionally, mETH can be freely traded across multiple DeFi venues, enabling liquidity and composability throughout the Ethereum and Layer 2 ecosystems.

Beyond liquid staking, the protocol enables restaking through a secondary asset, cmETH, which is issued when users opt into additional yield-generating opportunities that also carry increased slashing risks. Users who wish to access restaking rewards can convert mETH to cmETH at a 1:1 ratio. To redeem cmETH back to mETH, users must initiate an unstaking process that involves a minimum 8-hour waiting period; however, depending on queue availability and the withdrawal delays imposed by underlying restaking platforms, this period can extend up to 7 days or longer.

These opportunities include restaking on platforms such as EigenLayer, Symbiotic, Karak, and others. This layered structure allows users to choose their preferred balance of risk and return—from base staking yields with mETH to enhanced restaking rewards with cmETH.

Governance, Security Roles, and Upgradeability

The mETH Protocol incorporates multiple mechanisms to safeguard protocol integrity, manage upgradeability, and address critical events through role-based permissions and multisig governance.

The Security Council—a group of designated addresses with elevated privileges—operates as a 6-of-13 multisig without a timelock and is responsible for overseeing both the mETH and cmETH contracts. While this structure provides operational flexibility and rapid response capabilities, the high concentration of control within a small group introduces meaningful governance risks. As the protocol matures, managing and progressively decentralizing this authority will be critical to ensuring long-term trust and resilience.

Emergency Controls and Role-Based Pausing

The Security Council Guardians have the ability to pause the mETH staking contract under emergency conditions. Notably, any individual Guardian may unilaterally pause the protocol to mitigate potential risks.

In addition to manual intervention, the protocol also features automated pause logic triggered by the oracle system. The oracle contract continuously monitors for anomalous behavior and can automatically pause the staking contract if:

• An oracle update falls outside of configured sanity bounds, or
• A slashing event is detected, resulting in a cumulative loss greater than 0.1% of protocol-controlled ETH.

Once the protocol is paused only addresses with the Unpauser role may resume operations.

It’s important to highlight that the mETH:ETH exchange rate oracle updates only every 8 hours. In the event of a major slashing incident, this update cadence introduces a window during which stale prices could persist on Aave markets. If the Security Council Guardians do not act quickly enough to manually pause affected activities, Aave could be exploited through recursive borrowing based on outdated valuations, leading to unnecessary protocol losses and bad debt.

This risk could be mitigated through the use of a Risk Oracle for Aave’s mETH markets. The Risk Oracle could automatically freeze the market if mass slashing is detected. By immediately freezing the market until a valid price update occurs, a Risk Oracle would help shield Aave from additional systemic losses during the critical 8-hour window before the next exchange rate update, significantly reducing exposure to cascading risks.

Security Council Authority During Emergencies

In extreme scenarios, the Security Council Multisig possesses the authority to intervene directly in the protocol’s operation. Through multisig approval, the Security Council may:

• Upgrade the logic of any deployed smart contract,
• Change withdrawal addresses,
• Modify protocol roles and permissions, and
• Adjust configurable protocol variables.

While these privileges serve as an emergency mechanism to protect the protocol against attacks or failures, this level of centralized control also introduces governance risk. Concentrating such critical powers in a small group of actors can create single points of failure or capture risk, particularly as the protocol scales.

Recognizing this, the Mantle team has outlined plans to progressively decentralize and reduce the Security Council’s intervention authority over time. Considered measures include:

• Transferring Security Council powers to an on-chain DAO controller,
• Implementing a non-zero Timelock delay for contract upgrades and critical changes, and
• Burning upgrade keys entirely once the protocol reaches sufficient maturity and operational stability.

These steps aim to enhance trust minimization, improve transparency, and align the protocol more closely with decentralized governance principles as it evolves.

Contract Upgradeability

The mETH Protocol employs a standardized upgradability framework using OpenZeppelin’s TransparentUpgradeableProxy contracts.

Timelock

To protect against hasty or malicious upgrades, all contract upgrade actions are subject to execution via a Timelock Controller. This mechanism introduces a delay between when an action is scheduled and when it can be executed.

Currently, the timelock is configured with a default delay of 0, meaning upgrades can be scheduled and executed immediately. However, the Mantle governance process has indicated that this delay will increase over time as the protocol matures, aligning with industry best practices for decentralized governance.

mETH

mETH Technical Overview

mETH is a value-accruing LST that represents a user’s staked ETH along with the corresponding Ethereum staking rewards. Unlike a 1:1 pegged token, mETH’s value appreciates over time as staking rewards accumulate. As a result, its market price reflects a dynamic exchange rate between ETH and mETH, driven by the underlying yield.

mETH Staking Diagram

When users stake ETH through the mETH protocol on Ethereum Layer 1, their deposits are routed to Mantle’s staking contract, which subsequently forwards the ETH to Ethereum’s Beacon Chain deposit contract. In return, users receive mETH tokens representing their stake.

To run the underlying validators, Mantle partners with third-party node operators, including well-known infrastructure providers such as A41, P2P, Blockdaemon, and Stakefish. These operators manage validator duties on behalf of mETH holders and receive a 10% fee on the staking rewards, encompassing both consensus and execution layer earnings. This fee is applied only to the rewards, not the principal.

While this delegation model helps decentralize validator operations and offload technical complexity from end users, it introduces a layer of opacity. Specifically, there is limited public information regarding:

• Node Operator concentration among these operators (i.e., how much stake each controls),
• Client diversity, particularly the execution and consensus clients (e.g., Geth, Prysm, Lighthouse) used by these operators.

This lack of transparency makes it challenging to evaluate mETH’s exposure to correlated slashing risks at the Ethereum consensus layer. By contrast, our analysis of Ethereum Consensus Layer penalties in the context of Lido’s validator distribution illustrates how validator and client concentration can significantly impact a staking protocol’s vulnerability to slashing and liveness failures

Until this operator composition and infrastructure diversity is disclosed in greater detail, it remains challenging to quantify the underlying risks associated with mETH’s validator set.

Redemption

To redeem mETH, users initiate an unstaking process that typically takes around four days to complete, reflecting Ethereum’s validator exit and withdrawal mechanisms. However, it’s important to note that this timeline is not fixed and can vary based on the state of the Ethereum consensus layer at the time of the request. In periods of heavy network congestion—such as mass validator exits—the wait time can increase significantly, as the Beacon Chain currently limits exits to approximately eight validators per epoch (every ~6.4 minutes). This natural bottleneck can extend the unstaking period well beyond the typical four days if exit queues become saturated. There are no additional fees for redemption. In addition to staking and unstaking, mETH remains freely tradeable on various decentralized exchanges, where transactions are instant but subject to slippage and standard swap fees depending on market depth.

Bridging

mETH is natively minted on Ethereum Layer 1 and can be bridged to the Mantle Network via the official Mantle canonical bridge. Bridging from Ethereum to Mantle typically finalizes within ~12 minutes, allowing users to access mETH within the Mantle ecosystem with minimal delay.

This process follows standard optimistic rollup mechanics:

• L1 → L2 transfers usually finalize within 2 to 12 minutes, depending on network conditions.
• L2 → L1 withdrawals require a challenge period of 3 to 7 days, ensuring security via fraud-proof mechanisms.

In addition to the canonical bridge, several third-party bridges also support mETH transfers between Ethereum and Mantle. However, these options typically offer limited liquidity, and due to this, users may encounter significant slippage, especially when attempting to move larger amounts.

Market Capitalization

A total of 368,000 mETH is currently in circulation, backed by 391,596 ETH staked on the Ethereum consensus layer. The total supply of mETH has been on a downward trend since April 2024, when it peaked at around 520,000 mETH. Over the past 12 months, the supply has decreased by approximately 30%.

At present, 10% of the mETH supply is bridged to the Mantle network, amounting to 38,735.6 mETH. In October 2024, this figure was as high as 40%, with around 188,000 mETH available on Mantle. However, since then, the mETH supply on Mantle has declined significantly—dropping by roughly 80%.

In summary, while the overall supply of mETH has decreased, the decline on the Mantle Network has been even steeper. There are currently no clear signs that this trend will reverse in the near future.

It’s also important to consider cmETH, the protocol’s restaking token. Approximately 55% of the total mETH supply—around 201,500 mETH out of 368,000—has already been restaked across platforms such as Karak, EigenLayer, and Symbiotic. These restaked tokens are locked in restaking contracts and are therefore unavailable participate in DeFi as a liquidity source.

Liquidity

The on-chain liquidity for the mETH token has dropped significantly—from a peak of over $200 million in November 2024 to just $1.6 million today. This decline has occurred in parallel with the reduction of mETH supply on the Mantle Network.

Currently, only around $1 million in mETH buy liquidity remains in liquidity pools. At its peak, this figure was approximately $72 million. This marks a substantial loss of on-chain liquidity.

Due to the limited on-chain liquidity, trading more than $1 million worth of mETH (approximately 550 mETH at current prices) incurs a significant price impact—exceeding 11%.

It’s also worth highlighting that the largest mETH liquidity pool is currently paired with cmETH on the Mantle Network, representing over 56% of the total on-chain liquidity—$0.9 million out of $1.6 million. Since cmETH is backed 1:1 by mETH, relying on this pool as the primary source of liquidity poses risks during periods of market stress. Given that cmETH is essentially a wrapper of mETH, it is expected to mirror mETH’s price movements, offering little in the way of diversification or price stability.

On Ethereum, mETH liquidity is better than on the Mantle Network but still limited. Following a major withdrawal in late February—during which over 80% of the liquidity was removed—only $5.3 million in liquidity remains on Ethereum.

Volatility

The market price of mETH on the Mantle Network has shown moderately high volatility but remains closely aligned with its underlying exchange rate. During the observed period, there were instances—particularly in late February—where the deviation exceeded -0.7%. For comparison, similar assets recorded slightly lower maximum deviations over the same timeframe: wstETH diverged by up to 0.32%, weETH by 0.26%, and ezETH by 0.35%.

Pricing/Oracle

The mETH Protocol relies on an on-chain oracle deployed on Ethereum mainnet to determine the exchange rate between ETH and mETH. This oracle governs the value accrual of mETH and is responsible for ensuring accurate and secure price updates across the protocol.

The oracle operates with a 3-of-6 quorum—meaning at least three out of six authorized oracle nodes must agree on the price update for it to be submitted on-chain. Updates are pushed every 8 hours.

To safeguard against erroneous inputs, the oracle includes built-in sanity checks that prevent the submission of unreasonable or outlier values. These checks ensure the integrity of the mETH price feed and reduce the risk of protocol disruption due to faulty or manipulated data.

On the Mantle Network, mETH does not yet benefit from a native oracle feed. Although Chainlink is live on Mantle, it currently does not support mETH pricing. This can lead to price dislocations relative to the mainnet reference rate, particularly during periods of low liquidity or heightened volatility.

To address this gap, deploying a cross-chain oracle relay that securely mirrors the mainnet exchange rate onto Mantle would be an important improvement. Similarly, other lending protocols have adopted an API3-based solution, where nodes retrieve the mETH/ETH exchange rate directly from Mantle’s staking contract on Ethereum and aggregate it with the ETH/USD price feed to derive an mETH/USD value.

Without the introduction of a reliable oracle solution, protocols like Aave would remain exposed to elevated risk from potential price divergence between mETH on Mantle and its reference rate on Ethereum mainnet. This vulnerability is further amplified by the relatively low on-chain liquidity of mETH on Mantle, making it easier for market prices to deviate significantly from fair value during periods of market stress.

Recommendation

Based on our analysis, Chaos Labs does not recommend listing mETH at this time. While mETH maintains reasonable liquidity on Ethereum mainnet, several critical risks persist on the Mantle Network. These include significantly reduced on-chain liquidity, the absence of a native oracle-based price feed, and heavy reliance on the cmETH-mETH pool, which lacks diversification and poses heightened volatility risks. Additionally, the lack of fast and liquid bridging solutions—with the canonical bridge requiring multi-day withdrawal periods and third-party bridges offering limited capacity and high slippage—further undermines cross-chain usability. Given these limitations, listing mETH at this stage presents outsized risk for a lending protocol like Aave. We recommend revisiting the listing decision once the asset’s pricing infrastructure, liquidity depth, and bridging mechanisms are improved.

cmETH

cmETH Technical Overview

cmETH is a Liquid Restaking Token (LRT) that allows users to amplify their Ethereum staking yield by restaking their mETH across multiple restaking platforms such as EigenLayer, Symbiotic, and Karak. While mETH only earns Ethereum staking rewards, cmETH unlocks access to restaking rewards distributed in various third-party assets. Notably, 20% of these restaking rewards are allocated to support growth initiatives. Rewards are claimable on a periodic basis, offering users enhanced returns, but with the tradeoff of increased exposure to platform-specific and slashing-related risks.

Mint

cmETH is minted exclusively on Ethereum Layer 1 by converting mETH at a fixed 1:1 rate, after which it can be bridged to Mantle. Alternatively, users on Mantle L2 can acquire cmETH directly from liquidity pools via supported decentralized exchanges.

Redemption

While cmETH does not impose a fixed lock-up period, unstaking is subject to either an 8-hour delay or, in some cases, up to ~7 days, depending on available protocol inventory and the cooldown periods of third-party restaking platforms. During this time, unstake requests are processed based on mETH availability in the protocol’s unstaking queue. Once the request is fulfilled, users receive mETH, which can then be redeemed for ETH through the standard unstaking process. All redemptions must be initiated and completed on Ethereum.

Restaking Slashing Risks

Unlike mETH, which is solely exposed to Ethereum’s base staking risks, cmETH introduces an additional layer of risk through restaking. This is because the mETH backing cmETH is actively deposited into various restaking platforms, such as EigenLayer, Symbiotic, and Karak, where it is delegated to operator sets that participate in Actively Validated Services (AVSs).

These operators, selected by the Mantle team, can opt in to provide unique stake on AVSs, making the mETH they manage subject to slashing penalties if misbehavior occurs. With the launch of slashing enforcement on EigenLayer’s mainnet, this risk became tangible. Notably, just before slashing was activated, the Mantle team withdrew all of their delegated mETH from EigenLayer, potentially in response to heightened risk. As of now, 160,902.81 out of 209,021.41 mETH (~76%) held by Mantle is unallocated, meaning it is neither earning restaking rewards nor actively subject to slashing.

At this time, there is no public explanation from Mantle regarding the rationale behind this withdrawal or any future plans for reallocating these unassigned mETH tokens. This introduces a degree of uncertainty around the long-term direction of Mantle’s restaking strategy and the security assumptions underpinning cmETH.

How Slashing Affects cmETH Value

The conversion between mETH and cmETH is governed by a manually adjustable exchangeRate, which is initialized at a 1:1 ratio. The cmETH minting logic resides in the Deposit() function within the Teller contract, which calls getRateInQuoteSafe(), a wrapper function that derives the conversion rate from the internal exchangeRate state variable. This rate is stored in accountantState in AccountantWithRateProviders contract and determines how much cmETH a user receives in exchange for depositing mETH and vice versa.

Importantly, the exchangeRate can only be changed via manual intervention using the updateExchangeRate() function, and only by an address granted the UPDATE_EXCHANGE_RATE_ROLE. To date, this function has never been called, and the rate remains fixed at its default value of 1e18.

If a slashing event were to occur on a restaking platform—reducing the backing value of cmETH—the exchange rate would not reflect that change unless manually updated by the protocol’s admin. This introduces a latent risk that cmETH could temporarily trade at a value misaligned with its underlying backing, especially in the event of a slashing incident.

Bridging

cmETH leverages the LayerZero OFT (Omnichain Fungible Token) standard, enabling fast and seamless bridging across supported chains. This infrastructure allows users to move cmETH between networks in approximately five minutes, with no slippage—offering a significant improvement in speed and usability compared to traditional bridging solutions.

Market Capitalization

Since the beginning of 2025, the circulating supply of cmETH has remained relatively stable, fluctuating between 200,000 and 230,000 tokens, even as the total supply of mETH has declined significantly over the same period. This stability suggests sustained user interest in restaking opportunities, despite broader market conditions and the relative contraction in base staking demand.

Historically, the majority of cmETH supply has been bridged to the Mantle Network, with its share consistently exceeding 60% during peak periods. While this figure has recently declined from around 65% to just above 50%, more than half of the total cmETH supply remains actively used on Mantle—a noteworthy sign of persistent cross-chain activity and DeFi engagement on Layer 2.

This stands in sharp contrast to mETH, where only around 10% of the total supply is bridged to Mantle. The disparity can be explained by several key factors.

First, cmETH users generally have a higher risk appetite, as they are more willing to engage with restaking platforms and assume additional slashing risks. In contrast, mETH users are exposed solely to Ethereum’s base staking risks and tend to be more risk-averse, preferring to keep their assets on Ethereum mainnet.

Second, cmETH benefits from LayerZero’s OFT (Omnichain Fungible Token) standard, which enables fast and slippage-free bridging to and from Mantle. This significantly improves the user experience compared to traditional canonical bridges, which often involve multi-day delays.

Third, the Mantle ecosystem has actively promoted cmETH usage through its Methamorphosis points program, now in its third season. This program rewards users who bridge cmETH to Mantle and engage with DeFi protocols there. In contrast, no comparable incentives currently exist for mETH, making cmETH the more attractive option for users seeking utility and rewards on Mantle.

Liquidity

The liquidity profile of cmETH has experienced a notable contraction since its peak in late 2024. In November 2024, total on-chain liquidity for cmETH exceeded $150 million, but by April 2025, it had dropped significantly to approximately $27 million. Despite this decline, cmETH still maintains a reasonably healthy level of liquidity.

It is important to note that, out of the current $27 million in liquidity, $19.3 million—roughly 75%—is held in cmETH itself, indicating that most liquidity pools are heavily concentrated in the cmETH token and not in its trading pairs. This means that the actual buy liquidity (i.e., non-cmETH assets available for swapping out of cmETH) is only $6.7 million. Notably, $5.1 million of this is paired with fBTC, while the remaining $1.6 million is split between ETH and stablecoin pairs such as USDT and USDe.

A trade simulation confirms this limited buy side depth: swapping 900 cmETH ($1.66 million) for USDT on Mantle currently results in a 5.5% price impact.

While multiple liquidity pools for cmETH are incentivized by the Methamorphosis points program—including USDe-cmETH (on Agni and Merchant Moe), WETH-cmETH (on Agni), and mETH-cmETH (on Merchant Joe)—over 90% of the liquidity in these pools is provided directly by the Mantle Treasury, rather than organic liquidity from users or other market makers.

As discussed in bridging section cmETH benefits from its OFT integration via LayerZero, which makes it highly portable between Ethereum and Mantle. This design feature enhances cross-chain liquidity dynamics, allowing arbitrageurs to utilize liquidity from Ethereum mainnet to balance supply and demand across networks.

On Ethereum, however, cmETH liquidity remains minimal, with only a single pool historically available, paired against mETH with roughly $2 million in TVL, entirely provided by the Mantle Treasury.

Still, the cmETH/mETH pool on mainnet could hold strategic importance. Since mETH is paired with over $5.3 million in ETH liquidity on Ethereum—as shown in the mETH Liquidity section—arbitrageurs can bridge cmETH from Mantle to mainnet and route trades through cmETH → mETH → ETH. This allows them to leverage mainnet liquidity to support trading activity on Mantle, particularly when local buy liquidity is constrained on Mantle Network.

Volatility

The volatility of cmETH has historically mirrored that of mETH on the Mantle Network, particularly in relation to its exchange rate against ETH. This close correlation is expected, as cmETH is a 1:1 mintable and redeemable asset for mETH on Ethereum mainnet, meaning their price movements are tightly coupled.

Given this relationship, cmETH exhibits similar price dynamics and reacts in tandem with mETH to market conditions. As a result, any deviation in cmETH pricing is typically a reflection of underlying movements in mETH, rather than independent volatility.

Pricing/Oracle

The pricing of cmETH is fundamentally anchored to mETH, as currently cmETH is minted and redeemable 1:1 against mETH on Ethereum mainnet. This conversion mechanism is critical—not only for price parity, but also because cmETH functions as a Liquid Restaking Token. Unlike mETH, which is exposed only to Ethereum staking risks, cmETH inherits additional risk from restaking platforms, including the possibility of slashing. Therefore, maintaining a reliable and enforceable redemption path back to mETH is essential to uphold cmETH’s value and its role in risk-managed DeFi integrations.

There is currently no Chainlink oracle for cmETH on the Mantle Network, even though Chainlink itself is operational on Mantle. This creates a gap in oracle coverage for protocols like Aave that depend on real-time, tamper-resistant price feeds to manage collateral valuations, loan health, and liquidation logic.

To enable cmETH’s safe inclusion in lending protocols, a robust pricing oracle is needed on Mantle. This feed should accurately reflect cmETH’s linkage to mETH—potentially by referencing the mETH/ETH exchange rate from Ethereum.

We recommend developing a robust cmETH/USD pricing feed by aggregating three key exchange rates: cmETH:mETH, mETH:ETH, and ETH:USD. This multi-hop pricing approach ensures that cmETH’s value reflects both its direct convertibility to mETH and the broader market value of ETH. Without such infrastructure, lending against cmETH introduces heightened exposure to price manipulation and unaccounted slashing risk—especially in the absence of a verifiable and trusted oracle on Mantle to support accurate and secure collateral valuation.

Recommendation

While cmETH exhibits several promising attributes as a collateral asset, Chaos Labs does not currently recommend its listing on Aave’s Mantle deployment due to a combination of oracle infrastructure gaps and strategic uncertainty in its restaking model.

On the positive side, cmETH maintains adequate liquidity across both the Mantle Network and Ethereum mainnet, particularly in contrast to mETH, which has experienced a steep liquidity decline on Mantle. cmETH also benefits from fast and low-slippage bridging via LayerZero’s OFT standard, which supports more efficient capital mobility and enables arbitrageurs to help align prices across chains. Furthermore, cmETH has demonstrated stable volatility characteristics, closely tracking its underlying exchange rate to ETH through its 1:1 mint/redeem parity with mETH.

However, several critical concerns remain unresolved. First, Mantle’s current restaking strategy lacks transparency. As of now, 76% of the mETH backing cmETH is unallocated, meaning withdrawn from restaking platfroms. There is no public information regarding the intended allocation strategy going forward, or the nature of Mantle’s agreements with third-party restaking node operators. This lack of clarity introduces uncertainty around the yield generation and security assumptions underlying cmETH.

Second, and most importantly, there is no pricing oracle infrastructure on Mantle to securely support cmETH in a lending environment. As a Liquid Restaking Token, cmETH introduces additional risk—particularly slashing risk tied to misbehaving operators on restaking platforms. While the protocol allows for manual adjustment of the cmETH:mETH exchange rate via a role-gated function, it lacks an in-protocol oracle-based mechanism to automatically update the rate in response to slashing events. This creates a significant blind spot: in the event of a slashing incident, the cmETH-to-mETH redemption value could become misaligned with the token’s actual backing unless manually updated by governance or protocol admins. Until a transparent and automated pricing mechanism is implemented, this conversion logic remains a risk vector.

To support cmETH as a safe and borrowable asset, a comprehensive oracle solution is required. This includes aggregating cmETH:mETH, mETH:ETH, and ETH:USD price feeds to compute a reliable cmETH/USD valuation on Mantle. Without such infrastructure, listing cmETH exposes the protocol to price manipulation, stale valuation, and potentially uncompensated slashing losses.

Given these limitations, we recommend postponing the listing of cmETH on Aave’s Mantle deployment. We advise reassessing the asset once a robust oracle framework is in place and the protocol’s restaking strategy, including risk management and slashing response, is clearly defined.

Specification

Parameter	Value
Asset	MNT
Isolation Mode	No
Borrowable	Yes
Collateral Enabled	Yes
Supply Cap	15,000,000
Borrow Cap	7,000,000
Debt Ceiling	-
LTV	60.00%
LT	65.00%
Liquidation Penalty	10.00%
Liquidation Protocol Fee	10%
Variable Base	0
Variable Slope1	7%
Variable Slope2	300%
Uoptimal	45%
Reserve Factor	20%
Stable Borrowing	Disabled
Flashloanable	Yes
Siloed Borrowing	No
Borrowable in Isolation	No
E-Mode Category	N/A

Disclaimer

Chaos Labs has not been compensated by any third party for publishing this ARFC.

Copyright

Copyright and related rights waived via CC0

[Jon_mantle]

I’m Jon and I lead growth within the mETH protocol team

Thank you for the detailed feedback and for outlining the specific requirements for mETH and cmETH listings.

We appreciate the thorough review and wanted to briefly clarify a few points and share updates on our progress:

Regarding cmETH unallocated mETH:

The current allocation state is a result of the EigenLayer slashing mechanism upgrade. In close coordination with the EigenLayer team, we made a security-first decision to temporarily withdraw the staked assets during the upgrade process to avoid any potential risks to user funds. With the upgrade finalised, we intend to redeposit the assets promptly.

On price feed infrastructure:

We have been actively collaborating with Chainlink to strengthen oracle coverage and relevant feeds will be available shortly:

• The mETH/ETH and ETH/USD feeds are already live, and the Chainlink team will aggregate these price feeds for a mETH/USD feed.

• For cmETH/USD, Chainlink has received the necessary setup information and is actively configuring the price feed.

On Mantle liquidity:

We recognize the importance of deep liquidity on Mantle Network. A significant contributor to the decline in mETH liquidity has been the increased adoption and uptake of cmETH. We are actively implementing internal initiatives to strengthen liquidity for both mETH and cmETH across key venues.

COOK Token:

We are in the process of exploring how token governance can be effectively introduced into the various aspects of the mETH protocol whilst balancing core protocol security.

At this time, core protocol decisions remain under the purview of our Security Council during this stage of growth.

Restaking strategy:

Our approach to restaking remains intentionally agile as the restaking ecosystem continues to evolve. Given that slashing mechanisms are only just being introduced across protocols, we are not publishing a fixed restaking strategy at this time.

That being said, all allocation decisions - both across restaking protocols and at the AVS level - are thoroughly reviewed with our Security Council to ensure prudent risk management and protocol safety.

With the upcoming Pectra upgrade and nascent slashing frameworks still taking shape, we are prioritizing asset safety over aggressive yield strategies. As the landscape matures, we will continue to assess opportunities through a risk-reward lens and adapt accordingly.

We’re fully aligned with your expectations and are prioritising improvements across various facets to meet Aave’s listing standards.

Thank you again for your feedback and we look forward to engaging closely with the DAO as we work towards fulfilling the requirements

[Jon_mantle]

@ChaosLabs @LlamaRisk

Referencing previous conversations on accuracy and reliability of oracle price feeds, would like to update that as of 28 August, cmETH/USD and mETH/USD price feeds are live on Mantle L2 via chainlink.

Looking forward towards enabling mETH and cmETH as collateral assets on this Aave instance.

Calculated mETH / USD Price Feed | Chainlink

Calculated cmETH / USD Price Feed | Chainlink

[bgdlabs]

mETH (Mantle ETH) technical/infrastructural analysis

Summary

This is a technical analysis of all the smart contracts of the asset and main dependencies.

Disclosure: This is not an exhaustive security review of the asset like the ones done by the Mantle Team, but an analysis from an Aave technical service provider on different aspects we consider critical to review before a new type of listing. Consequently, like with any security review, this is not an absolute statement that the asset is flawless, only that, in our opinion, we don’t see significant problems with its integration with Aave, apart from different trust points.

Analysis

The mETH Protocol is a liquid staking solution that allows users to stake ETH and participate in the Ethereum validation to earn MEV and staking rewards. Users can stake ETH to receive mETH, a yield-bearing token whose exchange rate relative to ETH increases over time. Users can redeem mETH for ETH and accumulated rewards, subject to a minimum delay of 12 hours. The protocol has also integrated a Liquidity Buffer where ETH not staked is deposited on Aave Core, earning lending APY and facilitating users’ redemptions.

For the context of this analysis, our focus has been on the following aspects, critical for the correct and secure integration with Aave:

• Mechanism to update the exchange rate of the asset for the underlying ETH.

• A recommendation of pricing strategy to be used in the integration asset <> Aave.

• Any miscellaneous aspect of the code we can consider of importance.

• Analysis of the access control (ownerships, admin roles) and the nature of the entities involved in the system. Regarding the table permissions’ holders and their criticality/risk, it is done following these guidelines:

Criticality	Description
CRITICAL	Usually super-admin functionality: it can compromise the system by completely changing its fundamentals, leading to loss of funds if misused or exploited. E.g. proxy admin, default admin
HIGH	It can control several parts of the system with some risk of losing funds. E.g., general owners or admin roles involved in the flow of funds
MEDIUM	It can cause malfunction and/or minor financial losses if misused or exploited. E.g., fee setter, fee recipient addresses
LOW	It can cause system malfunctions but on non-critical parts without meaningful/direct financial losses. E.g., updating descriptions or certain non-critical parameters.

Risk	Description
	The role is controlled via a mechanism we consider safe, such as on-chain governance, a timelock contract, or setups involving multi-sigs under certain circumstances.
	The role is controlled in a way that could expose the system and users to some risk depending on the actions it can control.
	The role is controlled via a clearly non-secure method, representing risks for the system and users.

General points

• The system relies on multiple contracts, with the Staking contract as the core contract, managing the flow of funds between user deposits, the consensus layer, and the liquidity buffer. The Oracle updates the protocol state, syncing the total ETH managed in the CL and processing MEV and staking rewards that should be sent to the Staking contract.

• Most dependencies in the system are from OZ for tokenization, access control, math, security, and upgradability.

• It uses a granular role-based access control across the system.

• For proxies, it uses the OZ Transparent Proxy.

• The upgradable admin is a 0 delay Timelock contract.

• The default admin is shared across contracts between two 6-of-14 Safe Wallets (0x8497…8203 and 0x4e59…D40f) that have 6 common signers.

• The system has off-chain components managing Oracle updates, creating node validators, and unstaking requests.

Contracts

The following is a non-exhaustive overview of the main smart contracts involved with mETH.

METH

The mETH is the system’s ERC20 token. It supports minting and burning via the Staking contract, and minting, burning, and blacklisting addresses via role-based entities. It’s an upgradable OZ Transparent Proxy.

Role	Holder(s)	Function	Criticality	Risk
Upgradable Admin	0-delay Timelock	upgradeTo, upgradeToAndCall, changeAdmin	CRITICAL
DEFAULT_ADMIN_ROLE	Safe (0x4e59…D40f), Safe (0x8497…8203)	Grant/revoke roles	CRITICAL
ADD_BLOCK_LIST_CONTRACT_ROLE	Safe (0x8497…8203)	addBlockListContract	HIGH
REMOVE_BLOCK_LIST_CONTRACT_ROLE	Safe (0x8497…8203)	removeBlockListContract	HIGH
MINTER_ROLE	Safe (0x8497…8203)	forceMint	HIGH
BURNER_ROLE	Safe (0x8497…8203)	forceBurn	HIGH

• Access Control

  • DEFAULT_ADMIN_ROLE

    • can reassign all operational roles via grantRole(role, address) and revokeRole(role, address) methods.

  • MINTER_ROLE

    • can directly alter balances by minting unbacked mETH tokens via forceMint(to, amount, excludeBlockList) function. It is important to note that this method increases mETH.totalSupply() without a corresponding rise in staking.totalControlled(), meaning that a compromised MINTER_ROLE can dilute all mETH holders’ value with a single call. This role is held by a 6-of-14 multisig with no timelock protection.

  • BURNER_ROLE

    • can burn mETH from any account via forceBurn(from, amount) function. Similarly, this method removes supply without a corresponding ETH change, breaking the exchange rate invariant in the opposite direction and enabling confiscation of any holder’s funds.

  • ADD_BLOCK_LIST_CONTRACT_ROLE

    • can add addresses to the blocklist using the addBlockListContract(address) function. It is also important to note that each mETH _transfer calls all external block list contracts with unbounded gas. A malicious or reverting block list contract added through this role can permanently halt all mETH transfers, including Aave’s liquidation process.

  • REMOVE_BLOCK_LIST_CONTRACT_ROLE

    • can remove addresses from blocklist via the removeBlockListContract(address) function.

• Mint and Burn

  • Covered in the Staking contract section.

  • mint(staker, amount) is restricted to the configured staking contract.

  • burn(amount) is restricted to the configured UnstakeRequestsManager and burns from that contract balance.

Staking

Core system contract and the main user-facing interaction contract. It handles users’ stake and unstake requests, internal accounting, validator initiation, and funds allocation between validators and the liquidity buffer. It is an upgradable OZ Transparent Proxy with role-based access control.

Role	Holder(s)	Function	Criticality	Risk
Upgradable Admin	0-delay Timelock	upgradeTo, upgradeToAndCall, changeAdmin	CRITICAL
DEFAULT_ADMIN_ROLE	Safe (0x4e59…D40f)	grantRole, revokeRole	CRITICAL
STAKING_MANAGER_ROLE	Safe (0x4e59…D40f)	setMinimumStakeBound, setMinimumUnstakeBound, setExchangeAdjustmentRate, setMinimumDepositAmount, setMaximumDepositAmount, setMaximumMETHSupply, setWithdrawalWallet, setStakingAllowlist, reclaimAllocatedETHSurplus	CRITICAL
ALLOCATOR_SERVICE_ROLE	EOA (0xC62c…1447)	allocateETH	HIGH
INITIATOR_SERVICE_ROLE	EOA (0x0eC6…2046)	initiateValidatorsWithDeposits	HIGH
TOP_UP_ROLE	Liquidity Buffer, Topupper, EOA (0x3Dc5…8eB8), Safe 3-of-8	topUp	HIGH
STAKING_ALLOWLIST_MANAGER_ROLE	Safe 3-of-8, EOA (0x3Dc5…8eB8)	grantRole, revokeRole (only STAKING_ALLOWLIST_ROLE)	MEDIUM
STAKING_ALLOWLIST_ROLE	0xCa26…B6a5, 0x4229…EdC0, 0x3Ef7…8Ee6, 0xE945…de31, 0x8f45…7F21, 0xC487…3379, EOA (0x3Dc5…8eB8), 0xcC40…bBb3, Safe 3-of-8	stake (when allowlist enabled)	LOW

• Access Control

  • DEFAULT_ADMIN_ROLE

    • can reassign all operational roles via grantRole(role, address) and revokeRole(role, address) methods.

  • STAKING_MANAGER_ROLE

    • can configure minimum deposit and redemption amounts via the setMinimumStakeBound(amount), setMinimumUnstakeBound(amount) methods.

    • can set max mETH supply via the setMaximumMETHSupply(amount) function.

    • can set validator’s staking ranges via the setMinimumDepositAmount(amount), setMaximumDepositAmount(amount) functions.

    • can set the address to receive ETH from the beacon chain via the setWithdrawalWallet(address) function.

    • can reclaim to this contract idle ETH in the UnstakeRequestManager contract via the reclaimAllocatedETHSurplus() method.

    • can set the exchangeAdjustmentRate storage variable via the setExchangeAdjustmentRate(bps) function.

  • ALLOCATOR_SERVICE_ROLE

    • Control ETH movement into unstake queue, liquidity buffer and validator deposits via the allocateETH(unstake, deposits, buffer) function.

  • INITIATOR_SERVICE_ROLE

    • Initiate validators by sending ETH to the Beacon chain deposit contract via the initiateValidatorsWithDeposits(validators, root) function.

  • TOP_UP_ROLE

    • can bypass the stake and increase the total ETH controlled by the protocol via the topUp(msg.value) function. It doesn’t mint any new mETH.

  • STAKING_ALLOWLIST_MANAGER_ROLE

    • It’s the role Admin of STAKING_ALLOWLIST_ROLE.

• Deposit and Redemptions

  • Users can mint mETH using the stake(amount) function. Internally, it calculates mETH shares using ethToMETH(amount) and checks whether the amount is above the minimum deposit and does not exceed the supply cap. Finally, it calls METH.mint(to, amount), minting directly mETH to the user.

  • Users can initiate a redemption via the unstakeRequest(mETHAmount, minETHAmount) function. Internally, it calculates ETH amount via the mETHToETH(mETHAmount) and validates whether unstake is paused and the amount is above the minETHAmount. Then, it process the user’s request by transferring mETH to the UnstakeRequestManager contract and creating an unstakeRequestID.

  • After the unstake period ends, users can claim their unstake request using the claimUnstakeRequest(unstakeRequestID) function, which calls unstakeRequestManager.claim(unstakeRequestID, user) to burn the previously transferred mETH and then transfer the ETH to the user.

• Exchange Rate

  • Exchange-rate conversion depends on the totalControlled() method, which keeps track of all ETH controlled by the protocol across validators, the liquidity buffer, the unstake manager, and idle ETH. These values are tracked by internal virtual balances that update only during protocol operations, and oracle data (ETH staked on CL), making the protocol fault-proof against donation attacks.

  • For deposits, it uses ethToMETH(ethAmount) with the formula (1 - exchangeAdjustmentRate) * (mETH.totalSupply() / totalControlled()) * ethAmount. The exchangeAdjustmentRate applies a small exchange-rate discount (in basis points) to new staking deposits to offset the reward loss caused by entry/exit queue timing differences, protecting the protocol and fairly socializing the impact across stakers. Currently it’s set to 4 bps.

  • For redemptions, it uses mETHToETH(mETHAmount) with the formula (totalControlled / mETHSupply) * mETHAmount without applying exchange-rate discounts.

OracleQuorumManager

The OracleQuorumManager contract is responsible for coordinating submitted oracle reports, evaluating the quorum threshold, and forwarding agreed records to the Oracle contract. It is an upgradable OZ Transparent Proxy with role-based access control.

Role	Holder(s)	Function	Criticality	Risk
Upgradable Admin	0-delay Timelock	upgradeTo, upgradeToAndCall, changeAdmin	CRITICAL
DEFAULT_ADMIN_ROLE	Safe (0x4e59…D40f)	grantRole, revokeRole	CRITICAL
QUORUM_MANAGER_ROLE	Safe (0x4e59…D40f)	setTargetReportWindowBlocks, setQuorumThresholds	HIGH
REPORTER_MODIFIER_ROLE	Safe (0x4e59…D40f)	grantRole, revokeRole (only SERVICE_ORACLE_REPORTER)	HIGH
SERVICE_ORACLE_REPORTER	0x9314…EF94, 0x84AE…9B17, 0x7451…FeF1, 0x94EC…28Cd, 0x7258…5cBf	receiveRecord	HIGH

• Access Control

  • DEFAULT_ADMIN_ROLE

    • can reassign all operational roles via grantRole(role, address) and revokeRole(role, address) methods.

  • QUORUM_MANAGER_ROLE

    • can configure the threshold for a report to be accepted via the setQuorumThresholds(threshold, relativeBps) function and the report window size in blocks via the setTargetReportWindowBlocks(blocks) function.

  • REPORTER_MODIFIER_ROLE

    • It’s the role Admin of SERVICE_ORACLE_REPORTER.

  • SERVICE_ORACLE_REPORTER

    • The reporters can update the records (CL snapshots) by calling the receiveRecord(record) function. After reaching the quorum, it forwards the record to the Oracle contract by calling the oracle.receiveRecord(record) function.

Oracle

The Oracle contract is responsible for storing the Consensus-layer state by receiving records (CL snapshot data) from the off-chain oracles, thereby maintaining the protocol’s accounting. It is an upgradable OZ Transparent Proxy with role-based access control.

Role	Holder(s)	Function	Criticality	Risk
Upgradable Admin	0-delay Timelock	upgradeTo, upgradeToAndCall, changeAdmin	CRITICAL
DEFAULT_ADMIN_ROLE	Safe (0x4e59…D40f)	grantRole, revokeRole	HIGH
ORACLE_MANAGER_ROLE	Safe (0x4e59…D40f)	setFinalizationBlockNumberDelta,setOracleUpdater, setMinDepositPerValidator, setMaxDepositPerValidator, setMinConsensusLayerGainPerBlockPPT, setMaxConsensusLayerGainPerBlockPPT, setMaxConsensusLayerLossPPM, setMinReportSizeBlocks	HIGH
ORACLE_MODIFIER_ROLE	Safe (0x4e59…D40f)	modifyExistingRecord	HIGH
ORACLE_PENDING_UPDATE_RESOLVER_ROLE	EOA (0x3Dc5…8eB8), Safe 3-of-8, Safe (0x4e59…D40f)	acceptPendingUpdate, rejectPendingUpdate	HIGH

• Access Control

  • DEFAULT_ADMIN_ROLE

    • can reassign all operational roles via grantRole(role, address) and revokeRole(role, address) methods.

  • ORACLE_MANAGER_ROLE

    • can configure the oracleUpdater via setOracleUpdater(address) function.

    • can configure key validation/sanity thresholds, such as the range of deposits per validator, the range of CL gains per block, the maximum CL loss per block, and the minimum report size in blocks, directly affecting accepted records.

  • ORACLE_MODIFIER_ROLE

    • can rewrite an existing record and trigger additional returns processing through the modifyExistingRecord(id, record) function.

  • ORACLE_PENDING_UPDATE_RESOLVER_ROLE

    • can accept or reject pending updates after sanity-check failures using the acceptPendingUpdate() and rejectPendingUpdate() functions.

• Oracle Updates

  • After reaching quorum, the oracle record is submitted via the receiveRecord(record) function.

  • Internally, the contract first validates the record against the previous one by ensuring the reporting window starts after the previous record and that processed deposits and validator counts align with the Staking contract. If validation succeeds and the reporting period is sufficiently finalized, a sanity check verifies that the report size meets the minimum required number of blocks, validator counts do not decrease, deposits per validator remain within configured bounds, and the consensus layer balance change stays within acceptable limits. If the sanity check passes, the record is added, and the aggregator is called via the processReturns(reward, principal, shouldIncludeELRewards) method to forward the ETH rewards and any fees received; otherwise, it is stored as a pending update, and the protocol is paused until the update is resolved.

ReturnsAggregator

The ReturnsAggregator contract aggregates ETH rewards from the CL and EL, applies protocol fees, and forwards ETH to the Staking contract and the configured receiver. It is an upgradable OZ Transparent Proxy with role-based access control.

Role	Holder(s)	Function	Criticality	Risk
Upgradable Admin	0-delay Timelock	upgradeTo, upgradeToAndCall	CRITICAL
DEFAULT_ADMIN_ROLE	Safe (0x4e59…D40f)	grantRole, revokeRole	CRITICAL
AGGREGATOR_MANAGER_ROLE	Safe (0x4e59…D40f)	setFeesReceiver, setFeeBasisPoints	MEDIUM

• Access Control

  • DEFAULT_ADMIN_ROLE

    • can reassign all operational roles via grantRole(role, address) and revokeRole(role, address) methods.

• AGGREGATOR_MANAGER_ROLE

  • can configure fee receiver and fee applied to the rewards via the setFeesReceiver(address) and setFeeBasisPoints(bps) methods. It’s important to note that if feesReceiver is misconfigured to a contract that reverts on ETH receipt, the entire oracle update process breaks down, stopping oracle updates and freezing the exchange rate.

• Oracle

  • During a complete Oracle report update, it calls the processReturns(reward, principal, shouldIncludeELRewards) function, which transfers the reward generated by the ReturnReceiver contracts, any principal (withdrawals) from the CL Receiver, and the balance of the EL Receiver when shouldIncludeELRewards is flagged.

ReturnsReceiver (consensusLayerReceiver & executionLayerReceiver)

The ReturnsReceiver is the contract that receives the protocol’s ETH and ERC20 rewards. It is implemented as two contracts, one for the funds from the Consensus Layer and another for the Execution Layer. It is an upgradable OZ Transparent Proxy with role-based access control.

Role	consensusLayerReceiver Holder(s)	executionLayerReceiver Holder(s)	Function	Criticality	consensusLayerReceiver Risk	executionLayerReceiver Risk
Upgradable Admin	0-delay Timelock	0-delay Timelock	upgradeTo, upgradeToAndCall	CRITICAL
DEFAULT_ADMIN_ROLE	Safe (0x4e59…D40f)	Safe (0x4e59…D40f)	grantRole, revokeRole	CRITICAL
RECEIVER_MANAGER_ROLE	Safe (0x4e59…D40f)	Safe (0x4e59…D40f)	grantRole, revokeRole (only WITHDRAWER_ROLE)	HIGH
WITHDRAWER_ROLE	ReturnsAggregator	ReturnsAggregator	transfer, transferERC20	HIGH

• Access Control

  • DEFAULT_ADMIN_ROLE

    • can reassign all operational roles via grantRole(role, address) and revokeRole(role, address) methods.

  • WITHDRAWER_ROLE

    • can move all ETH/ERC20 held by this contract to recipient addresses via the transfer(to, amount) and transferERC20(token, to, amount) functions.

  • RECEIVER_MANAGER_ROLE

    • It’s the role Admin of WITHDRAWER_ROLE.

LiquidityBuffer

The LiquidityBuffer controls the net flow between the Staking contract and external Position Managers. It allocates funds received from the Staking to managers, tracks interest earned, and applies fees on top. It is an upgradable OZ Transparent Proxy with role-based access control.

Role	Holder(s)	Function	Criticality	Risk
Upgradable Admin	0-delay Timelock	upgradeTo, upgradeToAndCall, changeAdmin	CRITICAL
DEFAULT_ADMIN_ROLE	Safe (0x8497…8203)	grantRole, revokeRole	CRITICAL
POSITION_MANAGER_ROLE	Safe (0x8497…8203)	addPositionManager, updatePositionManager, setDefaultManagerId, setFeeBasisPoints, setFeesReceiver, setShouldExecuteAllocation, setPositionManagerStatus	HIGH
LIQUIDITY_MANAGER_ROLE	EOA (0xC62c…1447)	withdrawAndReturn, allocateETHToManager, withdrawETHFromManager, returnETHToStaking	HIGH
INTEREST_TOPUP_ROLE	EOA (0x55b7…CDa8)	claimInterestFromManager, topUpInterestToStaking, claimInterestAndTopUp	HIGH
DRAWDOWN_MANAGER_ROLE	Safe (0x8497…8203)	setCumulativeDrawdown	HIGH

• Access Control

  • DEFAULT_ADMIN_ROLE

    • can reassign all operational roles via grantRole(role, address) and revokeRole(role, address) methods.

  • POSITION_MANAGER_ROLE

    • Position managers can be configured by adding new ones via the addPositionManager(address, cap) function, changing params through the updatePositionManager(id, newCap, active) and setPositionManagerStatus(id, active) functions, making one the default via the setDefaultManagerId(id) function, and setting whether the allocation should be used via the setShouldExecuteAllocation(bool execute) function.

    • can configure fees and fees recipient via the setFeeBasisPoints(bps) and setFeesReceiver(address) functions.

  • LIQUIDITY_MANAGER_ROLE

    • directly moves principal between staking and external managers via the allocateETHToManager(id, amount), withdrawETHFromManager(id, amount), and withdrawAndReturn(id, amount), and idle ETH in this contract via the returnETHToStaking(amount).

  • INTEREST_TOPUP_ROLE

    • Claims interest earned for this contract and sends it to the staking via the claimInterestFromManager(id, amount) and topUpInterestToStaking(amount) functions, or in a single action via the claimInterestAndTopUp(id, amount) function.

  • DRAWDOWN_MANAGER_ROLE

    • Can set the cumulativeDrawdown variable, which directly impacts totalControlled() by decreasing it through the setCumulativeDrawdown(amount) function. It’s important to note that the bounds check in this method validates against totalAllocationCapacity (the sum of all manager caps), not the actual totalControlled() value. If a drawdown is set that exceeds the sum of all other totalControlled() components, the subtraction in staking.totalControlled() underflows and reverts, leading to a full protocol DoS. This causes all system interactions to fail, including CAPO price calculation via exchange rate reads.

PositionManager

The PositionManager contract manages the ETH allocated to it by the LiquidityBuffer on Aave Core, performing wrapping, unwrapping, depositing, and withdrawing ETH. It is an upgradable OpenZeppelin Transparent Proxy with role-based access controls.

Role	Holder(s)	Function	Criticality	Risk
Upgradable Admin	0-delay Timelock	upgradeTo, upgradeToAndCall, changeAdmin	CRITICAL
DEFAULT_ADMIN_ROLE	Safe (0x8497…8203)	grantRole, revokeRole	CRITICAL
MANAGER_ROLE	Safe (0x8497…8203)	approveToken, revokeToken, setLiquidityBuffer	HIGH
EXECUTOR_ROLE	LiquidityBuffer	deposit, withdraw	HIGH
EMERGENCY_ROLE	Not assigned	emergencyTokenTransfer, emergencyEtherTransfer	HIGH

• Access Control

  • DEFAULT_ADMIN_ROLE

    • can reassign all operational roles via grantRole(role, address) and revokeRole(role, address) methods.

  • MANAGER_ROLE

    • can change token approvals using the approveToken(token, to, amount) and revokeToken(token, from) functions.

    • can change the liquidity buffer contract, which revokes and grants EXECUTOR_ROLE via the setLiquidityBuffer(address) function.

  • EXECUTOR_ROLE

    • Controls deposits and withdrawals on Aave Core via the deposit(referralCode, msg.value) and withdraw(amount) functions.

  • EMERGENCY_ROLE

    • can transfer all ETH and tokens in this contract to any recipient using the emergencyTokenTransfer(token, to, amount) and emergencyEtherTransfer(to, amount) functions. While this role is currently unassigned, DEFAULT_ADMIN_ROLE can grant it at any time. If ever assigned, draining the aWETH tokens held by this contract would not update LiquidityBuffer accounting and exchange rate until manually corrected by DRAWDOWN_MANAGER_ROLE.

UnstakeRequestsManager

The UnstakeRequestsManager contract manages the lifecycle of user unstake requests within the protocol. It queues and processes users’ unstake requests initiated via the Staking contract, verifies finalization using oracle data, burns locked mETH upon claim, and distributes ETH to users once funding is available. It is an upgradable OpenZeppelin Transparent Proxy with role-based access controls.

Role	Holder(s)	Function	Criticality	Risk
Upgradable Admin	0-delay Timelock	upgradeTo, upgradeToAndCall, changeAdmin	CRITICAL
DEFAULT_ADMIN_ROLE	Safe (0x4e59…D40f)	grantRole, revokeRole	CRITICAL
MANAGER_ROLE	Safe (0x4e59…D40f)	setNumberOfBlocksToFinalize	HIGH
REQUEST_CANCELLER_ROLE	Safe (0x4e59…D40f)	cancelUnfinalizedRequests	HIGH

• Access Control

  • DEFAULT_ADMIN_ROLE

    • can reassign all operational roles via grantRole(role, address) and revokeRole(role, address) methods.

  • MANAGER_ROLE

    • controls queue finalization delay through the setNumberOfBlocksToFinalize(blocks) function.

  • REQUEST_CANCELLER_ROLE

    • can cancel not-yet-finalized requests and return locked mETH via the cancelUnfinalizedRequests(numRequests) function.

• Redemptions

  • When the user submits an unstake request via the Staking contract, the create(user, mETHLocked, ethRequested) function is called, which creates the request and adds it to the FIFO unstake request list.

  • During claiming via the Staking contract, it calls claim(id, requester), which internally validates whether the minimum blocks to finalize have passed, using the oracle’s latest record data. If everything goes well, it burns the user’s mETHLocked and sends the underlying to the requester.

Pauser

The Pauser contract controls the global pause-state of the mETH system. It is an upgradable OpenZeppelin Transparent Proxy with role-based access controls.

Role	Holder(s)	Function	Criticality	Risk
Upgradable Admin	0-delay Timelock	upgradeTo, upgradeToAndCall, changeAdmin	CRITICAL
DEFAULT_ADMIN_ROLE	Safe (0x4e59…D40f)	grantRole, revokeRole	CRITICAL
PAUSER_ROLE	0x96FA…24ae, Safe 3-of-8	setIsStakingPaused, setIsUnstakeRequestsAndClaimsPaused, setIsInitiateValidatorsPaused, setIsSubmitOracleRecordsPaused, setIsAllocateETHPaused, setIsLiquidityBufferPaused, pauseAll	HIGH
UNPAUSER_ROLE	Safe (0x4e59…D40f), EOA (0x3Dc5…8eB8), 0x207E…82f8	setIsStakingPaused, setIsUnstakeRequestsAndClaimsPaused, setIsInitiateValidatorsPaused, setIsSubmitOracleRecordsPaused, setIsAllocateETHPaused, setIsLiquidityBufferPaused, unpauseAll	HIGH

• Access Control

  • DEFAULT_ADMIN_ROLE

    • can reassign all operational roles via grantRole(role, address) and revokeRole(role, address) methods.

  • PAUSER_ROLE

    • can pause a contract or an action-specific pause via the specific methods listed above, or pause the protocol via the pauseAll() function.

    • The Oracle contract calls pauseAll() when sanity checks fail during the reports update.

  • UNPAUSER_ROLE

    • can unpause a contract or an action-specific unpause via the specific methods listed above, or unpause the protocol via the unpauseAll() function.

mETHL2 (Mantle)

The mETHL2 is the system’s ERC20 token on the Mantle Network. It supports minting and burning via the native L2StandardBridge, and minting, burning, and blacklisting addresses via role-based entities. It’s an upgradable OZ Transparent Proxy.

Role	Holder(s)	Function	Criticality	Risk
Upgradable Admin	0-delay Timelock	upgradeTo, upgradeToAndCall, changeAdmin	CRITICAL
DEFAULT_ADMIN	Safe 6-of-14	grantRole, revokeRole	CRITICAL
Bridge	L2StandardBridge	mint, burn	HIGH
ADD_BLOCK_LIST_CONTRACT_ROLE	not assigned	addBlockListContract	HIGH
REMOVE_BLOCK_LIST_CONTRACT_ROLE	not assigned	removeBlockListContract	HIGH
MINTER_ROLE	not assigned	forceMint	HIGH
BURNER_ROLE	not assigned	forceBurn	HIGH

• Access Control

  • DEFAULT_ADMIN_ROLE

    • can reassign all operational roles via grantRole(role, address) and revokeRole(role, address) methods.

  • MINTER_ROLE

    • can directly alter balances by minting unbacked mETH tokens via forceMint(to, amount, excludeBlockList) function.

  • BURNER_ROLE

    • can burn mETH from any account via forceBurn(from, amount) function.

  • ADD_BLOCK_LIST_CONTRACT_ROLE

    • can add addresses to blocklist via the addBlockListContract(address) function.

  • REMOVE_BLOCK_LIST_CONTRACT_ROLE

    • can remove addresses from blocklist via the removeBlockListContract(address) function.

• Bridging

  • To bridge mETH to Mantle, users first lock their mETH in the L1StandardBridge on the mainnet using the depositERC20(l1Token, l2Token, amount, gasLimit, data) function. On the L2, the cross-chain transfer is initiated in the L2CrossDomainMessenger via the relayMessage() function, which calls the L2StandardBridge to mint the token amount to the user.

  • To cross back to Ethereum, users burn the mETH on Mantle through the L2StandardBridge using the withdraw(l2token, amount, gasLimit, data) function. On L1, the user needs to call finalizeWithdrawalTransaction() in OptimismPortal, which internally calls l1StandardBridge.finalizeBridgeERC20() and transfers the token amount to the user.

Pricing strategy

We recommend using a LST Capo adapter consuming the Protocol’s exchange rate via the Staking contract with a Chainlink ETH/USD price feed, which follows the procedure of pricing LSTs on Aave.

Miscellaneous

• The system has undergone several security reviews, and the latest upgrade was covered by Mixbytes, Hexens, Blocksec, and Exvul. The reports are available here.

• The system has an ongoing bug bounty program on Immunefi with a maximum bounty of $500k. More information can be found here.

• The system includes off-chain components necessary for updating the oracle state and transferring funds between EL and CL. Further details on the design and architecture are available in the documentation here.

Conclusion

We believe that mETH has no issues with integration with Aave and no significant technical barriers to listing. However, after our analysis and considering that it will be used as collateral, some risks related to direct Aave integration, as it currently stands, which could impact users, should be addressed before listing. Based on our discussions with the Mantle team, they indicated plans to introduce timelocks where necessary, and we recommend waiting for these changes before proceeding with listing:

• Extend the timelock minimum delay (currently set to zero) on upgradable admins, to avoid being executed immediately with no advance notice or on-chain visibility.

• Timelock the DRAWDOWN_MANAGER_ROLE because an over-set drawdown causes staking.totalControlled() to revert, which bricks the exchange rate and blocks price calculation in the CAPO adapter.

• Timelock all DEFAULT_ADMINs, STAKING_MANAGER_ROLE, REPORTER_MODIFIER_ROLE, QUORUM_MANAGER_ROLE, ORACLE_MANAGER_ROLE, ORACLE_MODIFIER_ROLE, RECEIVER_MANAGER_ROLE, POSITION_MANAGER_ROLE, and MANAGER_ROLE. We understand that these roles can alter core system parameters that are not time-sensitive.

• Timelock the MINTER_ROLE and BURNER_ROLE because they can change mETH.totalSupply() without a matching update to staking.totalControlled(). The CAPO adapter limits upward changes but doesn’t protect against downward changes, which unfairly dilutes all mETH value through forceMint.

[MconnectDAO]

Directionally supportive of onboarding MNT, mETH and cmETH as collateral on the Mantle v3 instance, given the clear native-growth angle for the Mantle ecosystem and Aave there. For final parameters I’d like to see the detailed risk work on on-chain liquidity, peg/price stability (especially for the restaked stack), and correlated-liquidation scenarios before fully committing to specific LTVs and caps.

[bgdlabs]

cmETH (Mantle ETH) technical/infrastructural analysis

Summary

This is a technical analysis of all the smart contracts of the cmETH asset and its main dependencies.

Disclosure: This is not an exhaustive security review of the asset like the ones done by the Mantle Team, but an analysis from an Aave technical service provider on different aspects we consider critical to review before a new type of listing. Consequently, like with any security review, this is not an absolute statement that the asset is flawless, only that, in our opinion, we don’t see significant problems with its integration with Aave, apart from different trust points.

Analysis

cmETH is an LRT by the Mantle team using Veda Labs’ Boring Vault architecture. Users deposit ETH or mETH and receive cmETH. The underlying is deposited into restaking strategies, such as EigenLayer, Symbiotic, and Karak, to generate additional rewards on top of the staking rewards. To redeem, users submit a request and can claim their mETH 8 hours later. Additionally, cmETH can be bridged to other chains via the LayerZero OFT standard.

For the context of this analysis, our focus has been on the following aspects, critical for the correct and secure integration with Aave:

• Mechanism to update the exchange rate of the asset for the underlying mETH, in this case, mETH.

• A recommendation of pricing strategy to be used in the integration asset <> Aave.

• Any miscellaneous aspect of the code we can consider important.

• Analysis of the access control (ownerships, admin roles) and the nature of the entities involved in the system. Regarding the table permissions’ holders and their criticality/risk, it is done following these guidelines:

Criticality	Description
CRITICAL	Usually super-admin functionality: it can compromise the system by completely changing its fundamentals, leading to loss of funds if misused or exploited. E.g. proxy admin, default admin
HIGH	It can control several parts of the system with some risk of losing funds. E.g., general owners or admin roles involved in the flow of funds
MEDIUM	It can cause malfunction and/or minor financial losses if misused or exploited. E.g., fee setter, fee recipient addresses
LOW	It can cause system malfunctions but on non-critical parts without meaningful/direct financial losses. E.g., updating descriptions or certain non-critical parameters.

Risk	Description
	The role is controlled via a mechanism we consider safe, such as on-chain governance, a timelock contract, or setups involving multi-sigs under certain circumstances.
	The role is controlled in a way that could expose the system and users to some risk depending on the actions it can control.
	The role is controlled via a clearly non-secure method, representing risks for the system and users.

General points

• The system is built on the Boring Vault architecture from Veda Labs, with a custom ERC20 as the vault share. Most dependencies are from OZ for tokenization, upgradability, access control, and security, and from solmate for the Auth/RolesAuthority pattern used across the Boring Vault components.

• The upgradeable contracts (L1cmETH, BoringVaultUpgradeable, and L1cmETHAdapter) use the OZ Transparent Proxy pattern.

• The upgradeable admin is a 0-delay Timelock contract used across the mETH protocol.

• The Boring Vault components use a solmate RolesAuthority for role-based access control, with the Safe 6-of-14 as the owner with full access across all contracts. The cmETH token uses OZ access control with the same Safe as default admin.

Contracts

The following is a non-exhaustive overview of the main smart contracts involved with cmETH.

L1cmETH

The L1cmETH contract is the system’s ERC20 token, representing a user’s share in the BoringVaultUpgradeable. It allows minting and burning exclusively by the BoringVaultUpgradeable, and includes address blocklisting, sanctions-list checking, and external pausability through a separate L1MessagingStatus contract. It is an upgradable OZ Transparent Proxy with role-based access control.

Permission Owner	Holder(s)	functions	Criticality	Risk
Upgradable Admin	0-delay Timelock	upgradeTo, upgradeToAndCall, changeAdmin	CRITICAL
DEFAULT_ADMIN_ROLE	Safe 6-of-14	grantRole, revokeRole	CRITICAL
MANAGER_ROLE	Safe 6-of-14	setMaxTotalSupply, setBlocklist, setSanctionsList	HIGH
MINTER_ROLE	BoringVaultUpgradeable	mint	HIGH
BURNER_ROLE	BoringVaultUpgradeable	burn	HIGH

• Access Control

  • DEFAULT_ADMIN_ROLE

    • can reassign all operational roles via the grantRole(role, account) and revokeRole(role, account) functions.

  • MANAGER_ROLE

    • can set the maximum token supply via the setMaxTotalSupply(uint256) function, and configure the blocklist and sanctions list contracts via setBlocklist(address) and setSanctionsList(address).

  • MINTER_ROLE

    • can mint cmETH to any address via the mint(address, uint256) function, subject to the maxTotalSupply cap, pause status, and enforcement of blocklist and sanctions list restrictions

  • BURNER_ROLE

    • can burn cmETH from any address via the burn(address, uint256) function, subject to the pause status and enforcement of blocklist and sanctions list restrictions

• Minting and Burning

  • Internally, minting and burning are triggered by the BoringVaultUpgradeable during enter() and exit() calls respectively. The BoringVaultUpgradeable holds both the MINTER_ROLE and BURNER_ROLE.

BoringVaultUpgradeable

The BoringVaultUpgradeable is the main vault contract that holds deposited mETH, implements restaking strategies, and manages cmETH minting and burning. It uses the RolesAuthority pattern for access control and accepts arbitrary whitelisted calls by a Manager, primarily used for restaking operations. It is an upgradable OZ Transparent Proxy.

Permission Owner	Holder(s)	functions	Criticality	Risk
Upgradable Admin	0-delay Timelock	upgradeTo, upgradeToAndCall, changeAdmin	CRITICAL
owner	Safe 6-of-14	setAuthority, transferOwnership, manage, enter, exit	CRITICAL
Role 1	ManagerWithMerkleVerification	manage	HIGH
Role 2	TellerWithMultiAssetSupport	enter	HIGH
Role 3	DelayedWithdraw	exit	HIGH

• Access Control

  • Owner

    • can call any requiresAuth function directly, bypassing the RolesAuthority. This includes granting and revoking role capabilities through the RolesAuthority, changing the authority, and setting the owner.

    • It’s important to note that bypassing requiresAuth allows the owner to mint unbacked tokens, withdraw mETH held by this contract, and execute any arbitrary call from this contract without delay.

  • Role 1

    • allows it to call manage(address, bytes, uint256) and manage(address[], bytes[], uint256[]), enabling arbitrary external calls from the vault. All calls through this path are Merkle-proof verified in the ManagerWithMerkleVerification contract before execution.

  • Role 2

    • allowed to call enter(address, address, uint256, address, uint256) to accept assets and mint cmETH shares.

  • Role 3

    • allowed to call exit(address, address, uint256, address, uint256) to burn cmETH shares and return assets to users.

TellerWithMultiAssetSupport

The TellerWithMultiAssetSupport contract serves as the main entry point for interacting with the system. It accepts native ETH and mETH deposits from users, calculates the cmETH shares based on the current exchange rate from the Accountant, and deposits them into the vault. It also supports a restricted bulkDeposit and bulkWithdraw path for privileged on/off-ramp operations (not configured). It is a non-upgradable contract that uses solmate Auth.

Permission Owner	Holder(s)	functions	Criticality	Risk
owner	Safe 6-of-14	setAuthority, transferOwnership, addAsset, removeAsset, pause, unpause, bulkDeposit, bulkWithdraw	CRITICAL
Role 8 (via RolesAuthority)	Safe 6-of-14	addAsset, removeAsset	HIGH
Role 14 (via RolesAuthority)	Pauser	pause, unpause	HIGH

• Access Control

  • Owner

    • can directly call any requiresAuth function.

  • Role 8

    • can add or remove supported deposit assets via addAsset(address) and removeAsset(address). Currently, mETH is the only supported deposit asset.

  • Role 14

    • can call pause() and unpause() to halt or restore deposits.

• Deposits

  • Users can deposit native ETH or mETH via the deposit(address, uint256, uint256) function. Internally, it retrieves the current exchange rate via accountant.getRateInQuoteSafe(depositAsset), which reverts if the Accountant is paused, calculates shares as depositAmount * ONE_SHARE / rate, validates against a minimum mint threshold, and calls vault.enter() to transfer assets in and mint cmETH.

  • For native ETH deposits, internally the contract wraps ETH to WETH via the configured nativeWrapper, then proceeds as a standard ERC20 deposit.

• Exchange Rate

  • It will be covered in details in the Accountant section.

DelayedWithdraw

The DelayedWithdraw contract handles user withdrawals through a two-step process. Users lock their cmETH and request mETH; after a delay, they can complete the withdrawal and receive the underlying asset (mETH). It’s a non-upgradable contract that employs solmate Auth for access control.

Permission Owner	Holder(s)	functions	Criticality	Risk
owner	Safe 6-of-14	all requiresAuth functions	CRITICAL
Role 8 (via RolesAuthority)	Safe 6-of-14	setupWithdrawAsset, changeWithdrawFee, setFeeAddress, setPullFundsFromVault, changeMaxLoss	HIGH
Role 9 (via RolesAuthority)	Safe 3-of-8	changeWithdrawDelay, changeCompletionWindow, cancelUserWithdraw, completeUserWithdraw, stopWithdrawalsInAsset	HIGH
Role 14 (via RolesAuthority)	Pauser	pause, unpause	HIGH

• Access Control

  • Owner

    • can call any requiresAuth function directly.

  • Role 8

    • can configure withdrawal parameters via setupWithdrawAsset(asset, delay, completionWindow, fee, maxLoss), changeWithdrawFee(asset, fee), setFeeAddress(asset), changeMaxLoss(asset, max),and setPullFundsFromVault(bool).
    • Currently, the only withdrawable asset is mETH, with an 8-hour withdrawal delay, zero withdrawal fee, zero max loss, and a 60-day completion window.

  • Role 9

    • can update operational withdrawal parameters via changeWithdrawDelay(address, uint32) and changeCompletionWindow(address, uint32), cancel pending user withdrawal requests via cancelUserWithdraw(address, address), forcibly complete requests via completeUserWithdraw(address, address), and stop withdrawals for a specific asset via stopWithdrawalsInAsset(address).

• Withdrawals

  • Users initiate a withdrawal by calling requestWithdraw(asset, shares, maxLoss, allowThirdPartyToComplete), which transfers the user’s cmETH shares to this contract, records the exchange rate at the time of request via accountant.getRateInQuoteSafe(asset), and sets the maturity timestamp.

  • After maturity, users complete the withdrawal via completeWithdraw(asset, account). Internally, it validates that the maturity has passed and the completion window has not expired, computes assetsOut as shares * min(rateAtRequest, currentRate) / ONE_SHARE, verifies that the loss from rate change does not exceed maxLoss, and calls boringVault.exit() to burn the shares and transfer the underlying assets.

  • It’s important to note that since maximum loss is zero, any withdrawals will revert if the exchange rate has decreased at all since the request was made.

  • Users can allow third parties to complete their withdraw via the setAllowThirdPartyToComplete(asset, bool) function.

AccountantWithRateProviders

The AccountantWithRateProviders contract tracks the cmETH/mETH exchange rate by updating it with off-chain data, calculates management and performance fees, and provides rate data to the TellerWithMultiAssetSupport and DelayedWithdraw contracts. It is a non-upgradable contract that uses solmate Auth for access control.

Permission Owner	Holder(s)	functions	Criticality	Risk
owner	Safe 6-of-14	all requiresAuth functions	CRITICAL
Role 8 (via RolesAuthority)	Safe 6-of-14	updateDelay, updateUpper, updateLower, updateManagementFee, updatePerformanceFee, updatePayoutAddress, setRateProviderData, resetHighwaterMark	HIGH
Role 11 (via RolesAuthority)	Safe 6-of-14	updateExchangeRate	HIGH
Role 14 (via RolesAuthority)	Pauser	pause, unpause	HIGH

• Access Control

  • Owner

    • can call any requiresAuth function directly.

  • Role 8

    • can configure the minimum delay between exchange rate updates via updateDelay(delay) function.

    • can set the allowed upper and lower bounds per update via updateUpper(uint) and updateLower(uint) functions.

    • can update the management and performance fees via updateManagementFee(fee) and updatePerformanceFee(fee), and the fee recipient via updatePayoutAddress(address) functions.

    • can set the rate provider for non-mETH deposit assets via setRateProviderData(asset, peggedToBase, rateProvider) function and the high watermark to the current exchange rate via the resetHighwaterMark() function.

  • Role 11

    • can update the exchange rate via updateExchangeRate(uint96).

  • Role 14

    • can call pause() and unpause().

• Exchange Rate

  • The rate is updated with off-chain data by the updateExchangeRate(uint96) function. Internally, if the new rate deviates by more than the allowed bounds or if the minimum delay has not elapsed, the contract automatically pauses instead of reverting; otherwise it proceeds and calculates accrued fees. Currently, the allowed upper bound is 0.5% increase and 0.5% decrease, and the minimum update delay is 6 hours.

  • The exchange rate is denominated in terms of the base asset (mETH), and it’s currently 1:1.

  • Since the rate is not derived from any on-chain balance check and relies solely on the value stored in this contract from off-chain data, we can confirm that the cmETH exchange rate is protected against donation attacks due to the Accountant’s internal state variable accounting.

ManagerWithMerkleVerification

The ManagerWithMerkleVerification contract orchestrates the BoringVault’s restaking strategy execution. Authorized strategists submit batches of calls with Merkle proofs, which are verified against a per-strategist Merkle root before being forwarded to the BoringVault’s manage() function. It also supports Balancer flash loans within a strategy batch. It is a non-upgradable contract that uses solmate Auth for access control.

Permission Owner	Holder(s)	functions	Criticality	Risk
owner	Safe 6-of-14	all requiresAuth functions	CRITICAL
Role 8 (via RolesAuthority)	Safe 6-of-14	setManageRoot	HIGH
Role 7 (via RolesAuthority)	Safe 2-of-3 (0x7cc4…0e10d), Safe 2-of-6 (0x3370…320E), Safe 2-of-3 (0x3AD0…a3dD), Safe 2-of-3 (0x56B7…6e05), Safe 2-of-6 (0xbDFa…62D0), Safe 2-of-6 (0xD3C0…e2Ec)	manageVaultWithMerkleVerification	HIGH
Role 14 (via RolesAuthority)	Pauser	pause, unpause	HIGH

• Access Control

  • Owner

    • can call any requiresAuth functions directly.

  • Role 8

    • can update any role’s Merkle root via setManageRoot(address, bytes32) function allowing an immediate change to what strategy calls are authorized without delay.

  • Role 7

    • can execute strategy calls via manageVaultWithMerkleVerification(bytes32[][], address[], address[], bytes[], uint256[]). Each call must be validated against the caller’s assigned Merkle root. The contract also enforces that the cmETH totalSupply() remains unchanged after a management batch, preventing unauthorized minting or burning during strategy execution.

  • Role 14

    • can call pause() and unpause() to halt or restore strategy execution.

Pauser

The Pauser contract is the system’s centralized pause controller. It is allowed to directly pause system’s contracts such as the Accountant, Manager, and Teller contracts. It is a non-upgradable contract that uses solmate Auth for access control.

Permission Owner	Holder(s)	functions	Criticality	Risk
owner	Safe 6-of-14	all requiresAuth functions	CRITICAL
Role 15 (via RolesAuthority)	Safe 6-of-14	addPausable, removePausable, updateSenderToPausable	HIGH
Role 16 (via RolesAuthority)	EOA (0x3Dc5…8eB8), EOA (0x61a3…ef3), EOA (0xa823…18a), Safe 3-of-8	pauseSingle, pauseAll	HIGH
Role 17 (via RolesAuthority)	EOA (0x3Dc5…8eB8), Safe 6-of-14	unpauseSingle, unpauseAll	HIGH

• Access Control

  • owner

    • can call any function directly.

  • Role 15

    • can manage the list of pausable contracts via addPausable(address), removePausable(uint256), and updateSenderToPausable(address, address) functions.

  • Role 16

    • can pause individual contracts via pauseSingle(address) or pause all registered contracts at once via pauseAll().

  • Role 17

    • can unpause individual contracts via unpauseSingle(address) or unpause all registered contract at once via unpauseAll().

RolesAuthority

The RolesAuthority is the contract managing all roles across the Boring Vault components. It assigns roles to users and specifies which roles can call certain functions. A user can invoke a function if at least one of their roles grants permission for that function. It is a non-upgradable contract that uses solmate Auth for access control.

Permission Owner	functions	Criticality	Risk
owner: Safe 6-of-14	setRoleCapability, setPublicCapability, setUserRole, setAuthority, setOwner	CRITICAL

• Access Control

  • The owner (Safe 6-of-14) can assign or revoke roles for any address via setUserRole(address, uint8, bool), and configure what functions each role can call via setRoleCapability(uint8, address, bytes4, bool). It can also mark capabilities as publicly callable via setPublicCapability(address, bytes4, bool).

  • It is important to mention that the owner has direct control over the entire role-capability without delay, meaning it can unilaterally grant any role to any address or expand any role’s permissions at any point in time.

L1cmETHAdapter

The L1cmETHAdapter contract is the LayerZero OFT adapter that enables cross-chain bridging of cmETH. It locks L1 cmETH on Ethereum and triggers minting of wrapped cmETH on destination chains. It is an upgradable OZ Transparent Proxy implementing the OFTAdapterUpgradeable interface from LayerZero.

Permission Owner	Holder(s)	functions	Criticality	Risk
Upgradable Admin	0-delay Timelock	upgradeTo, upgradeToAndCall, changeAdmin	CRITICAL
owner	Safe 6-of-14	setPeer, setDelegate, setEnforcedOptions, setSendLibrary, setReceiveLibrary	HIGH

• Access Control

  • The owner can configure cross-chain peers and LayerZero endpoint settings for each chain via the standard OApp/OFTAdapter functions.

  • The delegate (when assigned by the owner through setDelegate(address)) can configure LayerZero endpoint configurations on behalf of the contract.

• Bridging

  • To cross-chain cmETH to Mantle, users first lock the cmETH in this OFT adapter using the send() function. Internally, the lz endpoint contract is triggered to send a cross-chain message. On the L2, the lz endpoint receives the message and calls the lzReceive() function in the cmETH OFT contract, which verifies whether the amount is within the caps before minting cmETH to the user.

L2 cmETH

The L2 cmETH is the system’s ERC20 token on the Mantle network. It uses the standard OFT ERC20 token implementation, including the standard LZ OApp, enabling cross-chain transfers through the LZ endpoint contract. It’s an upgradable OZ Transparent Proxy.

Permission Owner	Holder(s)	functions	Criticality	Risk
Upgradable Admin	0-delay Timelock	upgradeTo, upgradeToAndCall, changeAdmin	CRITICAL
DEFAULT_ADMIN_ROLE	Safe 6-of-14	grantRole, revokeRole	HIGH
owner	Safe 6-of-14	setPeer, setDelegate, setEnforcedOptions, setSendLibrary, setReceiveLibrary, setMsgInspector, setPreCrime	HIGH
MANAGER_ROLE	Safe 6-of-14	setBlocklist, setSanctionsList	HIGH

• Access Control

  • Owner

    • can configure cross-chain peers and LayerZero endpoint settings for each chain via the standard OApp/OFTAdapter functions.

  • DEFAULT_ADMIN_ROLE

    • can reassign all operational roles via the grantRole(role, account) and revokeRole(role, account) functions.

  • MANAGER_ROLE

    • can configure the blocklist and sanctions list contracts via setBlocklist(address) and setSanctionsList(address) functions.

• Bridging

  • To transfer back to the mainnet, users call the send() function in the OFT cmETH, which internally burns the L2 cmETH and calls the lz endpoint to send a cross-chain message. On the L1, the lz endpoint receives the message and calls the cmETH OFT adapter, which transfers the cmETH to the user.

Pricing strategy

We recommend pricing cmETH using a CAPO adapter composed of two layers: the cmETH/mETH exchange rate from the Accountant contract and the mETH CAPO adapter as the base provider (mETH/ETH exchange rate + ETH/USD Chainlink price feed). Even if the cmETH:mETH exchange rate stays at 1:1 and isn’t expected to increase as users are rewarded with other tokens and points, having the layered adapter is important to cover slash risk scenarios through its underlying restaking strategies.

Miscellaneous

• The Boring Vault architecture is developed by Veda Labs and has been deployed across multiple protocols. The cmETH deployment is a customized version with the L1cmETH token replacing the standard ERC20 share token.

• The security reviews of the custom cmETH ERC20 token were conducted by Quantstamp, MixBytes, Secure3, and Hexens. The reports are available here.

• 0xMacro and Cantina conducted the security reviews of The Boring Vault, which can be found here.

• The system has an ongoing bug bounty program on Immunefi with a maximum bounty of $500k. More information can be found here.

Conclusion

We believe that cmETH has no fundamental issues with integration with Aave and no significant technical barriers to listing as a collateral asset. However, after our analysis and considering that it will be used as collateral, some risks related to direct Aave integration, as it currently stands, which could impact users, should be addressed before listing. We indicated the items below to Mantle and they are considering them, and we recommend waiting for these changes before proceeding with listing:

• Extend the timelock minimum delay (currently set to zero) on upgradeable proxy admins for L1cmETH, BoringVaultUpgradeable, and L1cmETHAdapter, to avoid upgrades being executed immediately with no advance notice or on-chain visibility. This is consistent with our recommendation in the mETH analysis.

• Timelock DEFAULT_ADMIN_ROLE on L1cmETH, because it can instantly reassign all operational roles - including MINTER_ROLE and BURNER_ROLE - allowing a compromised or misused admin to grant minting to an arbitrary address and create unbacked cmETH.

• Timelock MANAGER_ROLE on L1cmETH, because it controls setBlocklist() and setSanctionsList(), which can point to arbitrary contracts whose return values determine whether transfers succeed. These functions are not time-sensitive.

• Timelock the owner role across the Boring Vault system (BoringVaultUpgradeable, TellerWithMultiAssetSupport, DelayedWithdraw, AccountantWithRateProviders, ManagerWithMerkleVerification, Pauser, RolesAuthority) and L1cmETHAdapter. In every contract using solmate Auth, the owner bypasses RolesAuthority entirely and can call any requiresAuth function directly - including minting unbacked tokens, withdrawing vault assets, executing arbitrary calls, manipulating exchange rate bounds, cancelling user withdrawals, and reconfiguring cross-chain peers via setPeer().

• Timelock Role 8 (via RolesAuthority), which has configuration privileges across TellerWithMultiAssetSupport, DelayedWithdraw, AccountantWithRateProviders, and ManagerWithMerkleVerification. These functions are not time-sensitive, and each has a path to affecting exchange-rate integrity, deposit/withdrawal availability, or draining value - notably the ability to widen exchange rate bounds and remove the update delay in a single transaction.

Additionally, the updateExchangeRate() function - which directly determines the pricing of user deposits and withdrawals - is currently only callable by the Safe 6-of-14. Without an automated oracle service holding this role, exchange rate accrual depends entirely on manual multi-sig action, and the rate could remain stale during periods of low operational activity. We recommend the Mantle team set up an automated oracle service for rate updates, with the Safe serving as a backup.