Paper testing an automation means running its exact rule set against live or recent market data without real orders, so a sizing bug, a bad trigger condition, or an API mistake surfaces on numbers you can afford to be wrong about instead of on real capital.

Key takeaways

• Paper testing checks whether the automation's rules do what you think they do — it is a logic test, not a profitability forecast.
• The most valuable bugs paper testing catches are sizing errors and duplicate or missing order triggers, not whether the strategy is profitable.
• A paper test only proves what it actually exercises — a strategy that never sees a fast-moving or illiquid period in testing has not been tested against that condition.
• Moving from paper to live should be gated by a stated pass condition, not by a calendar date or a feeling of readiness.
• Paper results without slippage, fees, or partial fills factored in will look better than live results — expect a gap, don't be surprised by it.
• DRKN can review the account context an automation would operate inside; it does not run or backtest the automation itself.

What a paper test actually proves

A paper test proves that a given rule set, fed a given stream of data, produces the orders you expected it to produce — nothing more. It does not prove the strategy is profitable, because paper fills are usually idealized: no slippage, no partial fills, and often no realistic latency between signal and execution. Treating a clean paper-test P&L curve as a promise about live results is the single most common way traders misuse this step.

What a paper test is genuinely good at is catching implementation bugs: a stop that computes off the wrong price field, a position-size formula that uses account balance instead of available margin, a webhook that fires twice for one signal. These are logic errors, and they show up the same way in paper mode as they would in live mode — except in paper mode they cost nothing to discover.

A worked example: a sizing bug caught in paper mode

A trader builds a rule that risks 2% of account equity per trade on a $5,000 paper account, targeting $100 of risk per position. Over 20 paper trades, the log shows position sizes ranging from $380 to $2,100 in notional — far more variance than a fixed 2% risk rule with a consistent stop distance should produce. Digging into the rule, the size formula was pulling from total account balance including funds already committed to other open positions, not available margin.

In paper mode, that bug just produces odd numbers in a log. In live mode, the same bug would have opened a position worth 40% of the account on a single signal, wiping out the risk budget the strategy was designed around before the trader noticed. The paper test did not predict profit or loss — it caught a formula error that would have been expensive to discover with a live fill.

What to check before calling a paper test 'passed'

• Every position size in the log matches the intended risk percentage within a small, explainable tolerance — not just on average, but on each individual trade.
• No duplicate orders were logged for a single signal, and no signal was silently dropped without a logged reason.
• The test ran across at least one fast-moving or gap-heavy period, not only calm, trending conditions.
• Stop and take-profit levels in the log match what the strategy document says they should be, trade by trade.
• A manual review of ten random trades from the log confirms the entry reason actually matches the rule that was supposed to trigger it.

Common mistakes when moving from paper to live

• Switching to live capital the moment paper P&L looks good, without checking whether the rule logic itself was ever actually exercised under stress.
• Running the paper test with idealized fills and then sizing live positions as if slippage and partial fills won't occur — see partial fill risk in automated crypto trading for how that gap shows up in practice.
• Testing on a small, cherry-picked date range instead of a period that includes at least one adverse move.
• Going live with full intended size on day one instead of a smaller size while the live-vs-paper gap is measured.
• Never checking what happens if the API connection drops mid-position — a scenario paper testing rarely simulates by default.

Before your automation goes live, review the account it will trade inside: DRKN can help you check leverage, concentration, and protection on your connected Toobit account so you know the baseline the automation is stepping into. It is educational risk guidance, not a backtesting or paper-trading engine, and it does not run trades for you.

Setting a real pass condition

A useful pass condition is written down before the test starts, not decided afterward based on how the results look. Something like: 'position sizing matches the risk rule on 100% of logged trades, no duplicate orders across 500 signals, and the strategy has been run through at least one 5%+ single-day move' is testable and specific. 'It looked good' is not a pass condition — it is a feeling, and feelings are exactly what a paper test exists to replace with evidence.

After the paper test passes

Passing a paper test is a green light for the logic, not for full size. Bringing an automation live still means deciding what emergency stop exists if something goes wrong after launch — see trading automation kill switch: when the emergency stop matters — and reviewing the account-level risk the automation adds on top of any existing manual positions.

What paper testing cannot catch

Paper testing catches logic and sizing bugs, but it cannot fully simulate execution reality: real slippage during thin liquidity, partial fills that leave a position smaller or larger than intended, or an exchange-side outage at the exact moment an order was supposed to fire. Treating a passed paper test as proof the strategy will execute exactly as logged in live conditions overstates what the test actually verified.

Frequently asked questions

How long should a paper test run before going live?

Long enough to include a range of conditions, not a fixed number of days — a rule tested only during a calm trend has not been tested against the volatility that usually causes the worst live losses.

Does DRKN run paper tests or backtests?

No. DRKN reviews live account risk from a connected, read-only Toobit account. Paper testing and backtesting a rule set happen in your automation or bot platform before that logic ever touches an account DRKN would review.

What if my paper results and live results don't match?

Some gap is expected from slippage, fees, and partial fills. A large, unexplained gap usually means the paper test's fill assumptions were unrealistic, or a rule behaves differently against a live data feed than it did against the test data — both are worth investigating before increasing size.