Backtesting vs Paper Trading vs Simulation

Answer first: Backtesting asks how an idea behaves on historical data. Paper trading observes current signals without sending a live transaction. Simulation evaluates a particular transaction or route against a known state. Each layer can reject a different class of mistake, but none can prove future profitability, inclusion, or execution success.

The three questions

A workflow may need all three, but they should not be collapsed into one score.

Backtesting: test the idea and the dataset

A useful backtest states where the data came from, which blocks or time windows were included, which costs were modeled, and how failed attempts were represented. It should keep a separate evaluation set so the strategy is not judged only on conditions used to tune it.

For on-chain execution, aggregate price candles are often insufficient. The strategy may depend on pool state, transaction ordering, fee rules, contract versions, and the actions of other participants. If the dataset cannot represent the decision the workflow would have faced, a clean result is not strong evidence.

Backtesting is best used to reject fragile ideas and expose assumptions. It is not a certificate for live capital.

Paper trading: test current behavior without signing

Paper trading follows the live observation path while suppressing the final transaction. It can reveal stale data, noisy signals, missing reason codes, unstable provider connections, or parameters that produce unexpected decisions.

The logs should explain:

• Why an opportunity was accepted or skipped.
• Which state and provider were used.
• Which limits were applied.
• Which transaction would have been built.
• Whether the result changed after a refresh.

Paper trading is valuable for operational readiness, but it can miss live wallet permissions, provider auctions, final ordering, and on-chain state changes.

Simulation: test a concrete execution

Simulation applies a proposed call or transaction to a selected state. For EVM development, Anvil can run a local node and fork an EVM-compatible chain at a chosen block, which makes a test reproducible when the block and inputs are recorded.

A simulation review should include:

• The block or state reference.
• The exact calldata and sender assumptions.
• Token balances and approvals.
• Fee, slippage, spending, and contract limits.
• Revert reasons and expected events.
• The difference between the simulated route and the intended submission path.

A successful result means the tested call passed under those assumptions. It does not mean the same state will exist when the live transaction is processed.

A controlled progression

1. Define the hypothesis and rejection criteria.
2. Backtest with documented data and costs.
3. Paper trade with current signals and complete reason logs.
4. Simulate the actual transaction shape and permissions.
5. Review remaining risks, wallet prompts, provider behavior, and limits.
6. If the operator accepts the risks, use a deliberately capped live test.
7. Compare the final receipt and state with the prior logs before increasing exposure.

No fixed number of days, signals, or transactions can prove readiness for every strategy. The threshold should come from the workflow's risk, failure modes, and the operator's ability to explain the evidence.

FRB's role

FRB Agent exposes a simulation-first workflow for local execution decisions. It does not replace independent backtesting, provider documentation, wallet review, or final receipt verification. Operators should use the Simulation Mode documentation together with the Risk Disclosure.

Methodology and limitations

This comparison describes testing layers, not expected returns or measured product performance. Foundry documentation is the primary source for Anvil's forking behavior. Product behavior is limited to the current FRB documentation.

Next step: Use the Simulation Mode checklist to document one route before considering live execution.