[ARFC] Deploy Aave V3 to MegaETH

[bgdlabs]

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.

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

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
owner	Safe 4-of-9	Safe 4-of-9	addMinter, removeMinter, addBlacklister, removeBlacklister, setRescueRecipient, setRateLimits, rescueBlacklistedTokens	HIGH
minter	USDmMinting, LZ endpoint	LZ endpoint	mint, burnFrom	HIGH
blacklister	Safe 4-of-9	not set	addToBlacklist, removeFromBlacklist	HIGH

• 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
GATEKEEPER_ROLE	(not set)	disableMintRedeem, removeMinterRole, removeRedeemerRole, removeCollateralManagerRole	HIGH
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
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
COLLATERAL_MANAGER_ROLE	(not set)	transferToCustody	HIGH

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