Rewind is a hosted service that gives you point-in-time account state and historical transaction simulation against the chain as it was — not as it is. Reproduce exploits exactly. Audit transactions against the state they actually saw. Validate strategies against real on-chain conditions, slippage, and competition. Built on a deduplicated archive of every account write on Solana mainnet and served from its own endpoint, with a 30-day rolling window on Pro and the full archive on Enterprise.
Solana's RPC tells you what accounts look like at this moment. To know what they looked like 30 days ago — or 30 minutes ago, with sub-slot precision — you've been on your own. Until now.
Rewind is infrastructure, not a workflow tool. POST JSON-RPC 2.0 to https://rewind.solanavibestation.com with your SVS API key in the Authorization header. The account reads are wire-compatible supersets of their Solana RPC counterparts, so standard SDKs deserialize the responses unchanged; the rest add sub-slot positioning, change history, and audit-trail metadata that live RPC can't offer.
The state of any account at any historical position: end of a slot, an exact (slot, writeVersion) inside a slot, or anchored immediately before or after a known transaction so you never need to know the slot. A strict superset of Solana's getAccountInfo response — existing tooling works unmodified and the extra rewindSlot field tells you exactly which archived version you were served.
{ "method": "getHistoricalAccountInfo", "params": [ "3MNi...cueS", { "slot": 446800000, "encoding": "base64" } ] } // Or anchor to a transaction for the exact state it read: { "anchor": { "signature": "<sig>", "position": "before" } } // Standard AccountInfo response plus rewindSlot / rewindWriteVersion
Up to 100 accounts in a single call, all pinned to exactly the same moment in chain history. Critical for any analysis that needs multiple accounts in coherent state — pool reserves, position vaults, multi-program compositions. The position is resolved once and applied to every account. Superset of Solana's getMultipleAccounts.
{ "method": "getMultipleHistoricalAccounts", "params": [ ["<pool_a>", "<pool_b>", "<vault>"], { "anchor": { "signature": "<swap-sig>", "position": "after" } } ] } // Up to 100 pubkeys; the position is resolved once and shared by every account
The full per-write history of any account in any slot range, newest-first, with the producing transaction signature attached. Walk a pool's reserves change by change, attribute every mutation to a specific transaction, dedup identical writes via stable content hashes, and filter on dataChanged to skip writes that only moved lamports. Archive gaps inside the range are surfaced inline instead of refusing the call.
{ "method": "getAccountChanges", "params": [ "<pubkey>", { "fromSlot": 446700000, "toSlot": 446800000, "limit": 100, "includeData": false } ] } // Each row: slot, writeVersion, lamports, owner, dataHash, txnSignature, dataChanged // value.next is the cursor for the next page; value.gaps lists archive holes in range
One account at two independently positioned points — full state on each side plus a structural summary: lamports delta, owner change, data-length change, byte mutation flag. Anchor side A before a signature and side B after it and you get exactly one transaction's effect on one account in a single round-trip.
{ "method": "getAccountDiff", "params": [ "<pubkey>", { "anchorA": { "signature": "<sig>", "position": "before" }, "anchorB": { "signature": "<sig>", "position": "after" } } ] } // diff: lamportsDelta, ownerChanged, executableChanged, dataChanged, dataLenA, dataLenB
The feature gates active at any slot — the same information you'd derive from the Feature111… accounts, tracked over time. Anyone replaying old transactions needs the feature set the cluster actually ran with at that slot, not today's. Optionally lists inactive gates with the reason (pending, closed, or activated later).
{ "method": "getHistoricalFeatureSet", "params": [{ "slot": 446800000, "includeInactive": false }] } // Result { "slot": 446800000, "activeCount": 221, "active": [{ "id": "16FM...shg", "activatedAt": 267840000, "name": "..." }], "observedThrough": 446843325 }
LiteSVM execution against the exact account state at any historical position, with sub-slot precision via signature anchoring and the feature set, sysvars, lookup tables, and program bytecode the network had at that moment. Mirrors Solana RPC's simulateTransaction response shape, plus extension fields revealing the resolved load position. Add accountOverrides for what-if analysis. Reproduce exploits exactly. Validate strategies against real slippage. Audit failed transactions against the state they actually saw.
{ "method": "simulateHistoricalTransaction", "params": [ "<base64 transaction>", { "anchor": { "signature": "<sig>", "position": "before" }, "innerInstructions": true, "accounts": { "addresses": ["<pubkey>"] }, "accountOverrides": {} } ] } // Returns: err, logs, unitsConsumed, accounts, innerInstructions, returnData // plus rewindSlot, rewindLoadSlot, rewindLoadWriteVersion, rewindOverriddenAccounts
The slot range your key can reach, every gap within it, how many slots were leader-skipped, and the number of days of history your plan is entitled to (windowDays). Reads that would land inside a real gap refuse rather than silently serving stale data. Served from an in-memory view, so it's cheap to call at any frequency. Built so you can trust what you're getting before you build on it.
{ "earliestSlot": 446259052, "latestSlot": 446843325, "slotRange": 584274, "missingSlotCount": 7, "skippedSlotCount": 467, "gapPercent": 0.0012, "gaps": [{ "fromSlot": 446366144, "toSlot": 446366150, "status": "partial" }], "truncated": false, "windowDays": 30 }
Returns "ok" when the service can serve reads, otherwise the standard Solana -32005 error with a reason. Existing client libraries and load-balancer health checks work unmodified.
{ "jsonrpc": "2.0", "id": 1, "method": "getHealth" } // Healthy { "jsonrpc": "2.0", "id": 1, "result": "ok" } // Otherwise the standard Solana error { "code": -32005, "message": "Node is unhealthy", "data": { "numSlotsBehind": 84, "reason": "starting" } }
Rewind is infrastructure for sophisticated users who already know what they want to investigate. It doesn't generate strategies or surface insights on its own — it makes hard questions about Solana history fast to answer when you bring the hypothesis.
Reconstruct any moment your protocol experienced. Reproduce attacks against historical state to verify the vulnerability and validate the fix. Test parameter changes (LTVs, fees, rebalance frequencies) against real chain conditions, not idealized models.
Price-based backtests assume idealized execution. Real strategies hit slippage, racing, and fee dynamics that conventional backtesters can't model. Rewind shows you what would have actually happened — same execution engine, same account state, same fee dynamics as mainnet.
What previously took weeks of running custom infrastructure now takes hours of API calls. Verify exploits against the exact state they targeted. Test attack vectors at thousands of historical moments. Produce signed forensic artifacts that hold up to external review.
You know your strategy makes money. Rewind tells you what the chain looked like at the moments you captured opportunities — and what it looked like at moments you missed. The denominator that lets you size infrastructure investment rationally.
Rewind runs on dedicated infrastructure behind one base URL. Account reads are answered by the read service and simulations by a separate simulation service that scales independently; the load balancer routes by method name, and both apply the same positioning, coverage, and error rules.
Rewind is sold as its own service — a key with Rewind enabled, independent of your RPC tier. Each plan sets both the rate limit and how many days of history your calls can reach. Two plans are available today; Enterprise is coming soon.
| Plan | History window | Reads | Simulations |
|---|---|---|---|
| Startertrials | 1 day | 5 req/s, burst 5 | 1 req/s, burst 1 |
| Proproduction | 30 days | 50 req/s, burst 50 | 10 req/s, burst 10 |
| Enterprisecoming soon | Full archive | 250 req/s, burst 250 | 50 req/s, burst 50 |
Your key's window is reflected in getRewindCoverage's windowDays and effective earliestSlot. Positions below your floor are refused with -32015, the same code as anything below the archive floor. Full limits in the docs.
https://rewind.solanavibestation.com, same SVS authentication scheme as every other service.