Three layers, one capital flow.
USD.estate is a two-sided credit protocol. It connects issuers of institutionally structured real-estate bonds with depositors who want yield from real-estate credit.
The system has three layers.
The protocol takes onchain dollar deposits, keeps a liquid Treasury bill reserve, allocates the remainder to permissioned real-estate bonds, and distributes the yield through a tokenized instrument stack. Legal title to every bond position sits offchain with a dedicated holding subsidiary.
Reserve layer
Where capital enters as USDest.
USDest · USDC · tokenized T-bills
Allocation layer
Where the sUSDest vault holds reserve and bond positions.
sUSDest · real-estate bonds
Governance layer
Where the USD.estate Foundation, a strategy multisig and a public timelock set and enforce protocol parameters.
Foundation · strategy multisig · timelock
How capital flows through USD.estate.
Capital in, capital out.
Capital in: USDest and sUSDest
Capital enters the protocol when an approved institution deposits USDC and receives USDest, a synthetic dollar pegged 1:1 and fully backed by USDC reserves. Part of the reserve is held in tokenized short-dated US Treasury bill funds. USDest itself does not generate yield. It is a stable, composable asset for holding, transferring or using across DeFi.
To earn yield, holders stake USDest and receive sUSDest, the protocol's yield-bearing token. sUSDest earns from USDC coupons from real-estate bonds held by the vault, and from Treasury bill yield on the USDest reserve, harvested into the vault. Yield is reflected in a rising exchange rate between USDest and sUSDest. Holders do not need to claim anything.
Direct minting and redemption of USDest at the smart contract level is restricted to allowlisted, KYC-verified market makers and institutions. USDest and sUSDest are always permissionless to hold, transfer, stake and trade on secondary markets.
Capital out: real-estate bonds and T-bills
On the allocation side, the protocol does not lend. It subscribes to permissioned real-estate bonds: ERC-3643 security tokens issued by regulated vehicles and secured on, or backed by, real estate. The initial eligible universe includes Luxembourg securitisation notes and Swiss-ISIN real-estate bonds.
No bond is eligible until it is added to the bond allowlist, and every addition waits out a public timelock. Once a bond is allowlisted, the strategy multisig may allocate to it within the guardrails.
Each position follows four phases: eligibility review, allowlisting, subscription and settlement, then holding through coupons to maturity. Legal title sits with a Cayman holding subsidiary; onchain, the BondPositionManager holds the ERC-3643 bond tokens and vault accounting records every position, accrued coupon and reserve balance.
Redemptions and liquidity.
Bonds are long-dated and illiquid, so sUSDest redemptions run on a fixed epoch cycle with a FIFO queue. At each epoch close, available USDest is paid out to queued requests. If demand is high and the reserve is fully used, the queue can carry over into later epochs. The protocol does not sell bonds early to satisfy withdrawals. Holders who need to exit immediately can sell sUSDest on secondary markets at the market price.
Deposits and redemptions use two different share prices. The deposit price includes coupon accrued but not yet received; the redemption price excludes it. This stops depositors from buying in just before a coupon lands and leaving right after.
Allocation guardrails.
Guardrails are the limits the strategy multisig cannot cross. The contracts check them on every allocation, and a transaction that would breach one reverts.
| Guardrail | Launch value | Purpose |
|---|---|---|
| Reserve floorRESERVE_FLOOR_BPS | 20% | Minimum share of vault NAV the vault must keep as unallocated USDest, so redemptions can be funded without selling bonds. |
| Per-issuer capISSUER_CAP_BPS | 20% | Maximum share of vault NAV exposed to any single issuer. |
| Per-bond capBOND_CAP_BPS | 10% | Maximum share of vault NAV in a single ISIN. |
| Bond allowlist timelockALLOWLIST_DELAY | 7 days | Delay between announcing a new bond and first allocation to it. |
| Subscription expiryMAX_SUBSCRIPTION_EXPIRY | 14 days | Maximum time USDest can stay committed to an unsettled subscription. |
Every change to a guardrail goes through the public 48-hour timelock, so depositors see it before it applies.
Foundation, strategy multisig and timelock.
USD.estate is operated by the USD.estate Foundation. Parameters are enforced in smart contracts and can only be changed through a public timelock.
A strategy multisig makes allocation decisions and services redemptions, bounded by guardrails enforced in the smart contracts. Changes to the guardrails, the bond allowlist and fee parameters are queued through a timelock controller, so depositors can see them before they take effect.
USD.estate Foundation
Cayman Islands foundation company, governed by a board of directors and an independent supervisor
Owns protocol IP; controls the timelock proposer role; approves institutional counterparties; holds the pause authority (timelock proposer is a 3-of-5 Safe; the compliance multisig that maintains the mint/redeem allowlist is 2-of-3)
Strategy Multisig
3-of-5 Safe multisig
STRATEGY_ADMIN_ROLEcommits and cancels subscriptions to allowlisted bonds, harvests base yield, deposits receipts, services redemptionsTimelock Controller
Onchain delay contract; open executor
Queues and executes allowlist changes, guardrail changes, fee changes, role changes and upgrades. Only the Foundation multisig can propose; once the 48-hour delay has run, anyone can execute the queued call
Pause Guardian
2-of-4 Safe multisig, signers disjoint from the strategy multisig
PAUSE_ADMIN_ROLEemergency pause onlyHolding Subsidiary
Wholly owned by the Foundation; 2-of-3 Safe multisig
CREDIT_AGENT_ROLErecords credit events, impairments and recoveries under the published rule
No governance token has been issued.