How to Paper-Trade a Solana Bot Before Going Live With Real Capital

Every Solana bot that has ever blown up an account shared one trait: it went live before it was ready. A dry-run phase is not optional polish — it is the engineering gate that separates a real trading system from an expensive experiment. The mechanics are straightforward once you understand what you are actually testing and where the traps hide.

What "Paper Trading" Actually Means on Solana

Paper trading on an EVM chain is relatively easy — you fork mainnet with Hardhat or Anvil, replay state, and your contract calls land on cloned storage. Solana's account model makes this more nuanced. State is not stored in contracts; it lives in accounts that programs read and write. A true paper-trading environment must either (a) replicate the relevant account state in real time, or (b) intercept transaction submission and simulate fills without broadcasting.

Two approaches are worth knowing:

• Devnet with mirrored price feeds. Spin up your bot against https://api.devnet.solana.com, but pipe in mainnet prices from a Pyth or Switchboard subscription. Your orders land on devnet AMMs or a dummy settlement program you deploy there. Latency and slot timing are realistic; liquidity depth is not.
• Shadow ledger / intercept mode. The bot constructs and signs transactions normally, but a thin middleware layer intercepts sendTransaction RPC calls, runs the Solana BPF simulator (solana-program-test or the litesvm crate), books a synthetic fill at the simulated price, and returns a fake signature. Mainnet slot timing is preserved and real order-book data flows through — only the broadcast is suppressed.

For most strategies the shadow ledger approach is superior because it exercises the full execution path, including slippage estimation, priority fee logic, and compute-unit accounting.

Wiring a Shadow Ledger in Practice

The implementation is smaller than it sounds. Your RPC client already wraps sendTransaction in one place. Replace that call with a function that:

1. Calls simulateTransaction against your mainnet RPC (or a Triton/Helius dedicated node for consistent simulation results).
2. Reads unitsConsumed and the post-simulation account deltas from the response.
3. Derives a fill price from the delta on the token accounts involved.
4. Writes the synthetic trade to a local ledger — a simple SQLite table with columns for timestamp, side, size, fill price, fees, and compute units consumed.
5. Returns a dummy signature so the rest of the bot's state machine continues normally.

One critical detail: simulateTransaction on a loaded mainnet node can return stale slot context. Pass commitment: "confirmed" and set replaceRecentBlockhash: true so the simulation does not fail on blockhash expiry while still reflecting current state. If you are trading Jupiter-routed swaps, extract the outputAmount from the instruction data in the simulation response rather than trusting post-account deltas, which can be ambiguous across multi-hop routes.

What the Numbers Should Tell You

After 48-72 hours of shadow operation, you have a sample you can interrogate. The metrics that matter before any capital goes live:

• Realised vs. expected slippage. If your model assumed 12 bps on a 5 SOL swap and the simulator is returning 28 bps consistently, your edge calculation is wrong.
• Compute unit variance. A strategy that occasionally burns 98% of the 1.4M unit limit is a strategy that will occasionally fail on mainnet under load. Budget with headroom.
• Priority fee calibration. Run the dry-run during peak congestion windows (typically 13:00-16:00 UTC on active market days) and record what fee level would have been required to land within your target slot. Underpricing here is the single most common cause of missed fills.
• Win rate and PnL distribution. A strategy with a 55% win rate but a fat left tail — a few large losers — may have a Sharpe below 1.0 even if average PnL is positive. See it in simulation before you see it with capital.

The bots we design and operate at TierZero go through a minimum 72-hour shadow phase before any mainnet capital is deployed, and we extend that window if variance in the synthetic PnL has not stabilised.

Devnet Limitations You Cannot Simulate Around

Be explicit with yourself about what devnet and shadow ledgers cannot test. They cannot replicate the behaviour of other market participants reacting to your orders. On-chain MEV — sandwich bots that detect your transaction in the mempool and front-run it — does not appear in simulation. Validator jitter and network partition behaviour under genuine congestion differs from devnet. These gaps are real, and they mean a clean dry-run is necessary but not sufficient.

The practical answer is position sizing on first mainnet deployment: run with 10-15% of intended capital for the first week and treat that period as a live canary, not full production. Compare mainnet fills against your shadow ledger fills from the same timestamp window. If slippage diverges by more than 1.5x your simulation baseline, halt and investigate before scaling.

Logging Infrastructure That Pays Off Later

Build your shadow ledger schema to match what you will log in production. Every synthetic trade row should carry the same fields your live trade rows will carry. When you eventually run both environments in parallel — shadow alongside live, comparing fills in real time — identical schemas mean you can diff them with a single SQL join rather than a bespoke reconciliation script.

Log compute units, priority fees, RPC node used, and slot delay on every simulated transaction. These columns feel verbose until the day you are debugging why mainnet fills diverged from simulation, and you discover the issue in thirty seconds by filtering on RPC node identifier.

---

If you are building a Solana strategy and want an experienced team to handle the dry-run infrastructure, simulation tooling, and production deployment, get in touch with TierZero — we scope engagements from standalone strategy audits through to fully managed bot operations.