sUSDest

sUSDest is the staked version of USDest. It accrues yield from real-estate bonds and T-bills.

sUSDest is the yield-bearing token of the USD.estate protocol.

Token Mechanics

USDest is staked to mint sUSDest. Yield from the underlying positions shows up in the exchange rate between the two, so sUSDest is not pegged 1:1 to any asset.

sUSDest is a non-custodial ERC-4626 vault with ERC-7540 asynchronous redemptions. Its bond exposure is held through the BondPositionManager, an allowlisted ONCHAINID identity that holds ERC-3643 bond tokens on behalf of the vault. The Holding Subsidiary is the legal holder of those bonds. Coupons, principal and recoveries are routed into the vault by predefined contract logic.

Conversion Rate Formula

The amount of sUSDest you receive when staking depends on the current deposit share price:

sUSDest received = USDest deposited ÷ Deposit share price

The amount of USDest you receive when redeeming depends on the redemption share price at the epoch in which your request is serviced:

USDest received = sUSDest redeemed × Redemption share price

where

Share price = Vault NAV ÷ Total sUSDest supply

At launch the conversion rate is 1:1: staking 100 USDest mints 100 sUSDest. As yield accumulates, the rate shifts. If the vault holds assets worth 110 USDest backing 100 sUSDest, the rate becomes 1.10 USDest per sUSDest. Staking another 100 USDest would then mint 90.91 sUSDest. (This example ignores accrued-but-unpaid coupon; in practice you pay the slightly higher deposit share price.)

The deposit price includes coupon that has accrued but not yet been received. The redemption price excludes it. See Deposit and Redemption Prices.

Exchange Ratio

sUSDest rebases by price, not by supply. The number of sUSDest tokens you hold never changes. Each token becomes redeemable for more USDest as yield accrues.

Yield Generation

Yield accrues as:

• Real-estate bond coupons accrue and are received in USDC
• The T-bill reserve behind USDest earns yield, which is harvested into the vault

Coupons and principal are routed automatically:

1. The issuer or paying agent pays USDC to the BondPositionManager.
2. The strategy role calls depositCoupon() or depositPrincipal(). The BondPositionManager converts the USDC into USDest through USDest.protocolMint and sends it to the vault.
3. The position's accrued coupon is settled, the vault's accounted reserve is credited (creditReserve), and the redemption share price steps up by the amount received.

More detail is in the Technical Protocol Overview.

Real-Estate Bonds

The vault earns most of its yield from permissioned real-estate bonds:

• Instruments: Luxembourg securitisation notes (for example Tortuga T-Evergreen), Swiss-ISIN real-estate bonds (for example through Estating), and other bonds meeting the eligibility criteria
• Token standard: ERC-3643 permissioned security tokens
• Collateral: real estate, within maximum LTV limits and with independent valuation
• Issuers: ring-fenced securitisation vehicles and bond issuers
• Coupons: set by each issuer under its bond terms and paid in or converted to USDC. The protocol does not set rates
• Tenor: held to maturity or to the issuer's scheduled redemption

Secondary Source: Treasury Bill Reserve

Capital not allocated to bonds stays as USDest in the vault, so it keeps earning T-bill yield through the reserve. That sets a yield floor for unallocated capital and limits cash drag between deposits, bond subscription windows and maturities.

The reserve has two jobs:

1. Yield continuity: depositors earn a baseline return regardless of when bonds are subscribed.
2. Liquidity: redemptions are paid from the reserve, so bonds never need to be sold early.

sUSDest Redemption Mechanics

Redemptions run on a global epoch cycle. This is one protocol-wide timer, not a countdown per user. The epoch length is a protocol parameter (EPOCH_LENGTH), set to 30 days at launch by governance and changeable only through the public timelock. The table below uses this 30-day epoch. For timing and pricing examples, see Deposit and Redemption Prices.

Timeline within each epoch (30-day example):

Period	Action
Any time	Holders may submit redemption requests (requestRedeem). Requests are never refused; the cutoff only decides which epoch they target
Day 28 — cutoff (EPOCH_CUTOFF, 48h before close)	Requests submitted up to this point are serviced at this epoch's close. Requests after it target the next epoch
Day 30 — epoch close	The strategy role services queued requests from available USDest at the redemption share price

Queue Processing: FIFO with Cash Constraints

At epoch close, redemptions are processed as follows:

1. Available USDest is calculated. This is USDest held by the vault that is not committed to a pending bond subscription.
2. The queue is processed FIFO. Requests are serviced in the order they were submitted.
3. All available USDest is released. The protocol pays out all available USDest to the queue, with no throttling. The reserve floor limits new bond allocations, not redemptions.
4. Scenario A (enough USDest): every queued request is filled in full.
5. Scenario B (not enough USDest):
   1. Requests are filled FIFO until USDest runs out
   2. A partially filled request receives its partial amount, and the remainder carries forward
   3. Unfilled requests carry forward to the next epoch
   4. Queue position is the only priority

A wallet may have several requests open at once. Each is a separate FIFO entry ordered by its own submission time, and each is filled and claimed independently. Staking more USDest later never changes the queue position of a request already submitted, and a later request never inherits an earlier one's place.

REDEMPTION QUEUE · FIFO

Request 1 Request 2 Request 3 Request 4 AVAILABLE USDest at close Epoch close FILLED IN FULL Claimable USDest filled in full USDest RUNS OUT Partial fill · remainder carries to next epoch →

Once a request is serviced, it becomes claimable. Click Claim on the request in the App (claimRequest(requestId, receiver)), or call the ERC-7540 redeem or withdraw functions, which claim your serviced requests oldest-first, to receive your USDest.

Critical Constraints

The protocol never sells bonds early to meet redemptions. Bonds run to maturity, or to the issuer's scheduled redemption under their terms. This means:

• When most capital is in bonds, available cash may be limited
• Redemption queues may extend across several epochs
• Nobody can force immediate liquidity from the protocol

Instant Exit

Holders who need liquidity before an epoch closes can sell sUSDest on a secondary DEX pool. The market price may be above or below the redemption share price.

Ready to stake? Stake for sUSDest.