Verification means checkable facts, not confidence
An agent cannot verify the future, so honest pre-sign verification is about what is observable now: the modeled slippage and route leak at this exact notional, whether the chain settles through a public mempool or a sequencer, whether the output token’s contract address matches a registry entry (a registry match — never a safety, sellability, rights, or redemption verification), and which parts of the picture were not evaluated at all.
Just as important is what a point-in-time read cannot do: it cannot observe a transaction that has not happened yet. A privilege exercised after the purchase settles — a mint, a blacklist entry, a pool withdrawal — is invisible to every pre-sign check, Routescore’s included. Verification that claims more than that ceiling is claiming to see the future; the mechanics are covered in the rug-mechanics explainer linked below.
- Checkable now: modeled slippage and leak at size, ordering regime, registry recognition state, named gaps and caveats.
- Not checkable now: future behavior, privileges exercised after settlement (T+1), realized outcomes.
- The honest output is a verdict plus reasons plus caveats — never a promise.
Step one: the pre-sign check, as structured data
One keyed POST /api/public/v1/check/swap call (or the check_swap MCP tool) returns an advisory verdict — clear, caution, or unsupported — with stable machine-readable reason codes, the token registry state, modeled route figures, per-source freshness states, pre-written caveat sentences, and a methodology version on every response. The design principle is schema-enforced honesty: the caveats arrive as structured fields an agent relays verbatim instead of paraphrasing away.
The verdict semantics are deliberately conservative. Unknown token: caution. Missing data: unsupported. Never a guess. A clear never upgrades an unknown — unverified tokens and unknown order flow downgrade the verdict instead — and nothing in the response marks anything "safe"; there is no such flag, by design. A caution is data for the agent’s policy, not a block; an unsupported means "not evaluated by Routescore", and the right agent behavior is to say so rather than substitute a guess.
Step two: the evidence record — showing what was verified
Verification an agent cannot show later is just a claim. Every keyed check_swap call persists a durable routescore.preflight_record.v0 evidence record and returns record_id, evidence_bundle_id, and record_output_hash on the response. The record nests the full response verbatim, adds an identity-free declared actor type and an identity-redacted request echo, and carries a canonical-JSON SHA-256 integrity hash a third party can re-derive offline.
That turns the post-mortem question — what did the agent know at signing time? — into a retrieval: fetch the record by id (REST or the get_preflight_record MCP tool, owner-scoped to your account), re-derive the hash, and read the verdict, caveats, and gap states exactly as they stood. If the record write ever fails, the check still returns with those fields null plus a record_persistence_failed caveat — a missing record is visible, never silent.
The limits, stated up front
Everything in the check is modeled and point-in-time: the figures describe a moment under a stated methodology version, and where realized outcomes are uncalibrated — Robinhood Chain today, for example — the response says so instead of smoothing it over. The verdict is advisory: it informs the agent’s own policy (or the human behind it); it is not a recommendation, not an instruction to execute, and not investment advice.
And the division of labor is fixed: Routescore is one composable evidence element of the agentic stack, alongside the planner, executor, and wallet elements — it hands over evidence with caveats attached, and the decision stays with you or your agent. It never signs, submits, executes, or custodies anything.