Skip to content

Deposit readiness

user

How the public deposit gate works — audit, disclosure, oracle, liquidity, and deployment readiness plus per-vault on-chain marking — and what each check covers.

The public deposit gate is driven by audit, disclosure, oracle, liquidity, and deployment readiness — each check individually recorded, all fail-closed. Pooled USDG belongs behind completed readiness checks, and the gate is enforced in the vault contracts, in the API, and in the UI. Its live state is on the vault status page and in GET /api/vaults/readiness.

What deposit readiness checks

  • Smart-contract internal audit signoff.
  • Deposit-terms and disclosure review signoff.
  • Stock Token and USDG source verification (canonical addresses, current docs).
  • Oracle policy (staleness limits, paused-feed behavior) and liquidity policy per asset.
  • Fee, creator/operator, depositor-risk, and withdrawal/lockup disclosures.
  • The no-endorsement, no-guarantee, and no-tax-advice disclaimers.
  • Contract deployment and verification status on Robinhood Chain.

There is deliberately no jurisdiction check in this gate. Issuer-side restrictions on specific assets (for example, U.S.-person restrictions on ERC-8056 Stock Tokens) are surfaced as per-asset disclosures the depositor acknowledges — they never gate HISS deposits.

What you can do today

  • Save vault candidates for free. Configure allocations, fuses, and fees with the vault creation wizard.
  • Complete the creator acknowledgment and generate deterministic receipts.
  • Creators can seed their own skin-in-game deposits once their vault is live on-chain.

States

  • Gate closed — the fail-closed default whenever any readiness approval is missing. Creators can prepare candidates; the public cannot deposit.
  • Deposits open (product level) — every readiness approval recorded and the factory wired to the on-chain deposit readiness registry. Each vault then accepts deposits only once it is individually marked ready in that registry. Revocable at any time, per vault or globally.

Reading the state: GET /api/vaults/readiness reports the gate as an affirmative, recorded state. A failed or rate-limited status read is unknown or last verified, never “closed” — the closed state is a recorded gate fact, not a fetch-failure default. Unknown/unavailable is not the same as not deployed, and a degraded live check means the page is using last verified status. The gate itself still fails closed on-chain and in the API: an unproven deposit intent is refused regardless of what any status page shows.

Why this is strict

Pooled deposits concentrate other people's money behind a creator's strategy. Every unlock in this system — per-asset live rebalancing, public deposits, house vaults — fails closed until its checks pass, and every check leaves an on-chain event. Track the live state on the vault status page.