The moment

In July 2026, Uniswap went live on Robinhood Chain — an Arbitrum-stack Ethereum L2 (chain id 4663) whose mainnet opened on July 1. Tokenized stocks and ETFs now sit in AMM pools next to stablecoins. At the same time, agent execution tooling matured: with skills like uniswap-ai, an AI agent can plan a swap, build the transaction, and submit it without a human touching a keyboard.

That is half a loop. The execution half — plan, quote, sign, submit — is well tooled. The evidence half — what this token legally is, whether this route can absorb this size, what ordering regime governs this chain, how fresh the reference price is, and what you will be able to prove afterwards — is mostly missing from agent pipelines today.

This guide is the evidence half, written as a checklist. Every item maps to a question you (or your agent) can actually check today, and each answer states plainly what has been observed, what is modeled, and what has not been evaluated at all.

The checklist

1. What does the token legally represent?

A tokenized stock on Robinhood Chain is not a share. Robinhood's Stock Tokens are, per the issuer's own disclosures, debt securities issued by Robinhood Assets (Jersey) Ltd that track the price of the underlying instrument. Holders do not receive shareholder rights — no voting, no direct claim on the underlying shares — and the tokens are not offered to persons in the US, Canada, the UK, Switzerland, or the UAE.

None of this is hidden; it is disclosed in the offering documents. The failure mode is not deception — it is an agent pipeline that never reads the disclosure. An agent that treats a price-tracking debt instrument as equity will make category errors in collateral policy, jurisdiction checks, and downside analysis. The wrapper structure is a legitimate design choice; the check is whether your policy layer knows which structure it is holding. The /robinhood-stock-tokens-rights page keeps the current rights-and-structure picture for Robinhood's Stock Tokens.

Checkable question: does your pipeline record, for each tokenized asset, the issuer, the instrument type, and the rights not granted — before sizing a position?

2. Is this contract the token you think it is?

New chains attract impersonation contracts within days. The question "is 0xabc… actually the AAPL token?" has a narrow, honest answer: registry recognition. A contract address either matches a curated registry entry or it does not.

Two boundaries matter here, and they are easy to blur:

Recognition is not safety. A registry match tells you the address corresponds to a known entry. It is not a sellability, liquidity, rights, redemption, or investment-quality verification. Routescore's own check_swap returns exactly this framing: recognized means registry match, nothing more.
Symbols are not contracts. For tokenized stocks and ETFs, a symbol-only lookup ("AAPL") cannot rule out fake-contract impersonation. Routescore downgrades symbol-only tokenized-asset checks to unverified and asks for the contract address. Anything outside the registry is unverified — which reads as "not evaluated as safe," never as "unsafe" and never as "fine."

Checkable question: does your agent resolve tokenized assets to a contract address and treat everything unmatched as unverified?

3. Can the route absorb your notional?

Pool depth on a days-old chain is thin and uneven. A quote that looks fine at $500 can carry materially different price impact at $50,000. The checkable facts are modeled slippage and price-impact bands at your notional, per route — and, just as important, the state label attached to those numbers.

Routescore reports Robinhood Chain at support level modeled: route and execution-risk modeling is available, but there is no live on-chain quote feed for the chain yet. A modeled number with a visible modeled state is usable in a policy ("only proceed on caution-or-better below X bps modeled slippage"). A number without its state is a trap — an agent cannot tell a live observation from a point-in-time model, so the response has to say which one it is.

Checkable question: does every slippage/impact figure your agent consumes carry an explicit state — chain support live / modeled / recognized, plus a score_state such as valid / partial / unsupported — and a methodology version?

4. What ordering regime applies?

Robinhood Chain uses sequencer ordering — first-come, first-served, the Arbitrum-stack default — with no Ethereum-style public mempool. That makes the mainnet mental model of pending-transaction sandwich exposure the wrong model here. Copying an Ethereum MEV checklist onto an FCFS L2 imports risk estimates that do not apply and misses the questions that do. The /robinhood-chain-mev page covers what changes under sequencer ordering — and what remains unmeasured.

The questions that do apply: how the single sequencer behaves under load, what inclusion and ordering look like in practice, and how finality interacts with the bridge. These are different risks, not obviously larger or smaller ones — and for Robinhood Chain, realized outcomes are so far uncalibrated. Routescore's route model flags this explicitly rather than scoring around it: sequencer-ordered flow produces a caution with reason sequencer_ordering_uncalibrated, because an unmeasured regime should not inherit another chain's numbers.

Checkable question: does your agent know which ordering regime the target chain uses, and does it treat uncalibrated regimes as a downgrade rather than a pass?

5. Is the reference price fresh?

An on-chain pool quotes 24/7. The underlying equity trades market hours. Between Friday close and Monday open, a tokenized stock's pool price can drift from the last official reference price of the underlying, and any oracle that reprices off the underlying goes quiet. A quote that is perfectly current as a pool price can be stale as a reference to the asset it tracks.

The checkable facts: whether the underlying market is open right now, when the reference price last updated, and how far the pool quote sits from it. Freshness deserves the same state discipline as everything else — fresh, partial, stale — so a policy can gate on it instead of guessing.

Checkable question: does your agent distinguish "the pool has a price" from "the reference price is fresh," especially outside market hours?

6. What will you be able to prove later?

If a position goes wrong in three weeks, the question becomes: what did the agent know at signing time, and from which sources? An agent pipeline that keeps no evidence records cannot answer it.

The checkable facts are boring and decisive: a timestamped record of the checks that ran, their verdicts, their caveats, and the methodology version that produced them — exportable, so the record is yours rather than trapped in a vendor. Every check_swap response is already dated and versioned (generated_at + methodology_version), so your agent can store it as that record; in the app, the decision journal and exportable evidence bundles keep durable, versioned decision records of what was observed, what was modeled, and what was not evaluated. Keyed check_swap calls go one further: each one persists a durable, hash-verifiable preflight record and returns its record_id, so a third party can retrieve the evidence and re-derive its content hash offline — see Verifiable pre-sign evidence records.

Checkable question: after your agent acts, can you reconstruct what it checked, when, and under which methodology version?

How to run these checks today

The pre-trade composite is one call. check_swap is available two ways, plus a partial browser preview:

REST: POST https://www.routescore.io/api/public/v1/check/swap
MCP: the check_swap tool in @routescore/mcp v0.2.1 (claude mcp add routescore --env ROUTESCORE_API_KEY=rs_live_... -- npx -y @routescore/mcp)
Browser, no account: /route-check?chain=4663 shows the modeled route-quality half only — no token-safety read and no composite verdict; those require the API/MCP check_swap call.

A real request against Robinhood Chain, with a tokenized-stock symbol and no contract address:

curl -X POST https://www.routescore.io/api/public/v1/check/swap \
  -H "Authorization: Bearer rs_live_..." \
  -H "Content-Type: application/json" \
  -d '{"notional_usd": 20000, "chain_id": 4663, "token_out": "AAPL"}'

And the shape of the honest answer (abridged; model figures elided):

{
  "verdict": "caution",
  "chain": { "chainId": 4663, "name": "Robinhood Chain", "supportLevel": "modeled" },
  "route": { "id": "uniswap-v3-rho", "orderFlow": "sequencer_ordered", /* modeled figures */ },
  "token_safety": {
    "state": "unverified",
    "recognized": false,
    "flags": ["address_required_for_tokenized_asset"],
    "caveats": [
      "AAPL is a tokenized stock/ETF symbol in the registry, but symbol-only checks are not recognized for tokenized assets. Provide the Routescore registry contract address for an address-level match.",
      "No safety, sellability, rights, redemption, custody, dividend, jurisdiction, or investment-quality verification was performed."
    ]
  },
  "reasons": ["sequencer_ordering_uncalibrated", "token_unverified"],
  "score_state": "partial",
  "methodology_version": "routescore.public_api.v1",
  "caveats": [
    "Pre-trade decision support only. Routescore does not execute trades, route funds, or promise an outcome.",
    "Route uses sequencer-ordered L2 settlement; Ethereum public-mempool sandwich assumptions are not applied, and realized RHC liquidity/slippage/oracle/finality outcomes remain uncalibrated."
  ]
}

Note what the response does not do: it does not upgrade an unknown into a pass, it does not paraphrase away the gaps, and caution arrives as data — the caller's policy decides what to do with it. A caution is not a block and a clear is not advice.

The step-by-step integration — MCP setup, verdict handling, rate limits — lives in the companion quickstart, Add a pre-sign evidence check to your agent.

For the standing chain-level picture, the Robinhood Chain risk map and the /robinhood-chain page cover the ordering, oracle, bridge, and liquidity gaps in one place. The /swap-slippage-checker and /benchmark pages cover route-level modeled slippage and the Route Quality Index methodology.

What is not solved yet

Honesty section, because a checklist that hides its own gaps fails its own test:

Robinhood Chain outcomes are uncalibrated. Support level is modeled; there is no live RHC quote feed yet, and realized liquidity/slippage/oracle/finality outcomes have not accrued enough labeled data to publish calibration for this chain. Until that clears, every RHC figure stays modeled-with-caveats.
Tokenized asset passports — machine-readable rights-granted / rights-not-granted fields per asset — are roadmap, not shipped. Today, item 1 on this checklist is read from issuer disclosures by a human or an agent, not from a structured Routescore field.
Basis monitoring (pool price vs. underlying reference divergence, item 5 as a live feed) is roadmap. Today the freshness question is checkable manually.
Can-sell probes (observed simulate-sell evidence) are roadmap. Today token safety is registry recognition vs. unverified — stated as such, never inflated into a sellability verdict.
preflight_action — a single policy-gated composite preflight beyond check_swap — is roadmap.

The operating position behind this list: gaps in a new rail get fixed by the platforms that own them. The useful work in the meantime is making each gap's state visible, machine-readable, and policy-usable — open — observed today, marked mitigated or resolved — observed publicly when the platform closes it. Nothing here requires the gaps to persist.

Where this sits in your stack

Routescore is one element of an agentic stack, alongside the planner, the executor, and the wallet — an evidence and attestation element, not a layer above the others:

plan → preflight (Routescore) → execute (venue/agent) → record (Routescore)

Think of it the way you would a home inspection report: the inspector doesn't guarantee the house and doesn't sell you the house — they document what they observed, what they couldn't access, and when they looked. The buying decision, and the execution, stay with you and your agent.

The browser checks — /route-check?chain=4663, the risk map, the slippage checker — are free and need no account. API and MCP access, key setup, and the full endpoint reference live at /developers and in the API & MCP access guide.

Modeled, point-in-time decision support. Routescore does not execute trades, route funds, custody assets, or promise outcomes, and nothing above is investment advice. Methodology version: routescore.public_api.v1.