[ARFC] Deploy Aave V3 to MegaETH

Governance New Market
23

Reminder that @ACI already have ready infrastructure to distribute point / TGE token. This infra build in collaboration with Merkl in already in use on Aave white label Ink instance.
We are ready to help if that can help Aave to get better KPI per points / token distributed

9 Likes
24

Aave v3 megaETH. Initial asset listings technical analysis - Cross-chain assets


Introduction

This analysis covers the assets proposed for the initial listing on megaETH, specifically those with cross-chain infrastructure already listed on one or more Aave instances.
The review provides an overview of key aspects such as contract implementations and access controls of critical components relevant to protocol security during the listing process, as extra transparency for the community

Disclosure: This is not an exhaustive security review of the asset like the ones conducted by the asset’s teams, but an overview analysis from an Aave technical service provider on various aspects we consider critical before listing an asset that is already listed on other Aave instances. Therefore, like with any security review, this does not make an absolute statement that the asset is flawless, only that, in our opinion, we do not see significant problems with its integration with Aave, aside from different trust points.



Assets

The following is a non-exhaustive overview of the assets’ smart contracts that will initially be listed on MegaETH.


USDT0

The USDT0 stablecoin is an upgradable OZ Transparent Proxy that uses the TetherTokenV2 standard with an OFT extension.

The asset is already listed on other Aave instances and follows the exact implementation on L2, such as Plasma.

For access control, it uses the OZ Ownable, where the owner is set to a Safe 3-of-5. The principal role is to set the OFT Contract and upgrade the implementation of the Proxy.

The OFT extension gives an OFT Contract the capabilities to mint and burn the tokens. This OFT Contract is the adapter (LZ OApp) that receives messages from the LayerZero bridge to mint tokens.

The implementation doesn’t impose risks for the listing.

For USDT0 pricing, we recommend using the Capo stable adapter with the USDT/USD Chainlink price feed.

Upgradable Access Control Minter and Burner Locked funds on mainnet Upgradable Locked funds Locked funds access Control
USDT0: ProxyAdmin → Safe 3-of-5 ownable: Safe 3-of-5 owner: Safe 3-of-5 and OFT Contract OFTAdapterUpgradable Proxy Admin → Safe 3-of-5 Ownable: Safe 3-of-5

WETH

The WETH token is a non-upgradable contract that inherits the WETH98 implementation, wrapping the chain’s native asset into an ERC20-like token. The MegaETH WETH token reads the symbol and name from the L1 (mainnet) via the L1Block contract. Users can mint WETH by first bridging native ETH through the canonical bridge. The WETH98 is the WETH9, upgraded to Solidity 0.8.x, and a widely used standard on EVM chains that poses no risk to the listing.

The OptimismPortal2 contract locking funds on mainnet is controlled by the MegaETH network Safe Wallet.

For WETH pricing, we recommend using the ETH/USD Chainlink price feed.

Upgradable Access Control Minter and Burner Locked funds on mainnet Upgradable Locked funds Locked funds access Control
- - L1StandardBridge OptimismPortal2 ProxyAdmin → Safe 4-of-8 -

wrsETH

The wrapped rsETH token is an upgradable Transparent Proxy contract that uses the RsETHTokenWrapper implementation to wrap the rsETH OFT version and also include native wrsETH minting.

The asset is already listed on other Aave instances, following the exact implementation on other chains, such as Avalanche, Base, and Plasma. The implementation does not introduce any additional risks compared to the asset’s existing listings on Aave.

It uses role-based access control, where a 3-day Timelock controls the list of assets that can natively mint wrsETH, while the rsETHPool is the entry point for users to mint wrsETH natively.

The cross-chain is managed through the rsETH OFT, which serves as the facilitator, receiving messages directly from the bridge (LZ endpoint) to mint and burn tokens.

We recommend pricing wrsETH with a CAPO adapter using the rsETH/ETH exchange rate from Chainlink, with the ETH/USD price feed. The suggestion is consistent with other instances where both assets are listed.

Upgradable Access Control Minter and Burner Locked funds on mainnet Upgradable Locked funds Locked funds access Control
proxyAdmin → 3-day Timelock 3-day Timelock rsETHPool RSETH_OFTAdapter - Ownable: Safe 3-of-6

ezETH

The ezETH contract is an OZ Transparent Proxy contract with the XERC20 contract as implementation.

The asset is already listed on other Aave instances, following the exact implementation on other chains, such as Avalanche, Base, and Plasma. The implementation does not introduce any additional risks compared to the asset’s existing listings on Aave. We have reached out to the Renzo team, and they’ll transfer the upgradable and owner to a timelock contract.

The cross-chain integration involves a HypXERC20Lockbox contract on the mainnet that transmits cross-chain messages through the HyperLance Mailbox contract. Relayers then deliver these messages to the Mailbox on the L2, specifically MegaETH, which then validates and calls the HypXERC20 contract to mint ezETH for the user.

We recommend pricing ezETH with a CAPO adapter using the ezETH/ETH exchange rate from Chainlink, with the ETH/USD price feed. The suggestion is consistent with other instances where both assets are listed.

Upgradable Access Control Minter and Burner Locked funds on mainnet Upgradable Locked funds Locked funds access Control
ProxyAdmin → Safe 3-of-6 Ownable: Safe 3-of-6 (not set yet) Lockbox ProxyAdmin → 7-day Timelock HypXERC20Lockbox

wstETH

The wrapped stETH token is an upgradable OZ Transparent Proxy contract that uses the BurnMintERC20Transparent contract. The asset operates through the CCIP’s system via the BurnMintTokenPool contract.

The asset is already listed on other Aave instances, following the exact implementation on the Plasma instance. The implementation does not introduce any additional risks compared to the asset’s existing listings on Aave.

The cross-chain is managed through CCIP’s router, which locks tokens on mainnet in the SiloedLockReleaseTokenPool and forwards the message to CCIP’s OffRamp contract. The message is sent and received by the BurnMintTokenPool in the destination chain, which mints the tokens.

We recommend pricing wstETH with a CAPO adapter using the wsETH/stETH exchange rate from Chainlink, with the ETH/USD price feed. The suggestion is consistent with other instances where both assets are listed.

Upgradable Access Control Minter and Burner Locked funds on mainnet Upgradable Locked funds Locked funds access Control
ProxyAdmin → 3 hours RBACTimelock DEFAULT_ADMIN : 3 hours RBACTImelock BurnMintTokenPool SiloedLockReleaseTokenPool - OffRamp

BTC.b & LBTC

BTC.b (acquired by Lombard) and LBTC are upgradable OZ Transparent Proxies utilizing the NativeLBTC and StakedLBTC, respectively, both inheriting from the baseLBTC contract. NativeLBTC represents BTC on the EVM, while StakedLBTC is the LBTC we previously analyzed for its listing on Aave.

These assets are bridged from Ethereum to L2s via Lombard’s GMP (General Message Passing) system via the Lombard Mailbox, BridgeV2, and AssetRouter contracts. The GMP integrates with Chainlink’s CCIP via the LombardTokenPoolV2 contract.

The AssetRouter contract serves as the primary connector between Lombard assets and the message-passing system, while the BridgeV2 enables users to cross-chain these assets by interacting with the Mailbox to send minting and burning messages across chains. The LombardTokenPoolV2 integrates with the CCIP system by inheriting the releaseOrMint and LockOrBurn features from the TokenPool contract.

The assets are already listed on other Aave instances, and the implementations introduce no additional risks beyond their existing listings. We have reached out to the Lombard team, and they’ll transfer the upgradable and default admin to a timelock contract.

We recommend pricing BTC.b using the Chainlink BTC/USD price feed and LBTC using the LSTs CAPO adapter consuming the Chainlink LBTC <> BTC Exchange Rate feed with the BTC/USD Price feed. The approach is consistent with other instances where both assets are listed.

Upgradable Access Control Minter and Burner Locked funds on mainnet Upgradable Locked funds Locked funds access Control
BTC.b: ProxyAdmin → Safe 3-of-5 DEFAULT_ADMIN_ROLE: Safe 3-of-5 BridgeV2, AssetRouter LombardTokenPoolV2 (CCIP) - ownable: Safe 3-of-5
LBTC: ProxyAdmin → Safe 3-of-5 DEFAULT_ADMIN_ROLE: Safe 3-of-5 BridgeV2, AssetRouter LombardTokenPoolV2 (CCIP) - ownable: Safe 3-of-5

Miscellaneous

  • The listed assets are the official contracts on the megaETH network. The respective asset’s teams selected LayerZero bridge implementing OFT standard and CCIP’s infrastructure to avoid liquidity fragmentation. Renzo’s ezETH kept the bridge infrastructure from Hyperlane, which is consistent with the asset in other chains.

  • These bridged assets use the widely adopted OFT standard implementation with little to no changes, which does not affect their overall usability or security. The same applies for bridged assets using the CCIP’s BurnMintTokenPool standard.

  • The assets on mainnet are secured and locked in an OFT Adapter extension contract, which implements the OFT mechanisms, locking and releasing the tokens as they are bridged through LayerZero. The same applies for assets securing via CCIP’s TokenPool stack.

  • The OFT and OApp audits can be found in the LayerZero audits GitHub repository here.

  • The security reviews of the CCIP contracts’ infrastructure can be found here.

  • We still recommend time-locking the upgradable admins of the upgradable assets and the ownership of general asset configurations that can add new token minters, which enhances the overall security of the assets and provides extra time to validate any changes made to the current configuration.


Conclusion

We believe the initial cross-chain assets have no problems with integration into Aave, and there are no technical blockers for listing.

25

Aave v3 megaETH. Initial asset listings technical analysis - USDm


Summary

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

Disclosure: This is not an exhaustive security review of the asset like the ones done by the USDm 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

USDm is the MegaETH stablecoin, issued through Ethena’s Whitelabel stablecoin infrastructure. Reserves are to be primarily invested in BlackRock’s tokenized U.S. Treasury fund (BUIDL) via Securitize, with on-chain stablecoins held for redemptions. Authorized accounts can mint USDm by depositing USDtb or other supported stablecoins, such as USDC, and redeem USDm for the same stablecoins.


usdm1
usdm11611×357 27.4 KB


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

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

  • Any miscellaneous aspect of the code that can be considered 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
:green_circle: 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.
:yellow_circle: The role is controlled in a way that could expose the system and users to some risk depending on the actions it can control.
:red_circle: The role is controlled via a clearly non-secure method, representing risks for the system and users.

General points

  • The USDm system relies on two contracts: most dependencies are from LayerZero’s OFT token for cross-chain transfers, blacklist controls, and rate-limited bridging, and from OZ for access control, tokenization, upgradability, and security.

  • The upgradable and general admin is controlled by a Safe 4-of-9.

  • For proxies, it uses the UUPS proxy pattern.


Contracts

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


usdm2
usdm22676×1266 354 KB


USDm Ethereum / MegaETH (xUSDOFTUpgradeable)

The USDm token is the main system’s contract; xUSDOFTUpgradeable is the upgradeable ERC20 OFT token for USDm with LayerZero cross-chain support, blacklist controls, and a rescue mechanism. It uses UUPS upgradability and ownable access control to manage minters, blacklisters, and cross-chain rate limits.

Role Holder(s) (Ethereum) Holder(s) (MegaETH) Function Criticality Risk
upgradable admin (UUPS owner) Safe 4-of-9 Safe 4-of-9 upgradeToAndCall CRITICAL :yellow_circle:
owner Safe 4-of-9 Safe 4-of-9 addMinter, removeMinter, addBlacklister, removeBlacklister, setRescueRecipient, setRateLimits, rescueBlacklistedTokens HIGH :yellow_circle:
minter USDmMinting, LZ endpoint LZ endpoint mint, burnFrom HIGH :green_circle:
blacklister Safe 4-of-9 not set addToBlacklist, removeFromBlacklist HIGH :green_circle:

  • Access Control

    • owner:

      • Can add/remove minters and blacklisters via the addMinter(address), removeMinter(address), addBlacklister(address), and removeBlacklister(address) functions respectively.

      • Can configure cross-chain rate limits via the setRateLimits({chain, limit, window}) function.

      • Can set the recipient address for blacklisted tokens by calling the setRescueRecipient(address) method.

      • Can rescue blacklisted tokens via the rescueBlacklistedTokens(address) method.

    • blacklister:

      • Can add/remove addresses from the blacklist, preventing transfers for those addresses via the addToBlacklist(address) and removeFromBlacklist(address) functions respectively.

  • Mint and Burn

    • Authorized minters, in this case, only the USDmMinting can mint new USDm tokens to specified recipients via mint(to, amount) function.

    • Token holders (or approved spenders) can burn via burnFrom(from, amount), subject to allowance checks.

  • Bridging

    • By featuring the OApp, USDm acts as the facilitator, receiving messages directly from the bridge (LZ endpoint) to mint and burn tokens.

USDmMinting

The USDmMinting contract is the primary entry point for minting and redeeming USDm. It is a non-upgradable contract that implements role-based access control, allowing authorized operators to execute mints and redemptions on behalf of users via signed orders. The contract enforces global and per-asset caps per block, restricts participation through a benefactor whitelist and per-benefactor beneficiary approvals, and includes an emergency gatekeeper mechanism that can hard-disable minting and redemption.

Role Holder(s) Function Criticality Risk
owner / DEFAULT_ADMIN_ROLE Safe 4-of-9 setGlobalMaxMintPerBlock, setGlobalMaxRedeemPerBlock, addSupportedAsset, removeSupportedAsset, addCustodianAddress, removeCustodianAddress, addWhitelistedBenefactor, removeWhitelistedBenefactor, setMaxMintPerBlock, setMaxRedeemPerBlock, setTokenType, setStablesDeltaLimit, grantRole, revokeRole HIGH :yellow_circle:
GATEKEEPER_ROLE (not set) disableMintRedeem, removeMinterRole, removeRedeemerRole, removeCollateralManagerRole HIGH :green_circle:
MINTER_ROLE EOA (0x31cF…4d23), EOA (0x14Ef…490A), EOA (0x254C…6d17), EOA (0x0405…61ca), EOA (0x5DEe…4b2C), EOA (0x4569…5A5C), EOA (0xc3a0…dfA3), EOA (0xD316…6e82), EOA (0xe28f…683d), EOA (0x29f1…f1E6) mint, mintWETH HIGH :yellow_circle:
REDEEMER_ROLE EOA (0x31cF…4d23), EOA (0x14Ef…490A), EOA (0x254C…6d17), EOA (0x0405…61ca), EOA (0x5DEe…4b2C), EOA (0x4569…5A5C), EOA (0xc3a0…dfA3), EOA (0xD316…6e82), EOA (0xe28f…683d), EOA (0x29f1…f1E6) redeem HIGH :yellow_circle:
COLLATERAL_MANAGER_ROLE (not set) transferToCustody HIGH :green_circle:

  • Access Control

    • DEFAULT_ADMIN_ROLE:

      • Can configure global and per-asset mint/redeem limits by calling the setGlobalMaxMintPerBlock(amount), setGlobalMaxRedeemPerBlock(amount), setMaxMintPerBlock(amount, asset), setMaxRedeemPerBlock(amount, asset) functions. Currently, global mint and redeem are 10M tokens per block.

      • Can add/remove supported assets via the addSupportedAsset(address, {TokenType, isActive, maxMintPerBlock, maxRedeemPerBlock}) and removeSupportedAsset(address) functions. Currently, USDC and USDtb are whitelisted to mint/redeem USDm. It can also switch the asset type between STABLE or ASSET via the setTokenType(TokenType) function.

      • Can add/remove custodians and whitelisted benefactors via the addCustodianAddress(address), removeCustodianAddress(address), addWhitelistedBenefactor(address), removeWhitelistedBenefactor(address) functions, respectively.

      • Can set the stablecoin price slippage limits through the setStablesDeltaLimit(uint limit) function.

    • GATEKEEPER_ROLE:

      • can disable mint/redeem globally by calling the disableMintRedeem() method.

      • can revoke operational roles by calling the removeMinterRole(address), removeRedeemerRole(address), and removeCollateralManagerRole(address) methods.

    • MINTER_ROLE:

      • Can execute mints of USDm against supported collateral using signed orders.

    • REDEEMER_ROLE:

      • Can execute redemptions that burn USDm and send collateral to beneficiaries.

    • COLLATERAL_MANAGER_ROLE:

      • Can transfer held collateral to approved custodian addresses via the transferToCustody(address wallet, address asset, uint amount) function.

  • Mint and Burn

    • Whitelisted minters (address assigned with MINTER_ROLE) can mint USDm by calling the mint(Order, Route, Signature) function. Internally, it validates the Order.OrderType is a MINT and the benefactor’s Signature, if the collateral asset is a STABLE, and the custody Route ratio sum is 100%. It finalizes by consuming the amount from the global per-block mint limit, transferring the collateral from the Order.benefactor to the custodian wallets (currently the EOA is the only custodian), and minting USDm to the Order.beneficiary.

    • Whitelisted redeemers (addresses granted the REDEEMER_ROLE) can redeem USDm by calling the redeem(Order, Signature) function. Internally, it validates that the Order.OrderType is REDEEM and that the benefactor’s Signature is valid. If everything is correct, it consumes the amount from the global per-block redeem limit, burns the USDm from the Order.benefactor, and transfers the Order.amount of the Order.asset to the Order.beneficiary address.

    • The system also features minting with native ETH through the mintWETH(Order, Route, Signature) function; however, it is currently disabled.



Pricing strategy

Given the only-borrowable intended configuration and the nature of the asset, we recommend pricing USDm using a fixed 1 USD price feed, a strategy consistent with others similar.



Miscellaneous

  • The security reviews were performed by Quantstamp, Zellic, Spearbit and Pashov. They can be found here.

  • We confirmed with Ethena that the EOAs with MINTER_ROLE are protected via HSM (Hardware Security Modules) and must pass an internal KYB process before being assigned, following the same process as USDe.

  • We confirmed with Ethena that the only Custodian address is a Coinbase Prime custodial wallet, which requires 3 signatures (with no external signers) to operate the policy engine.



Conclusion

We think USDm doesn’t have any issues with integration with Aave, and there are no major technical blockers to listing.

Also, it is important to note that after an internal discussion with Ethena regarding access-control security, they have confirmed that the upgradable admin and master admin for USDm will be transferred to a Timelock, which provides an additional security layer for the most critical actions on USDm.

2 Likes
26

Overview

Following the prior assessment of the MegaETH deployment in this post, this analysis presents an initial set of recommendations based on the list of assets proposed by Aave Labs.
As the previous post included an initial review of the network and no further information has been released, this post will not cover MegaETH’s technical aspects.
This deployment includes an initial set of core assets that have been listed on existing Aave instances; as such, their technical aspects have already been covered and will not be the focus of this analysis.
As Mega’s native stablecoin, USDM, is a key asset for deployment, a technical analysis will be performed on it.
Furthermore, as the MegaETH network is currently in a private mainnet state and has not yet deployed its initial ecosystem projects, liquidity bootstrapping has not been completed. As such, the parameters recommended in this analysis will be based on pre-launch commitments, and Chaos Labs will adjust the recommended values if realized liquidity following the chain launch falls short of pre-launch assumptions and commitments.

MegaETH Network Overview

The initial ecosystem-relevant liquidity for the Aave launch is expected to be split between two main venues. Kumbaya is positioned as the primary AMM venue for initial liquidity, while World Capital Markets (WCM) is expected to provide spot CLOB execution with market-making guarantees by the MegaETH team on key pairs.

MegaETH currently adopts an OP Stack for ETH and ERC-20 bridging from Ethereum to MegaETH, running OP Stack’s Standard Bridge with minor parameter adjustments. Deposits finalize after Ethereum finality, while withdrawals inherit the standard optimistic bridge delay, commonly on the order of seven days.

While bridging ERC20 tokens will be available through the canonical bridge, it is expected to be meaningfully expanded via third-party bridge and routing integrations. This addition meaningfully reduces the bridging of MegaETH assets to the Ethereum Mainnet, enabling more efficient arbitrage and peg stability.

Oracle and pricing infrastructure

MegaETH, in collaboration with Chainlink, has integrated Chainlink Data Streams through a native precompile. This model enables access to per-block market data, improving latency and pricing accuracy for fast-moving markets.

The benefits, particularly tighter oracle freshness and reduced liquidation latency, are promising but hinge on the robustness of the integration under adversarial conditions. Specifically, given the higher frequency of updates, the feeds are exposed to a higher risk of market manipulation.

Until the reliability and safety of Data Streams are fully validated, Chaos Labs recommends adopting standard Chainlink Oracle feeds for Aave’s initial deployment on the MegaETH chain.

Market Making Agreement

MegaETH Team has communicated the presence of a market-making agreement in place to bootstrap the WCM spot market orderbooks. This agreement materially strengthens price formation for the major volatile spot pairs relevant to BTC and ETH by committing to top-of-book spreads and minimum executable depth on both sides of the book from Day 1.

For BTC-USDm and ETH-USDm, the liquidity provider is required to maintain a top-of-book bid/offer spread at or below 0.05% with at least 98% KPI uptime, while also quoting meaningful depth bands of approximately $50k within 25 bps, $100k within 50 bps, and $250k within 100 bps per side.

This combination of spread and depth requirements establishes a reliable arbitrage surface against external reference venues, as any sustained divergence from CEX pricing creates immediate economic incentive for arbitrageurs to trade into WCM, compressing basis and stabilizing the onchain mid-price. Although the committed depth is not sufficient to absorb very large liquidation flows in a single print without impact, it is sufficient to support gradual execution, where liquidations can be processed in increments while arbitrage refills the book and re-anchors quotes. Because WCM runs natively on MegaETH without cross-venue bridging latency, the orderbook liquidity is effectively part of the same onchain liquidity domain as AMM pools, improving cross-venue price alignment and reducing the persistence of AMM dislocations relative to oracle prices.

Assets

WETH

WETH can be bridged via MegaETH’s canonical OP Stack Standard Bridge from Ethereum, with deposits finalizing after Ethereum finality and withdrawals inheriting optimistic bridge delays. Initial liquidity is expected to be primarily bootstrapped on Kumbaya via team-committed WETH/USDM and WETH/USDT0 pools, and secondarily supported by CLOB liquidity on WCM via ETH/USDM quoting commitments.

Following discussions with the MegaETH team, we expect the initial TVL of the WETH/USDM and WETH/USDT0 liquidity pools to be $33.3M combined.

Given the pre-launch nature of liquidity, we recommend configuring WETH as collateral only within WETH/Stablecoin E-Mode (USDT0/USDM) and enabling its borrowability only within the LST/LRT E-Modes.

Chaos Labs recommends aligning the LTV/LT parameters and the IR Curve of WETH with those on Ethereum Core and Plasma Instance.

The initial supply and borrow cap of WETH and the other assets in this analysis are calibrated on the liquidity commitments provided by the team.

Chaos Labs will adjust the recommended values if realized liquidity following the chain launch falls short of pre-launch assumptions and commitments.

BTC.b

BTC.b, launched by Lombard following its acquisition from Ava Labs, is a 1:1 BTC-backed asset with permissionless mint/burn and on-chain Proof of Reserve. It operates with cross-chain capabilities via Chainlink CCIP. Following the change of ownership of the product, the subsequent deployments of BTC.b adopt the same architecture of minting/redeeming used for Lombard’s LBTC product.

Liquidity on MegaETH will be driven by a WCM BTC/USDM CLOB and a BTC.b/USDM AMM pool. Per the team’s communication, the expected initial TVL of the BTC.b/USDM AMM pool is expected to be between $2-3M, with an additional commitment of $10M of liquidity available on Ethereum mainnet accessible following the bridging process.

Given BTC.b’s use of new contracts, which have not been adopted by Aave prior to this deployment, the asset should launch as a collateral-only asset in a BTC-stable E-Mode alongside USDT0 and USDM. Conservative risk parameters are warranted given the combined custody and bridging surfaces.

wstETH

ezETH is a restaked ETH token (LRT) whose primary risk drivers, beyond ETH correlation, include restaking-specific tail risks and a reliance on an exchange-rate component for pricing. On MegaETH, ezETH issuance is expected to occur via a cross-chain minting flow involving a HypXERC20Lockbox on Ethereum mainnet. The lockbox transmits cross-chain messages through the HyperLance Mailbox, which are relayed to the Mailbox on MegaETH and validated before invoking the HypXERC20 contract to mint ezETH on L2. Liquidity is expected to be bootstrapped on Kumbaya via a fixed TVL commitment.

Following discussion with the MegaETH team, we are expecting the initial TVL of the Kumbaya wstETH liquidity pools to be of a combined value of $5M.

wstETH should be enabled as collateral and with its borrowing disabled and included in a WETH-correlated E-Mode to support looping/leveraged staking demand. In addition, we recommend wstETH to be included in a separate collateral-to-stables E-Mode, reflecting historically stronger and more persistent demand for wstETH collateral against stable borrowing versus LRT collateral against stables. Stable E-Mode efficiency must remain conditioned on realized sell-side liquidity into USDT0/USDM.

ezETH

ezETH is a restaked ETH token (LRT) whose primary risk drivers, beyond ETH correlation, include restaking-specific tail risks and a reliance on an exchange-rate component for pricing. On MegaETH, ezETH issuance is expected to occur via a cross-chain minting flow involving a HypXERC20Lockbox on Ethereum mainnet. Liquidity is expected to be bootstrapped on Kumbaya via a fixed TVL commitment.

Following discussion with the MegaETH team, we are expecting the initial TVL of the Kumbaya ezETH liquidity pools to be of a combined value of $4M.

At launch, ezETH should be collateral-enabled but restricted to a WETH-correlated E-Mode only, with borrowing disabled. Supply caps should be set from the committed AMM depth.

rsETH

rsETH is a restaked ETH token (LRT) with similar deployment-relevant considerations to ezETH. The bridging path is expected to be LayerZero OFT per team statement, implying unified-supply cross-chain mint/burn. Liquidity is expected to be provisioned on Kumbaya via a fixed TVL commitment.

Following discussion with the MegaETH team, we are expecting the initial TVL of the Kumbaya wrsETH liquidity pools to be of a combined value of $4M.

rsETH should be configured as collateral-enabled with borrowing disabled and restricted to a WETH-correlated E-Mode to support leveraged staking loops while constraining cross-asset liquidation pathways. Caps should be derived from committed liquidity.

USDT0

USDT0 is an omnichain representation of USDT built on LayerZero’s OFT standard, designed to unify liquidity across chains and support native cross-chain movement.

On MegaETH, USDT0 is expected to be a core borrowable stable asset thanks to its presence in the initial team-committed liquidity pools on Kumbaya, and as the redemption destination for USDM’s PSM backstop.

USDT0’s supply and borrow caps should be set as a function of observed and committed stable-stable and stable-ETH depth, with an explicit post-launch adjustment rule once real flows materialize. The interest-rate curve should be aligned with competitive stable markets while maintaining sufficient slope to deter sustained utilization over the kink.

USDM

USDM is MegaETH’s native stablecoin, developed in collaboration with Ethena, and is intended to serve as the canonical unit of account and the primary base liquidity asset across the chain. Its risk assessment must incorporate issuance constraints, redemption mechanics, and the credibility of its liquidity backstops.

USDM minting and redemption are permissioned at the primary layer, with issuance and burning occurring on the Ethereum mainnet, and access is restricted to entities authorized by Ethena (market makers, OTC desks, and authorized bridge operators). Public users are expected to access USDM via secondary markets on MegaETH or via routing/bridging flows that source other stablecoins and swap into USDM. This implies that, unlike fully permissionless stablecoins, USDM’s primary arbitrage loop is concentrated in a limited set of authorized actors, which can be a stabilizing factor in normal conditions but a concentration risk under operational stress.

The mint path is USDC-based at issuance time, with 1:1 issuance against deposited USDC on Ethereum, while reserves are held in USDtb with institutional custody. The design includes a redemption buffer in liquid USDC that is intended to cover near-term redemption demand; per the provided documentation, the steady-state target is approximately 10% of backing in USDC, with an initial higher buffer (25% indicated) to support early-stage redemption intensity and reduce first-week liquidity fragility. When the buffer is exhausted, authorized redeemers may redeem into USDtb directly, which shifts exit liquidity from on-chain/USDC into off-chain/venue-dependent liquidity, increasing sensitivity to operational execution and market conditions.

USDM’s cross-chain movement to MegaETH is expected to occur via OFT-compatible bridges, with minting and burning restricted to Ethereum. This architecture reduces the need for AMM-based bridge liquidity but introduces a reliance on bridging times to ensure minimal price deviations and dependence on the operational security of the OFT bridge stack. In addition, the public onboarding flow described by the team introduces a “solver/market-maker intervention” path: if on-chain USDM depth is insufficient, a designated authorized entity can mint USDM on Ethereum and supply it at par to complete a user’s conversion. This mechanism can materially reduce slippage for users, but it also increases reliance on a small authorized set to maintain the peg during adverse conditions.

The most important stabilization mechanism for USDM on MegaETH is a Peg Stability Module (PSM) backstop that guarantees 1:1 swaps between USDM and USDT0 during stress events or periods of thin liquidity. The stated flow uses a Redemption Contract that routes requests to a Settlement Contract pulling USDT0 liquidity to complete par exits. For Aave risk, the PSM is highly relevant because it can transform liquidation outcomes: if USDM is widely used as the borrowed unit, the ability for liquidators and borrowers to access USDT0 at par under stress reduces the probability of disorderly stablecoin cascades.

Given USDM’s centrality to MegaETH, Aave’s configuration should treat it as a core borrowable stablecoin but with launch parameters explicitly conditioned on realized depth in USDM pairs and on the observable readiness of the PSM backstop. Supply and borrow caps should be derived from committed stable liquidity (USDT0/USDM) plus any additional stable routes, with a conservative haircut for venue concentration and for the fact that early flows are likely to be programmatic. The interest rate curve should be designed to avoid sustained extreme utilization in the first phase, as high utilization in a stablecoin whose primary redemption loop is permissioned increases run-like dynamics if confidence is challenged. Oracle design should assume a standard $1 target with conservative upward caps and clear fallback behavior until a production-grade feed is confirmed; the recommended approach is to avoid any configuration that depends on millisecond oracle updates for USDM solvency, even if Data Streams are available, until those feeds are validated under mainnet conditions.

Oracle/Pricing Methodology

This section outlines the recommended pricing configuration for the proposed assets on MegaETH. The objective is to ensure consistent, robust, and conservative price formation aligned with existing Aave v3 standards, while accounting for asset-specific characteristics such as yield accrual.

WETH

WETH pricing is recommended to use the standard ETH-USD oracle feed.

BTC.b

BTC.b pricing is recommended to use the BTC-USD oracle feed. As the use of BTC.b’s specific price feed would introduce meaningful deviation risk stemming from reduced liquidity and market efficiency.

USDT0

USDT0 pricing is recommended to use the USDT-USD oracle feed. In addition, a stable CAPO cap is recommended to bound upward price deviations.

USDM

USDM is recommended to be hardcoded to 1 USD as its lack of collateral status prevents this setup from presenting arbitrage risk during temporary downward market deviations. At the same time, in a true fundamental depeg scenario, where USDM’s backing, redeemability, or market structure is impaired and its market price trades below $1 for a sustained period, the static oracle maintains a conservative posture for the protocol. Debt continues to be booked at 1 USD while the asset’s market value falls. From the protocol’s perspective, this improves resilience: liquidators can source USDM more cheaply to repay a 1 USD unit of debt, increasing liquidation profitability and reducing the likelihood of bad debt.

wstETH

Pricing is recommended to use the ETH-USD oracle feed as the base price, combined with a wstETH-stETH exchange rate oracle to reflect reward accrual. A dynamic CAPO adaptor is recommended to constrain extreme price movements while allowing gradual exchange rate evolution.

wrsETH

Pricing is recommended to use the ETH-USD oracle feed as the base price, combined with a wrsETH-ETH exchange rate oracle to reflect reward accrual. A dynamic CAPO adaptor is recommended to constrain extreme price movements while allowing gradual exchange rate evolution.

ezETH

Pricing is recommended to use the ETH-USD oracle feed as the base price, combined with an ezETH-ETH exchange rate oracle to reflect reward accrual. A dynamic CAPO adaptor is recommended to constrain extreme price movements while allowing gradual exchange rate evolution.

Specifications

Parameters Value Value Value Value Value Value Value
Asset WETH BTC.b USDT0 USDM wstETH wrsETH ezETH
Isolation mode No No No No No No No
Borrowable No No Yes Yes No No No
Collateral Enabled No No No No No No No
Supply Cap 50,000 120 50,000,000 100,000,000 12,000 10,000 10,000
Borrow Cap 46,000 - 46,000,000 95,000,000 - - -
Debt Ceiling - - - - - - -
LTV - - - - - - -
LT - - - - - - -
Liquidation Bonus - - - - - - -
Liquidation Protocol Fee 10% 10% 10% 10% 10% 10% 10%
Variable Base 0.0% - 0.0% 0.0% - - -
Variable Slope1 2.50% - 5.0% 5.0% - - -
Variable Slope2 8.00% - 10.0% 10.0% - - -
Uoptimal 90.0% - 90.0% 90.0% - - -
Reserve Factor 15% - 10% 10% - - -
Stable Borrowing Disabled Disabled Disabled Disabled Disabled Disabled Disabled
Flashloanable Yes Yes Yes Yes Yes Yes Yes
Siloed Borrowing No No No No No No No
Borrowable in Isolation No No Yes Yes No No No
E-Mode WETH/Stablecoins, wstETH/WETH, wrsETH/WETH, ezETH/WETH BTC.b/Stablecoins wstETH/Stablecoins, WETH/Stablecoins, BTC.b/Stablecoins wstETH/Stablecoins, WETH/Stablecoins, BTC.b/Stablecoins wstETH/WETH, wstETH/Stablecoins wrsETH/WETH ezETH/WETH

E-Mode Configurations

WETH Stablecoins #1

Parameter Value Value Value
Asset WETH USDT0 USDM
Collateral Yes No No
Borrowable No Yes Yes
Max LTV 80.50% - -
Liquidation Threshold 83.00% - -
Liquidation Bonus 5.50% - -

BTC.b Stablecoins #2

Parameter Value Value Value
Asset BTC.b USDT0 USDM
Collateral Yes No No
Borrowable No Yes Yes
Max LTV 70.00% - -
Liquidation Threshold 75.00% - -
Liquidation Bonus 6.50% - -

wstETH Stablecoins #3

Parameter Value Value Value
Asset wstETH USDT0 USDM
Collateral Yes No No
Borrowable No Yes Yes
Max LTV 75.00% - -
Liquidation Threshold 79.00% - -
Liquidation Bonus 6.50% - -

wstETH Correlated #4

Parameter Value Value
Asset wstETH WETH
Collateral Yes No
Borrowable No Yes
Max LTV 94.00% -
Liquidation Threshold 96.00% -
Liquidation Bonus 1.00% -

wrsETH Correlated #5

Parameter Value Value
Asset wrsETH WETH
Collateral Yes No
Borrowable No Yes
Max LTV 93.00% -
Liquidation Threshold 95.00% -
Liquidation Bonus 1.00% -

ezETH Correlated #6

Parameter Value Value
Asset ezETH WETH
Collateral Yes No
Borrowable No Yes
Max LTV 93.00% -
Liquidation Threshold 95.00% -
Liquidation Bonus 1.00% -

CAPO

Asset maxYearlyRatioGrowthPercent ratioReferenceTime MINIMUM_SNAPSHOT_DELAY
wstETH 9.68% Monthly 7
wrsETH 6.67% Monthly 14
ezETH 10.89% Monthly 14

Disclaimer

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

Copyright

Copyright and related rights waived via CC0

Chaos Labs - Monthly Community Update
27

Greetings Aave Community,

We’re updating the specifications for this ARFC to present two options on incentive and revenue structures provided by MegaETH.

Option 1 - Points Program + Revenue Guarantee (with Rollover)

User Incentives

MegaETH will distribute 30 million points to Aave users on MegaETH during the mainnet launch period. If Option 1 is selected, the points campaign will run only after the MegaETH mainnet is live and will be distributed over a defined campaign window.
Revenue Guarantee

For each of the first 5 years after the Aave market launches on MegaETH, the DAO is guaranteed at least USD $2,000,000 per year in protocol revenue generated by the MegaETH Aave market.

  • If annual revenue is below $2,000,000, MegaETH will pay the difference to the DAO within 30 days after the end of that year.

  • If annual revenue exceeds $2,000,000, the excess rolls forward and counts toward meeting the $2,000,000 minimum in future years.

  • There is no cap on how much excess revenue can roll forward, and excess revenue may roll over across multiple years.

Example
Year 1 revenue: $5,000,000

  • $2,000,000 satisfies Year 1 guarantee

  • $3,000,000 rolls forward to Year 2

Year 2 revenue: $1,000,000

  • The $3,000,000 carried forward from Year 1 covers the full Year 2 guarantee

  • No payment is required from MegaETH in Year 2

Option 2 - Revenue Guarantee Only (Points Not Guaranteed)

User Incentives

No points program is guaranteed under this option. However, MegaETH may, at its sole discretion, choose to run user incentive or points campaigns in the future. Any such incentives are not committed, not guaranteed, and not part of this option.

Revenue Guarantee

For each of the first 5 years after the Aave market launches on MegaETH, the DAO is guaranteed at least USD $2,000,000 per year in protocol revenue generated by the MegaETH Aave market.

  • If annual revenue is below $2,000,000, MegaETH will pay the difference to the DAO within 30 days after the end of that year.

  • If annual revenue exceeds $2,000,000, the excess does not carry forward and does not offset future years.

Example

Year 1 revenue: $5,000,000

  • $2,000,000 satisfies Year 1 guarantee

  • The additional $3,000,000 does not carry forward

Year 2 revenue: $1,000,000

  • MegaETH pays $1,000,000 to reach the $2,000,000 minimum

MegaETH shall have no payment obligation unless and until the DAO approves the launch proposal and the Aave market is actually deployed on MegaETH with USDM listed under parameters defined at the AIP stage. The annual revenue guarantee period shall commence from the Aave market launch date on MegaETH.

We will edit the original post to include these two options in the Specifications section so the thread stays consistent for reviewers.

Next steps are to collect community feedback on the preferred option, and to proceed with the risk assessment analysis for initial launch parameters and the initial asset set.

Once the community is ready to escalate this proposal to snapshot, the voting options will be:

  1. Option 1 (Points Program + Revenue Guarantee (with Rollover))

  2. Option 2 (Revenue Guarantee Only (Points Not Guaranteed))

  3. NAE (Do not proceed with MegaETH deployment under these terms)

  4. ABSTAIN

Aave Labs

4 Likes
28

I’m leaning toward Option 2, revenue guarantee only. It keeps things simple and the DAO gets a guaranteed $2M/year without having to manage points or anything. v4 is coming up and it’s already a lot of work and Aave Labs has too much on their plate.

If MegaETH wants to run their own user incentives later, that’s fine, they can do it at their own discretion. We don’t have to commit upfront and revenue is guaranteed with fewer moving parts.

Let’s vote.. Aave will win

2 Likes
29

Hello, could the DAO please know in what way megaeth intends to pay the difference to the DAO?
Will it be stablecoins?
Because native token shouldn’t be even considered by the DAO at all.

4 Likes
30

Well, it’s not really that Aave Labs was in charge of the points programs. That was more the responsibility of growth providers like ACI, so your concern is probably unfounded

31

If the deployment does not bring in $2M in revenue for a given year, MegaETH will cover the difference in stablecoins within 30 days of the end of that year.

4 Likes
32

Summary

LlamaRisk supports the initial parameters for the deployment of Aave V3 on MegaETH. At least $62.8M in initial liquidity commitments has been confirmed internally across core pairs to bootstrap the ecosystem. These efforts ensure that the instance launches with sufficient depth to support liquidations and scaling.

We believe that it is rational to launch the instance with a subset of initially proposed assets, also restricting all borrowing to E-Modes uniquely. After the initial phase, additional asset listing proposals are expected to follow, each of which will be reviewed in depth by LlamaRisk and other SPs.

Initial Setup

Aave’s MegaETH instance will be initially structured to enforce all borrowing to happen exclusively under E-Modes. This is enabled by the Aave V3.6 update and ensures future flexibility for collateral isolation. Therefore, the market will be structured around USDm as the primary stablecoin, together with USDT0 as a bluechip stablecoin choice. As of now, the market will heavily depend on ETH-correlated assets as well as BTC.b on the collateral side.

The initially proposed yield-bearing stablecoins (cUSD, stcUSD, USDe, sUSDe) are planned to be deployed at a later time after the initial market deployment. This also holds for iTRY and wiTRY, which represent a novel asset type not yet approved and included in the Asset Class Allowlist. Nonetheless, we are in touch with the respective teams (Cap and Brix) and are carrying out internal due diligence in order to prepare for the eventual deployment proposals of these assets.

Chain-Specific Asset Evaluations

Note: USDm is a novel asset not yet onboarded on other Aave markets; BTC.b has recently been acquired by Lombard and shifted to a different technical setup, therefore, both of these assets required in-depth asset reviews, presented in separate responses on this forum thread.

USDT0 (LayerZero OFT)

USDT0 serves as the canonical representation of USDT on MegaETH.

  • Standard: Powered by the LayerZero’s OFT standard.
  • Mechanism: Uses a lock-and-mint architecture on Ethereum Mainnet (via OFTAdapter), ensuring 1:1 backing and cross-chain interoperability without fragmented liquidity pools.
  • Access Controls: The contract is an upgradable OpenZeppelin Transparent Proxy. Ownership and ProxyAdmin functions are controlled by a 3/5 Safe Multisig, with the OFT Contract acting as the authorized minter/burner adapter.

As the chain is in the private mainnet mode, the total supply of the asset is yet to be fully bootstrapped, with a 32.5M total supply, 4.5M of which resides in a Uniswap V3 USDm/USDT0 pool.

image
image2458×590 66.7 KB

Source: MegaETH Blockscout, January 27, 2026

WETH

WETH is the standard wrapped native asset representation on MegaETH.

  • Standard: Non-upgradable contract that wraps the chain’s native asset into an ERC20-compatible representation.
  • Mechanism: Users mint WETH by bridging native ETH through the canonical bridge.
  • Access Controls: The underlying ETH locked on Ethereum Mainnet is controlled by the MegaETH network’s 4/8 Safe Multisig. The L2 token contract itself is non-upgradeable.

The total supply of WETH on MegaETH is 114.2, with most of the supply flowing into Uniswap V3 pools and other contracts, potentially representing preparatory steps for liquidity bootstrapping.

image
image2456×980 230 KB

Source: MegaETH Blockscout, January 27, 2026

wstETH

wstETH is the bridged representation of Lido’s wrapped staked ETH, utilizing Chainlink CCIP.

  • Standard: Upgradable OpenZeppelin Transparent Proxy using the BurnMintERC20Transparent implementation.
  • Mechanism: Cross-chain issuance operates via the Chainlink CCIP lock-and-mint bridge. The SiloedLockReleaseTokenPool locks tokens on Mainnet, while the BurnMintTokenPool on MegaETH handles minting and burning upon receiving verified CCIP messages.
  • Access Controls: The Proxy Admin is a 3-hour RBACTimelock. This structure introduces a standard delay for proxy upgrades and configuration changes.

At the time of writing, there is no supply of wstETH available on MegaETH.

ezETH

ezETH is the bridged representation of Renzo’s liquid restaking token.

  • Standard: Upgradable Transparent Proxy using XERC20 standard.
  • Mechanism: Cross-chain integration leverages Hyperlane. A HypXERC20Lockbox on Mainnet transmits messages via the HyperLance Mailbox. Relayers deliver these to MegaETH, where the HypXERC20 contract validates and mints ezETH.
  • Access Controls: The Implementation Proxy is currently controlled by a 3/6 Safe Multisig.

At the time of writing, there is no supply of ezETH available on MegaETH.

wrsETH

wrsETH is the bridged representation of Kelp DAO’s liquid restaking token.

  • Standard: Upgradable Transparent Proxy utilizing the RsETHTokenWrapper implementation.
  • Mechanism: The asset wraps the rsETH OFT version. It utilizes LayerZero for cross-chain functionality, where the rsETH OFT adapter acts as the facilitator to receive bridge messages and mint/burn tokens.
  • Access Controls: A 3-day TimelockController governs critical functions, including the list of assets eligible for native minting. The ProxyAdmin is also subject to this 3-day Timelock.

At the time of writing, there is minimal supply of wrsETH available on MegaETH.

Asset Liquidity

The heuristics used to determine adequacy for initial supply and borrow caps are based on the following:

  • Projected Price Impact: Based on the $62.8M in confirmed initial commitments, we anticipate that once deployed, liquidity will be sufficient to support a target price impact threshold of 5-7.5% for core collateral assets. These projections are anchored by significant commitments in WETH and stable/stable pairs.
  • Contingency on Deployment: The proposed parameters and caps outlined in this document are preliminary. A final validation of realized liquidity depth and DEX router efficiency will be required post-deployment to ensure that the Aave Effect and committed bootstrapping efforts meet the necessary safety requirements for scaling.
  • Correlated E-Modes: In this deployment, each asset will be assigned its own specific E-Mode, limiting the borrowing to bluechip (BTC.b, WETH and wstETH) stablecoin borrowing and LST/LRT (wstETH, wrsETH, ezETH) WETH borrowing. This allows for higher capital efficiency while isolating the specific risk profiles of different providers.
Assets Committed DEX Liquidity Proposed Supply Cap
USDm ~$16.60M $50.00M
USDT0 ~$16.60M $50.00M
WETH ~$23.10M 50.00K (~$179M)
wstETH ~$2.50M 12.00K (~$43M)
wrsETH ~$2.00M 10.00K (~$36M)
ezETH ~$2.00M 10.00K (~$36M)
BTC.b ~$3M 120 (~$10M)

The following commitments have been confirmed with strategic partners to ensure deep liquidity at launch. We further expect that targeted incentive programs as well as DEX launches will immediately grow the liquidity TVL at the time of deployment.

Core Stable & ETH Pairs

Pairs Committed Liquidity TVL DEX Venue
WETH / USDm $16.6M Kumbaya
WETH / USDT0 $16.6M Kumbaya
USDT0 / USDm $16.6M Kumbaya
BTC.b/USDm up to $3.00M TBD

Correlated LST/LRT Pairs

Pairs Committed Liquidity TVL DEX Venue
wstETH / WETH $5.0M Kumbaya
wrsETH / WETH $4.0M Kumbaya
ezETH / WETH $4.0M Kumbaya

Perps and Spot Trading Platforms

A novelty introduced by the MegaETH’s architecture is the capability to support real-time trading platforms, such as the WCM exchange. Since such exchanges will reside fully onchain, the orderbook liquidity will also become an integral part of chain’s overall liquidity flows. Therefore, instead of solely focusing on DEX liquidity levels, liquidations on Aave will also be supported by liquidity on the native, orderbook-based exchanges.

Parameter Recommendations

Parameters have been agreed jointly with @ChaosLabs. We also agree on the approach of using regular Chainlink Price Feeds as of the initial launch.

Disclaimer

This review was independently prepared by LlamaRisk, a community-led non-profit 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.

LlamaRisk - Monthly Community Update
33

MegaETH USDm Asset Review

Summary

LlamaRisk supports the onboarding of USDm to the MegaETH instance, acknowledging its unique structure as a whitelabel stablecoin powered by Ethena’s infrastructure. USDm functions as a bridged stablecoin (via LayerZero OFT) backed primarily by off-chain real-world assets (BlackRock’s BUIDL). While the asset benefits from Ethena’s established operational stack and multiple security audits (Quantstamp, Zellic, Spearbit, Pashov), we highlight the layers of infrastructural dependency. Ultimately, we believe that the asset structure is fit to become the main stablecoin of Aave’s MegaETH market.

Collateral Risk Assessment

1. Asset Fundamental Characteristics

1.1 Asset

USDm is the native stablecoin of the MegaETH network, issued through Ethena’s whitelabel stablecoin infrastructure. The asset is designed to be fully backed, with reserves primarily invested in BlackRock’s tokenized U.S. Treasury fund (BUIDL) via Securitize, alongside a portion of on-chain stablecoins (USDC) held to facilitate immediate redemptions.

1.2 Architecture

USDm may be minted and redeemed against both fiat and stablecoins. For fiat minting and redemption, USDm is first converted into USDtb. On that basis, onboarding with Anchorage Digital Bank (ADB) is required in order to become an eligible Client under the applicable Terms.

USDm’s backing is primarily provided through USDtb, with a portion of the backing held in USDC to service redemptions. USDtb, in turn, is backed by BUIDL and USD.

Reserve commitments are reflected in the Anchorage Terms, which state that all Covered Stablecoins issued by ADB, i.e., USDtb, are backed by assets with an aggregate market value, as of the end of each business day, at least equal to the aggregate number of outstanding Covered Stablecoins. ADB publishes information regarding the composition of the Covered Stablecoin Reserve as required by applicable U.S. federal law.

The team represents that all USDm reserves are held by qualified custodians, including Anchorage Digital Bank and Coinbase Custody. Given that the USDtb transparency page identifies Anchorage Digital Bank as the sole custodian, it may be assumed that the remaining portion of USDm backing held in USDC is maintained with Coinbase Custody.

2. Market Risk

2.1 Liquidity

As USDm is to be launched at the mainnet deployment of MegaETH, liquidity data is not yet available. Liquidity is expected to be bootstrapped via internal efforts and commitments from external parties. USDm is provisioned to be paired with ETH-correlated assets, BTC, and USDT0. The exact confirmed commitments are as follows:

Pairs Committed Liquidity TVL DEX Venue
WETH / USDm $16.6M Kumbaya
USDT0 / USDm $16.6M Kumbaya
BTC.b/USDm up to $3.00M TBD

We expect that targeted incentive programs as well as DEX launches will immediately grow the liquidity TVL at the time of deployment, especially as USDm is viewed as the main stablecoin for the MegaETH network.

2.2 Exchanges

Given the primary chain stablecoin label. USDm is expected to be deployed on all native DEXs, as well as the more established and mature DEXs that will be deployed on MegaETH immediately or shortly after the mainnet launch.

3. Technological Risk

3.1 Smart Contract Risk

The USDm system is built on two primary components: the token contract (xUSDOFTUpgradeable) and the minting entry point (USDmMinting).

  • Token Contract: Utilizing the LayerZero OFT standard, the token is an upgradable OpenZeppelin Proxy contract. This standard facilitates cross-chain transfers, blacklist controls, and rate-limited bridging.
  • Minting Contract: A non-upgradable contract governing the mint/redeem flow. It utilizes role-based access control where authorized operators execute orders signed by users. It enforces global and per-asset caps per block and includes an emergency gatekeeper mechanism to halt operations.

The underlying codebase and infrastructure of the Ethena issuance layer have been audited by multiple firms, including Quantstamp, Zellic, Spearbit, and Pashov. We will confirm whether the audits have also been carried out for the extending USDmMinting contract or any peripheral contracts.

3.2 Bug Bounty Program

While specific details for a standalone USDm bounty were not provided, MegaETH currently does not have an active bug bounty program or plans to have one in the near future, as confirmed by the MegaETH team. Therefore, we can expect that this applies to USDm as well.

3.3 Price Feed Risk

We agree on the approach of initially pricing USDm using a fixed 1 USD price feed. Given the asset’s design as a permissioned, reserve-backed stablecoin and the borrowable-only configuration on Aave, this standardizes the peg assumptions while relying on the underlying collateral quality (USDtb and BUIDL dependencies) to be maintained. Nonetheless, as the liquidity and TVL of USDm scale, it may be rational to move towards a stable USDm/USD market price feed of Chainlink.

3.4 Dependency Risk

USDm introduces several dependencies:

  • LayerZero: The asset relies on LayerZero’s OFT standard and endpoints for all cross-chain bridging and message passing.
  • Custodial Risk: The value of USDm is dependent USDtb (directly), BUIDL (indirectly), and USDC held in custody.
  • Operational Dependencies: The MINTER_ROLE is operated by EOAs (protected by HSMs) performing mints based on off-chain policy engines. Failure or compromise of these off-chain coordination layers could impact mint/redeem functionality.

4. Counterparty Risk

4.1 Governance and Regulatory Risk

Our initial focus for the legal analysis has been MegaETH’s Terms, which are drafted as a broad website/platform agreement but expressly sweep in “the pre-deposit bridge flow interface, USDm minting functionality, [and] vault services” within the defined “Services.” The Terms state that the contract is between the user and “MegaETH Foundation (including all its affiliates and subsidiaries)” (defined as the “Company”), and they hardwire Cayman Islands governing law.

The Terms frame USDm minting access as restricted: they require KYC for the “pre-deposit bridge flow,” require AML checks and whitelisting, and they expressly state that “United States-based users are not eligible to participate in the pre-deposit bridge flow or USDm minting services powered by Ethena.” In practice, this means the only clearly documented “rights” around USDm in this agreement are not holder-rights in the asset; rather, they are conditional “platform access” rights to participate in MegaETH’s gated minting/bridging workflow, which are revocable at will (including for compliance reasons).

The Terms describe an operational sequence: users deposit USDC; MegaETH integrates with the Ethena protocol for USDm minting; and USDm is then bridged to MegaETH mainnet via LayerZero. Critically, in the Third-Party Services section, the Terms go further and describe “limited operational roles,” including (i) “a Vault Contract on Ethereum mainnet that receives and holds USDC deposits with multi-signature governance controls hosted by the Company,” and (ii) MegaETH maintaining “whitelisted addresses authorized to call” Ethena “Minter Contracts,” thereby triggering Ethena to release USDm 1:1 against deposited USDC, plus (iii) OFT bridging via LayerZero.

However, none of the foregoing constitutes a legal characterization of USDm itself. The Terms do not state whether USDm is (for example) a claim on an issuer, a claim on specific reserves, a contractual redemption right against any person, a settlement token with no issuer obligations, or something else. While the Terms contemplate a “pre-deposit bridge flow” and USDm “minting functionality,” they do not provide a clean set of mint/redeem terms on which a holder could reasonably rely (eligibility aside). They do not clearly state who owes redemption, at what price, within what time, with what fees, subject to what suspensions, or what happens in the event of downtime or insolvency.

On the issuance perimeter, Ethena’s USDtb documentation states that, as of the current documents, only customers of Anchorage Digital Bank can mint and redeem USDtb, and the legal terms position Anchorage Digital Bank as sole issuer/obligor for its “Covered Stablecoins,” with Non-Clients having no contractual rights against the bank except as may arise under applicable law. Hence, USDm could be viewed as an Ethena-mediated minted-and-bridged token that is operationally backed by a reserve rail but does not itself confer a direct contractual redemption right for most holders, with redemption effectively limited to participants who pass KYC/AML and are permitted to access the minting workflow.

Because USDm’s legal nature (issuer, obligor, and the holder’s claim) is not defined in the Terms—despite explicitly marketing “USDm minting functionality” as part of the Services and disclaiming liability for depeg/redemption/liquidity failures—we sought further clarification from the MegaETH team on this issue of significant importance. As of the date of this write-up, a special purpose vehicle has been incorporated in the BVI to support the minting flow of USDm, namely MegaUSD (BVI) Ltd. USDm is issued by MegaUSD (BVI) Ltd, which is wholly owned by MegaUSD Foundation, a vehicle stated to be independent of both Mega and Ethena, with Ethena Labs acting as a service provider to MegaUSD (BVI) Ltd.

4.2 Access Control Risk

4.2.1 Contract Modification Options

The USDm token (xUSDOFTUpgradeable) utilizes the upgradable proxy pattern. Currently, the ownership and admin role is held by a 4/9 Safe Multisig (the same multisig setup as USDe and USDtb). The signers list is as follows:

4.2.2 Timelock Duration and Function

There is currently no on-chain Timelock enforcing a delay on administrative actions. However, Ethena and MegaETH teams have confirmed that both the upgradable admin and master admin roles for USDm will be transferred to a Timelock contract.

4.2.3 Main Contract Roles

The system is governed by the above-mentioned 4/9 Safe Multisig, which controls the Owner and Admin roles. This multisig has high-level privileges, including managing minters, blacklisters, and rescue recipients.

  • Minter Roles: The MINTER_ROLE and REDEEMER_ROLE are assigned to 10 specific EOAs at the time of writing. Ethena has confirmed these EOAs are protected via Hardware Security Modules (HSM) and subject to internal KYB processes.
  • Collateral Custody: The COLLATERAL_MANAGER_ROLE can transfer held collateral to approved custodians. The sole approved custodian is a Coinbase Prime wallet, which requires a 3-signature threshold (internal signers only) to operate.

Parameter Recommendations

Parameters have been agreed jointly with @ChaosLabs.

Disclaimer

This review was independently prepared by LlamaRisk, a DeFi risk service provider funded in part by the Aave DAO. LlamaRisk serves as a member of Ethena’s Risk Committee and an independent attester of Ethena’s PoR solution. LlamaRisk did not receive compensation from the protocol(s) or their affiliated entities for this work. The information should not be construed as legal, financial, tax, or professional advice.

LlamaRisk - Monthly Community Update
34

MegaETH BTC.b Asset Review

Summary

LlamaRisk supports onboarding BTC.b to the MegaETH instance with conservative initial parameters and a monitoring posture until liquidity and organic market depth mature. BTC.b is presented as a 1:1 BTC-backed bridged BTC representation with publicly described PoR monitoring, and the bridging architecture is built around a separation of concerns between the user-facing token contract and the cross-chain issuance stack. The audit review reported no critical or high-severity findings, and all identified issues were resolved, while Lombard also maintains an active Immunefi bug bounty. Governance and access control are clearly defined and operationally constrained via an AdminProxy multisig (3/5) and a 24-hour on-chain timelock for administrative actions on MegaETH. The Lombard team plans to seed approximately $2–3M in initial liquidity at launch and subsequently scale this up to around $10M.

The post will be amended with the regulatory and legal screening section once Lombard completes the clarification request posed internally.

Collateral Risk Assessment

1. Asset Fundamental Characteristics

1.1 Asset

BTC.b is Lombard’s bridged Bitcoin asset designed for multi-chain DeFi use. It is positioned as a permissionless BTC-onchain bridge, where users can mint by depositing BTC on Bitcoin, after which BTC.b is issued on supported EVM chains, with each BTC.b being 1:1 backed by native BTC and the backing published on-chain using Chainlink Proof of Reserve, with an additional verification component via Cubist Bascule.

1.2 Architecture

Lombard positions BTC.b as a 1:1 BTC-backed bridged Bitcoin asset that is always redeemable for BTC, with reserve verification presented through its Proof-of-Reserve framework and product feeds; the PoR page states a verified reserves ratio of 1 BTC.b to 1 BTC. Lombard’s product page highlights a fixed-fee model with a zero minting fee and a redemption fee of 0.0001 BTC. The minimum minting amount is 0.0002 BTC with no maximum.

image
image1345×727 60.8 KB

Source: Lombard, January 26, 2026

Key smart contracts:

  • BTC.b: ERC-20 representing BTC exposure on MegaETH.
  • AssetRouter: Handles deposit/redemption orchestration and fee accounting.
  • BridgeV2: Bridge execution contract for burn-and-mint transfers.
  • LombardTimelock: OpenZeppelin 24 hours TimelockController.
  • LombardTokenPoolV2: Chainlink CCIP TokenPool integration that acts as the CCIP-facing gateway into BridgeV2.

BTC.b on MegaETH follows a layered design where the BTC.b token is the user-facing ERC-20 representation, while cross-chain issuance is handled by the bridging stack. AssetRouter acts as the canonical entry point to initiate deposits/redemptions and route payloads, BridgeV2 enforces the core burn-and-mint bridging logic and finalizes mints only upon accepted inbound messages, and LombardTokenPoolV2 provides the CCIP-facing transport adapter on Ethereum that translates CCIP lock/burn and release/mint flows into BridgeV2-compatible deposit/finalization operations.

Lombard’s architecture is split across five components: the Lombard Ledger (a CometBFT-based chain) operated by a Security Consortium is the system-of-record for deposits, mints, redemptions, and cross-chain transfers, and actions require approval from two-thirds of consortium members; BTC deposits are considered valid after 6 confirmations. Cubist CubeSigner provides HSM-backed signing where key material is not exposed to operators and signing is constrained by policy. Cubist Bascule Drawbridge performs independent verification: it verifies BTC deposits prior to mint authorization and, for withdrawals, verifies that tokens were burned before authorizing BTC payout (reverse verification).

image
image1920×1080 136 KB

Source: Lombard, January 27, 2026

Onchain, BTC.b contracts implement minting/redemption and Chainlink CCIP integration for cross-chain transfers, with administrative safety controls (e.g., pause and timelocked two-step upgrades). A Trustless Relayer automates monitoring and execution steps but is limited to operational roles.

1.3 Tokenomics

Given the closed private mainnet deployment of BTC.b on MegaETH, the current on-chain circulation remains limited, with total supply presently around 0.002 BTC.b.

1.3.1 Token Holder Concentration

image
image1544×775 75.3 KB

Source: BTC.b token holders, January 27, 2026

2. Market Risk

2.1 Liquidity

DEX liquidity for BTC.b on MegaETH has not yet been established. The Lombard team plans to seed approximately $2–3M in initial liquidity into USDm/BTC.b pools at launch. The DEX venues that BTC.b will initially be deployed are to be confirmed.

3. Technological Risk

3.1 Smart Contract Risk

The bridge codebase (BridgeV2, BTC.b contracts, and associated CCIP pool components) was reviewed by OpenZeppelin on October 24, 2025, including the adapter layer used for non-standard assets. During the audit process, 16 issues in total were found (all resolved)—0 critical, 0 high, 4 medium, 5 low, and 7 informational.

Medium findings (core risk themes): TokenPool deployment may fail if a token does not implement decimals(); destination-token configuration is not cross-checked between Pool contracts and Bridge mappings (mismatch risk); an unnecessary infinite approval increases potential blast radius; and limited deposit input validation can lead to transfers that cannot finalize on the destination chain (stuck finalization).

Low and informational items: additional validation gaps, inconsistencies in route introspection, and documentation/maintainability cleanup (docstrings, redundant mappings, unused imports, interface signaling, security contact metadata).

3.2 Bug Bounty Program

Lombard has a public bug bounty run via Immunefi. The Immunefi listing shows rewards up to $250,000 (critical bugs are described as 10% of funds affected up to $250k, with a $50k minimum for critical).

3.3 Price Feed Risk

We recommend pricing BTC.b using the Chainlink BTC/USD market price feed.

3.4 Dependency Risk

BTC.b depends on the Bitcoin network for deposit finality and redemption settlement (including confirmation assumptions and congestion-driven delays) and also relies on Lombard’s off-chain coordination layer (the Lombard Ledger/Security Consortium and relayer operations) to correctly sequence deposit verification, mint authorization, and withdrawal processing, creating liveness and governance/operations risk if the consortium cannot reach the threshold or if relayer automation fails.

CubeSigner from Cubist

Consistent with our prior LBTC analysis, Cubist CubeSigner remains a key dependency risk for BTC.b, as it is used for remote key management and transaction signing within Lombard’s operational stack. Because CubeSigner is an offchain, SaaS-based signing system, the effective security posture depends on Cubist-managed HSM infrastructure and internal policy controls that are not fully transparent onchain; this introduces a centralization and operational availability risk relative to fully onchain controls and makes incident response and liveness partially dependent on a third-party service provider.

4. Counterparty Risk

4.1 Governance and Regulatory Risk

This section is to be completed once Lombard completes the clarification request posed internally. We will provide the legal section as a separate update in the same forum thread.

4.2 Access Control Risk

4.2.1 Contract Modification Options

The BTC.b smart contract is deployed as an upgradeable OpenZeppelin TransparentUpgradeableProxy with NativeLBTC as the implementation contract, where NativeLBTC represents BTC exposure on the EVM.

The update process, as proposed/implemented by Lombard, is that upgrades are executed through the proxy admin path of the transparent proxy pattern (i.e., the admin triggers upgradeToAndCall via the ProxyAdmin mechanism rather than upgrading in-place).

4.2.2 Timelock Duration and Function

On MegaETH, Lombard gates BTC.b administrative changes behind a 24-hour on-chain timelock. The timelock contract is implemented as an OpenZeppelin TimelockController with minDelay = 86400 seconds.

4.2.3 Multisig Threshold / Signer identity

Access control on MegaETH is centralized via a 3/5 AdminProxy for BTC.b, AssetRouter, and BridgeV2, with all sensible actions executed through this admin entity. The AdminProxy is controlled by the following signers:

LombardTokenPoolV2 is governed separately via an Ethereum mainnet 3/5 Safe admin multisig. The multisig is controlled by the following signers:

All listed signer keys are controlled by Lombard Finance team members acting in an operational/admin capacity.

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

Parameters have been agreed jointly with @ChaosLabs.

Disclaimer

This review was independently prepared by LlamaRisk, a DeFi risk service provider 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.

LlamaRisk - Monthly Community Update
[Direct to AIP] Onboard BTC.b to Aave V3 Core Instance
35

I would suggest that the ARFC vote has the following voting options.

Option 1
Option 2
Abstain
NO (because no option is good or no for other reasons)

That way everyone can vote on what they think is the best option.

1 Like
36

I see no interest in option 2. I do not even understand how the option can have been considered. There is no engagement except the 2m and we already we what can be the result of incentive without engagement cf Superfest first batch before we publish them our stats. Aave is not a protocol that will lack treasury in the future if treasury is managed as it is currently. Option 2 is a belief that MegaETH will have a more guaranteed treasury than Aave; I am very pessimistic on that.

So option 1 and No are the only objective votes.
Yet if option 2 seems good to some people I’m ok to follow @EzR3aL vote structure

2 Likes
37

@AaveLabs, some tickers you proposed are used by different projects. Could you edit your post to specify their issuer and, if they are already deployed on MegaETH, their address as well? This will reduce the risk of misunderstanding and misconfiguration.

38

In my personal opinion (not on behalf of Aave Labs), option 2 is more attractive for the DAO for two main reasons:

  1. Aave is likely to become the primary lending market on MegaETH. This means it will be used for any looping strategy available on the network, and we can reasonably expect incentives from asset issuers. At the same time, MegaETH would be required to fund the $2M annual commitment, which strongly incentivizes them to remain committed to supporting the Aave market and its growth.

  2. From a financial standpoint, this option 2 is more compelling for the DAO because it effectively guarantees $10M over five years, while preserving full upside every single year. The $2M annual floor is enforced independently each year, meaning the DAO benefits immediately from strong performance without that upside being used to subsidize weaker years in the future.

    In the alternative setup, excess revenue generated in good years is rolled forward to offset future minimum guarantees. While this provides downside protection, it also means that upside is largely front-loaded and can reduce or eliminate effective guarantees in later years. As a result, revenues are more incentive-driven and concentrated in the short term, with less clarity on long-term cash flows.

    In crypto, five years is a very long time, and having predictable, recurring revenue with clean yearly guarantees is meaningfully different from relying on incentives and revenue smoothing across years.

This chart helps give some further context to the discussion.

image
image2048×975 125 KB

Aave’s revenue growth has historically come from deployments where Aave became the default lending market and stayed there over time, rather than from short-lived incentive programs. The chains that contribute the most to cumulative revenue are the ones where Aave has been structurally embedded in the ecosystem.

This supports the idea that long-term alignment and multi-year commitments tend to generate more durable and compounding value for the DAO compared to setups that mainly rely on incentives with an uncertain duration.

3 Likes
39

I would say both options 1 and 2 are great and secures at minimum 10 million revenue for the DAO for the next 5 years.

I would vote for Option 2 because the upside on any strategies on MegaETH would not be capped by revenue rollover and the base line revenue requirement would already sets the need for incentives and strategies in the MegaETH ecosystem that will create the revenue without separate commitment.

What I like about the proposal in general is that it commits to a long-term relationship with with clear revenue commitments.

2 Likes
40

A valuable lesson for Aave Labs here.

3 Likes
41

I agree, option 2 seems the more logical choice. Great work to have the long-term relationship in place as well with revenue commitments as well. Will establish Aave as the default lending platform on MegaETH from the start and likely yield significant revenue to the DAO

1 Like
42

At ACI, we acknowledge that Aave Labs bypassed the established workflow and BD pipeline for the MegaETH deployment.

We also acknowledge the earlier precedent of bypassing Skywards by escalating a slightly non-compliant Snapshot vote for an ARFC.

At this point, it is clear that some Aave Labs contributors are choosing to operate on top of workstreams built and maintained by other service providers rather than coordinating through the shared process and generating net-new BD pipelines. We take note of that reality.

Accordingly, we will adapt.

On MegaETH specifically, ACI will continue to execute its mandate. We will make Skywards services available on demand for any proposal related to this network, regardless of the proposing party. We will support authors with payload preparation, publication of AIPs where relevant, and execution within our service provider scope.
We will make Masiv infrastucture available for any incentives campaign desired on the network.

However, to maintain consistency, efficiency, and to mitigate overlap, we will not allocate BD bandwidth to MegaETH. We will focus our BD efforts on other pipelines where coordination and attribution are aligned with the DAO’s processes. If Aave Labs wants to lead BD for this deployment, they are free to do so, and they should own the outcome end-to-end.

We just want roles to be explicit, so DAO-funded work isn’t duplicated and responsibility is unambiguous.

7 Likes
Aave Labs: $86 Million, 23% of the Token Supply, and this is their Track Record