---
name: hiss-coilops-bankrbot-vaults-meridian
description: Use HISS for three coordinated surfaces. Part I — the Bankrbot → Robinhood MCP autonomy path: compile user-authored Coils into Bankrbot command packs and Robinhood MCP execution capsules with mandatory fuses, ack-gated live_candidate, and post-run audits. Part II — Robinhood Chain USDG Creator Vaults: permissionless pooled USDG vaults on Robinhood Chain (4663/46630) with source-verified tokenized assets, transparent creator fees, high-water-mark accounting, deterministic receipts, and a public deposit gate that blocks public deposits. Part III — launch architecture and x402 payment lanes: Bankr x402 Cloud (Base-settled) and Meridian x402 (documented facilitator support for Robinhood Chain with USDG). HISS never stores credentials, never places orders, never routes pooled vault capital through Robinhood MCP, and never claims guaranteed yield.
tags: [robinhood-chain, usdg-vaults, creator-vaults, bankrbot, robinhood-mcp, coilops, risk-fuses, receipts, x402, meridian, agents]
version: 6
visibility: public
metadata:
  clawdbot:
    emoji: "🐍"
    homepage: "https://hiss.finance"
---

# HISS CoilOps Skill: Bankrbot, Robinhood MCP, USDG Vaults, and Meridian x402

Canonical route: https://www.hiss.finance/skill.md (lowercase). The uppercase
/SKILL.md route remains supported for older links.

HISS operates two strictly separated product paths plus a payment layer, and
this skill covers all three:

- **Part I — Bankrbot → Robinhood MCP autonomy path.** A user-authored Coil is
  compiled into a Bankrbot command pack and a Robinhood-MCP-ready execution
  capsule for the user's OWN Robinhood Agentic Account. No pooled custody, no
  HISS order placement, `liveOrderSent` hard-typed false.
- **Part II — HISS USDG Creator Vaults on Robinhood Chain.** Pooled on-chain
  USDG vaults deployed by creators to Robinhood Chain smart contracts, with a
  source-verified tokenized asset registry, vault shares, transparent creator
  and protocol fees, on-chain rebalance policies, and deposit-readiness gates.
  Robinhood MCP is never used for pooled vault execution.
- **Part III — launch architecture and x402 payment lanes.** Two distinct
  paid-service rails: Bankr x402 Cloud (production, Base-settled where
  configured) and Meridian, an x402 facilitator whose docs list Robinhood
  Chain (4663) with USDG settlement. The vault chain and the payment chain are
  always tracked separately.

The vault chain is Robinhood Chain (mainnet 4663, testnet 46630). Base is not
a vault chain; it appears only as an x402 payment settlement rail. Robinhood
itself does not document x402 support — Meridian documents x402 facilitator
support for Robinhood Chain, which is a statement about Meridian, never about
Robinhood. HISS is not a broker-dealer, investment adviser, custodian, or
order router. Nothing here is personalized investment advice or a guarantee
of anything.

# Part I — Bankrbot → Robinhood MCP Autonomy Path

## I.1 Purpose

- HISS is a CoilOps compiler and safety-verification layer.
- Bankrbot is the natural-language / payment-facing agent interface. It can
  call HISS services and present user-approved workflows.
- Robinhood MCP (`https://agent.robinhood.com/mcp/trading`) is the
  user-authorized execution rail.
- The user's Robinhood Agentic Account — a dedicated, separately funded
  account the user controls — is the only place any live stock order occurs.
- HISS outputs instructions, receipts, runbooks, checklists, and audits.
- HISS does not execute trades. There is no order-placement surface anywhere
  in HISS.

## I.2 When to use this skill

- A user wants to compile a Coil for Bankrbot.
- A user wants to prepare a Robinhood MCP instruction pack.
- A user wants to validate autonomy fuses.
- A user wants to run a paper/preview workflow.
- A user wants to check live-readiness (the live-readiness gate).
- An agent wants to call HISS x402 services.
- An agent wants to run a post-run audit against a receipt.

## I.3 When not to use this skill

- Do not use it to recommend securities. HISS operationalizes the user's own
  Coil; it never picks tickers.
- Do not use it to bypass user consent, in any form.
- Do not use it to place orders directly through HISS — no such rail exists.
- Do not use it to collect credentials of any kind.
- Do not use it to provide personalized investment advice.
- Do not use it for crypto: current Robinhood docs do not support crypto for
  agentic trading (crypto, futures, and event contracts are listed only as
  "coming soon" as of 2026-07-07).
- Do not translate chain addresses into broker tickers. The two symbol
  spaces never mix.

## I.4 System roles

| Role | Owns |
|---|---|
| **User** | The strategy (Coil), the accounts, the agentic budget, all permissions, and the responsibility to monitor agents, account activity, and positions. |
| **HISS** | Validation, compilation, fuse checks, live-readiness gating, deterministic receipts, instruction packs, post-run audits. Nothing else. |
| **Bankrbot** | Calling HISS services (free HTTP or paid x402) and presenting/operating user-approved workflows. It must not widen anything HISS compiled. |
| **Robinhood MCP** | The user-authorized trading interface for the asset classes Robinhood currently supports (long equities and options orders; crypto and futures are announced, not shipped). |
| **Agentic Account** | The user-controlled, separately funded Robinhood account where agentic trading is confined. All other Robinhood accounts are read-only to the agent. |

## I.5 Non-negotiable safety rules

- HISS must never claim an order was placed — no artifact can honestly say it.
- HISS must never output "order sent," "trade executed," "bought," "sold,"
  or any equivalent execution claim; the output guard fails closed on them.
- `liveOrderSent` must always be `false` in HISS artifacts.
- HISS must never accept or store Robinhood credentials.
- HISS must never request API keys, passwords, OAuth tokens, session
  cookies, seed phrases, private keys, or brokerage credentials.
  Credential-looking fields in any request are rejected without echoing
  their values.
- HISS must never provide personalized investment advice.
- HISS must never recommend specific securities.
- HISS must never bypass mandatory fuses — fuses are binding, not advisory.
- HISS must never infer live consent from a mode string.
- `live_candidate` requires a separate LiveAutonomyAck (section 7).
- `paper` is the default mode, always.
- `preview` cannot place orders.
- `live_candidate` is not proof that a live order may be placed — it only
  records that HISS readiness checks passed.
- All live execution, if any, must happen only through the user-authorized
  Robinhood MCP connection, in the user's Agentic Account, under the user's
  configured consent settings.

## I.6 Autonomy modes

`autonomyMode ∈ { paper, preview, live_candidate }` — distinct from the Coil
executionMode and never a consent mechanism.

### paper (default; shown as "Readiness Check" in public UI)
- **Purpose:** pre-execution readiness verification and simulated planning only.
- **Allowed outputs:** paper runbook, Bankrbot command pack, fuse checklist,
  receipts, share card.
- **Prohibited outputs:** anything framed as account-ready execution
  instructions.
- **LiveAutonomyAck required:** no.
- **Order execution allowed by HISS:** no (never, in any mode).

### preview (shown as "Preview Capsule" in public UI)
- **Purpose:** prepares the Robinhood MCP execution capsule and checks
  readiness. Preview cannot place orders.
- **Allowed outputs:** everything in paper, plus the Robinhood MCP
  instruction pack marked preview and the live-readiness gate status.
- **Prohibited outputs:** any instruction authorizing order placement.
- **LiveAutonomyAck required:** no.
- **Order execution allowed by HISS:** no.

### live_candidate (shown as "Live Candidate" in public UI)
- **Purpose:** records that the capsule passed HISS readiness checks. It is
  a readiness label, not live execution and not an execution grant.
- **Allowed outputs:** the full artifact set with
  `liveReadinessGateStatus` reflecting the gate.
- **Prohibited outputs:** execution claims of any kind; anything implying
  HISS transmits the plan anywhere.
- **LiveAutonomyAck required:** YES — compilation fails closed without it.
- **Order execution allowed by HISS:** no. Any live order happens only in
  the user's Robinhood Agentic Account via the user's own MCP connection.

## I.7 LiveAutonomyAck requirement

The exact object (field names are load-bearing):

```json
{
  "acknowledgedAgentCanTradeWithoutPerOrderInput": true,
  "acknowledgedLossOfPrincipalRisk": true,
  "acknowledgedUserResponsibleForMonitoring": true,
  "acknowledgedUserResponsibleForAgentInstructions": true,
  "acknowledgedOrdersMayAppearInRobinhoodActivityAndHistory": true,
  "acknowledgedLongEquitiesAndOptionsOnlyUnlessDocsChange": true,
  "acknowledgedOptionsRiskIfOptionsEnabled": true,
  "acknowledgedHissNoCredentialsNoOrders": true,
  "acknowledgedNotInvestmentAdvice": true,
  "timestamp": "2026-07-07T00:00:00.000Z"
}
```

Rules:
- All fields must be present.
- All acknowledgment booleans must be literally `true` — truthy strings or
  numbers do not count and are rejected.
- `timestamp` must be a valid ISO-8601 string.
- The acknowledgment is separate from `autonomyMode`. Collecting it is a
  distinct user flow, never a side effect of choosing a mode.
- A mode string alone must never enable `live_candidate`.
- The acknowledgment hash (`liveAutonomyAckHash`) may be stored in receipts;
  raw sensitive credentials must never appear anywhere.
- Agents must never fabricate an ack, pre-check it, or carry one over from a
  previous session or a different Coil.
- The options-risk acknowledgment is part of the object and always required
  for live_candidate; options workflows additionally require Robinhood
  options eligibility on the user's account.

## I.8 Required autonomy fuses

Every autonomous trading path requires all ten fuse fields
(`AutonomyFuses`). Missing, ambiguous, or conflicting fuses fail closed.

| Field | Meaning / bounds |
|---|---|
| `allowedTickers` | Non-empty list of plain broker tickers, each present in the Coil's own `brokerSymbols`. |
| `maxNotionalPerOrderUsd` | Positive USD cap per order. |
| `maxDailyNotionalUsd` | Positive USD cap per day; must be ≥ the per-order cap. |
| `maxPortfolioAllocationPerSymbolBps` | (0, 10000] basis points. |
| `maxRebalanceFrequency` | `daily` \| `weekly` \| `monthly`. |
| `marketHoursPolicy` | `market-hours-only` \| `extended-allowed`. |
| `slippageLimitPolicy` | `{ orderType: "limit" \| "market", maxSlippageBps: (0, 10000] }`. |
| `stopConditions` | Non-empty list of binding stop rules. |
| `receiptLogging` | Must be literally `true`. |
| `postRunAuditRequired` | Must be literally `true`. |

Additional hard rules:
- Allocation basis points in the Coil manifest must sum exactly to 10,000.
- Broker tickers and chain addresses are separate symbol spaces.
- Any chain address (`0x…`) in a broker ticker field must fail validation
  (`SYMBOL_SPACE_CONFUSION`).
- Missing, ambiguous, or conflicting fuses must fail closed — there is no
  "best effort" compile.

## I.9 Coil input expectations

A Coil (`schemaVersion: "coil-1.0.0"`) supplies:
`name`, `whisper` (the originating idea), `manifest` (thesis + holdings with
`allocationBps` weights), `brokerSymbols` (the allowed-ticker source),
`fuses`, `triggers` (cadence), `policy`, `executionMode`, and receipt
metadata (`coilId`, `version`, timestamps).

- The Coil must be user-authored or explicitly user-provided.
- Agents must not invent holdings, tickers, allocation weights, or strategy
  intent.
- Agents may ask the user for missing Coil details, but they must not fill
  missing investment decisions with their own recommendations.

## I.10 Bankrbot command pack

A `BankrbotCommandPack` is a copy-pasteable instruction bundle that tells
Bankrbot how to call HISS, validate the Coil, request compilation, run paper
preview, and prepare the Robinhood MCP handoff.

Required sections (all present in the compiled object):
`userIntentSummary` · `manifestHash` · a HISS validation call prompt · a
HISS compile call prompt · `x402CallPlan` · a paper preview command · a
live-readiness gate reminder (`liveReadinessReminder`) · Robinhood MCP
handoff instructions (`robinhoodMcpHandoff`) · a post-run audit instruction
· banned-action reminders (`bannedActions`).

Required language the pack always carries:
- "Validate this Coil with HISS before any Robinhood MCP use."
- "Do not bypass fuses."
- "Do not infer user consent."
- "Do not claim HISS placed a trade."
- "Run paper preview before live_candidate."
- "Use only the user-authorized Robinhood Agentic Account."

The pack operationalizes the user's own Coil. It contains no personalized
buy/sell recommendations.

## I.11 Robinhood MCP instruction pack

A `RobinhoodMcpInstructionPack` is a structured set of instructions for a
Robinhood-MCP-connected agent based on a verified Coil.

Must include:
- A supported-asset-class statement based on current Robinhood docs (today:
  long equities and options orders; no crypto).
- The source-verified `robinhoodMcpToolPolicy`: all 44 Robinhood MCP tool
  names grouped (account/portfolio, watchlist, market data, equities,
  options, scanner), with the four live-capable order tools —
  `place_equity_order`, `cancel_equity_order`, `place_option_order`,
  `cancel_option_order` — marked as external Robinhood MCP tools, never HISS
  tools (`hissMayCallLiveOrderTools: false`, hard-typed).
- The account/agent boundary sentences, verbatim in the rendered
  instructions: "Use Robinhood MCP only through the user's connected
  Robinhood Agentic Account." · "HISS did not place, route, execute, buy,
  sell, or cancel any order." · "Live order tools such as
  place_equity_order, place_option_order, cancel_equity_order, or
  cancel_option_order are Robinhood MCP tools. They are not HISS tools." ·
  "The user is responsible for monitoring account activity, positions, and
  agent behavior." · "If the user has authorized the agent to act without
  per-order approval, the agent may be able to place trades without
  confirmation. HISS must make this explicit in the live-readiness
  acknowledgment." · plus the pre-live validation sentence covering fuses,
  account permissions, asset class, tradability, notional/cadence limits,
  market-hours policy, stop conditions, and receipt logging.
- The user-supplied `allowedTickers`.
- Order constraints (`orderConstraints`: order type + max slippage bps).
- Notional limits (`maxNotionalPerOrderUsd`, `maxDailyNotionalUsd`).
- Portfolio allocation limits (`maxPortfolioAllocationPerSymbolBps`).
- Cadence limits (`rebalanceCadence`).
- `marketHoursPolicy`, `stopConditions`.
- `receiptLoggingRequired: true`, `postRunAuditRequired: true`,
  `paperFirstRequired: true`.
- `liveReadinessGateStatus`.

Must NOT include:
- Robinhood credentials or user secrets of any kind.
- Instructions to bypass Robinhood safety flows.
- Claims that HISS executed any trade.
- Personalized recommendations.

## I.12 x402 service usage

HISS exposes five paid services for Bankr x402 Cloud (HTTP 402 flow, priced
in USD, settled in USDC on Base; a 4xx response is never billed). Schemas
live in each service's `bankr.x402.json` so agents can call them without
custom integration.

| Service | Price target | Purpose |
|---|---|---|
| `compile-coil-for-robinhood` (`compile_coil_for_robinhood`) | $1.00/call | Full path compile: command pack + instruction pack + runbook + receipt. |
| `validate-autonomy-fuses` (`validate_autonomy_fuses`) | $0.50/call | Validate the ten mandatory fuses + live-readiness gate; verdict, not a throw. |
| `generate-bankrbot-trading-prompt` (`generate_bankrbot_trading_prompt`) | $0.50/call | Just the Bankrbot command pack for a Coil. |
| `simulate-rebalance-plan` (`simulate_rebalance_plan`) | $0.75/call | Drift/rebalance simulation against supplied current weights — previews only. |
| `post-run-audit` (`post_run_audit`) | $0.50/call | Audit reported activity against a receipt's fuses after any session. |

Per-service contract:
- **Input:** JSON body per the published schema (`coil` and options; the
  audit takes `receipt` + `activity`). Optional `nowIso` pins the clock for
  deterministic output.
- **Output:** the standard envelope `{service, generatedAt, result,
  checksums, notes, notInvestmentAdvice: true, liveOrderSent: false}`.
- **Safety behavior:** credential-looking fields are rejected before
  compute; every response passes the same execution-claim output guard as
  local HISS tools.
- **Failure behavior:** structured `{error: {code, message, issues[]}}` with
  a 4xx status — failed calls are not billed.

Honesty rules: x402 services may be scaffolded without being deployed. A
service must not be claimed as deployed unless deployment is verified. x402
calls never require brokerage credentials.

## I.13 MCP tools

New autonomy tools on the local `@hiss/mcp-server` (stdio):

| Tool | When to call | In → Out |
|---|---|---|
| `hiss_compile_bankrbot_robinhood_path` | User wants the full autonomy artifact set. | `{coil, autonomyMode?, fuses?, liveAutonomyAck?, paperPreviewCompleted?, nowIso?}` → path result (packs, runbook, gate, receipt, share card, warnings). |
| `hiss_validate_autonomy_fuses` | Before anything else, or to explain failures. | `{coil, autonomyMode?, fuses?, liveAutonomyAck?}` → issues + live-readiness gate (a verdict — an invalid input does not throw). |
| `hiss_generate_bankrbot_command_pack` | Regenerate only the Bankrbot pack. | `{coil, …options}` → `BankrbotCommandPack` + receipt. |
| `hiss_generate_robinhood_mcp_instructions` | Regenerate only the instruction pack. | `{coil, …options}` → `RobinhoodMcpInstructionPack` + receipt. |
| `hiss_post_run_audit` | After any external agent session. | `{receipt, activity[], nowIso?}` → `PostRunAuditReport` (violations, ok). |

Refusal / fail-closed cases for every tool: credential-looking fields;
`live_candidate` without a valid LiveAutonomyAck; missing or out-of-bounds
fuses; chain addresses in ticker fields; any output that would read as an
execution claim (the server refuses to return it).

Phase 5 stance still holds: local stdio MCP server; guarded output on every
tool; no order placement; no credentials; deterministic receipts wherever a
`nowIso` is pinned. Install:
`claude mcp add hiss -- node /path/to/hiss/mcp-server/dist/index.js`.

## I.14 API routes

| Route | Purpose |
|---|---|
| `POST /api/bankrbot/compile-robinhood-path` | Full autonomy path compile. |
| `POST /api/bankrbot/validate-autonomy` | Fuse + ack + gate validation (verdict). |
| `POST /api/bankrbot/generate-command-pack` | Bankrbot command pack only. |
| `POST /api/bankrbot/post-run-audit` | Audit reported activity vs a receipt. |
| `GET /api/bankrbot/schema` | Machine-readable schema for all of the above. |

All routes: 256 KB request cap · rate limited (30 req / 5 min per client
per tool) · no secrets · credential-looking fields rejected with
`CREDENTIAL_FIELD_REJECTED` and never echoed · no direct order placement ·
deterministic structured responses (pin `nowIso`) · output guard against
execution claims · errors as `{error: {code, message, issues[]}}`.

The schema route and the compile / validate / generate responses carry a
`sourceVerification` block citing the Robinhood "Trading with your agent"
article (URL, last-verified date, `supportedLiveOrders:
["long_equities", "options"]`, `cryptoSupported: false`, and the user-
responsibility notes) so downstream agents can see which primary source
backs the constraints.

## I.15 Standard workflow

1. Confirm the user has supplied a Coil or wants to create one (they author
   it; you do not).
2. Validate allocation math (bps sum exactly 10,000).
3. Validate symbol spaces (broker tickers only; no `0x…` anywhere near a
   ticker field).
4. Validate the ten mandatory fuses (`hiss_validate_autonomy_fuses` or
   `POST /api/bankrbot/validate-autonomy`).
5. Default to `paper` mode.
6. Compile the Bankrbot command pack.
7. Compile the Robinhood MCP instruction pack.
8. Produce the receipt and record the manifest hash.
9. Run the paper preview and review it with the user.
10. Require LiveAutonomyAck before `live_candidate` — a separate,
    explicit flow.
11. Require a post-run audit after any external agent activity
    (`hiss_post_run_audit` / `POST /api/bankrbot/post-run-audit`).

## I.16 Failure behavior

Fail closed, always:

- Missing fuses → fail (`AUTONOMY_FUSE_MISSING`).
- Invalid bps sum → fail (`WEIGHTS_SUM`).
- Credential-looking fields → fail (`CREDENTIAL_FIELD_REJECTED`); never echo
  the value.
- Chain address in a ticker field → fail (`SYMBOL_SPACE_CONFUSION`).
- Unsupported asset class (e.g. crypto via Robinhood agentic trading) →
  fail; do not improvise support.
- `live_candidate` without LiveAutonomyAck → fail (`LIVE_ACK_REQUIRED`).
- Output implies HISS placed an order → fail (output guard; the response is
  blocked, not softened).
- User asks for a specific stock recommendation → refuse, or redirect to
  user-authored strategy creation without choosing tickers for them.
- User asks HISS to execute a trade → explain that HISS does not execute
  trades; point to the user's own Robinhood MCP connection and controls.

## I.17 Output schemas

High-level shapes (see `GET /api/bankrbot/schema` for the full machine
version):

**BankrbotCommandPack** — `packVersion, coilId, coilName, manifestHash,
autonomyMode, userIntentSummary, prompts[{title, prompt}], x402CallPlan,
robinhoodMcpHandoff, bannedActions[], liveReadinessReminder, disclaimer,
liveOrderSent: false`.

**RobinhoodMcpInstructionPack** — `packVersion, coilId, manifestHash,
autonomyMode, supportedAssetClasses, allowedTickers[], orderConstraints,
maxNotionalPerOrderUsd, maxDailyNotionalUsd,
maxPortfolioAllocationPerSymbolBps, rebalanceCadence, marketHoursPolicy,
stopConditions[], receiptLoggingRequired: true, postRunAuditRequired: true,
paperFirstRequired: true, liveReadinessGateStatus, robinhoodMcpToolPolicy,
instructions, liveOrderSent: false`.

**LiveReadinessGate** — `status (not_ready | paper_pending | ack_required |
passed), checklist[{id, label, satisfied, detail?}], liveAutonomyAckHash?,
evaluatedAt`.

**AutonomyReceipt** — `receiptId, kind: "autonomy_path", coilId,
coilVersion, manifestHash, generatedAt, compilerVersion, autonomyMode,
bankrbotReady, robinhoodMcpReady, liveReadinessGateStatus,
liveAutonomyAckHash (if present), allowedTickers[], maxNotionalPerOrder,
maxDailyNotional, rebalanceCadence, stopConditions[],
postRunAuditRequired: true, supportedLiveOrderAssetClasses[],
toolPolicyChecksum, fuseChecksum, liveOrderSent: false, warnings[]`.

**PostRunAuditReport** — `auditId, receiptId, manifestHash, generatedAt,
activityCount, violations[{code, message}], ok, notes[],
liveOrderSent: false`. Activity is user/agent-reported; HISS reads no
brokerage account and confirms no order — it checks reports against fuses.

## I.18 Allowed language

- "Compiled for Bankrbot + Robinhood MCP."
- "No live order sent by HISS."
- "Not a performance claim."
- "Paper preview required before live_candidate."
- "This is a user-authored Coil."
- "HISS validates fuses and emits instructions; it does not route orders."

## I.19 Banned language

Every item below is banned in any HISS output or agent message about HISS —
never write these claims:

- Never claim "guaranteed returns" — no such guarantee exists.
- Never claim "safe profits" — not a claim any HISS artifact can make.
- Never describe the path as "set and forget" — users must monitor agents.
- Never say "we bought" — HISS cannot buy anything.
- Never say "we sold" — HISS cannot sell anything.
- Never say "order sent" — no HISS output may claim an order went anywhere.
- Never say "trade executed" — HISS executes nothing.
- Never write "HISS executed" anything — false by construction.
- Never write "HISS placed" an order — false by construction.
- Never present a "recommended portfolio" — HISS does not recommend.
- Never offer "personalized advice" — HISS does not provide it.
- Never call anything "risk-free" — autonomous trading risks principal.
- Never promise to "beat the market" — not a claim HISS supports.

## I.20 Example interactions

**Example 1 — user supplies a Coil and asks for a Bankrbot command pack.**
Validate the Coil (allocation math, symbol spaces, fuses), compile the path
in `paper` mode, return the command pack plus receipt, and include the
paper-first warning: paper preview comes before anything else.

**Example 2 — user asks to go live by setting mode to `live_candidate`.**
Reject: the LiveAutonomyAck is missing. Explain that live_candidate requires
the separate acknowledgment flow (section 7) and that a mode string alone
never enables autonomy. Do not pre-fill the ack for them.

**Example 3 — user includes a Robinhood password / API key / token.**
Reject the credential field (`CREDENTIAL_FIELD_REJECTED`). Do not echo the
secret back, do not store it, and explain that HISS cannot accept
credentials — Robinhood MCP auth happens through Robinhood's own OAuth
login, which never exposes the password to any agent.

**Example 4 — user asks which stocks to buy.**
Do not recommend securities. Offer to help structure a user-authored Coil —
they choose the tickers and weights; you validate structure, fuses, and
math.

## I.21 References

Last verified: 2026-07-07.

- Robinhood Agentic Trading overview — https://robinhood.com/us/en/agentic-trading/
- Robinhood support: agentic trading overview (MCP endpoint, setup, consent
  model) — https://robinhood.com/us/en/support/articles/agentic-trading-overview/
- Robinhood support: trading with your agent (current asset support: long
  equities and options orders) — https://robinhood.com/us/en/support/articles/trading-with-your-agent/
- Robinhood newsroom launch post (2026-05-27) — https://robinhood.com/us/en/newsroom/robinhood-is-now-open-to-agents/
- Bankr docs — https://docs.bankr.bot/
- Bankr x402 Cloud quick start — https://docs.bankr.bot/x402-cloud/quick-start/
- x402 protocol — https://www.x402.org/
- Coinbase CDP x402 docs — https://docs.cdp.coinbase.com/x402/welcome
- HISS docs: /docs/bankrbot-robinhood · /docs/autonomous-trading-safety ·
  /docs/mcp-server · /docs/x402-cloud · schema: /api/bankrbot/schema
- HISS research snapshot: docs/research/phase6-robinhood-bankr-verification.md

## I.22 Maintenance rules

- Re-verify Robinhood docs before changing any asset-class support claim.
- Re-verify Bankr/x402 docs before changing service or deployment claims.
- Keep SKILL.md, llms.txt, the docs pages, and MCP tool descriptions
  aligned — they describe one system.
- Any new tool or route must inherit the no-credentials, no-orders, and
  output-guard requirements.
- Any new autonomous mode must be added to tests before being documented.

# Part II — HISS USDG Creator Vaults on Robinhood Chain

## II.1 The two paths, never confused

| | Part I (Bankrbot → Robinhood MCP) | Part II (USDG Creator Vaults) |
|---|---|---|
| Capital | User's own brokerage Agentic Account | Pooled on-chain USDG in vault contracts |
| Chain | n/a (brokerage rail) | Robinhood Chain (4663 / 46630) |
| Execution | User-authorized Robinhood MCP tools | On-chain rebalance via registered adapters |
| Custody | Robinhood brokerage | The vault smart contract (never HISS) |
| HISS role | Compiler, fuse verifier, receipt layer | Compiler, fuse verifier, receipt layer, protocol treasury |
| Robinhood MCP | The user's execution rail | NEVER used for pooled vault execution |

Agents must never route pooled vault capital through Robinhood MCP, and must
never describe vaults as brokerage products.

## II.2 Chain and payment model

Every vault schema separates the chains explicitly:

```json
{
  "vaultChain": "robinhood_chain",
  "vaultChainId": 4663,
  "baseAsset": "USDG",
  "baseAssetAddress": "0x5fc5360D0400a0Fd4f2af552ADD042D716F1d168",
  "x402Providers": {
    "bankrCloud": {
      "status": "live_or_configured",
      "paymentChain": "base",
      "label": "Bankr x402 Cloud on Base where configured"
    },
    "meridian": {
      "status": "configured_or_live_or_blocked",
      "paymentChain": "robinhood_chain",
      "chainId": 4663,
      "asset": "USDG",
      "facilitator": "0x8E7769D440b3460b92159Dd9C6D17302b036e2d6",
      "label": "Meridian x402 facilitator on Robinhood Chain"
    }
  },
  "robinhoodMcpUsedForVaultExecution": false,
  "hissStoresRobinhoodCredentials": false,
  "hissPlacesOrders": false
}
```

Rules:
- The vault chain is Robinhood Chain only: chainId 4663 (mainnet) or 46630
  (testnet). Any other chainId — including Base 8453 — fails validation, in
  TypeScript, in the API, in the database CHECK constraint, and in the
  VaultFactory contract itself.
- Base appears only as an `x402PaymentChain` value, because Bankr x402 Cloud
  settles exclusively on Base (USDC) per current docs.
- Robinhood does not document x402 support. Never claim it. Meridian — a
  third-party x402 facilitator — documents Robinhood Chain (network
  `robinhood`, chainId 4663) with USDG as the payment token and facilitator
  contract `0x8E7769D440b3460b92159Dd9C6D17302b036e2d6`. See Part III for the
  full lane model; a self-hosted facilitator remains a disabled candidate
  (`ENABLE_ROBINHOOD_CHAIN_X402_CANDIDATE=false`).

## II.3 USDG base asset policy

- Canonical Robinhood Chain USDG: `0x5fc5360D0400a0Fd4f2af552ADD042D716F1d168`.
- USDG has **6 decimals** — never assume 18. Vault shares use 18 decimals with
  explicit conversion and a virtual-offset inflation-attack guard.
- USDG is the only base asset for Phase 7 vaults; vault creation with any
  other base asset fails closed.

## II.4 Tokenized asset registry

17 source-verified Robinhood Chain assets are seeded (last verified
2026-07-08): USDG, WETH, ten Stock Tokens (AAPL, AMD, AMZN, COIN, GOOGL, META,
MSFT, NVDA, PLTR, TSLA) and five tokenized ETFs (SPY, QQQ, SGOV, SLV, CUSO).

- Address is identity. A ticker match is never sufficient; every entry derives
  its contract address from the canonical registry and fails at load if a
  ticker is missing.
- Stock Tokens are ERC-8056 ERC-20s issued by Robinhood Assets (Jersey) Ltd.
  They provide **economic exposure** — not legal or beneficial ownership of,
  or rights against, the underlying issuer. Never claim direct stock
  ownership for any token unless docs explicitly document it for that token.
- U.S. persons are restricted from tokenized equities; jurisdiction policies
  ride on every asset entry and every depositor acknowledgment.
- Oracle policy: per-asset Chainlink AggregatorV3 total-return feeds whose
  price ALREADY includes the ERC-8056 `uiMultiplier()` — never apply the
  multiplier twice. Feeds run 24/5, may hold last price off-hours, and may be
  `oraclePaused()` during corporate actions; stale or paused feeds block
  rebalancing. Exact heartbeats are unverified, so staleness limits are
  conservative (25h) pending verification.
- Providers xstocks, ondo_stocks, issuer_native_tokenized_security, and
  unknown_provider are permanently disabled placeholders this phase.
- Every asset starts `liveRebalanceEnabled: false` and stays disabled until
  liquidity routes, oracle policy, legal readiness, and owner approval all
  pass. Live rebalancing is currently disabled for all 17 assets.

## II.5 Fee model (deterministic, disclosed, capped)

Fee schedule — launch. Launch fees are designed to stay close to an
external vault benchmark (leaders take a 10% share of gains — never of
losses — with ≥5% leader skin) while HISS grows vault supply. The active phase is `launch_beta` (`VAULT_FEE_PHASE` env; post-beta
values are config-gated, never silent).

| Fee | Launch beta | Later / bounds | Notes |
|---|---|---|---|
| Vault candidate save | 0 USDG | always free | Vault candidates are free to save — no VaultFactory deployment, no public deposits required |
| Public vault creation | 50 USDG | 25 USDG early-creator promo; post-beta target 100 USDG | Applies only when the vault is published onchain; paid to the HISS protocol treasury |
| Creator performance fee | 10% of new net profits above the high-water mark | launch cap 10% unverified; verified creators up to 20%, displayed prominently | Never charged on losses; never until prior losses are recovered |
| HISS protocol share | 10% of the creator performance fee at launch | 20% maximum, config-gated + disclosed | Carved from the creator fee, not an extra depositor fee — depositors pay no separate HISS performance fee |
| Rebalance routing fee | 0 bps (routing disabled) | 0.5 bps default / 1 bps standard cap / 2 bps advanced max once live | Routing fees are disabled until HISS routing infrastructure is live and used; never charged on candidate saves, validation, receipts, or blocked intents |
| Deposit fee | 0 | — | HISS charges no deposit fee |
| Withdrawal fee | 0 | excluding disclosed chain/liquidity costs | Chain gas, liquidity unwind, and slippage are disclosed separately; no hidden spread |
| Referral share | optional | carved from creator/protocol shares only | Always emitted on-chain, never hidden |

Worked protocol-share example (creator fee 10%, 100,000 USDG of new net
gains above the high-water mark — never charged on losses → total performance
fee 10,000 USDG): beta 0% share → creator 10,000 / HISS 0; standard 10% share
→ creator 9,000 / HISS 1,000; maximum 20% share → creator 8,000 / HISS 2,000.
Depositors retain 90,000 USDG of the gains in every case — no separate
depositor fee exists at any share level.

Creator policy: minimum 5% of vault TVL as creator skin-in-the-game, required
before public deposits can open (not to save a candidate) and enforced on
withdrawals while public deposits are open; public creator address and fee
recipient; strategy hash versioned with a notice period before changes.

Additional revenue surfaces (all disclosed): paid vault verification, creator
subscriptions, marketplace featured placements (labelled "paid placement",
which never implies safety or expected return), and paid x402 vault services.

## II.6 Depositor risks (state them, always)

- Depositors receive vault shares and share profits AND losses.
- Loss of principal is a real risk. No guaranteed yield, APY, or return of
  any kind exists. Vault deposits are not FDIC-insured and not bank deposits.
- Withdrawals may be subject to a disclosed lockup policy.
- Tokenized stocks are economic exposure, not direct ownership.
- Past performance is not a guarantee of future returns.
- Robinhood does not endorse HISS vaults; building on Robinhood Chain implies
  no endorsement (per the Robinhood Chain Terms of Service).

## II.7 Public deposit gate and house vaults

Public pooled deposits are DISABLED unless the 15-item gate is fully approved:
smart-contract audit, compliance review, jurisdiction policy, U.S.-person
restriction disclosure, Stock Token + USDG source verification, oracle policy,
liquidity policy, fee disclosure, creator/operator disclosure, depositor risk
disclosure, withdrawal/lockup disclosure, tax/legal-advice disclaimer,
no-endorsement disclaimer, and no-guarantee disclaimer. Current global status:
`candidate` — public deposits are blocked (audit and compliance review pending).
Creator skin-seeding deposits are allowed pre-approval so vaults can be
prepared responsibly.

Three house vaults (HISS Core USDG Vault, HISS Tokenized Equity Index Vault,
HISS RWA Cash-Equivalent Vault) are designed but BLOCKED behind explicit owner
approval, compliance approval, audit approval, published strategy
disclosure, skin-in-the-game, and full fee disclosure.

## II.8 Acknowledgment objects (exact shapes)

`VaultDepositorAck` — all 11 booleans literally true + valid ISO-8601
timestamp, validated fail-closed; the hash may be stored, the object carries
no PII:

```json
{
  "acknowledgedDepositorsShareProfitsAndLosses": true,
  "acknowledgedLossOfPrincipalRisk": true,
  "acknowledgedNoGuaranteedYield": true,
  "acknowledgedNotFDICInsured": true,
  "acknowledgedTokenizedStocksAreEconomicExposureNotDirectOwnership": true,
  "acknowledgedJurisdictionRestrictions": true,
  "acknowledgedHissNotBrokerDealerInvestmentAdviserCustodianOrOrderRouter": true,
  "acknowledgedRobinhoodDoesNotEndorseHissVaults": true,
  "acknowledgedRobinhoodMcpNotUsedForPooledVaultExecution": true,
  "acknowledgedVaultChainIsRobinhoodChain": true,
  "acknowledgedX402MaySettleOnBaseWhereConfigured": true,
  "timestamp": "ISO-8601 string"
}
```

`VaultCreatorAck` — all 9 booleans literally true + timestamp:

```json
{
  "acknowledgedCreatorIsVaultOperator": true,
  "acknowledgedCreatorFeeDisclosureRequired": true,
  "acknowledgedSkinInGameRequirement": true,
  "acknowledgedStrategyChangesRequireNotice": true,
  "acknowledgedNoGuaranteedYieldClaims": true,
  "acknowledgedNoPersonalizedAdviceClaims": true,
  "acknowledgedNoRobinhoodEndorsementClaims": true,
  "acknowledgedVaultChainIsRobinhoodChain": true,
  "acknowledgedX402MaySettleOnBaseWhereConfigured": true,
  "timestamp": "ISO-8601 string"
}
```

A depositor risk acknowledgment hash is required before any deposit intent
compiles. No intent, receipt, or contract stores sensitive PII.

## II.9 Vault API routes

`GET /api/vaults/schema` · `GET /api/vaults` · `POST /api/vaults/create` ·
`GET /api/vaults/:slug` · `POST /api/vaults/:id/validate` ·
`POST /api/vaults/:id/deposit-intent` · `POST /api/vaults/:id/withdraw-intent` ·
`POST /api/vaults/:id/compile-rebalance-policy` ·
`POST /api/vaults/:id/simulate-rebalance` · `POST /api/vaults/:id/rebalance-intent` ·
`POST /api/vaults/:id/post-rebalance-audit` · `GET /api/vaults/:id/receipts` ·
`GET /api/vaults/:id/fees` · `GET /api/vaults/:id/source-verification` ·
`GET /api/vaults/asset-registry` · `GET /api/vaults/marketplace` ·
`GET /api/vaults/readiness`

All routes: rate limited, 256KB POST cap, credential-field rejection, double
output guard (execution claims + vault banned copy), structured errors,
deterministic receipts, chain validation (Base → 400 `VAULT_CHAIN_INVALID`),
and deposit-readiness validation. `deposit-intent` returns 409
`LEGAL_READINESS_BLOCKED` for public deposits while the gate blocks;
`rebalance-intent` returns 409 `LIVE_REBALANCE_BLOCKED` while every asset is
live-disabled. Both are the expected, honest states today.

## II.10 Vault MCP tools

`hiss_validate_usdg_vault`, `hiss_create_vault_manifest`,
`hiss_compile_vault_rebalance_policy`, `hiss_generate_vault_deposit_intent`,
`hiss_generate_vault_receipt`, `hiss_post_vault_rebalance_audit`,
`hiss_calculate_vault_fees`, `hiss_score_vault_risk`,
`hiss_compare_vaults_without_recommendation`.

All are guarded, credential-rejecting, and deterministic where applicable.
`hiss_compare_vaults_without_recommendation` returns a factual side-by-side
with `recommendation: null` — it refuses to rank or recommend, always.
`hiss_score_vault_risk` scores structure and readiness, never future returns.

## II.11 Vault x402 services (two payment lanes — see Part III)

| Service | Price |
|---|---|
| validate_usdg_vault_fuses | $0.50 |
| compile_vault_rebalance_policy | $1.00 |
| simulate_vault_rebalance | $0.75 |
| generate_vault_receipt | $0.25 |
| post_vault_rebalance_audit | $0.50 |
| vault_risk_score | $0.50 |
| vault_creator_due_diligence_pack | $2.00 |
| vault_comparison_report | $1.00 |

Each service has two potential payment lanes: the live Bankr x402 Cloud lane
(settles on Base, USDC, while Bankr documents Base settlement) and the
Meridian lane (settles on Robinhood Chain in USDG when `MERIDIAN_ENABLED` and
an API key are configured — see Part III for selection policy). Every schema
carries the vaultChain/x402PaymentChain separation, and a lane is never
silently downgraded: the selected provider and payment chain are always
labeled. 4xx responses are unbilled. Services never accept credentials, never
place orders, and pass the same output guards as everything else. A service
must not claim deployment unless deployment is verified.

## II.12 Allowed language

- "USDG Vaults on Robinhood Chain — with HISS fuses in the loop."
- "Vault chain: Robinhood Chain." / "Base asset: USDG."
- "x402 payments may use Base where configured."
- "Robinhood MCP is not used for pooled vault execution."
- "Public deposits are currently disabled until readiness checks pass."
- "Tokenized equity exposure" / "economic exposure, not direct ownership
  unless explicitly documented."
- "Past performance is not a guarantee of future returns."
- "Depositors share profits and losses." / "Not a performance claim."

## II.13 Banned language

- Never claim "guaranteed yield", "guaranteed APY", "safe vault", or
  "risk-free" anything.
- Never say "set and forget", "managed portfolio", "we invest for you", or
  "deposit and earn safely".
- Never say "HISS guarantees performance" or "verified returns".
- Never claim "direct stock ownership", "own every stock", or "all stocks
  onchain".
- Never claim Robinhood, Paxos, Global Dollar, or any exchange "approved" or
  "endorsed" anything HISS ships.
- Never say "Robinhood supports x402" or claim x402 runs on Robinhood Chain
  (candidate only, unverified).
- Never describe vaults as "on Base" or "Base-native"; never say "Base vault".
- Never describe Robinhood MCP as a vault execution rail.
- Never present HISS as an investment adviser, broker, custodian, or order
  router; never give personalized investment advice or recommend a vault.

## II.14 Example interactions

**"Create a tech vault for me and pick the best stocks."**
Refuse the picking. Help the user author their own vault manifest: they choose
the allowed assets from the source-verified registry; HISS validates fuses,
fees, and policies, and compiles receipts. HISS never selects securities.

**"Which vault should I deposit in?"**
Do not recommend. Call `hiss_compare_vaults_without_recommendation` (or
`vault_comparison_report`) and present the factual side-by-side — fees, skin,
lockup, assets, risk score, readiness — with `recommendation: null`, plus the
depositor risk disclosures.

**"What APY does this vault guarantee?"**
State plainly: no guaranteed yield, APY, or return exists; depositors share
profits and losses; past performance is not a guarantee. Show the fee schedule
and risk disclosures instead.

**"Deposit 500 USDG for me now."**
Explain the boundary: HISS compiles a deposit intent that the USER signs from
their own wallet — HISS holds no keys and sends no transactions. Then check
the gate: while legal readiness is `candidate`, public deposit intents return
`LEGAL_READINESS_BLOCKED`, which is the expected honest state.

**"Route the vault through my Robinhood account."**
Refuse. Robinhood MCP is a per-user brokerage path (Part I) and is never used
for pooled vault execution. Vault rebalances happen on Robinhood Chain under
the vault's fuses, if and when live rebalancing is enabled.

## II.15 Failure behavior (fail closed)

- Wrong chain (anything except 4663/46630, including Base): fail.
- Noncanonical token address or unknown ticker: fail.
- Missing/ambiguous/conflicting fuse: fail.
- Stale or paused oracle: block rebalance.
- Public deposit gate not passed: block public deposits (409).
- `liveRebalanceEnabled` false (all assets today): block rebalance intents.
- Invalid or incomplete acknowledgment object: fail with field-level issues.
- Credential-shaped fields anywhere: reject without echoing values.
- Output implying execution, guarantees, or endorsement: blocked by guards.
- Requests for recommendations or "the best vault": refuse and redirect to
  factual comparison.

## II.16 References

- Connecting to Robinhood Chain — https://docs.robinhood.com/chain/connecting/
- Robinhood Chain Token Contracts — https://docs.robinhood.com/chain/contracts/
- Stock Tokens — https://docs.robinhood.com/chain/stock-tokens/
- Building with Stock Tokens — https://docs.robinhood.com/chain/building-with-stock-tokens/
- Chainlink tokenized equity feeds — https://docs.chain.link/data-feeds/tokenized-equity-feeds/robinhood
- Robinhood Chain Terms of Service — https://docs.robinhood.com/chain/terms-of-service/
- Bankr x402 Cloud — https://docs.bankr.bot/x402-cloud/overview/
- Bankr Agent Profiles — https://docs.bankr.bot/agent-profiles/overview/
- Bankr token launching — https://docs.bankr.bot/token-launching/overview/
- x402 protocol — https://x402.org / https://docs.cdp.coinbase.com/x402/welcome
- HISS docs: /docs/usdg-vaults, /docs/vault-depositor-risks,
  /docs/vault-deposit-readiness, /docs/tokenized-assets,
  /docs/robinhood-chain-stock-tokens, /docs/robinhood-chain-x402-candidate,
  /docs/vault-source-verification, /api/vaults/schema

Last verified: 2026-07-08 (see docs/research/phase7-source-verification.md).

## II.17 Maintenance rules

- Re-verify Robinhood Chain docs before changing chain, contract, asset, or
  restriction claims; re-verify Bankr/x402 docs before changing settlement or
  deployment claims.
- Any new vault asset requires canonical address + oracle + liquidity +
  jurisdiction + corporate-action policy before it may be enabled, and starts
  live-disabled.
- Any change to fees, acknowledgments, or the readiness gate must land in tests
  before it lands in docs.
- Keep SKILL.md, llms.txt, docs pages, MCP tool descriptions, and x402 schemas
  aligned; new tools and routes inherit the no-credentials, no-orders,
  output-guard requirements.
- Part I (Bankrbot → Robinhood MCP) invariants are unchanged by Part II:
  `liveOrderSent` stays false, and the two paths never mix.

# Part III — Launch Architecture and x402 Payment Lanes (Phase 7.5)

## III.1 Two providers, two payment chains, one rule

HISS paid services run on two distinct x402 lanes. They are never conflated,
and a lane is never silently swapped:

| Lane | Provider | Payment chain | Asset | Status |
|---|---|---|---|---|
| Bankr x402 Cloud | `bankr_cloud` | Base (8453) | USDC | Production — 11 deployed services + 8 vault-service scaffolds |
| Meridian facilitator | `meridian_facilitator` | Robinhood Chain (4663) | USDG | Configured when `MERIDIAN_ENABLED=true` + `MERIDIAN_API_KEY` present; blocked otherwise |
| Self-hosted | `self_hosted_candidate` | — | — | Disabled candidate (`ENABLE_ROBINHOOD_CHAIN_X402_CANDIDATE=false`) |

The one rule: **the vault chain and the payment chain are tracked
separately.** Vault deposits, shares, rebalances, and contracts live on
Robinhood Chain regardless of which lane a paid service call settles on.

## III.2 Required language (exact)

- "Bankr x402 Cloud is the existing production paid-service rail and
  currently settles on Base where configured."
- "Meridian documents x402 facilitator support for Robinhood Chain with USDG.
  HISS uses Meridian as the Robinhood Chain x402 lane when configured and
  verified."
- "Robinhood does not need to natively support x402 for HISS to use a
  third-party facilitator. Do not say Robinhood supports x402 unless
  Robinhood documents it."
- "Vault deposits and vault contracts remain on Robinhood Chain."

## III.3 Meridian facts (source-verified 2026-07-08)

- Supported-networks row, verbatim: network `robinhood`, chain ID `4663`,
  payment token `0x5fc5360D0400a0Fd4f2af552ADD042D716F1d168` (the canonical
  Robinhood Chain USDG address), facilitator
  `0x8E7769D440b3460b92159Dd9C6D17302b036e2d6` (X402ProxyFacilitator V6, the
  same address on all 16 Meridian mainnet networks), cross-chain via Across.
- **Mainnet only.** Meridian lists no Robinhood Chain testnet (46630) row —
  the Meridian lane never applies to testnet flows.
- API: base `https://api.mrdn.finance/v1`, auth `Authorization: Bearer pk_…`.
  Primary endpoint `POST /v1/settle`; also `POST /v1/permit` and
  `GET /v1/supported`. `POST /v1/verify` is deprecated (legacy only) — HISS
  does not build on it.
- Env: `MERIDIAN_API_KEY` (server-only, never `NEXT_PUBLIC_`), plus
  `MERIDIAN_ENABLED` (default `false`) and `MERIDIAN_PAYTO_ADDRESS`. The
  older `MERIDIAN_SK` / `NEXT_PUBLIC_MERIDIAN_PK` naming is stale demo-era
  naming and is not used.
- No SDK package exists; the integration is plain server-side fetch calls
  modeled on Meridian's reference implementation. Meridian's demo app is
  Base-Sepolia-oriented — its network config is never copied into HISS
  production vault flows.

## III.4 Lane selection policy

`selectX402Lane(serviceName)` in `@hiss/core`:

1. For vault services, prefer the Meridian lane when `MERIDIAN_ENABLED=true`
   AND `MERIDIAN_API_KEY` is configured.
2. Otherwise use the Bankr Base lane — always labeled as Base settlement.
3. Every selection result carries `{provider, paymentChain, reason}`; there
   is no silent downgrade, and `vaultChain: "robinhood_chain"` is invariant
   in the result regardless of lane.
4. Phase 6 Bankrbot autonomy services remain on the Bankr lane.

## III.5 Meridian settlement flow (server-side, fail-closed)

1. Buyer requests a vault service → HISS returns x402 payment requirements
   REBUILT on the server for every request: scheme `exact`, network
   `robinhood`, chainId 4663, canonical USDG (6-decimal base units), payTo
   pinned from server config. Buyer-supplied amounts, assets, networks, and
   recipients are never trusted.
2. Buyer submits the signed payment payload → `validateSettlementRequest`
   compares it against the rebuilt requirements and fails closed on any
   mismatch with typed codes: `X402_SERVICE_MISMATCH`,
   `X402_NETWORK_MISMATCH`, `X402_CHAIN_MISMATCH`, `X402_ASSET_MISMATCH`,
   `X402_RECIPIENT_MISMATCH`, `X402_AMOUNT_MISMATCH`, `X402_SCHEME_MISMATCH`.
3. Only on a clean validation does the server call the Meridian facilitator
   (`POST /v1/settle`) with the server-held API key. The key never reaches
   the client, logs, or receipts.
4. A deterministic x402 payment receipt (`hxrcpt_…`, `liveOrderSent: false`)
   is persisted to Postgres.
5. When Meridian is not configured, `POST /api/x402/meridian/settle` returns
   an honest `503 MERIDIAN_NOT_CONFIGURED` — no fake success, ever.

## III.6 x402 API routes

| Route | Purpose |
|---|---|
| `GET /api/x402/schema` | All lanes + the architecture object (III.8) |
| `GET /api/x402/providers` | Lane list with per-service provider/chain/status |
| `GET /api/x402/meridian/status` | Config booleans only, docs-derived chainId/USDG/facilitator, facilitator host, live `/v1/supported` check when a key exists — never key material |
| `GET /api/x402/bankr/status` | Deployed Bankr endpoints, Base settlement label, profile status |
| `POST /api/vaults/x402/[serviceName]/requirements` | Server-rebuilt payment requirements for a vault service via the selected lane |
| `POST /api/x402/meridian/settle` | Fail-closed validation + server-side facilitator settlement (503 when not configured) |

All are rate-limited, capped, credential-rejecting, and output-guarded like
every other HISS route.

## III.7 Robinhood Chain infrastructure (launch state)

- **RPC:** server-side reads resolve Alchemy first
  (`ALCHEMY_ROBINHOOD_MAINNET_RPC_URL`, keyed URL, server-only — never in
  client bundles), then generic env, then the rate-limited public RPC as a
  documented fallback. Live chain health (chainId 4663, latest block, USDG /
  WETH / sample Stock Token code, sample Chainlink feed freshness) feeds
  `/api/readiness` and `/api/vaults/readiness`.
- **Oracle requirements (per Robinhood docs, verified 2026-07-08):**
  staleness checks against the feed heartbeat, nonzero-price checks
  (`answer > 0`), sequencer-uptime verification before trusting a price (the
  uptime feed address is not yet published in Robinhood docs — Chainlink is
  the source of truth; HISS reports it "unverified" rather than inventing
  one), and `oraclePaused()` handling during corporate actions. Feed values
  already include the ERC-8056 corporate-action multiplier — never applied
  twice. Feeds update 24/5 following market hours.
- **Account abstraction (status only):** Robinhood Chain documents
  first-class ERC-4337 (entrypoints v0.6.0
  `0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789`, v0.7.0
  `0x0000000071727De22E5E9d8BAf0edAc6f37da032`, v0.8.0
  `0x4337084D9E255Ff0702461CF8895CE9E3b5Ff108`) and EIP-7702, with Alchemy
  and ZeroDev tooling. HISS does not use account abstraction yet; this is
  recorded so future work starts from verified facts.
- **Contracts:** vault contracts compile and test against chain 4663/46630;
  testnet broadcast remains blocked on an unfunded deployer (no faucet is
  documented); mainnet deploy requires explicit owner approval.

## III.8 Architecture object (canonical)

```json
{
  "vaultChain": "robinhood_chain",
  "vaultChainId": 4663,
  "baseAsset": "USDG",
  "baseAssetAddress": "0x5fc5360D0400a0Fd4f2af552ADD042D716F1d168",
  "x402Providers": {
    "bankrCloud": {
      "status": "live_or_configured",
      "paymentChain": "base",
      "label": "Bankr x402 Cloud on Base where configured"
    },
    "meridian": {
      "status": "configured_or_live_or_blocked",
      "paymentChain": "robinhood_chain",
      "chainId": 4663,
      "asset": "USDG",
      "facilitator": "0x8E7769D440b3460b92159Dd9C6D17302b036e2d6",
      "label": "Meridian x402 facilitator on Robinhood Chain"
    }
  },
  "robinhoodMcpUsedForVaultExecution": false,
  "hissStoresRobinhoodCredentials": false,
  "hissPlacesOrders": false
}
```

## III.9 Launch language additions

Allowed (in addition to Parts I–II):
- "Meridian x402 on Robinhood Chain."
- "Bankr x402 Cloud on Base where configured."
- "x402 payment chain is separate from vault chain."
- "Readiness Check" / "pre-execution verification" / "live-readiness gate" /
  "audit-readiness gate."
- "Public deposits are blocked until legal, audit, oracle, liquidity, and
  jurisdiction readiness are complete."

Banned (in addition to Parts I–II — public UI, docs, OG, metadata, API copy):
- Never say "paper mode" in public copy (internal mode values and test files
  may keep simulation vocabulary; users see "Readiness Check").
- Never present "mock", "mock data", "mock login", or "mock agent" publicly.
- Never present "demo trading", "demo vault", "fake trading", or "fake vault" publicly.
- Never present "fake TVL", "fake APY", "placeholder", or "lorem ipsum" publicly.
- Never present "prototype", "sample balance", or "sample trade" states publicly.
- Never say "Robinhood supports x402" or "x402 native to Robinhood".
- Never say "Base-native vault" or "vaults on Base".
- Never fabricate counters, TVL, APY, PnL, balances, trades, agents, wallet
  state, or vault data. Real data, honest empty states, or an explicit
  blocked/unavailable status — nothing else.

## III.10 Example interactions (launch layer)

**"Pay for a vault risk score via Meridian."**
Call `POST /api/vaults/x402/vault_risk_score/requirements`. If the Meridian
lane is selected, the response carries server-rebuilt requirements (network
`robinhood`, chainId 4663, USDG base units, pinned payTo). Sign exactly those
values and submit to `POST /api/x402/meridian/settle`; any tampered field
fails closed with a typed mismatch code. If Meridian is not configured, the
response labels the Bankr Base lane instead — the payment chain is always
explicit.

**"So Robinhood supports x402 now?"**
No. Robinhood does not document x402 support. Meridian — a third-party x402
facilitator — documents Robinhood Chain settlement support with USDG. That is
a statement about Meridian's infrastructure on a permissionless chain, not
about Robinhood, and Robinhood's terms note that third-party builders are
neither controlled nor endorsed by Robinhood.

## III.11 References (Part III)

- Meridian supported networks — https://docs.mrdn.finance/api-reference/supported-networks (verified 2026-07-08)
- Meridian smart contracts — https://docs.mrdn.finance/payments/smart-contracts (verified 2026-07-08)
- Meridian API reference — https://docs.mrdn.finance/api-reference/introduction (verified 2026-07-08)
- Meridian quickstart + API keys — https://docs.mrdn.finance/quickstart · https://docs.mrdn.finance/essentials/api-keys (verified 2026-07-08)
- Robinhood Chain oracles — https://docs.robinhood.com/chain/oracles-and-price-feeds/ (verified 2026-07-08)
- Robinhood Chain connecting/providers — https://docs.robinhood.com/chain/connecting/ (verified 2026-07-08)
- Robinhood Chain account abstraction — https://docs.robinhood.com/chain/account-abstraction/ (verified 2026-07-08)
- Robinhood Chain protocol contracts — https://docs.robinhood.com/chain/protocol-contracts/ (verified 2026-07-08)
- Bankr x402 Cloud — https://docs.bankr.bot/x402-cloud/overview/ (verified 2026-07-08)
- Full verification record: docs/research/phase75-source-verification.md

## III.12 Maintenance rules (Part III)

- Re-verify Meridian's supported-networks table before changing any Robinhood
  Chain settlement claim; re-verify Bankr docs before changing Base
  settlement claims.
- The Meridian lane may be marked "live" only after a successful live
  `/v1/supported` check AND a settled test payment; until then it is
  "configured" or "blocked", honestly.
- Any new payment lane inherits: server-rebuilt requirements, fail-closed
  validation, server-only keys, deterministic receipts, output guards.
- The canonical skill route is /skill.md (lowercase); /SKILL.md remains
  supported. Keep root SKILL.md and apps/web/public/SKILL.md byte-identical.