# 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](https://app.ethena.fi/dashboards/solvency).
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().

<br>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.ethena.fi/solution-design/key-trust-assumptions.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.