Vault contract status

This page answers one question honestly: are the HISS vault contracts deployed on Robinhood Chain? Deployment status is verified from Robinhood Chain reads — bytecode at recorded addresses — never asserted from copy. The card below reflects the live, machine-verified state; when the live check is degraded it falls back to the last verified snapshot, labeled as such.

What is live today

• The vault interface: marketplace, creation wizard, fee schedule, risk pages.
• Vault candidates. Creators can configure allocations, fuses, and fees, complete the creator acknowledgment, and save a validated candidate for free — no contract deployment required. Saving a candidate never implies deployment.
• Deterministic receipts and manifest hashes for every saved candidate.
• The Bankrbot → Robinhood MCP path, which is separate and does not use vault contracts.

The four possible states

• Not deployed. “Vault contracts are not deployed yet.” Candidates can be created; public deposits are not open.
• Testnet deployed. “Vault contracts are deployed on Robinhood Chain testnet.” Testnet contracts are available for verification; mainnet deployment is not live; public deposits are not open.
• Mainnet deployed. “Vault contracts are deployed on Robinhood Chain.” Even then, deployment alone never opens deposits — verification and deposit readiness follow.
• Mainnet deployed and verified. “Vault contracts are deployed and verified on Robinhood Chain.” The full state: bytecode proven by chain reads plus a source-verification artifact for every contract.

What opens public deposits

1. Contract deployment to Robinhood Chain, verified by chain reads.
2. Contract source verification and the internal audit signoff.
3. Deposit readiness: deposit-terms, disclosure, oracle, and liquidity approvals, each individually recorded. There is no jurisdiction axis in this gate — issuer-side asset restrictions are per-asset disclosures, never a deposit requirement.
4. The VaultFactory’s deposit gate wired on-chain to the deposit readiness registry. Even with the product gate open, each vault accepts deposits only once it is marked ready in that registry.

Deployed contracts on Robinhood Chain (chain id 4663)

• VaultFactory: 0x278d237c6890a5f7101296a9021ed9D26c821810
• VaultDepositReadinessRegistry (the live deposit gate): 0x2Bb41af03d2080896f0F6e5fb85136f7d7a34BFb
• VaultLegalReadinessRegistry (superseded): 0x31E4ECF99C993dfd1887E30dBa07c813BCe23e97 — the original readiness registry. Still deployed and source-verified, but the factory’s deposit gate was re-pointed to the VaultDepositReadinessRegistry above; it no longer gates anything.

The full suite (oracle adapter, asset registry, vault implementation, fee distributor, receipt registry, access policy) is recorded in the readiness API’s contractAddresses field with the same explorer base URL.

Status semantics

Statuses come from the shared StatusTruth vocabulary (live, verified, open, closed, pending, blocked, degraded, unavailable, unknown, last_verified), resolved with a fixed evidence precedence: fresh on-chain reads, then the readiness API, then database records with verified artifacts, then deployment artifacts with proof, then the last verified snapshot. Two rules bind every reader, human or agent: Unknown/unavailable is not the same as not deployed. Live check degraded means the page is using last verified status. A failed or rate-limited status fetch is never evidence that contracts are undeployed, the token is unlaunched, or deposits are closed — negative claims require affirmative proof, such as a no-bytecode chain read or an artifact recording the closed state.

How to check programmatically

GET /api/vaults/readiness reports vaultContractsStatus (not_deployed · testnet_deployed · mainnet_deployed · mainnet_deployed_verified), contractsVerified, vaultFactoryAddress, depositReadinessRegistryAddress, publicDepositsEnabled, publicDepositGateStatus, and jurisdictionGate: "removed". The agent skill file at /skill.md carries the same truth rules.