Historical State InfrastructureStandalone service

Replay Solana, at any moment in its past.

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.

Live Slot Scrubber
Online
Querying State At
446,800,002
live — mainnet
30 days agonow
pubkey: 3MNi…cueS
lamports: 8,421,094
owner: CPMMoo8L…sN
rewindSlot: 446,394,827
resolved: 22ms
The Gap

The chain only shows you now. Everything else is gone.

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.

Without Rewind
01Run your own archival validator (weeks to set up, months to harden)
02Build a custom indexer per program
03Reconstruct state from transaction history
04Hope your CPI write tracking is correct
05Maintain it through every protocol upgrade, forever
06Build your own simulation framework on top
Months. Sometimes never.
With Rewind
01curl -X POST https://rewind.solanavibestation.com
02—
03—
04—
05—
06—
Tens of milliseconds.
JSON-RPC Methods

Eight methods. Compose them however you want.

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.

01 / 08
Read Primitive
getHistoricalAccountInfo

Point-in-time account state.

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.

Used For
"What did this pool look like 47 minutes before the exploit?"
POSTgetHistoricalAccountInfo
read
{
  "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
02 / 08
Read Primitive
getMultipleHistoricalAccounts

Batched lookups, one shared position.

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.

Used For
"Show me Pool A and Pool B at the exact same moment."
POSTgetMultipleHistoricalAccounts
≤100 accounts
{
  "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
03 / 08
Read Primitive
getAccountChanges

Every write to an account, paginated.

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.

Used For
"Walk every change to this pool over the last week."
POSTgetAccountChanges
paginated
{
  "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
04 / 08
Read Primitive
getAccountDiff

Two-point structural comparison.

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.

Used For
"What exactly did this transaction change?"
POSTgetAccountDiff
two positions
{
  "method": "getAccountDiff",
  "params": [
    "<pubkey>",
    {
      "anchorA": { "signature": "<sig>", "position": "before" },
      "anchorB": { "signature": "<sig>", "position": "after" }
    }
  ]
}

// diff: lamportsDelta, ownerChanged, executableChanged, dataChanged, dataLenA, dataLenB
05 / 08
Read Primitive
getHistoricalFeatureSet

The runtime that was.

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).

Used For
"Which runtime rules applied when this transaction landed?"
POSTgetHistoricalFeatureSet
per slot
{
  "method": "getHistoricalFeatureSet",
  "params": [{ "slot": 446800000, "includeInactive": false }]
}

// Result
{
  "slot": 446800000,
  "activeCount": 221,
  "active": [{ "id": "16FM...shg", "activatedAt": 267840000, "name": "..." }],
  "observedThrough": 446843325
}
06 / 08
Execution · Flagship
simulateHistoricalTransaction

Simulate a transaction against the chain as it was.

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.

Used For
"Would my transaction have succeeded at this exact moment?"
POSTsimulateHistoricalTransaction
simulation service
{
  "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
07 / 08
Operational
getRewindCoverage

Honest data coverage reporting.

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.

Used For
"What data do you actually have?"
POSTgetRewindCoverage
cached · cheap
{
  "earliestSlot": 446259052,
  "latestSlot": 446843325,
  "slotRange": 584274,
  "missingSlotCount": 7,
  "skippedSlotCount": 467,
  "gapPercent": 0.0012,
  "gaps": [{ "fromSlot": 446366144, "toSlot": 446366150, "status": "partial" }],
  "truncated": false,
  "windowDays": 30
}
08 / 08
Operational
getHealth

Solana-compatible liveness probe.

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.

Used For
"Is Rewind up before I send the batch?"
POSTgetHealth
probe
{ "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" } }
Who It's For

Built for people with specific questions they can't answer otherwise.

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.

Protocol Teams
Incident response & parameter tuning
"What was the exact pool state when the exploit happened?"

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.

Quants & Researchers
Realism-anchored backtesting
"Would my transaction actually have executed at the prices my OHLCV backtest assumed?"

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.

Security & Audit Firms
Forensic reconstruction
"Would this attack have worked at any point in the protocol's history?"

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.

Trading Firms
Strategy validation against real conditions
"How much was I missing because of execution gaps?"

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.

How It's Built

Its own service. Not a bolt-on to your RPC endpoint.

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.

Layer 0
Account state archive
Continuous, deduplicated capture of every account write on Solana mainnet, ordered within each slot by writeVersion. Only finalized slots are stored. Vote-owned accounts are deliberately not archived; everything else is. The archive floor is exact, resolved from when data was actually ingested rather than estimated from slot times.
Live
Layer 1
Read service
getHistoricalAccountInfo, getMultipleHistoricalAccounts, getAccountChanges, getAccountDiff, getHistoricalFeatureSet, getRewindCoverage. Wire-compatible supersets of Solana RPC where an analogue exists; coverage and gap reporting that refuses to serve stale data silently.
Live
Layer 2
Simulation service
simulateHistoricalTransaction on LiteSVM, loading every account through the same at-or-before lookup the read service uses, with the archived feature set and sysvars for the slot. Transactions whose accounts are all inside the archive reproduce mainnet's outcome, logs, and compute units exactly; the internal shadow validator holds simulations to a 99.99% match rate. Warm-cache latency is tens of milliseconds for a small transaction.
Live
Layer 3
Client SDKs
Typed clients for every method with the same error codes: svs-rewind on crates.io and @solanavibestation/rewind on npm. Both add a change walker that pages history and surfaces gaps, a before/after transaction view, an offline coverage guard, chunked batch reads, data decoding, and an opt-in retry policy.
Live
Next
Enterprise plan
Full-archive access with the highest rate limits, for teams whose questions reach further back than 30 days. Contact the SVS team for early access.
Coming soon
Plans & Rate Limits

Metered per API key. Your plan sets your window.

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.

PlanHistory windowReadsSimulations
Startertrials1 day5 req/s, burst 51 req/s, burst 1
Proproduction30 days50 req/s, burst 5010 req/s, burst 10
Enterprisecoming soonFull archive250 req/s, burst 25050 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.

What's Included

Every method, on every plan.

  • All eight methods. Read primitives, feature sets, coverage, and historical simulation — no feature gating between plans, only window and rate.
  • Your own endpoint. https://rewind.solanavibestation.com, same SVS authentication scheme as every other service.
  • Typed SDKs. Rust and TypeScript clients with walkers, guards, and retry policies built in.
  • Full documentation. Every method, every parameter, every error code, plus a quickstart that gets you to a first read in minutes.
  • Direct support. Talk to the engineering team, not a tier-1 helpdesk.
Getting Access

Pick a plan, get a key, make a call.

  • Trying it out? Starter gives you one day of history and every method, enough to answer a real question end to end.
  • Running it in production? Pro unlocks the 30-day window and production rate limits.
  • Need the full archive? Enterprise is coming soon — contact the SVS team for early access or higher limits.
  • Start with the quickstart. Check your coverage, read an account, replay a transaction — three calls, with cURL, TypeScript, and Rust examples.