Key Trust Assumptions

While the Ethena protocol attempts to minimize trust assumptions across all areas of the infrastructure, certain trust assumptions need to exist in order to access centralized liquidity and enable the scaling of the underlying product.

As the protocol develops further, there are specific plans to gradually reduce trust assumptions on certain entities.

Summary of Major Trust Assumptions

1. The user initially needs to trust that the hedging system will execute the appropriate hedge for the backing assets provided upon issuance of USDe. However, this can easily be verified by the issuance of USDe vs assets transferred, alongside the existence of read APIs to both custody wallets and the exchange APIs that are transparently displayed on the Ethena dashboards.

2. The USDe holder makes a trust assumption that the various OES providers will undertake their roles diligently and without major errors with regard to custody of the underlying backing. To date, none of the custodial providers which hold the assets have ever lost users' funds compared to $7bn of hacks on DeFi smart contracts.

3. The GATEKEEPER_ROLE is responsible for pausing the mint and redeem function, as well as adding new whitelisted custodial addresses that backing assets assets on mint are transferred to. This role is time-locked to ensure an extensive time period exists before such a sensitive change is able to be made.

4. The DEFAULT_ADMIN_ROLE, granted exclusively to the protocol multisig, will act seldomly and only in the best interest of the protocol. This multi-sig wallet requires 7 signatures to sign or transact, both from internal and external stakeholders, with keys geographically distributed and controlled by distinct individuals both within and outside of the Ethena Labs team.

The GATEKEEPER_ROLE and Multi-Sig Safety Layer

1. The GATEKEEPER_ROLE is used in the system in order to accelerate response times in the case of an issue. Gatekeepers can only disable minting and redeeming or remove the corresponding minting and redeeming roles from individual addresses. Gatekeepers cannot re-enable minting and redeeming nor take any other action. This role is distributed both within the Ethena Labs organization and among external stakeholders including market makers and exchanges.

2. The time-locked multi-sig ensures that privileged roles cannot be abused by the Ethena Labs team with keys distributed outside of the core contributor team and 7 day time-locks for any change to core functions.

Mint & Redeem Privileged Roles

EthenaMinting.sol

DEFAULT_ADMIN_ROLE

• Can set the maxMintPerBlock.

• Can set the maxRedeemPerBlock.

• Can add and remove supported assets.

• Can add and remove custodian wallets.

• Can add and remove addresses from other roles and perform all actions restricted by other roles.

MINTER_ROLE

• Can mint USDe from assets, within 5% of 3rd party oracle pricing provided by Pyth and Redstone.

• Can transfer any asset in the minting contract to any custodian wallets.

REDEEMER_ROLE

• Can redeem USDe for assets, within 5% of 3rd party oracle pricing.

GATEKEEPER_ROLE

• Can disable minting and redeeming.

• Can remove the MINTER_ROLE or REDEEMER_ROLE from an address.

USDe.sol

Owner

• can set minter

minter

• a single address, the only address that can mint USDe. It cannot be set to the same address as owner. Set to EthenaMinting and only modifiable in case a new minting contract needs to be deployed to preserve protocol.

Staking Contract Privileged Roles

owner/DEFAULT_ADMIN_ROLE

1. Can add and remove addresses from other roles. This should be the role of the Gatekeeper according to documentation.

2. Can redistribute sUSDe from wallets with the FULL_RESTRICTED_STAKER_ROLE to any unrestricted address.

3. REWARDER_ROLE

4. Can add protocol-generated yield vested USDe to the contract via transferInRewards().