v0.2.0 — M2, recommendation

POST /v1/recommend advises a channel group and a bid for a transaction
described before it exists: program, compute units, cheap or fast, and a
target window in slots. Advice is priced from the last hour of real landings,
carries the age of its data, is marked stale rather than silently served old,
and says when a cheaper group exists that FairLane can only observe, not send
through. Access keys are self-service, with no account and no personal data.
The same advice is available from the @fairlanerouter/sdk package.

Measured on the deployed product:

• SC-004, answer to a recommendation request (p95) — 186 ms against a budget
  of 300 ms (2026-09-28). 100 keyed requests, four intents in turn, all 200;
  p50 125 ms, of which about 115 ms is the network to the host itself.
• SC-012, issuing an access key with no personal data — 1.54 s against a
  budget of 10 s (2026-09-24), worst of six runs; empty request body.
• FR-021, per-key limit of 120 per minute — 132 let through in 6.1 s out of
  140 sent in bursts: 120 of capacity plus 12 of refill, the rest 429 with
  Retry-After (2026-09-25).
• FR-047, keyless limit of 10 per minute — exactly 10 after draining and
  waiting a minute; a forged X-Forwarded-For gives no fresh quota (2026-09-25).
• FR-048, revoking a key keeps its counters — usage row 3 before, 3 after,
  3 after a repeated revoke (2026-09-25).

Not proven here, and this has to be said out loud:

• Advice that nobody followed saves nothing. SC-005 (savings through the
  recommended channel) and SC-006 (landing within the window in fast mode)
  need FairLane's own sends and stay unmeasured until M3.
• For the same reason landProbability is null in every answer: passive
  collection sees what landed, not when it was sent.
• "cheap" and "fast" are bid levels inside a group — the median and the 90th
  percentile of recent landers — not measured landing speeds.

Dashboard: https://fairlanerouter.github.io/FairLane-Router/
API: https://fairlane-api.onrender.com
SDK: packages/sdk/README.md

v0.1.0 — M1, the transparency core

The indexer, the database, GET /v1/summary with its SSE stream, the live
board and the methodology page, all running on real mainnet data.

Measured on the deployed product (2026-09-22):

• SC-001, a landing visible in the public summary after confirmation (p95) —
  17.8 s against a budget of 60 s. 58 data points over 26 minutes, 1397
  polls, 0 failures; p50 14.1 s, worst case 18.6 s, none over budget.
• SC-002, first screen on a 3G connection — 1.76 s against a budget of 2 s.
  Chrome "Fast 3G" profile, 3 runs on github.io (1.73 / 1.76 / 1.81).
  Before the optimisation it was 2.54 s.

Not measured here, and this has to be said out loud:

• SC-003 is checked by hand on 100 landings. A control set with an
  independently known channel is only possible from M3 on, once the system
  sends transactions itself.
• SC-007 and SC-008 need accumulated history and 30 days of collection.
• SC-005 and SC-006 cannot be measured by construction: the dashboard shows
  what the channels charge, not what could be saved by choosing between
  them. There are no recommendations, no sends of our own and therefore no
  proof of savings in this release — that is M2 and M3.

Dashboard: https://fairlanerouter.github.io/FairLane-Router/
API: https://fairlane-api.onrender.com