Redemption Liquidity Design

How sUSDest matches illiquid, long-dated real-estate bonds with predictable, fair redemptions.

How sUSDest matches illiquid, long-dated real-estate bonds with predictable and fair redemptions.

Introduction

Real-estate bonds pay coupons on fixed schedules and return principal at maturity. They cannot be turned into cash on demand without accepting a discount. A vault that promises instant redemption at par on top of them risks the classic liquidity mismatch: a wave of withdrawals forces sales at depressed prices, and holders who stay pay for holders who leave.

sUSDest avoids that by design. Redemption liquidity comes only from cash the vault actually has or will receive on schedule. Exits are sequenced in fixed epochs, and anyone who wants to leave immediately goes to a secondary market instead of forcing the vault to sell.

Motivation

Rigid or over-promised redemption terms on illiquid assets produce disorderly exits: secondary markets gap to steep discounts and confidence spirals. In both bank runs and the depegs of tokenized credit products, the proximate cause has usually been a redemption promise the asset side could not honour on demand, not the credit quality of the assets themselves.

USD.estate's answer rests on three commitments:

  1. Bonds are never sold early to fund redemptions.
  2. Redemptions are paid from a liquid reserve in fixed, global epochs.
  3. Instant exit is always available on secondary markets, at the market price.

Mechanism Design

Liquidity events: where redemption cash comes from

Between epochs, the vault's available USDest is refilled from four scheduled sources:

  • New deposits of USDest into the vault
  • Bond coupons received in USDC and converted to USDest
  • Principal repayments: maturities, amortisation, and issuer redemption windows (for example quarterly windows on T-Evergreen notes)
  • Base yield harvested from the T-bill reserve

The reserve floor

The strategy multisig cannot commit new subscriptions that would take the vault's liquid share below the reserve floor (RESERVE_FLOOR_BPS). The floor limits new allocation, not redemptions. At epoch close, all available USDest can go to the queue. If redemptions draw the reserve below the floor, new bond allocations stop until coupons, maturities or deposits refill it.

The queue: FIFO

Requests submitted before an epoch's cutoff are serviced at its close in submission order, until available USDest runs out. A request that is only partly filled keeps its place for the remainder. Nothing but submission order gives priority.

Example (available USDest at close = 5,000,000)

Holder Request time Requested (USDest equiv.) Filled this epoch Carried forward % filled
Alice Day 3 2,000,000 2,000,000 0 100%
Bob Day 11 2,500,000 2,500,000 0 100%
Charlie Day 20 1,500,000 500,000 1,000,000 33%
Dana Day 27 800,000 0 800,000 0%

Pricing during the queue

A request stays exposed to the vault until it is serviced. It is filled at the redemption share price at epoch close, not at the price when it was submitted. Queued holders still share in coupons received while they wait, and they also bear any impairment recorded before their request is filled.

Secondary markets as the instant exit

Holders who need immediate liquidity can sell sUSDest in DEX pools. When the market price trades below the redemption share price, arbitrageurs who can wait for an epoch buy at the discount. Their buying narrows the gap and keeps the secondary market liquid without any protocol subsidy.

Economic Implications

  • No reflexive fire sales. Because bonds are never sold into a run, a queue delays exits but does not destroy value for holders who stay.
  • Predictability. Holders can see available cash, the queue and upcoming coupon and maturity dates in the App and estimate when a request will fill.
  • Fairness. Two prices stop coupon sniping on the way in, and FIFO with no discretionary priority governs the way out.

Future research

USD.estate does not plan to launch paid priority mechanisms for the redemption queue, such as auctions for queue position. Any such mechanism would be documented, audited and put through the timelock first.