[ARFC] Onboard sUSDe to Aave V3 on Ethereum

Governance
9

sUSDe technical/security analysis



Introduction

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

Disclosure: This is not an exhaustive security review of the asset like the ones done by the Ethena 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 a way of providing visibility and transparency to the Aave community about any potential technical/security risk.



Analysis

sUSDe is a staked version of USDe that accrues the yield of the Ethena delta-hedging positions. On this system, USDe can be exchanged for sUSDe by depositing it an ERC-4626 vault, which allows users to earn staking rewards on their USDe.

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 USDe.
  • Access control (ownerships, admin roles) and nature of the entities involved.
  • Any miscellaneous aspect of the code we can consider of importance.

General points

  • The main contracts are non-upgradable using OZ dependencies.
  • The system has a proper hierarchical organisation of permissions: the most critical permissions are controlled by a 5-of-11 Gnosis Safe, and others like lower power have different protections surrounding them.
  • The system is centralized, but with a maturely designed distribution.
  • Ethena has a continuously growing insurance, which size was/is used as reference for different security configurations.

Contracts

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


stakedUSDeV2

A staked version of USDe that allows you to receive rewards from hedge positions. The exchange rate of USDe per sUSDe increases over time as staking rewards are only added to the vault.

  • It’s a non-upgradable OZ ERC-4626 Vault contract, modified with vesting (rewards) and cooldown (unstaking) mechanics.
  • The REWARDER_ROLE can send a certain amount of rewards for vesting to this contract by calling the transferInRewards() function. Tokens transferred to the contract will be unlocked linearly during the a constant VESTING_PERIOD of 8 hours. These rewards are also taken into account in the totalAssets() function.
  • 3 addresses have REWARDER_ROLE. 2 Gnosis Safe multisig wallets and 1 external contract. The contract has a single operator inside, which is set to the EOA address.
  • The exchange rate can be calculated by calling the convertToAssets(uint256) and convertToShares(uint256) functions.
  • There’s 14-day cooldown period on unstaking sUSDe. The cooldown is configurable for up to 90 days by DEFAULT_ADMIN_ROLE.
  • It is also possible to add a user to a blacklist via the BLACKLIST_MANAGER_ROLE or DEFAULT_ADMIN_ROLE for addresses based in countries that are restricted from accessing the protocol for regulatory reasons or for addresses associated with sanctioned individuals.

USDe

USDe - is a synthetic dollar, which peg to the exchange rate is ensured by a delta-neutral strategy. USDe does not accrue yield rewards, only sUSDe.

  • It’s a non-upgradeable ERC20 contract whose owner is a 5-of-11 Gnosis Safe.
  • The function mint(address, uint256) can only be called by the minter , with the owner having the power set the minter role to any address. Currently, it’s set to the EthenaMinting contract.
  • The mint/burn functions in this layer are not limited by a maximum amount, meaning authorized addresses can mint any amount of USDe. The limits are defined in the EthenaMinting contract.

EthenaMinting

The contract mints new USDe and sends assets to custody addresses in exchange for it. The contract uses EIP-712 signatures from users, signing order objects (struct with the collateral asset, amount, and USDe amount).

  • It’s a non-upgradeable contract whose owner is the same 5-of-11 Gnosis Safe.

  • The owner can grant MINTER_ROLE, REDEEMER_ROLE, and GATEKEEPER_ROLE to any address.

    • The MINTER_ROLE can mint new USDe, and send collateral to custody addresses.
    • The REDEEMER_ROLE can burn USDe and send assets to the beneficiary address.
    • The GATEKEEPER_ROLE can remove MINTER_ROLE/REDEEMER_ROLE roles from accounts and disable mint/redeem functions.

  • Currently, all minters are EOA addresses. If one or more EOA addresses are compromised, the addresses with GATEKEEPER_ROLE can revoke their roles.

    When writing the report, 20 EOA addresses have MINTER_ROLE, the same addresses are set for REDEEMER_ROLE and 4 EOA addresses have GATEKEEPER_ROLE.

  • Addresses in the signer set of the 5-of-11 Gnosis Safe and those with MINTER_ROLE and GATEKEEPER_ROLE are all different.

  • In case of a compromised MINTER_ROLE or REDEEMER_ROLE addresses, attackers can’t mint/redeem more than the values defined on maxMintPerBlock and maxRedeemPerBlock . This value is currently configured to 2’000’000 USDe. They must also obtain the required signature or have the delegatedSignerStatus for the signer as ACCEPTED to verify the signature, together with enough ERC20 allowance.

Miscellaneous security

  • The system has 5 technical audits by Zellic (v1), Quantstamp, Spearbit, and Pashov, public audit by Code4rena. The system has as well economic ones, including Risk Analysis by Chaos Labs.


Conclusion

We think sUSDe doesn’t have any problem in terms of integration with Aave, and there is no major blocker for listing.

For extra visibility about potential risks, some final thoughts about the system:

  • The 5-of-11 Gnosis Safe “super-admin” of the system has in practise complete power over the system, so it should be considered a trusted entity in case of listing.

    From our discussion with the Ethena team, not having a Timelock in front of it is due to what felt like well though security trade-offs, to keep consistency with the overall security strategy of the system. E.g. protection against un-authorized minting has time components that would need to be re-evaluate if introducing time-locks.

  • The maxMintPerBlock and maxRedeemPerBlock is pretty high, and for precaution we recommended to potentially lower it. The explanations from the Ethena team on the reaction time of their system (mainly gatekeepers stopping minting/redeeming) were convincing for us though.

  • The exchange rate calculation logic looks solid for us. Even being an hybrid approach using balance of assets in the ERC-4626 vault and additional internal storage, the approach is sound.

  • Even if we don’t see any security concern at the moment, we don’t recommend listing the asset as borrowable, only as collateral.

  • The Ethena team has answered all our questions in a pretty transparent manner, and even if a subjective aspect, our perception is that important focus has been placed into an holistic security approach of the system.

  • The underlying of USDe (consequently sUSDe) has important counterparty risk due to its usage in centralised venues. It is outside of our scope to evaluate that, but something the community should be really aware of.

  • Some further discussion between Aave service providers is required for the pricing strategy of sUSDe before listing, but given the presence of USDe on Aave v3 Ethereum using an USDe/USD CAPO, the strategy should be consistent with this.

1 Like