Replay any Solana transaction, at the slot it ran.
svmscope rebuilds the state a transaction executed against, runs the real programs locally, and tells you where every byte came from. Then change one value and run it again.
Decode
The full cross-program call tree, balance flows and compute per program. Lookup tables resolved, accounts named from on-chain IDLs.
Replay at any slot
Accounts and program binaries rebuilt as they were at any slot in the last 30 days, re-executed in an embedded SVM, with a certificate naming every account it could not prove for that slot.
Ask what if
Rewrite a pool reserve, an oracle price, any account's bytes, then replay and diff to see what would have happened instead.
Time travel
Warp the clock a day, an epoch, a year, and watch vesting cliffs, cooldowns and auctions play out without waiting.
Instruction call tree
Instruction introspection
Program logs
Local replay
Scenario tests
svmscope replays the real programs against edited state, so you can assert what
should happen in each edge case — with no test harness to write. It starts you with a
suite auto-generated from this transaction; tweak the expectations, run them, and export the
suite to run in CI with svmscope test suite.json.
Advanced — edit account fields & add a custom scenario
Edit any field below, then Stage your changes and Add as test scenario to drop them into the suite above — or just Simulate once to preview.
See exactly what a transaction did, step by step
Paste any Solana transaction signature. You get a plain-English account of what happened, which step failed and why, and you can change a value and run it again.
What it did, step by step 0
Where the compute went
Program logs
Where did the compute go?
Paste any Solana transaction signature. Every BPF instruction it executed is attributed to programs, functions and syscalls and drawn as a flamegraph. Built your program yourself? Add its .debug file and every function gets its Rust name.
Where the compute went
Know before your users do
Your program calls programs you do not control. When one of them is upgraded, svmscope replays your recent mainnet transactions against the new binary and tells you what broke: which transactions now fail, which errors are new, where the compute moved. Register your program in the on-chain registry with the programs it depends on, and the report arrives at your alert URL.
Run a check now
Replay a program's recent transactions that call a dependency, once with the dependency's binary from before its latest deploy and once with the current one, and see what the deploy changed. No program of your own? Give the wallet that sends your transactions instead: every transaction it signed that calls the dependency is replayed. The earlier binary comes from the watcher when it holds one, else from the account history stream on mainnet; without either the report can only say the transactions still execute.
Lift a transaction
Composition in transaction construction, measured. Take a landed transaction whose router called venues from inside its program, rebuild it with those calls as top-level instructions the client would send itself, and run both on the same state. You get whether every token balance still moves the same, how much compute the on-chain router cost, whether the rebuilt transaction even fits in a packet, and which inner calls cannot be lifted because only the router's program-derived address could sign them.
Registry
Protocols registered on devnet and the programs they watch. Register yours with the dependency_registry program in the repo: the signer must hold your program's upgrade authority.
Watcher
Reports
Every redeploy the watcher caught, the check it ran, and whether the alert was delivered.
One transaction is never the whole story
Some transactions only make sense together. A bot buys in one and sells in the next. A liquidator moves a price, then seizes the position. Open the second one on its own and you are looking at it starting from a world that never existed, because the first one already moved the pool.
Paste the group. Every transaction is replayed in order on one machine, each starting from what the ones before it left behind, and every step is checked against what the chain actually recorded. Then change one step and watch the change travel into the rest.
The sequence
The cascade
An account that one step changed and a later step also uses. These are the wires a change travels along: edit the earlier step and any step on the far side of one of these lines can move.
Change one step
Pick a step and open any account it touches. Every field it has is listed with the value that step actually sees, once the steps before it have run. Type over the one you want different and apply. The step runs with your value and every step after it runs on whatever that produced, so you watch the change arrive downstream rather than having to imagine it. Edits stack, on one step or several.
Step through
One transaction of the sequence, instruction by instruction, with every step before it already run.