Skip to content

Leaderboard & methodology

After this page you can read the public leaderboard critically: what the score means, what the intervals admit, and why a program’s rank can move without its code changing.

Each program gets a Landing Score: the bot-adjusted real-user landing rate over the window. Of the transactions real users attempted, the fraction that landed. It is not:

  • a raw success rate (that would mostly measure bot spam tolerance),
  • an uptime metric,
  • a code-quality judgment — a program whose users are mostly arbitrage bots can rank lower on raw stats and higher here, correctly.

The full recipe, including the bot heuristic and interval math, is versioned as Landing Score v1.

Public on-chain data only. The leaderboard needs no cooperation from the ranked program: no SDK, no account. (Programs with the SDK installed get private drop diagnostics too, but SDK data does not affect the public score — that would let participants influence their own denominator.)

Observation is sampled within a fixed RPC budget. Every published number carries the consequences honestly: observed counts, the sample rate, and Wilson 95% intervals that widen when evidence is thin. Two programs whose intervals overlap are not meaningfully ordered — the rank column is a convenience, the interval is the claim.

Each program page shows:

  • Landing Score trend — daily score with the 95% band. Look for level shifts at deploy slots rather than day-to-day wiggle.
  • Bot share — fraction of observed transactions attributed to bots. High bot share means the raw failure rate you see in explorers wildly overstates real-user pain.
  • Top decoded errors — the program’s failures by IDL-decoded name, real-user weighted.
  • CU headroom — p95 compute used vs requested per instruction.

Program owners can request removal from the public leaderboard, or claim a program to add a verified name. Both are currently manual — contact us. Self-hosted instances never publish anything.