Methodology
How Sato Route chooses
A route is a recommendation with its reasons attached. Each lane ranks candidates on an ordered list of readings, and every answer returns chosen_by — the signal, the value read, and the field it came from — so a caller can re-derive the choice instead of trusting it. The tables below are the same arrays the choosers are written against.
Swap — Which venue should this swap go through?
What it ranks over: Listed venues on the chain asked for, plus any venue that answered the caller's quote request even when it has no listing. An unlisted venue can still be routed to; it simply has no record behind it, which is unknown and not bad.
Why the first criterion is first: Exclusion comes first: a retired or year-silent venue is never offered, however good its quote.
- 0Retired or dormant venues are excluded outright
A listing marked "Deprecated", or with no public activity for over a year, is never chosen and never offered as an alternative.
reads: resources.status, resources.last_activity_at
- 1Quotable
When quotes were supplied at all, a venue that answered with one outranks a venue that did not. A route the caller cannot execute is not a route.
reads: the caller's quotes
- 2Liveness
Active > Recent > Quiet > no signal. A recency reading, not a quality judgment; no signal is unknown, and unknown ranks below a good reading rather than below a bad one.
reads: resources.last_activity_at
- 3Observed success of our own daily checks
The share of Sato Hub's OWN checks that succeeded, over at least 14 days. This is never uptime — a failure can be on our side. Under that window there is no record to rank on, which is not a bad record.
reads: resources.uptime_observed
- 4Verification state
A reproduced install and a reviewed listing are worth one point each. Self-reported earns nothing.
reads: resources.deploy_spec.deploy_status, resources.verification_status
- 5Price
Larger quoted output first — but BELOW liveness and the observed record on purpose: a venue that quotes a better number and then does not answer is worth less than one that answers. Every alternative is returned with its own numbers, so the caller can decide otherwise.
reads: the caller's quoted amountOut
- 6Name
The tiebreak of last resort, so the same data always yields the same route.
reads: resources.slug
A route is a recommendation, chosen on the fields named in chosen_by as they read on checked_at. It is not a security review, a quality judgment, or a statement about price, execution or returns — a quote is a quote, not a fill. Sato Hub does not sign, hold or move funds; the caller signs the transaction it is handed.
x402 — Which endpoint should this agent pay for a given capability?
What it ranks over: Endpoints that answered 402 inside the verification window and carry the capability asked for. Capabilities: price-feed, onchain-data, swap-quote, inference, storage, search, identity, other.
Why the first criterion is first: Qualification comes first: an endpoint that did not ask for money in a parseable shape inside the window is not a route, whatever else it scores.
- 0Qualify
The endpoint answered 402 inside the verification window, carries the capability asked for, and — when a chain was asked for — declares that network. A stale verification is "last checked", not verified. A declared facilitator that answered an error is disqualified; one we could not reach is unknown and ranks lower, not out.
reads: agent_metrics_daily answers_402, the requested capability, the 402 payload's declared network
- 1Facilitator reachable
Reachable ranks above unknown or none declared. Reachable is not solvent and not honest: it means something answered.
reads: the declared facilitator's own endpoint
- 2Declares a settlement network
Applied only when the caller asked for no particular chain. An endpoint that says where it settles is easier to act on than one that does not.
reads: the 402 payload
- 3Observed success of our own daily checks
The success rate OF OUR CHECKS, never uptime, and never invented where there is no record. A missing record ranks below a good record and above nothing.
reads: resources.uptime_observed
- 4Declared price
Cheapest first, ONLY between endpoints whose terms name the same asset. Prices in different assets are not comparable and are not compared.
reads: the 402 terms
- 5Host, then URL, alphabetically
So the same data always yields the same route.
reads: the endpoint URL
A verified 402 is a PROTOCOL observation: on that date the URL asked for money in a shape a client can parse. No payment was sent, then or now, and Sato Hub does not relay, forward, fund or settle anything. An endpoint answering 402 is not solvent, correct or honest.
Agent — Which agent should this job go to?
What it ranks over: Sato Agent Passports only. ERC-8004 registrations are NOT enumerated — no keyless enumeration exists in the request path, and inventing rows to fill the gap would be a claim about agents we never read. The payload says so in its coverage block.
Why the first criterion is first: Filters come first, and an empty pool answers unknown with its reason rather than stretching to a match.
- 0Filters
A candidate that does not claim what was asked for is removed, and an empty pool answers unknown with the reason — never a stretched match.
reads: the caller's need (chain, capability, requires_mcp, requires_x402)
- 1Registration confirmed
A registration proves a claim was made on-chain. It does not prove the agent works.
reads: erc8004.ownerOf(agentId), agents.onchain.erc8004.registered
- 2A declared service answered a probe
Answered > not probed > probed and did not answer. Not probed is unknown and ranks above a failure, not below it. A probe says the interface answered once, at checked_at — never uptime, never quality.
reads: preflight.probe.ok
- 3Counterparty feedback count
Higher first. A null count is unknown and ranks below EVERY number, including zero — a read we never took is not a score of nothing.
reads: erc8004.ReputationRegistry.getSummary.count, agents.onchain.reputation.erc8004.count
- 4Liveness
Most recently seen first; never seen sorts last.
reads: preflight.registration.checked_at, agents.onchain_checked_at
- 5Wallet verified by signature (passports only)
A signature proves control of the key, not that the product does what it says.
reads: agents.wallet_verified
- 6Id
So ties are stable rather than dependent on the order the pool happened to arrive in.
reads: the candidate id
A route is a recommendation, chosen by the fields in chosen_by as they read at checked_at. An ERC-8004 registration proves a claim was made on-chain, not that the agent works. A probe proves the declared service answered once. A feedback count is whatever counterparties published, and a null count means unknown, never zero. No job-outcome data exists yet. This is not an endorsement, and it is not a security review.
Launch — Where should this token launch, and why that venue?
What it ranks over: The static, cited venue table in lib/route/launchVenues.ts — 5 venues, every fact read from the venue's own documentation on 2026-09-11 and carrying the URL it was read from. Nothing here is measured.
Why the first criterion is first: Exclusions come first, each with the reason attached, so a caller can see which venues were dropped and why.
- 0Exclusions
A venue that does not document launches on the chain asked for, that the caller excluded, or whose published pool fee is above the caller's ceiling, is dropped with the reason attached. A venue that publishes NO fee is not excluded — unknown is not disqualifying.
reads: chains, the caller's constraints
- 1Execution lane
A venue we can hand a prepared deploy config for ranks above one we can only recommend. Recommending a venue and saying we cannot prepare its config beats emitting a config shaped from a guess.
reads: lane, programmable_fee_split
- 2Goal fit
A venue documented to serve the goal asked for ranks above one that is not. Documented by the venue itself, not inferred by us.
reads: goals
- 3Published creator share of the pool fee
Larger share first. A venue that publishes no per-party split has no creator share to compare and sorts last on this signal — unknown, not zero.
reads: creator_share_pct
- 4Published pool fee
Lower first. A published schedule is a schedule; it says nothing about what a token does after it launches.
reads: pool_fee_pct
- 5Slug
So the same table always yields the same route.
reads: slug
A launch route is a recommendation, chosen on the venue facts named in chosen_by as they were read on their as_of date. It is not a security review, an audit, a price forecast or a statement about what a token will do after it launches. Sato Hub does not deploy, sign, hold keys or move funds — the caller signs the deploy themselves.
The launch venues, and what is unconfirmed
Every fact here was read from the venue’s own documentation on 2026-09-11 and carries the page it was read from. Nothing in this table is measured, and a published fee schedule says nothing about what a token does after it launches. A null is a number the venue does not publish — unknown, never zero.
- Chains
- Base, Arbitrum
- Goals
- agent_token, meme, utility
- Pool fee
- 1%
- Creator share of that fee
- 80%
Unconfirmed
- ▸The maximum number of reward recipients is not stated on the SDK reference page read on 2026-09-11.
- ▸The 1% pool fee is the default static fee; a deploy may configure static or dynamic fees, so an individual token's fee can differ.
- Chains
- Base, Arbitrum, Robinhood Chain
- Goals
- agent_token, meme, utility
- Pool fee
- 0.7%
- Creator share of that fee
- 95%
Unconfirmed
- ▸Whether fees can be split BETWEEN a creator and a third party by basis points — as opposed to routed wholesale to one designated recipient — was not confirmed from the fee-splitting documentation on 2026-09-11. Sato Route therefore recommends Bankr without emitting a config or claiming a slice.
- Chains
- Base, Robinhood Chain
- Goals
- agent_token
- Pool fee
- 1%
- Creator share of that fee
- 70%
Unconfirmed
- ▸No documented third-party recipient field: the split is creator/treasury, so Sato Route can recommend Virtuals but cannot route a slice through it.
- ▸The Robinhood Chain deployment is evidenced by the contract-addresses page plus a code read; whether the 1% / 70-30 launch mechanics documented for Base apply unchanged on Robinhood Chain is NOT stated on the pages read on 2026-09-12.
- Chains
- Robinhood Chain
- Goals
- agent_token, meme, utility
- Pool fee
- 1%
- Creator share of that fee
- 70%
Unconfirmed
- ▸No multi-recipient or basis-point split is documented — the fee wallet is a single address, so no slice can be routed alongside a creator's.
- ▸Robinhood's own documentation does not mention Pons; the chain's docs name only Uniswap, Rialto and Morpho as ecosystem apps. Pons is documented by Pons.
- Chains
- Base
- Goals
- creator_coin
- Pool fee
- 1%
- Creator share of that fee
- not published per party
Unconfirmed
- ▸The referrer's share of the 1% fee is not published on the pages read on 2026-09-11, so no slice is claimed and no config is emitted.
What “unconfirmed” means. `unconfirmed` lists what we could NOT read from the venue's own documentation on the date given — a recipient cap that is not stated, a default fee that an individual deploy may change. It is not a suspicion and not a warning. It is the edge of what we read, printed so a caller knows where our reading stops and theirs has to begin. A venue with a long unconfirmed list is a venue we were careful about, not a venue we distrust.
The fee schedule
| Lane | Amount | How it is taken | When nothing is taken |
|---|---|---|---|
| Swap — stable to stable | 3 bps (0.03%) | A parameter on the aggregator's own quote, taken inside the swap transaction by the router, on the input leg, to 0xcEE53Eb001d4d1743EF9df333Dcf45bC38622bE9. Stated on every quote before anything is signed. | A failed, reverted or unsigned trade pays nothing. |
| Swap — any volatile leg | 15 bps (0.15%) | The same way. A token whose address we have not written down is treated as volatile — the schedule never guesses downward without evidence. | A failed, reverted or unsigned trade pays nothing. |
| Launch | 0 bps of the creator's LP fee share (ROUTE_LAUNCH_FEE_BPS, default 0, capped at 1000) | One entry in the venue's own programmable reward-recipient list, alongside the deployer's 10000 bps, written into the deploy config before anything is signed and claimed through the venue's fee locker like any other recipient. | At 0 bps no Sato recipient appears in the config at all, and the deployer holds the full 10000 bps. |
| x402, agent routing, Preflight | 0 | Nothing is charged and nothing is relayed. These lanes read records and sort them. | Always. |
The disclosure travels with every response, including when it reads 0. A fee a caller only discovers after signing is the thing our trust rules forbid.
Non-custodial, without an asterisk
- ▸Sato Hub never holds your funds, never nets them and never forwards them.
- ▸Sato Hub holds no keys and signs nothing. Every transaction a route returns is signed by the caller.
- ▸The swap fee is a parameter on the aggregator's own quote, charged by the router inside the transaction you sign — not a payment to us that we then pass on.
- ▸The launch fee is one recipient entry in the venue's own reward split, claimed through the venue's fee locker. It is in the config before you sign it.
- ▸Nothing in the x402 lane relays, forwards, funds or settles a payment. It reads rows we already banked and sorts them.
- ▸A fee that is not disclosed before signing is the thing the trust rule forbids, so the fee block travels with every response even when it reads 0.
What we do not know
A route is chosen on readings we hold. These are not among them, and none of them is quietly approximated.
- ▸Impermanent loss. Nothing in any lane models it, and no route accounts for it.
- ▸Whether a quote fills. A quote is a quote, not a fill — it is the venue's number at the moment it was asked, and it can move before you sign.
- ▸Slippage as realised. The chooser reads quoted output; what you actually receive is settled by the chain, not by us.
- ▸Gas, MEV and inclusion. Not read, not modelled, not priced into the ranking.
- ▸Depth. A pool existing is not a pool with liquidity in it; the swap lane reads quotes, and the token lane reads that a pool exists without reading reserves.
- ▸Whether an x402 endpoint delivers what its label says. Nobody paid it to find out.
- ▸Whether an agent finishes the work. No job-outcome data exists for us yet.
- ▸What a token does after it launches. A fee schedule is a fee schedule.
- ▸Anything after checked_at. Every reading is a reading at a moment.
Questions
How does Sato Route pick a venue?
By an ordered list of readings, applied one at a time until they separate two candidates. Exclusions first, then whether the candidate can actually be acted on, then the records Sato Hub holds about it, and price below both. Every answer returns chosen_by — each signal, the value read and the field it came from — plus every alternative and what it is behind on.
Why does price not rank first?
Because a venue that quotes a better number and then does not answer is worth less than one that answers. Price sits below liveness and the observed record, and every alternative comes back with its own numbers so a caller who disagrees can pick differently.
What does Sato Route charge?
On swaps: 3 bps for stable-to-stable and 15 bps where either leg is volatile, taken as a parameter on the aggregator's own quote inside the transaction the caller signs. On launches: a share of the creator's LP fee set by ROUTE_LAUNCH_FEE_BPS, written into the deploy config before signing. The x402, agent and Preflight lanes charge nothing. A failed, reverted or unsigned transaction pays nothing.
Does Sato Hub hold my funds or keys?
No. Sato Hub holds no keys, signs nothing, and never holds, nets or forwards funds. A route hands back a transaction and the caller signs it.
What does unconfirmed mean on a launch venue?
`unconfirmed` lists what we could NOT read from the venue's own documentation on the date given — a recipient cap that is not stated, a default fee that an individual deploy may change. It is not a suspicion and not a warning. It is the edge of what we read, printed so a caller knows where our reading stops and theirs has to begin. A venue with a long unconfirmed list is a venue we were careful about, not a venue we distrust.
What can a route not tell me?
Impermanent loss, whether a quote fills, realised slippage, gas and inclusion, pool depth, whether a paid endpoint delivers, whether an agent finishes the work, and what a token does after it launches. Each is listed on this page rather than left as a silent gap.
Related: Sato Route · House rules · Preflight methodology · x402 verified