[micahalp]

What this changes

Adds Route, the swap router for Robinhood Chain, as a provider on two existing benches, and adds Robinhood Chain to the EVM quote-latency basket.

evm-quote-latency (bench 033, harnesses/evm-swap-quoting)

• New basket pair: 0.1 ETH → USDG on Robinhood Chain (chainId 4663, USDG 0x5fc5360D0400a0Fd4f2af552ADD042D716F1d168). The basket goes from 5 to 6 pairs, so each (provider, chain) is sampled every 6 minutes (240 samples / 24h instead of 288). Spec text, methodology and harness comments updated to match.
• ChainSlugFor(4663) = "robinhood". KyberSwap and LI.FI now also probe Robinhood (both quote it today: aggregator-api.kyberswap.com/robinhood/... and li.quest with fromChain=toChain=4663), so the Robinhood tab has three providers.
• New route.go adapter: GET https://partners.route.fun/quote?in=&out=&amount= with Authorization: Bearer $ROUTE_API_KEY. Native ETH is the zero address. No-route is HTTP 200 with ok: false, recorded on the no-route counter. Robinhood only.
• robinhood chain dimension, per-chain explainer, route provider entry.

token-quote-coverage (bench 102, harnesses/token-quote-coverage)

• New route.go adapter: 1 USDG → token on Robinhood, same counters as the other providers. The Robinhood explainer now lists five aggregators.

Both adapters are optional: without ROUTE_API_KEY the Route provider is not registered, so nothing changes for existing deployments until the key is set. We'll send a dedicated quote-only key to contact@openchainbench.com.

Local runs (us-east, home connection)

• evm-swap-quoting, Robinhood ETH→USDG, first probe in a fresh process (5 runs): Route 99-141 ms, KyberSwap 284-478 ms, LI.FI 448-1,446 ms. Warm connection: Route 19-26 ms, KyberSwap 263-762 ms, LI.FI 331-1,013 ms. Other chains unchanged.
• token-quote-coverage, one discovery round (18 Robinhood tokens, Virtuals): Route 18/18, KyberSwap 18/18, Relay 9/18, ParaSwap 6/18. Mobula not measured (no key locally).

Type

• New benchmark spec (benchmarks/<slug>.yml)
• New harness (harnesses/<slug>/)
• Site / component changes
• Docs / tutorial
• Other: new provider + new chain on existing specs and harnesses

Checklist

• pnpm validate passes (253 specs valid, rebased on dev)
• pnpm typecheck passes (not run locally; no TypeScript changed)
• pnpm build passes (not run locally)
• go vet ./... and go build pass for both harnesses (Go 1.23)
• Harness READMEs and .env.example document ROUTE_API_KEY
• No API keys, secrets or private endpoints committed

Disclosure: opened by the Route team.

🤖 Generated with Claude Code

[Flotapponnier]

Thanks for this, and for the disclosure at the bottom — that is the right way to open a PR about your own product.

Two things from our side.

The key has not reached us. Nothing has arrived at contact@openchainbench.com. Easiest is to ping Florent directly on Telegram, @flouflof, and we will sort the handover there rather than over a mailbox nobody watches closely enough.

Please retarget this at dev, not main. Every change lands on dev first, gets reviewed on staging, and reaches main as a release. Your branch is also based on main, which is currently eight specs behind dev, so rebasing will save you a conflict later. (Your pnpm validate reporting 245 specs is the tell — dev is at 253.)

On the substance, two notes so you know what to expect rather than hearing it after review:

• The figures in the description are measurements from your machine and your connection. We will not publish those. Once the key is set we run the adapter from our three probe regions for at least 24h and publish our own numbers, whatever they say.
• Going from 5 to 6 basket pairs changes the sampling density for every provider already on bench 033 (288 → 240 samples per 24h). You documented that honestly in all four places, which we appreciate, but it is a methodology change to a published board, so we will decide it separately from the provider addition.

The code itself reads well: the adapters are isolated, no-route is recorded on its own counter instead of being dressed up as an error, and the optional registration means nothing moves for existing deployments until the key exists. That last choice is what lets us review and merge on our own schedule, so thank you for it.

[Flotapponnier]

Key received, thanks — and verified before anything else:

• GET /quote with the bearer returns 200 and a real route (0.1 ETH → USDG on Robinhood Chain, one hop, block 91,218,021), 415 ms from Paris.
• The same call without the header returns 401, so the endpoint genuinely requires it rather than ignoring it.

It is stored outside the repository, with the rest of our probe credentials. It will not appear in a commit, a spec, a page or a report.

Still needed from your side: retarget the PR at dev. We cannot review it where it sits, and your branch is based on main, which is behind.

What happens after that, so the sequence is not a surprise:

1. We review and merge to dev.
2. The key goes into the three evm-quote-latency probes (us-east, eu-west, Singapore) and the token-quote-coverage container. 600 rpm is far more than we need: bench 033 samples each (provider, chain) once every six minutes.
3. We let it run at least 24h and read our own numbers from our own regions.
4. Route appears on the pages with whatever those numbers say.

The figures in your description will not be published. Nothing personal in that — we do not publish a vendor's own measurement of themselves, including when it flatters them, because the moment we do every other row on the board becomes worth less.

One thing worth saying plainly, since you asked what to adjust: moving the basket from five pairs to six drops every existing (provider, chain) from 288 to 240 samples per 24h. You documented it honestly in all four places, and we appreciate that, but it changes the sampling density for providers who are already on a published board. We will decide that separately, and it may land after your rows do.

[micahalp]

Retargeted at dev and rebased on the latest dev (pnpm validate: 253 specs valid; both harnesses build).

Thanks for verifying the key. Fine with you publishing only your own numbers.

Happy to split the basket change (5 → 6 pairs) into its own PR if that makes the separate decision easier. The Route provider would then sit idle on bench 033 until a Robinhood pair lands, but bench 102 would be unaffected.