Infrastructure · 6 min read
Fork simulation vs fixture demos
Tarmac has two execution modes with the same tools, policy engine, trace format and verdicts. They differ only in where quotes and swaps come from.
| Fixture demo | Fork simulation | |
|---|---|---|
| Quotes | Deterministic constant-product model | Uniswap v3 QuoterV2 on the fork |
| State | In-memory market per run | Fresh Anvil fork per run, pinned to a block |
| Needs | Nothing | Anvil + a read-only Robinhood Chain RPC |
| Swap reference | Fixture receipt id, no link | Simulated tx hash on the fork, no explorer link |
| Best for | Demos, CI, reproducible agent tests | Realistic liquidity and contract behaviour |
Pinned blocks
A fork copies chain state lazily from an upstream RPC at a specific block. Pinning the block makes a run reproducible: the same block, the same pools, the same quote. Robinhood Chain's public RPC is rate-limited and keeps only recent history, so pinning an older block needs an archive endpoint from a provider.
Isolation between runs
Every fork run starts its own Anvil process on a loopback port and stops it when the run ends. Nothing a previous run did — balances, approvals, pool state — leaks into the next one. Liquidity scenarios are set up on the fork only and recorded on the run, so you can see exactly how “thin liquidity” was produced.
Failure is a result
If a fork can't start, the run ends as “Simulation failed” with the reason. It is never silently replaced with fixture data, because a fake pass is worse than an honest failure.