simulateTransactionsAtSlot

Simulates one or more transactions against the archived account state at a historical slot, using the real Solana runtime. It is a separate method from simulateTransaction and from Jito's simulateBundle, combining simulateTransaction's "what would this do" question with simulateBundle's multi-transaction sequencing, and extending both to any slot in the Account Archive's coverage.

Up to 5 transactions execute in order over a single shared, mutable overlay: each successful transaction's writable-account changes are written back before the next entry runs, even across a slot change. The first failure aborts the rest of the sequence, which are marked skipped. stateOverrides lets you patch specific accounts (or the Clock sysvar) before each entry runs; everything you do not override keeps its archived value.

Response invariants:

• simulationResults is always an array, in request order, even for a single-entry request.

• status is authoritative; filter on it rather than on err, because skipped entries also carry err: null.

• A failed entry still ran, so it reports feeLamports and an empty (not null) changedWritableAccounts.

• A failed transaction returns a successful JSON-RPC response with the entry's err populated. Bad input (unknown fields, more than 5 simulations, decreasing slots, a vote-program transaction, an unparseable transaction) is a -32602 JSON-RPC error, detected before anything executes.

• Each entry's postExecutionAccounts is filtered to only the accounts the simulation actually touched (its stateOverrides plus the transaction's writes); accounts named in postExecutionAccountsConfigs that the simulation did not touch are omitted from that entry (expect [] on a success whose transaction touched none of them).

Caps enforced before execution (each triggers -32602 if exceeded): at most 5 simulations per request; 100 accounts per accounts config; 100 stateOverrides entries per simulation (10 MiB per data override); 128 unique transaction-referenced accounts per entry (static keys plus lookup-table entries); 25 MiB combined byte budget across the rendered result.

Notes on behavior worth knowing before you build:

• Durable-nonce transactions (an AdvanceNonceAccount instruction at index 0) validate against the archived nonce account's real state at that slot, not against a blockhash.

• Vote-program transactions are rejected outright with -32602 because vote accounts are not in the archive.

• sigVerify: true requires replaceRecentBlockhash: false, since replacing the blockhash would invalidate signatures; sending both as true is refused with -32602.

• The simulator pins a single Agave/SVM release, so very old slots fall outside what the current build can reproduce faithfully. The usable window is recent history and grows over time as the backfill pipeline extends further back.