Robinhood Chain agent trades

Verify execution before an agent signs on Robinhood Chain.

Robinhood is opening Robinhood Chain to third-party AI agents that trade on your behalf. Before an agent signs an RHC swap, it can call Routescore for a read-only pre-sign evidence read — modeled route quality, modeled MEV/execution exposure, a token registry read, and an advisory clear / caution / unsupported verdict — and every keyed call persists a tamper-evident, hash-verifiable record of exactly what the agent knew before it signed. Routescore is the pre-sign journal, a flight recorder for the decision — it records evidence, it never executes, signs, routes, or custodies.

Add a pre-sign check to your agentSee the calibration proof
Inspect it yourself

Model a Robinhood Chain swap the way an agent would — verdict, modeled leak, and caveats — then wire the same check into your agent.

The pre-sign journal for agents trading on Robinhood Chain

Robinhood Chain launched on 1 July 2026 as an Arbitrum-stack Ethereum L2, and Robinhood has said it is opening the surface to third-party AI agents — Anthropic, OpenAI, and Grok among them — that can trade on a user's behalf. That raises a question the retail era never had to answer at machine speed: when an agent signs a swap for you, what did it actually know before it signed? A pipeline that keeps no record cannot answer it later.

Routescore is the pre-sign journal for that moment — a flight recorder for the decision. Before your agent signs an RHC swap, one keyed call returns a read-only evidence read, and the same call persists a durable record of exactly what was observed, modeled, and not evaluated at signing time, under a stated methodology version. It is a black box for the agent's decision, not a control on the trade: Routescore records the evidence and hands it back with caveats attached; the decision — and the signature — stay with you or your agent.

  • One keyed call before the signature: an advisory clear / caution / unsupported verdict with machine-readable reasons.
  • The same call writes a durable, owner-scoped record of what the agent knew — re-verifiable offline.
  • Records evidence, never gates the trade: Routescore does not approve, block, execute, sign, route, or custody.

Where Routescore sits in the agent stack

Routescore is one composable element of the agentic stack — the read-only evidence / attestation element — alongside your planner, executor, and wallet. It is not a layer above them and not a guarantor of results. The composition is fixed and Routescore only ever occupies the bracketed steps:

The planner decides what to do; the executor and wallet sign and submit in your own venue; Routescore reads evidence before the signature and records the decision after. It never occupies the execute step. That division of labor is deliberate: an evidence element that could also execute would no longer be a neutral flight recorder.

  • plan → preflight (Routescore) → execute (venue / agent / wallet) → record (Routescore)
  • Preflight = the read-only check_swap evidence read your agent makes before signing.
  • Record = the persisted, hash-verifiable journal entry of what that read returned.

What the pre-sign read returns on Robinhood Chain today

Robinhood Chain is chain_id 4663, and check_swap supports it today: pass the chain id and the day-one Uniswap route (uniswap-v3-rho) and Routescore returns a modeled route-quality grade, a modeled expected-leak and slippage band at your notional, the token registry recognition state (recognized vs unverified), and an advisory verdict with stable reason codes. Because Robinhood Chain is a sequencer-ordered L2 with no public mempool, the Ethereum public-mempool sandwich framing is not applied and publicMempoolMevBps comes back null — the modeled MEV penalty on this chain sits near zero by construction, so slippage and thin day-one liquidity carry the read.

The honest RHC verdict today is caution, not clear. Robinhood Chain support is modeled, not live, and realized RHC liquidity, slippage, oracle, and finality outcomes remain uncalibrated — so the response returns the sequencer_ordering_uncalibrated reason and says so in the caveats rather than dressing an uncalibrated chain up as a clean pass. An unverified token or an unknown order flow downgrades the verdict further; nothing in the response ever marks a swap "safe" — there is no such flag, by design.

  • chain_id 4663 + route uniswap-v3-rho → a modeled route-quality grade, expected-leak band, and slippage band.
  • Token registry read: recognized vs unverified. A registry match is not safety, sellability, rights, redemption, custody, or liquidity verification.
  • Verdict clear / caution / unsupported with stable reason codes; the honest RHC verdict today is caution (support is modeled, outcomes uncalibrated).
  • publicMempoolMevBps is null on RHC — sequencer-ordered, no public mempool to model — never read as "no risk".

The record: what the agent knew, re-verifiable offline

Every keyed check_swap call persists a durable routescore.preflight_record.v0 record and returns three additive fields on the response: record_id (fetch the record via GET /api/public/v1/records/{record_id} or the get_preflight_record MCP tool), evidence_bundle_id (the stored evidence bundle), and record_output_hash. The record nests the full response verbatim — no figure renamed, softened, or re-summarized — and adds only what an audit needs: an identity-redacted request echo, a declared actor type (declared by the caller, never verified), and a canonical-JSON SHA-256 integrity hash.

That hash is what makes the journal a flight recorder rather than a note. It is a content hash, not a signature — record_id, recorded_at, and the integrity block are excluded, so anyone can re-derive it offline from the record document alone, with no Routescore account; if any field were edited after the fact, the recomputed hash would no longer match. The record is tamper-evident and hash-recorded, never cryptographically signed. Two boundaries are structural: records are identity-free (wallet addresses, ENS names, and emails are dropped before recording), and a response carrying calldata, transaction payloads, or signing material is rejected outright rather than stored — a preflight record can never be replayed into an execution.

  • record_id + record_output_hash returned on every keyed call — a canonical-JSON SHA-256 hash re-derivable offline.
  • The full response nests verbatim; the record is a superset, never a fork of what the check returned.
  • Identity-free by construction and execution-material rejected — evidence only, never signing material.
  • If the durable write fails, the check still returns with those fields null plus a record_persistence_failed caveat — a missing record is visible, never silent.

The proof the evidence is trustworthy — and where it is still a roadmap on RHC

Modeled evidence is only worth recording if it holds up against reality, so Routescore publishes its calibration openly at /calibration: a public claim requires at least two independent sources to clear a sample floor and a Brier/ECE quality ceiling on their own realized outcomes before any cohort may be cited. That is the mechanism that turns "modeled" into "calibrated".

For Robinhood Chain specifically, that calibration is a direction, not a live claim: realized RHC outcomes are not yet a calibrated public cohort. RHC route figures are modeled and honestly labeled uncalibrated today, and Routescore is building toward a calibrated read of RHC execution quality as realized-outcome labels accrue and a cohort clears the publication bar — the page will show it when it clears, not before. Until then the pre-sign read stays modeled and point-in-time, the verdict stays caution, and the journal records exactly that.

  • Live: /calibration publishes the methodology — the two-independent-source sample-floor + Brier/ECE bar every claim must clear.
  • Directional (not a live claim): a calibrated read of realized Robinhood Chain execution quality — RHC is uncalibrated and not yet a public cohort.
  • The direction is stated as a direction; the modeled read never borrows confidence from calibration that has not landed.
FAQ

Common questions

When an AI agent trades for me on Robinhood Chain, what does Routescore do?

Before the agent signs a swap, it can call Routescore for a read-only pre-sign evidence read — a modeled route-quality grade, modeled MEV/execution exposure where observable, a token registry read, and an advisory clear / caution / unsupported verdict. The same call persists a durable, hash-verifiable record of exactly what the agent knew at signing time. Routescore records the evidence; it never executes, signs, routes, or custodies the trade, and the decision stays with you or your agent.

Does Routescore approve or block the agent's trade?

No. Routescore is a read-only flight recorder, not a gatekeeper. It returns a modeled advisory verdict with reasons and caveats and records the decision — it does not approve, block, execute, sign, route, or hold funds. Your agent's own policy (or the human behind it) decides what to do with the evidence; a caution is data for that policy, not a stop.

Is the record tamper-evident, and can I verify it without Routescore?

Yes. Every keyed check_swap call persists a record carrying a canonical-JSON SHA-256 integrity hash, returned as record_output_hash. It is a content hash, not a signature: record_id, recorded_at, and the integrity block are excluded, so anyone can re-derive it offline from the record document alone — no Routescore account — and any after-the-fact edit changes the recomputed hash. The record is tamper-evident and hash-recorded, not cryptographically signed.

Does Routescore have calibrated proof of Robinhood Chain execution quality?

Not yet — and it says so rather than implying otherwise. RHC support is modeled, realized RHC outcomes are uncalibrated, and Robinhood Chain is not yet a calibrated public cohort on /calibration, which requires at least two independent sources to clear a sample floor and quality ceiling before any claim. A calibrated read of RHC execution quality is the direction Routescore is building toward as outcome labels accrue; today the pre-sign verdict is caution and the read stays modeled and point-in-time.

How does my agent get this — REST or MCP?

Both. POST /api/public/v1/check/swap with chain_id 4663 (and route uniswap-v3-rho) is the REST call; the same tool ships in @routescore/mcp as check_swap, with get_preflight_record to fetch the persisted record. check_swap is on the free agent tier — any signed-in tier can mint a key and call it (free 100/day, Pro 1,000, Power 10,000, per account); retrieving records is a Power-tier capability. The browser route check at /route-check?chain=4663 stays free and keyless for the modeled route-quality half, without a composite verdict or a persisted record.

Run it yourself — no signup, no wallet.

Routescore is read-only, non-custodial decision support. Run a check, keep the record, review the outcome — modeled and point-in-time, not investment advice.

Add a pre-sign check to your agent