Ethena Labs

The proper functioning of the protocol heavily depends on the protocol's hedging strategy. In case of market turmoil, it is possible that the protocol cannot liquidate funds from centralized exchanges, so users might not be able to redeem their full balance. Furthermore, to facilitate users redeeming tokens for their USDe, the protocol admin must first transfer enough funds from the custody back into the Ethena Minting contract. There is no on-chain guarantee that USDe will be redeemable as the team can simply choose not to return the funds. Below we list all the privileged roles in the system. 1. `EthenaMinting` 1. `DEFAULT_ADMIN_ROLE` 1. Can set the `maxMintPerBlock`. 2. Can set the `maxRedeemPerBlock`. 3. Can add and remove addresses from other roles (excluding `owner`). 2. `owner` 1. Can set the USDe token address. 2. Can add and remove supported assets. 3. `MINTER_ROLE` 1. Can mint stablecoins from assets. 2. **Can transfer any asset in the contract to any address.** 4. `REDEEMER_ROLE` 1. Can redeem stablecoins for assets. 5. `GATEKEEPER_ROLE` 1. Can disable minting and redeeming. 2. Can remove the `MINTER_ROLE` from an address. 2. `StakedUSDeV2.sol` 1. `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 stUSDe from wallets with the `FULL_RESTRICTED_STAKER_ROLE` to any unrestricted address.** 2. `REWARDER_ROLE` 1. Can add vested USDe tokens to the contract via `transferInRewards()`. <br> In the current state of the system, privileged roles can perform various actions that would be detrimental to the health of USDe. Most notably, the following capabilities could be problematic: 1. The price of an order is not considered on-chain, which means that Ethena Labs could mint any amount of USDe without providing an equal amount of underlying tokens or redeem a small amount of USDe for all of the underlying assets. 2. The underlying assets backing USDe can be withdrawn from the minting contract to any address. 3. stUSDe tokens can be seized at any time by the admin role of the staking contract. There should be a separation of roles between assigning the fully restricted role and redistributing their tokens. 4. Profits from the underlying assets intended for stUSDe holders need to be manually deposited.

The `SOFT_RESTRICTED_STAKER_ROLE` is given to addresses that are partially blacklisted from the contract. They are not permited to deposit funds but can still perform all other operations. Therefore, an address with the `SOFT_RESTRICTED_STAKER_ROLE` could transfer their USDe tokens to another address they own and deposit them.

Documentation and the code suggest that the `EthenaMinting` contract doesn't hold any underlying LST assets, but rather custodial wallets do. This is evident in the documentation and the `_transferCollateral` function where collateral is transferred elsewhere. As funds are not stored in the contract itself, the team controls the liquidity that is managed in this contract. As a result, there is the potential that there could be friction for USDe redemptions if there is insufficient liquidity in the Ethena Minting contract.

Currently, the nonce implementation in `_deduplicateOrder()` implies that we can only have $$2^{64}$$ different slots for a user, where each slot allows $$256$$ bits. However, in the `_orderBitmaps` mapping, the key and value types are of `uint256`, which means different nonces might collide even when they shouldn't (e.g. $$2^{64}+1$$ and $$1$$).