# Github Overview
[**USDe.sol**](https://etherscan.io/address/0x4c9edd5852cd905f086c759e8383e09bff1e68b3)
`USDe.sol` is the contract of USDe. It extends `ERC20Burnable`, `ERC20Permit` and `Ownable2Step` from OpenZeppelin. There's a single variable, the `minter` address that can be modified by the `OWNER`. Outside of `Ownable2Step` contract owner only has one custom function, the ability to set the `minter` variable to any address.
The `minter` address is the only address that has the ability to mint USDe. This minter address has one of the most powerful non-owner permissions, the ability to create an unlimited amount of USDe. It will always be pointed to the `EthenaMinting.sol` contract.
#### [EthenaMinting.sol](https://etherscan.io/address/0xe3490297a08d6fC8Da46Edb7B6142E4F461b62D3#tokentxns)
`EthenaMinting.sol` is the contract and address that the `minter` variable in `USDe.sol` points to. When users mint USDe with stETH (or other backing) or redeems backing for USDe, this contract is invoked.
The primary functions used in this contract are `mint()` and `redeem()`. Users who call this contract are all within Ethena. When outside users wishes to mint or redeem, they perform an EIP712 signature based on an offchain price provided to them. They sign the order and sends it back to Ethena's backend, where a series of checks are run and are the ones who take their signed order and put them on chain.
By design, Ethena will be the only ones calling `mint()`, `redeem()` and other functions in this contract.
#### Minting
In the `mint()` function, `order` and `signature` parameters come from users who wish to mint and performed the EIP 712 signature. `route` is generated by Ethena, where it defines where the incoming assets from users go to. The address in `route` defined must be inside `_custodianAddresses` as a safety check, to ensure funds throughout the flow from users end up in custodial solutions within a single transaction. Only `DEFAULT_ADMIN_ROLE` can add custodian address.
#### Redeeming
Similar to minting, the user performs an EIP712 signature with prices provided by the system. Their signature is submitted and order into `redeem()` function. The funds from redemption come from the Ethena minting contract directly. Ethena aims to hold a certain amount of backing assets at all times for hot redemptions. Users intending to redeem a large amount will need to redeem over several blocks. Alternatively they can sell USDe on the open market.
#### Setting delegated signer
Some users trade through smart contracts. Ethena minting has the ability to delegate signers to sign for an address, using `setDelegatedSigner`. The smart contract should call this function with the desired EOA address to delegate signing to. To remove delegation, call `removeDelegatedSigner`. Multiple signers can be delegated at once, and it can be used by EOA addresses as well.
By setting a delegated signer, the smart contract allows both the `order.benefactor` and delegated signed to be the address that's ecrecovered from the order and signature, rather than just `order.benefactor`.
**Security**
`EthenaMinting.sol` has crucial roles called the `MINTER` and `REDEEMER`. Starting with `MINTER`, in the original design, they have the ability to mint any amount of USDe for any amount of backing assets. Given `MINTER` is a hot wallet and is an EOA address, in the scenario where this key becomes compromised, an attacker could then mint a billion USDe for no backing, and dump them on pools, causing a black swan event the reserve fund cannot cover.
The solution is to enforce an on chain mint and redeem limitation per block. In addition, the contracts have `GATEKEEPER` roles with the ability to disable mint/redeems and remove `MINTERS`,`REDEEMERS`. `GATEKEEPERS` acts as a safety layer in case of compromised `MINTER`/`REDEEMER`. They will be run in separate AWS accounts not tied to Ethena, constantly checking each transaction on chain and disable mint/redeems on detecting transactions at prices not in line with the market. In case compromised `MINTERS` or `REDEEMERS` after this security implementation, a hacker can at most mint 100k USDe for no backing, and redeem all the backing within the hot contract, for a max loss in a single block, before `GATEKEEPER` disable mint and redeem. The loss would not be expected to materially affect operations.
Further down the line, there has been considerations to give external organisations a `GATEKEEPER` role. Such an external organisation would only be expected to invoke the gatekeeper functions when price errors occur on chain. Abuse of this privilege means their `GATEKEEPER` role will be removed.
The `DEFAULT_ADMIN_ROLE` is required to re-enable minting/redeeming. `DEFAULT_ADMIN_ROLE` also has the power to add/remove `GATEKEEPERS`,`MINTER` and `REDEEMER`.
`DEFAULT_ADMIN_ROLE` is the most powerful role in the minting contract, but is still beneath the `OWNER` role of `USDe.sol`, given that the owner can remove the minting contract's privilege to mint.
#### [StakedUSDeV2.sol](https://etherscan.io/address/0x9d39a5de30e57443bff2a8307a4256c8797a3497)
`StakedUSDeV2.sol` is where holders of USDe stablecoin can stake their stablecoin, get stUSDe in return and earn yield. Protocol yield is transferred out by having a `REWARDER` role of the staking contract send protocol yield in USDe, increasing the sUSDe value with respect to USDe.
This contract is a modification of the ERC4626 standard, with a change to vest in rewards linearly over 8 hours to prevent users frontrunning the transfer of protocol yield, then unwinding their position right after (or even in the same block). This is also the reason for `REWARDER` role. Otherwise users can be denied rewards if random addresses send in 1 wei and modifies the rate of reward vesting.
There's also an additional feature to add a 14 day cooldown period on unstaking sUSDe. When the unstake process is initiated, from the user's perspective, sUSDe is burnt immediately, and they will be able to invoke the withdraw function after cooldown is up to get USDe in return. Behind the scenes, on burning of sUSDe, USDe is sent to a separate silo contract to hold the assets for the cooldown period. And on withdrawal, the staking contract moves those funds from the silo contract out to the user's address. The cooldown is configurable up to 90 days.
Due to legal requirements, there's a `SOFT_RESTRICTED_STAKER_ROLE` and `FULL_RESTRICTED_STAKER_ROLE`. The former is for addresses based in countries that are restricted from accessing the protocol for regulatory reasons, for example USA. Addresses under this category will be soft restricted. They cannot deposit USDe to get sUSDe or receive USDe for sUSDe.
`FULL_RESTRCITED_STAKER_ROLE` is for any address associated with sanctioned individuals or associated with users suspected to be operating within a country subject to comprehensive sanctions, or for addresses associated with criminal activity, or if we get a request from law enforcement to freeze funds. Addresses fully restricted cannot move sUSDe, and only Ethena can unfreeze the address. Ethena also has the ability to repossess funds of an address subject to full restrictions. It is understood that having the ability to freeze and repossess funds could be a cause of concern for defi users deciding whether to stake USDe; while the aim is to make operations as secure as possible, interacting with Ethena still requires a certain amount of trust outside of code on the smart contract, given the nature of the architecture.
Note this restriction only applied to staking contract, there are no restrictions or ability to freeze funds of USDe.
#### [ **StakingRewardsDistributor.sol**](https://etherscan.io/address/0xf2fa332bd83149c66b09b45670bce64746c6b439)
`StakingRewardsDistributor.sol` is a helper contract that automates and streamlines the distribution of staking rewards to the `StakedUSDeV2` contract. It serves as an intermediary between the **EthenaMinting** contract and the **staking contract**, allowing for more frequent and automated reward distributions while mitigating potential arbitrage opportunities.The contract has two key roles:
* `OWNER` (**multisig**) - Responsible for administrative configuration such as setting the operator, updating the minting contract, and managing asset approvals.
* `OPERATOR` - A delegated signer that can only perform two actions: mint USDe using available funds in the contract and transfer the minted USDe rewards to the staking contract via `transferInRewards()`.
The main function `transferInRewards()` can only be called by the operator and requires the contract to have sufficient USDe balance. This contract must be granted the `REWARDER_ROLE` in the staking contract to successfully distribute rewards.
Safety features:
* Two-step ownership transfer (inherited from **Ownable2Step**)
* Owner cannot renounce ownership
* Operator can be instantly replaced by the owner
* Assets can only be approved to the current minting contract
This contract simplifies the reward distribution process by removing the need for frequent multisig transactions while maintaining security through role separation and safety checks. The operator's permissions are strictly limited to reward distribution functions, while all administrative control remains with the owner multisig.
#### [StakedENA.sol](https://etherscan.io/address/0x8bE3460A480c80728a8C4D7a5D5303c85ba7B3b9)
`StakedENA.sol` is the staking contract for `ENA` tokens, implementing **ERC4626** with additional security features and vesting mechanics. Users can stake their ENA tokens to receive **sENA** (Staked ENA) tokens in return. The contract includes both a cooldown period for unstaking and a vesting period for rewards distribution. Key Features:
* Vesting System - Rewards are vested linearly over a configurable period (max 90 days) to prevent reward sniping
* Cooldown Mechanism - Similar to `StakedUSDeV2`, implements a configurable cooldown period (max 90 days) for unstaking
* Blacklist System - Includes roles for managing restricted addresses
* Minimum Shares - Implements a minimum shares threshold (1 ENA) to prevent donation attacks
The contract has several important roles:
* `DEFAULT_ADMIN_ROLE` - The owner with highest privileges
* `REWARDER_ROLE` - Allowed to distribute rewards via transferInRewards()
* `BLACKLIST_MANAGER_ROLE` - Can add/remove addresses to/from blacklist
* `BLACKLISTED_ROLE` - Addresses restricted from transfers, staking, or unstaking
Security Features:
* Two-step ownership transfer (inherited from SingleAdminAccessControl)
* Reentrancy protection on critical functions
* Role-based access control
* Non-renounceable roles (prevents accidental role abandonment)
* Blacklist system for regulatory compliance
* Emergency token rescue functionality (except for ENA tokens)
* Prevention of zero-amount transactions
* Minimum shares requirement
* Vesting and cooldown periods cannot exceed 90 days
* Cannot update vesting parameters while rewards are still vesting
This contract serves as the core staking mechanism for ENA tokens while maintaining necessary security controls and regulatory compliance features. The combination of vesting and cooldown periods helps prevent various economic attacks while the blacklist system provides regulatory compliance capabilities.
### [Owner of Ethena's smart contracts](https://app.safe.global/home?safe=eth:0x3B0AAf6e6fCd4a7cEEf8c92C32DFeA9E64dC1862)
Ethena utilises a gnosis safe multisig to hold ownership of its smart contracts. All multisig keys are cold wallets and each multisig requires 7/10 or more confirmations before transactions are approved. This multisig is purely for the purpose of owning the smart contracts, and will not hold funds or do other on chain actions.
---
# 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/overview/github-overview.md?ask=
```
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.