Ethereal closed pre-deposits while retaining a conditional eUSDe redemption route

eUSDe represents a claim on deposited USDe

The pre-deposit vault issued eUSDe shares when holders deposited USDe, giving the deposit a transferable token representation. Those shares identify a claim on the vault’s underlying asset. They aren’t a trading-account balance, and a token transfer doesn’t by itself release USDe from the vault. Redemption uses that claim to exchange shares for the underlying token.

The vault follows ERC-4626, the tokenized-vault standard, and its share token also uses ERC-20 functions. These functions explain why eUSDe could move into lending markets and other integrations during the pre-deposit program. Once another contract holds the shares, the wallet’s directly redeemable balance and its broader position can differ.

The redemption amount follows the vault’s conversion

The original pre-deposit design paired eUSDe with USDe on a 1:1 basis, without accumulating rewards inside the vault. That relationship describes token units, not a guaranteed dollar value. Receiving USDe leaves the holder exposed to that asset’s value; the conversion doesn’t create a fiat payment or fix a cash sale price.

Direct USDe donations to the pre-deposit vault can change its share-to-asset conversion rate. Its accounting uses the underlying token balance and the outstanding share supply. Consequently, the original pairing shouldn’t replace the contract’s calculation for a particular redemption.

The contract exposes convertToAssets for share conversion and previewRedeem for the USDe output of a specified share amount. A preview describes a calculation under the relevant onchain conditions. It doesn’t establish that the caller owns enough shares or that withdrawals are enabled, and conditions can change before execution.

Reading a preview doesn’t submit a redemption transaction.

Redeem and withdraw start from different quantities

The vault’s redeem method starts with an eUSDe share quantity and calculates the USDe that it returns. Its withdraw method starts with a USDe quantity and calculates the shares that it must burn. Both methods use the same underlying asset, with an owner whose shares fund the operation and a receiver who gets USDe.

ERC-4626 rounds a redemption’s asset output down and a withdrawal’s share requirement up, using the tokens’ smallest units. A wallet’s displayed decimal precision doesn’t define those contract quantities. The contract interface supports both methods; that doesn’t imply that the portal exposes every parameter or presents them as separate buttons.

Deposit closure and withdrawal enablement are separate

A closed pre-deposit campaign stops new participation without automatically answering whether existing shares can be redeemed. The pre-deposit contract defines separate enablement flags for deposits and withdrawals. Its withdrawal control applies to the shared logic behind redeeming shares and withdrawing assets. Switching from one method to the other doesn’t bypass that control.

Open full-size image

The portal’s remaining withdrawal option describes the available interface, while the contract state governs execution. A transaction simulation can reveal a disabled-withdrawal error or another execution problem before submission. A preview alone only calculates an amount.

Deposit closure doesn’t establish a redemption deadline or promise an unlimited withdrawal period.

Different operations return different assets

A direct pre-deposit redemption consumes eUSDe, while an external lending withdrawal can release eUSDe without converting it. Transferring receipt tokens and withdrawing exchange funds have different outcomes again. Lending withdrawals concern existing positions; ending the pre-deposit program doesn’t establish that those protocols have enough liquidity to release every holding.

External collateral adds conditions before redemption

An eUSDe position in a lending protocol can remain outside the connected wallet’s directly spendable share balance. The pre-deposit program included Aave and Euler integrations, alongside other DeFi placements. A supplied position or lending-vault receipt represents a different layer of ownership from wallet-held eUSDe. Returning that underlying asset depends on the holding protocol’s withdrawal rules.

Aave V3 limits collateral withdrawals when they would leave a borrowing position with a health factor below 1. Available reserve liquidity also matters. Closing the pre-deposit campaign doesn’t repay a borrowing position or make its collateral freely withdrawable. Any necessary debt or collateral adjustment belongs to that lending account.

Euler lending vaults likewise apply their own liquidity limits and account checks. A vault share represents a claim on that particular lending vault. When its underlying asset is eUSDe, a successful withdrawal returns eUSDe shares for redemption. The lending-vault receipt and the eUSDe receipt aren’t interchangeable, even though both can use ERC-4626 accounting.

A debt-related restriction and a liquidity shortfall require different responses. Reducing debt or providing eligible collateral can change borrowing constraints; it doesn’t necessarily restore assets that other users have borrowed. Conversely, additional reserve liquidity doesn’t remove an account’s collateral obligations.

Ethereum gas remains separate from the USDe output

The pre-deposit vault operates on Ethereum, where an ordinary wallet pays transaction gas in ETH. The gas payment is separate from the USDe that the redemption returns. Its amount depends on execution work and the applicable gas price, so a fixed withdrawal cost wouldn’t describe every transaction. Any external protocol exit adds its own execution and fee conditions.

USDe in the vault can’t fund an ordinary wallet’s ETH gas payment.

A redemption receipt identifies the actual token movement

A transaction hash identifies a transaction without proving submission. An execution receipt records block inclusion and the transaction’s overall success or failure. A pending transaction hasn’t completed redemption. A successful vault redemption burns the owner’s specified shares and transfers USDe to the receiver within the same transaction. It doesn’t require a later pre-deposit-vault claim merely because the portal calls the action a withdrawal.

The vault’s Withdraw event records the caller, receiver, share owner, asset amount, and share amount. Those fields distinguish the eUSDe consumed from the USDe paid, including cases where owner and receiver differ. Token balances and the transaction’s execution status describe the outcome more precisely than a connection message or a submitted signature.

A successful approval can leave the redemption entirely unexecuted.

Ended rewards don’t determine the vault’s payout

The pre-deposit program used eUSDe holdings for Ethereal points and Ethena rewards, with eligibility tied to the relevant program period. The mainnet-alpha transition set an endpoint for the earlier eUSDe points emissions and shifted the emphasis toward exchange activity. Those historical incentives shouldn’t be treated as ongoing compensation for retaining a receipt token after the program ended.

The portal marks its displayed integration bonuses as ended. That status concerns incentives, while the vault’s conversion determines its token payout. Its original design didn’t accrue rewards within the pre-deposit contract. A points balance therefore isn’t an extra USDe asset balance that the redemption method automatically includes.

Remaining exchange funds require the exchange withdrawal path

The closed exchange directed users to withdraw remaining funds and transition to Meridian. That notice concerns the trading platform and doesn’t redefine eUSDe as a successor-platform balance. USDe held in an exchange subaccount and eUSDe held on Ethereum belong to different accounting systems. If the holding is still a trading-account balance, the exchange’s withdrawal procedure applies instead of the pre-deposit vault’s redemption method.