Your RPC says 200. Does your app agree?
SlotCheck replays the transactions, accounts and history your app actually reads against your own Solana endpoint — then runs the answers through your decoder. Raw response and app path get separate verdicts, so you know which one broke
One request, five separate answers
Every check is split along the path a response takes into your app. The summary never folds them into one “healthy”
The wire worked. The method didn't
Data is there. Your app path breaks
Absent at observation — not a wrong balance
Genesis mismatch stops every dependent probe
The RPC was fine. The upgrade wasn't
Run run_6dc49f72 replays 10 mainnet transactions after an adapter bump to 2.4.0. Raw bytes match golden on every one — and 2 reverted routes decode with the error pinned on the wrong instruction
- Raw sha256 identical to the approved record
- Target moved 4.4.0 → 4.4.1 between runs — logged, not blamed
- Same pack, same config: the diff isolates the adapter
Reverted Jupiter route, 33 loaded accounts
2t9oTQrsP7aPg6…EAjUmJvWoksLnj ↗Raw response matches golden byte-for-byte (sha256 d29f1ad47f…). The adapter attributed meta.err InstructionError[1] to inner instruction #1 instead of top-level instruction #1. The RPC is fine; the app path is not
Six read methods. Nothing else
The allowlist is the product. Parameters are validated before a call, finalized is the default, and results from different commitments are never compared as equal
Identity & capabilities
getGenesisHash · getVersionThe network you meant, and the version it reports. A version string is evidence — never proof of a feature
Checkpoint & freshness
getSlot · finalizedTarget and reference read inside a ≤2 s bracket, three times. Otherwise freshness is incomparable, not a fake lag number
Historical transactions
getTransactionYour signatures with an explicit version and encoding. Full response, error or null — each against the golden fields
Message decoding
Saved raw → adapterVersion, static and loaded accounts in order, instruction indexes, CPI depth and meta result — through your trusted adapter
Account reads
getAccountInfoOwner, encoding, bytes and selected layout. Moving balances are never treated as an invariant
History pages
getSignaturesForAddressBounded before/until windows with a known ending checkpoint. Duplicates at page joins handled and shown
It can't touch production
The plan is hashed before any live request. A new scope means a new plan. When the budget runs out, remaining checks are not run — never pass
https://mainnet.example-rpc.com/v2/8f1c…e92a?region=fraprod-primary · https://mainnet.•••••••.com/•••••Public benchmarks rank providers. SlotCheck checks yours
The CLI is free. The upkeep isn't
Teams pay for what goes stale: fixture packs reviewed against every SDK and Agave release, a CI gate, and run history the team can share
- CLI: validate · plan · probe · decode · recheck · compare · report
- Your own fixture packs
- One trusted adapter
- Offline recheck of saved artifacts
- Static HTML + JSON reports
- Maintained packs: Jupiter, Token-2022, ALT-heavy, archival, failed-tx meta
- Two reviewers per golden record
- CI gate on pull requests
- Opt-in shared run history
- Alerts when a pack fixture regresses
- Extra adapters for your SDK stack
- Several providers per profile
- Pack built from your production signatures
- Runbook and handover
Straight answers
Run it before the next upgrade
Pick five signatures your app can't live without. Ten minutes later you know whether the next SDK or provider version reads them the same way
npx slotcheck@0.9.3 initQuickstart