[ARFC] Onboard eUSDe to Aave v3 Core Instance

[bgdlabs]

eUSDe (Ethereum) technical analysis

Summary

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

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

eUSDe represents the pre-deposit for the initial stage of Ethereal, a decentralized spot and perpetual exchange built on the Ethena Network and powered by native USDe collateral. Users can deposit USDe and receive eUSDe to earn Ethereal and Ethena points.

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.
• A recommendation of pricing strategy to be used in the integration asset <> Aave.
• Any miscellaneous aspect of the code 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

• eUSDe relies on a single contract with dependencies from OZ for access control and tokenization.
• The system’s owner is a 2-of-3 Safe wallet (to be changed, more later).
  
  

Contracts

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

eUSDe

eUSDe is the only contract of the system, which is an OZ ERC4626 Vault using OZ Ownable for access control. Users can mint eUSDe by depositing USDe, and they can withdraw USDe at any time. eUSDe is paired 1:1 with USDe and allows users to earn Ethereal Points. It is a non-upgradable contract.

Permission Owner	functions	Criticality	Risk
owner: 2-of-3 Safe wallet.	setDepositsEnabled, setWithdrawalsEnabled, transferOwnership	HIGH

• Access Control
  • The owner can pause/unpause deposits and withdrawals via the setDepositsEnabled(bool) and setWithdrawalsEnabled (bool) functions, respectively.
• Deposit and Withdrawals
  • Users can deposit USDe via the deposit(assetsAmount) function, which internally checks whether deposits are enabled and mints 1:1 shares of eUSDe for the user.
  • Users can redeem eUSDe for USDe via the redeem(sharesAmount) function. If withdrawals are not paused, the contract will burn the sharesAmount and send the equivalent amount of USDe to the user.
• Exchange Rate
  • As an ERC4626 Vault standard, the exchange rate of eUSDe can be obtained using the convertToAssets(shares) function, which calculates it based on totalAssets() and total supply().
  • It is important to highlight that totalAssets() does not use proper internal accounting and relies on the asset.BalanceOf(), which means that it CAN suffer donation attacks.

Pricing strategy

For eUSDe, the price strategy can be done in two different directions:

• The first option is to use the CAPO stable adapter, which is already used for USDe. Since eUSDe’s intention is not to accrue any rewards within the contract, the exchange rate should be 1:1 with USDe.
• The second option could be the CAPO LST adapter using the eUSDe <> USDe exchange rate with the USDe CL feed. However, the maxYearlyRatioGrowthPercent must be set to zero, as any donations of USDe to the eUSDe will directly affect the exchange rate, and the adapter would cap any price changes.

For simplicity, we recommend pricing eUSDe with the first option. This way, we can avoid any unexpected behavior regarding the eUSDe price on Aave.

Miscellaneous

• The system has undergone one security review by Guardian Audits with no High or Critical findings. The reports can be found here.
• Following our discussion with the Ethereal Team regarding our concerns about the super admin of eUSDe being a multisig wallet with a low number of signers and a low threshold, as highlighted by recent incidents involving Safe wallets, the team has agreed to change the owner to the zero address, as the functionality is not required.

Conclusion

We think eUSDe doesn’t have any problems in terms of integration with Aave, both for direct listing and as the underlying of assets like Pendle PTs.
The only technical prerequisite is as commented for the team to change the ownership role, but once done, we don’t see any blocker for listing.