RPC Benchmark Dashboard

Continuous, regional, non-gameable benchmarking of Solana RPC providers.

What this is

A benchmark that fires randomized, commit-revealed challenges at public Solana RPC providers from several clouds and regions. It decides correctness by majority vote across the benchmarked panel, guards against gaming with honeypot spot-checks, and publishes a filterable leaderboard scoring latency, win rate, reliability, correctness, and freshness.

It covers ~45 read methods — block and transaction lookups, account and token reads, and chain-metadata calls. The full list is EMITTED_METHODS in packages/shared/src/types.ts. Every challenge, sample, and score is open data you can recompute from this repo against your own infrastructure.

Architecture

Generator (HA) → Postgres ← Workers (per region × egress) → Dashboard (Next.js)
       │                              │
       └── Utility RPC (derivation)   └── Consensus across the benchmarked panel
                                            (majority vote, per vantage × mode)

The generator draws challenge params from live chain state (via a utility RPC endpoint), commits to them under a hidden seed, and dispatches one assignment per active vantage. Workers fire each challenge in parallel at every provider and decide correctness locally by majority vote across the panel. Honeypots — challenges replaying a known-good answer — are mixed in to catch a provider serving wrong data. The seed is revealed after the challenge TTL, so anyone can confirm the params were fixed before any provider responded.

Run the benchmark yourself

There are two ways to run this, depending on how much you want to reproduce. Both share the same methodology packages (@rpcbench/methods, @rpcbench/runner, @rpcbench/shared) — challenge derivation, fanout, consensus, and scoring — so the numbers are computed the same way. The difference is scope.

	Standalone CLI (lite)	Full reproduction
Command	pnpm --filter cli start -- … (one process)	generator + workers + dashboard
Database	none	Postgres required
Secret / honeypots / commit-reveal	none	required
Vantage	your machine (single)	your own multi-region fleet
Correctness	consensus across your endpoints, or vs a --reference node	full consensus panel + honeypots + auditor
What you get	live per-provider table (latency, reliability, correctness)	the whole dashboard: leaderboard, eligibility, historical rollups, /status, /raw
Best for	"how do these endpoints look from here, right now?"	reproducing the published leaderboard end-to-end

Feel free to start with the CLI to test out the benchmarks. Then set up the full system when you want to fully verify.

Option A — standalone CLI (no database)

The fastest way to try it: bring your own endpoints, and it generates challenges, benchmarks them from your machine, and prints a live table as samples land. No Postgres, no secret, no honeypots — nothing to provision.

git clone https://github.com/helius-labs/rpc-perf-dash.git
cd rpc-perf-dash
pnpm install

pnpm --filter cli start -- \
  --provider helius=https://mainnet.helius-rpc.com/?api-key=XXX \
  --provider triton=https://your-triton-url \
  --provider alchemy=https://solana-mainnet.g.alchemy.com/v2/XXX \
  --provider quicknode=https://your-quicknode-url \
  --provider chainstack=https://solana-mainnet.core.chainstack.com/YOUR_KEY \
  --challenges 50

• Correctness needs voters. With ≥3 endpoints it's decided by consensus among them (use ≥5 for robust dissent detection). With 1–2 endpoints, pass --reference <url> to score each against a node you trust; otherwise you get latency/reliability only (correctness: n/a).
• Single vantage. Latency is measured from your machine/network, not the multi-region cloud fleet — so run it where your code runs (your EC2 instance, Lambda, container, etc.) to measure the latency your app actually sees.
• Full flag list, correctness regimes, and caveats: apps/cli/README.md.

Option B — full reproduction (database + continuous fleet)

Sets up the whole system: the generator, per-region workers, honeypot anti-gaming, commit-reveal, and the Next.js dashboard. You supply a Postgres instance and your own provider API keys; the repo does the rest.

1. Prerequisites

• Node 22+, pnpm 9+ (corepack enable works).
• A Postgres database. The Neon free tier is enough to start, though samples will outgrow its storage cap; any Postgres ≥ 14 works.
• API keys for the providers you want to benchmark (see the env list below).

2. Install and configure

git clone https://github.com/helius-labs/rpc-perf-dash.git
cd rpc-perf-dash
pnpm install
cp .env.example .env.local

Fill in .env.local:

• NEON_DATABASE_URL_POOLED / NEON_DATABASE_URL_DIRECT — your Postgres connection strings. The NEON_ prefix is just a naming convention; any Postgres works.
• HELIUS_URL, TRITON_URL, ALCHEMY_URL, QUICKNODE_URL, CHAINSTACK_URL, etc. — your provider endpoints. Any provider whose env is unset is skipped, so you can benchmark a subset. Correctness scoring needs at least 3 configured providers to form a consensus panel (see the minimal-eval note below).
• UTILITY_RPC_URL — the generator's chain-observation endpoint: it derives challenge inputs from live chain state, polls the tip slot, and seeds honeypots. It never votes on correctness, so it needs no independence from the panel (reusing a panel key here is fine). A paid, full-archive endpoint works best. Not on the leaderboard; workers never see it.
• GENERATOR_SECRET — HMAC secret for commit-reveal. Generate with openssl rand -hex 32.

3. Bootstrap (one command)

With .env.local filled in, run:

pnpm bootstrap

여기까지가 README 앞부분입니다. 나머지는 원문에서 읽을 수 있습니다. README 전문 보기 ↗