As of 1 Nov 2026, Ethena has 14 audit reports by 6 security firms on Trustblock; the latest is by Guardian Audits, dated 17 Aug 2026. Those reports list no open critical findings.
Record last updated . It holds audits and findings, contracts and incidents up to Oct 2026. Trustblock does not review code.
Newest first
| Audit | Security firm | Date | Scope | Critical findings | Report |
|---|---|---|---|---|---|
| Ethena PSMAdapter Review | Security firm: Guardian Audits | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · GitHub |
| Ethena Onchain Minting | Security firm: Guardian Audits | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · GitHub |
| Ethena Execution Guard Review | Security firm: Guardian Audits | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · GitHub |
| Ethena TimelockController | Security firm: Guardian Audits | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · GitHub |
| Ethena Timelock Audit Report | Security firm: Cyfrin | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · GitHub |
| Ethena UStb token and minting | Security firm: Quantstamp | Date: | Scope: Files named in the report | No open critical findings | Open · certificate.quantstamp.com |
| Ethena security review | Security firm: Pashov Audit Group | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · GitHub |
| Ethena security review | Security firm: Pashov Audit Group | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · GitHub |
| Ethena security review | Security firm: Pashov Audit Group | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · GitHub |
| Ethena security review | Security firm: Pashov Audit Group | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · GitHub |
| ethena | Security firm: Cantina | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · cantina.xyz |
| Ethena security review | Security firm: Pashov Audit Group | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · GitHub |
| Ethena Labs | Security firm: Quantstamp | Date: | Scope: Files named in the report | No open critical findings | Open · certificate.quantstamp.com |
| Ethena security assessment | Security firm: Zellic | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · GitHub |
Statuses are the security firm’s own, from each report.
| Severity | Open | Acknowledged | Fixed |
|---|---|---|---|
| Critical | 0 | 0 | 0 |
| High | 0 | 0 | 0 |
| Medium | 0 | 6 | 6 |
| Low | 0 | 22 | 30 |
The report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe 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.
Open the reportThe `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.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the report<br> 1. The initial limits of a new asset added to `UStbMinting` (max mint and max redeem limits per block per asset) are not accessible to off-chain observers via events because the event `AssetAdded` has only one field: `AssetAdded(address indexed asset)`. 2. Updates made via the function `setStablesDeltaLimit()` are not logged.
Open the reportWhen orders are submitted to the functions `mint()` and `redeem()`, their field `uint128 nonce` is checked via the function `verifyNonce()`. That function uses the data structure `_orderBitmaps` to check if a sender already used or not a given nonce. In detail, it is a mapping storing for a given address a `uint256` bitmap called `invalidator` at the `uint128` keys called `invalidatorSlot`. However, the following line could lead to an issue: ``` uint128 invalidatorSlot = uint64(nonce) >> 8; ``` Casting `nonce` to `uint64` seems too restrictive. If any value of `uint128 nonce` is valid, it is possible to have two different values of `nonce` that will be stored at the same bit in the data structure `_orderBitmaps`. For instance, the two values: `nonce_a = (1 << 125) + (1 << 60)` and `nonce_b = (1 << 60)`, since any non-matching bit higher than the 64th bit will be ignored because of the cast `uint64(nonce)`. Ultimately, this could prevent valid Orders from being accepted by the contract.
Open the reportIt is important to validate inputs, even if they only come from trusted addresses, to avoid human error: 1. In `UStb.sol`, function `initialize()`, the address `minterContract` may not be a contract; 2. In `UStb.sol`, function `addBlacklistAddress()`, it is possible to blacklist: <br>- the minter contract and this could temporarily disrupt the mint and redeem operations; <br>- the address with the role `DEFAULT_ADMIN_ROLE`, and this could temporarily disrupt the operation to redistribute locked amounts; 3. In `UStbMinting.sol`, function `verifyOrder() `, the uniqueness and the size of `Order.order_id` is not checked; 4. In `UStbMinting.sol`, function `setUStb() `, the value of `_ustb` is not checked to be: <br>- Different from `address(0x0)`; <br>- Different from existing supported assets; <br>- Different from existing custodian;
Open the reportThe `UStb` and `SingleAdminAccessControlUpgradeable` contracts are designed to be upgradable. Upgradable contracts usually have reserved space to allow future versions to add new state variables to the contract without shifting down storage in the inheritance chain. As `SingleAdminAccessControlUpgradeable` is inherited by `UStb`, adding a storage gap can be done to prevent storage collisions in future updates where storage slots could be added to `SingleAdminAccessControlUpgradeable`. For instance, if in a future update, `SingleAdminAccessControlUpgradeable` is modified to include a new variable, and the `UStb` contract were upgraded to use the new version, this new variable would likely collide with the `transferState` variable in `UStb` (except in the special case where the new variable is given a custom slot).
Open the reportSupporting tokens with specific features such as fees, rebasing, pausable, upgradeable, blacklist-able, or hooks on transfers could negatively impact the main flows of the system (deposits via `mint()`, transfer to custody, redeems via `redeem()`) if no specific mitigation measure is enforced to limit the consequences. For instance, in the function `_transferCollateral()` if `asset` represents an asset where the amount transferred is different than the amount requested to be transferred (ex: if fees are enforced), the actual amount transferred to custodians may differ from the expected transferred amount.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportDocumentation 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.
Open the reportCurrently, 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$$).
Open the reportThe reports name a repository or files. Open a report to see its scope.
Is this your project? Show this record on your own website. The label states what the record holds, links to this page and updates by itself. It is free and needs no sign-in.
Automatic: the three strongest facts of this project’s own record (its last audit and two more), highlighted. They update with the record. Picking a fact turns Automatic off.
<head><script src="https://widget.trustblock.run/project-widget.min.js" defer></script></head><body><divdata-tb-project-widgetdata-tb-project-slug="ethena"></div></body>
Paste the code where the label should appear. It uses no API credit and updates by itself.
Something wrong on this page? A missing report, a wrong date, a finding that was fixed since. Tell us and we check it against its source.
Tell us