Review of the L2 USDe PSM Proposal

Kairos Research: Review of the L2 USDe PSM Proposal

Prepared by Kairos Research for the Ethena Risk Committee. Onchain state verified as of July 15, 2026, and updated for the Guardian security review and subsequent clarifications from the Ethena team.

Context

The proposal introduces an L2 PSM (peg stability module), pre-funded with a small USDe float, where an approved market maker atomically swaps USDC/USDG for USDe near mint cost, in both directions. The design has three parts:

  1. The PSM contract is already built; it is a two-way, whitelisted, oracle-guarded swap contract that holds no funds itself.

  2. A seed float of 10M USDe per chain (20M total initially) is preminted once on mainnet and bridged to the L2.

  3. A revolving replenishment loop: swap proceeds are swept to mainnet and re-minted through the normal, fully collateralized mint path, then bridged back. Steady-state replenishment creates no unbacked supply; the unbacked quantum is a constant equal to the seed.

Today USDe is minted and redeemed only on Ethereum and reaches L2s through LayerZero’s lock-and-mint OFT, so entering or exiting a position on an L2 means either bridging back to mainnet or crossing AMM spread. Neither works for automated strategies that need atomic entry and exit, and the gap has been a real point of friction for key distribution partners, which this design closes.

What we reviewed

Rather than assessing the proposal on paper, we verified it against deployed code. The Ethena team shared a proof-of-concept deployment on Base (0xfcdd707a477c8bdece30910d3a1a20c2a805ff94), and we verified its state independently onchain. Although the proof of concept is unverified on public explorers, its runtime bytecode matches the source-verified mainnet USDtb PSM (0x73e35c5c35a274e34ade6eb13cc7f62aee323728) byte for byte outside of the immutable asset address, so the code running on Base is exactly the published PSM source. We also reviewed that source in full, along with the Guardian security review that covers it.

The proof of concept behaves as the proposal describes. The contract holds no funds at any point; each swap routes tokens directly between a whitelisted counterparty and external custodian wallets through two simultaneous transfers, and the trade either clears in full or reverts. Swaps require no per-transaction signature from Ethena, which supports the goal of unattended availability. Pricing executes at the peg net of fees with the output bounded by the oracle price, each collateral carries a configurable depeg band with staleness checks, and the test swaps priced exactly as expected, at the peg net of the configured five basis point fee, in both directions. The seed ceremony is also feasible as described: USDe is a single-minter token, the timelock’s minimum delay is exactly the stated one day, and the delayed batch path can execute the mint and both minter changes atomically.

Ethena has clarified that the Base instance is an integration test, deliberately run with test wallets throughout, and that production will be a fresh deployment managed by a timelocked multisig from day one, with custody at dedicated MPC wallets kept separate from the admin role. Our conditions below reflect that plan.

The security review

Guardian audited the PSM contract, its deployment script, and its test suite in June 2026, with the final report issued on July 2. No Critical or High severity findings were identified; the report contains three Medium findings that the team acknowledged as accepted operational tradeoffs, alongside nine Low and nine Informational findings, the majority resolved in remediation, and Guardian assigned a High Confidence ranking. Two of the acknowledged items are operational in nature and map directly to our conditions: the manually set peg price creates a brief arbitrage window during repricing events if configuration lags the market, and token-level blacklisting does not by itself freeze PSM routing authority. Both are managed through configuration discipline and monitoring rather than code changes, which is why our conditions focus on production configuration.

Key considerations

The backing invariant is operational, not enforced. The contract has no awareness of the reserve fund or of float size, so the commitment that the float remain below the reserve fund is a governance covenant rather than a property of the code. That makes sizing a Risk Committee matter: 20M represents roughly a third of the reserve fund’s gross onchain holdings, and a larger share of the reserve net of buffers already earmarked against other exposures. We are comfortable at the proposed 20M given the containment model, with the full reserve position confirmed at seeding and any future increase returning for a fresh review.

Launch is effectively one-directional until collateral accumulates. Redemptions pay out of a standing USDC/USDG inventory that the proposal does not separately budget. Ethena has indicated that the collateral side will accumulate from initial mints, with custodians initially holding the USDe float, honoring mints, and then holding inventory as directed by the ALM manager. That is a workable design, and we ask that the phasing be explicit so whitelisted participants know that redemption capacity in the early period is bounded by accumulated mint proceeds.

Oracle and limit configuration is where the remaining risk lives. The audit’s stale-peg finding and our own review point in the same direction: production should tighten the oracle staleness bound well below the code maximum, use canonical price endpoints, and set per-market-maker limits below the global caps so that no single counterparty can consume the system’s full throughput.

Supply accounting must be arranged before the ceremony. The seed raises total supply without raising reserves, so the carve-out needs to be agreed with the proof-of-reserves attestors and supply trackers before the mint executes, with the float held at dedicated, disclosed addresses. This is the one step that cannot be repaired after the fact.

Conditions

We support approval subject to five conditions, each of which is operational and achievable before launch.

  1. The production deployment launches with its admin, all functional roles, and control of the oracle stack under the timelocked multisig from day one, with source verified on the L2 explorer and the full configuration (roles, custodians, limits, fees, oracle parameters, and the redemption phasing plan) published for review before the float is seeded. Ethena has confirmed the fresh deployment under a timelocked multisig; the verification and publication requirements are ours, and we will confirm them at the pre-seeding review.

  2. Custody sits at dedicated MPC wallets separated from the admin role, and token approvals are capped near the float size rather than left unlimited.

  3. The supply carve-out is agreed with the proof-of-reserves attestors and the tracker exclusions are in place before the mint ceremony, with the float held at dedicated and disclosed addresses.

  4. The ceremony batch is published for review during the timelock delay, with a commitment that the USDe minter functions are never added to the timelock’s no-delay whitelist.

  5. The full reserve position, including assets held offchain, is confirmed at seeding, and any future float increase returns for a fresh review against the reserve at that time.

Recommendation

We support the approval of this proposal subject to the conditions above. The mechanism removes a real point of friction for key distribution partners, the proof of concept behaves as the proposal describes, the code has been independently audited with no critical or high severity findings, and the containment model around a novel structure is credible. We thank the Ethena team for their responsiveness throughout the review, including sharing the proof of concept and the security review, and we will re-review the production configuration ahead of seeding.

Blockworks Advisory has reviewed the proposal, supports it and agrees with Kairos Research’s recommendation, including the five conditions outlined in their review. The following analysis was run independently and is offered as supporting context for the committee.

Reserve Fund sizing

Kairos notes that the proposed 20M float represents roughly a third of the Reserve Fund’s gross onchain holdings, and a larger share once other committed uses are taken into account. The figures below quantify that second point.

The Reserve Fund’s onchain visible assets currently total approximately $62.6M. Two amounts within that total are already set aside for other purposes and would not be available to absorb a loss on this facility. The first is a provision held against potential losses on the protocol’s real world asset holdings, calculated as 4.5% of total RWA exposure and against current RWA exposure of approximately $501.7M, this comes to around $22.6M. The second is a smaller buffer tied to funding rate risk, currently around $0.2M. Net of both, the Reserve Fund available to this facility specifically is $39.8M rather than the full $62.6M.

Measured against that $39.8M figure, the proposed 20M float represents roughly half of the available amount, compared with roughly a third when measured against the full $62.6M. Both are valid ways of looking at the reserve, before or after those commitments are set aside. The arithmetic behind each is shown here since the float’s share of the reserve changes meaningfully depending on which base is used, and this supports treating the net figure as the more conservative reference point for sizing. As additional context, the RWA provision moves with RWA exposure over time. Thus, a decline in RWA exposure of around a quarter from current levels would raise the net figure to approximately $45.5M and lower the float’s share to roughly 44%. This is a sensitivity comparison only and it is not a prediction or recommendation about RWA exposure levels.

Demand levels based on historical activity on a comparable facility

Historical activity on Spark’s PSM3, a comparable facility already operating on Arbitrum and Base, provides a reference point for realistic day to day usage. The analysis covers 375 days of onchain swap activity across both chains, from roughly November 2024 through late January 2026.

Typical daily usage in that data was modest. On the busiest 5% of days, activity reached around $0.6M and on the busiest 1% of days, around $3.1M. One unusually large day, around $14.7M, was tied to early adoption activity shortly after one of the two chains launched. Usage was somewhat higher on weekdays than weekends (an average of about $0.2M versus $0.1M), and it was concentrated heavily on one chain (Base) throughout the sample, with the busier chain seeing roughly ten times the stress case activity of the quieter one.

This concentration is directly relevant to how a float might be split across chains. Sizing each chain to its own usage pattern gives a stress requirement of around $10M for the busier chain and around $1M for the quieter one, a combined total near $11M. Sizing both chains identically, matching the busier chain’s requirement on both sides, gives a combined total around $20M which is in line with the proposed size.

Estimating USDe specific demand directly

Spark’s PSM3 activity is a useful reference point but measures usage of a different facility swapping different assets. Demand was also estimated directly using data specific to USDe itself. Since no equivalent USDe facility exists yet to measure directly, several methods were tested, producing noticeably different results.

Scaling Spark PSM3’s usage rate to the amount of USDe currently available on L2s produces a modest estimate, under $1M. This method likely understates actual demand, since the amount of USDe currently on L2s is small partly because a facility like this one does not yet exist to make L2 use convenient. Assuming a portion of USDe’s existing bridge volume between mainnet and L2s would shift to this new facility, using 10% as a planning assumption, produces an estimate of around $8M. Incorporating a share of L2 decentralized exchange trading volume in USDe alongside that bridge volume produces a more conservative, higher estimate of around $16M.Together, these USDe specific estimates run from under $1M to around $16M depending on method, a wide spread that reflects genuine uncertainty in the available data.

Bringing the two sizing perspectives together

The historical PSM3 comparison and the USDe specific estimates point to a combined float in the range of $11M to $20M depending on method, with the equal split historical comparison landing closest to the proposed size at approximately $20M. Reserve Fund capacity at a considered risk level supports a float in the $23.9M to $27.3M range. Taken together, the proposed size sits at the upper end of demand based estimates and comfortably below Reserve Fund capacity at accepted risk level, consistent with equal expected demand across both integrations.

Blockworks Advisory supports moving forward with the proposal on the terms outlined in Kairos Research’s review.

1 Like