USDe · Question revision 2

What risks exist across USDe's mechanisms, smart contracts, protocols, integrations, and counterparties, and how can those risks combine and propagate through the system?

RESEARCH · 12 SEPTEMBER 2026 · BANGKOK DATE

Who can change
USDe’s rules?

USDe can keep moving between wallets while its primary redemption route is stopped. The token, the exit machinery and the people controlling them are different layers.

The inspected token lets its owner replace the address allowed to issue USDe. The minting contract has its own operators, limits and emergency stop. Staking adds another set of permissions. A single signature count cannot explain all three. [1: token] [2: minting] [3: staking]

Measured settings below come from Ethereum block 25,952,841, timestamp 11 September 2026, 08:03:35 UTC. The provider supplied it as finalized. This is a dated observation, not a live dashboard or an independent consensus check. [4: snapshot]

Three measured settings. Three different questions.

A multisignature wallet requires an agreed number of owner approvals. The supplied Safe returned five and ten respectively. That resolves the number for that wallet at this block. It does not prove who those owners are, that they are independent people, or that every important action must pass through that wallet. [4: decoded getters] [5: Safe proxy]

The critical extra step is the owner link. Both USDe and Mint V2 returned 0xe8dc0fab349ea169283c48ccfd09d797e6db7c94 as owner, not the Dev Safe address. Earlier external work identifies this address as a timelock controller, but this review lacks its same-block source/configuration evidence. The map therefore leaves the Safe-to-controller relationship dashed. [4: source] [8: earlier review]

A global cap limits gross minting or redemption in one block through V2. Per-asset caps, supported-asset settings, authorization and a valid order can impose tighter conditions. Redemption also needs assets to deliver. The observed 10 million USDe ceiling is not proof that 10 million is ready to pay out. [2: source] [4: source]

How the cap values were decoded

The V2 ABI returns globalMaxMintPerBlock first and globalMaxRedeemPerBlock second, both unsigned 128-bit integers. The raw values are 200000000000000000000000000 and 10000000000000000000000000. Dividing by 10¹⁸, the USDe base-unit scale, gives 200,000,000 and 10,000,000 USDe. No price conversion or annualization is involved. The public observation record preserves the raw values and scope.

Who can do what?

The token owner can replace the minter

The setMinter function checks the caller is the owner. The token’s mint function then checks only that the caller is the chosen minter before issuing tokens. It does not independently prove backing or impose the V2 contract’s economic caps. Those caps constrain the current route, not every route a future owner-authorized minter could implement. [1: source]

This is intended privileged power, not a newly discovered exploit. Whether that power can be exercised responsibly depends on the controller, approval paths and safeguards around it. Those paths are precisely the part that still needs evidence.

The V2 administrator controls limits and permissions

The default administrator can change global limits, manage supported assets and custody destinations, and grant or revoke operational roles. The mint executor, redemption executor and collateral manager are distinct gates in the source. An address could hold several roles, but this review has not enumerated the actual overlap. Reading a role title in a document is not enough. [2: source]

One consequence for monitoring is easy to miss: the selected global-cap setters and emergency-disable method write their values without a dedicated global-cap-change event. Watching only role changes cannot reconstruct the cap history. State reads and decoded transactions or traces are also needed. This does not make transactions invisible; it changes what a useful monitor must inspect. [2: source]

Gatekeepers can stop primary minting and redemption

The gatekeeper’s disable function sets both global limits to zero. Positive mint/redeem orders then fail their global-limit checks. The gatekeeper can also remove selected operational roles, but does not acquire re-enabling authority merely by being a gatekeeper. [2: source]

That emergency response can prevent further damage. It can also leave holders needing a buyer rather than a functioning primary redemption route. Ordinary USDe transfers use the token contract, whose inspected code has no comparable administrative freeze hook. A functioning transfer still says nothing about the price a buyer will offer. [1: source] [2: source]

Staking shares add different restrictions

sUSDe is a claim on USDe inside a staking vault. Its inspected source permits restrictions on staking-share movement and lets the administrator redistribute fully restricted shares. That is different from an arbitrary power to confiscate ordinary USDe balances. The administrator can also change the unstaking duration, with a source maximum of 90 days. The measured setting here is one day. [3: source] [4: source]

Even within staking, the stage matters. Starting a cooldown converts shares and transfers USDe to a silo. The later unstake method checks that the request has matured—or the global duration is zero—and releases that already-converted amount. It does not repeat the same full-restriction checks as the share-withdrawal path. This is a reason to trace the exact path, not to promise that every restricted position is either always blocked or always free to exit. [3: source]

A protective stop can still change your exit

The conditional chain is straightforward: a gatekeeper stops primary redemptions; some holders or intermediaries still need to leave; more of that demand seeks secondary buyers. If usable market liquidity is insufficient, a discount could interact with borrowing and collateral liquidations. No pause, market shortfall or loss amount is observed by this snapshot.

There are buffers to test: fast operational recovery, available backing inventory, and alternative liquid routes. Their effectiveness cannot be inferred from a cap or a signature threshold. The earlier report explains how exit dependencies combine; this report adds the specific source-level stop and control conditions.

The evidence moved beyond a historical repository

This review used source-provider bundles associated with the USDe, Mint V2 and sUSDe addresses, including their ABIs, compiler metadata, source files and deployment records. Each core bundle reports an exact match. Every bundled source digest was checked, compiler versions agreed with runtime metadata, and the full runtime bytes supplied by the node also appeared in the corresponding supplied explorer pages. [1: source] [2: source] [3: source] [4: source]

This is stronger than matching a contract name or pointing at a repository branch. It is still provider-reported source verification with local cross-checks, not a fresh independent compilation. The token and staking metadata specify Solidity 0.8.19; Mint V2 specifies 0.8.20. The Safe provider reports a match rather than an exact match, and its proxy implementation remains a separate missing dependency. [5: source]

Source inspection and historical audit follow-through

The control-bearing token, V2 minting, staking base/V2, silo, single-admin and Safe proxy source were read, with consequential access-control, signature and transfer imports. Hash checks across a bundle are not a claim to have semantically audited every import. No Solidity compilation, fork transaction or EVM security test was run.

A historical Pashov minting review discusses an unsafe truncation of a nonce bit mask. The supplied V2 source uses a 256-bit mask instead. A local integer model checks the boundary; it is not a proof of complete remediation or a deployed exploit test. That minting review is not evidence that every staking or timelock version was audited. [6: audit] [2: source]

Why the document descriptions are not used as live settings

The issuer’s key-address page describes a different Dev Safe owner count. Other control prose and overview examples also differ from the inspected gates or dated values. These are documentation/configuration discrepancies to reconcile, not evidence of compromise. Off-chain policy may impose additional requirements, but a written policy must not be presented as a check enforced by the selected contract. [7: issuer descriptions]

The missing link still matters

A previous external record describes a one-day timelock. Separately, an example timelock implementation has a privileged allowlisted execution path; a primary audit documents changes across its revisions. Neither establishes the actual owner controller’s code, roles or exceptions at this snapshot. We therefore make no guaranteed governance warning-window claim. [8: source] [9: example and audit]

The remaining control checks are concrete: the controller’s source and bytecode; its proposer, executor and allowlisted permissions; the Safe’s implementation, modules, guard and fallback; the staking administrator; and complete bounded role histories. Per-asset limits and backing available for redemption need separate measurements. The supplied observations do not provide them.

For the token-to-exit steps, continue with What do you actually get back? For the rest of the system, see audit scope and unresolved dependencies.

Sources and observation scope

1. USDe token source. Supplied source-provider bundle and explorer page, collected 11 September 2026; owner/minter and source control gates inspected.
2. EthenaMinting V2 source. Complete minting source and relevant inherited gates; global limit setters, role separation and order validation. Same-day supplied runtime/configuration evidence.
3. StakedUSDeV2 source and bundled dependencies. Control and exit-stage scope; separate silo deployment matching and full economic tests remain open.
4. Curated block observation record. Ethereum 25,952,841, hash 0x608803fe345eb1e3aabca34208f7e62e3397ee9fd55092f3f4d17aa97e1a1540, 11 September 2026 at 08:03:35 UTC. Provider-supplied finalized snapshot; decoded locally, not a new live query.
5. Development Safe proxy. Separate successful RPC threshold/owner responses; singleton and optional authority paths are not verified.
6. Pashov May minting review. Specific nonce/constructor patterns compared; not an audit of every current contract.
7. Key addresses, trust assumptions and contract overview. Freshly revisited issuer descriptions; publication/version dates not established.
8. Earlier Pharos control record. Reports August observations; automation-authored research per its review footer. Corroborating lead, not reproduced September state.
9. Timelock example and Cyfrin review. Not matched to the owner deployment in this review.

This report adds a dated control snapshot and source/deployment cross-checks. The 11 September exit report and its assets remain unchanged. These findings do not replace unmeasured backing, custody or market-exit evidence.