Skip to content

Vault V2 — the 24/7 deposit vault

user

HissUsdGVaultV2 is the canonical vault for new deposits: instant bounded keeper-lane deposits, queued deposits and redemptions, in-kind redemption, live Price Mesh capacity, distinct preparation/submission/settlement receipts, and rebalancing inactive by policy. V1 is legacy.

HissUsdGVaultV2 is the canonical HISS vault for new deposits. It is live and seeded on Robinhood Chain mainnet (4663), runs a 24/7 request queue with constrained keeper settlement, and prices deposits and redemptions through the on-chain Price Mesh. Users sign their own transactions — HISS never holds keys, never custodies deposits, and never executes brokerage orders. Read live state from the Vault V2 status page or GET /api/vaults/v2/status — never from copy.

Deposit and redemption lanes

  • Instant bounded USDG deposit (keeper lane). Execution-coupled: shares mint against real fills, inside a live per-trade capacity bound.
  • Queued USDG deposit. The request enters the on-chain queue and settles in a keeper batch epoch.
  • Queued USDG redemption. Same request/settle model; the instant side is bounded by the vault's USDG cash buffer.
  • In-kind redemption. Structurally available whenever shares exist: redeem shares for the vault's pro-rata holdings, with no valuation gate.
  • Request lifecycle. Every request supports status reads, cancellation, and expiry recovery — a request is never silently dropped.

Capacity is a live read, never a promise

Per-trade capacity comes from the live Price Mesh safe-notional model, per asset and per side. GET /api/vaults/v2/status reports immediateDepositCapacityUsdg, immediateUsdgRedemptionCapacityUsdg, and the exact limiting fuse (liveness, TWAP, peg, rolling flow budget, manipulation cost, or the USDG cash buffer). Capacity moves with market depth; never quote a remembered number as current, and a failed read is unknown — never rendered as live capacity and never as zero.

Receipts: preparation ≠ submission ≠ settlement

  • PREPARATION — HISS compiled the request or calldata; nothing was signed or sent (liveTransactionSent: false). MCP and CLI outputs are at most this stage.
  • SUBMISSION — the user's own signed transaction landed on chain; a queued request exists but has not settled.
  • SETTLEMENT — the keeper batch epoch settled the request with exact conservation (or the instant/in-kind path completed). Only this stage is a completed deposit or redemption.

These stages never collapse: each later stage requires its own on-chain proof.

Rebalancing: inactive by policy

The chunked-rebalance lane is inactive by owner policy — not a fault state, never rendered as degraded, and never a promise of future activation. The owner's exact reason: "AAPL is currently the only execution-grade Stock Token asset. Initial public operation uses settlement-driven allocation and preserves the current USDG cash reserve." The deferred-decision record lives in the repository at docs/vault-v2/activation/REBALANCE-DEFERRED-DECISION.md.

The V2 contract suite (chain id 4663)

Truth rules for agents

  • Live state comes from GET /api/vaults/v2/status (stage ladder, MODE, lane states, capacity, limiting fuse, timelock ETAs) — all fresh on-chain reads.
  • A failed read is unknown — never "live", never "closed".
  • A deposit or redemption is complete only at the SETTLEMENT stage, proven on chain — job status, UI copy, and memory never count.
  • Depositors share profits and losses; nothing here is a performance claim or a guarantee of anything.

Read next