SHARKRULE / Learn

Paper trading vs live trading: what a simulated fill cannot prove

Paper trading records trades against virtual money using a model of execution. Live trading submits orders to an exchange, where acceptance, available liquidity and other orders determine what actually fills. A simulation can reveal whether a rule behaves as intended under its assumptions; it cannot establish that the same trades, costs or results will occur with real money.

SharkRule · Reviewed

First, name what your test actually tested

A forward paper test follows incoming market data after it starts. A backtest replays historical data. Both need assumptions about when orders arrive and how fills occur. An exchange test environment is another separate setting; its successful responses do not establish production liquidity or your live account’s permissions.

An order-validation check is narrower still. Binance’s Test new order endpoint validates a request without sending it to the matching engine. Passing that check is not a filled trade. Label each result as rule observation, modeled execution or exchange-confirmed execution before comparing it with another result.

Worked example: one rule, three possible fill records

Everything here is hypothetical: asset A, quote currency Q, quantities, prices, queue and fees. These are arithmetic inputs, not an asset choice, position-size recommendation or an account test. Begin with 200 Q and no A. When the chosen condition is observed, the rule requests one limit buy of 10 A at no more than 10 Q each. Any unfilled quantity is canceled at the review time; the balances below assume cancellation has been confirmed. Assume every fill is at exactly 10 Q and no additional fills occur before cancellation confirmation.

For a simple common accounting convention, each scenario charges 0.1% of filled purchase value in Q. This is not a Binance fee quote or a claim about SharkRule’s fee model. Actual rates and fee assets must be checked separately.

The idealized model fills all 10 A when its price data reaches 10 Q. In the constrained scenario, 6 A of earlier buys have priority at the same price. Only 10 A of selling reaches that queue before review, so the earlier buys receive 6 A and this order receives 4 A. Assume no other queue changes. A third scenario has no eligible selling reach this order.

Same requested limit order; different execution assumptions
RecordIdealized full fillQueue-constrained fillNo fill
A actually acquired1040
Purchase value in Q10 × 10 = 1004 × 10 = 400
Hypothetical fee in Q100 × 0.001 = 0.1040 × 0.001 = 0.040
Q remaining at review, after any remainder is canceled200 − 100 − 0.10 = 99.90200 − 40 − 0.04 = 159.96200
Unfilled A canceled0610
Share of requested quantity filled100%40%0%
  1. Compare filled quantity and final order state before comparing balances. The extra cash in the partial-fill scenario comes with fewer acquired units; it is not evidence of better performance.
  2. Keep the remaining 6 A request separate from the 4 A holding until cancellation is confirmed. A request to cancel does not establish that nothing else filled before confirmation.
  3. Do not invent a later sale for the unfilled units. An exit calculation based on all 10 A would describe a different position from the one acquired.
  4. If a fee is deducted in A or another asset instead of Q, record that asset and recalculate the relevant balance. The table’s simple Q-only subtraction would no longer describe all balances.

A price touch does not establish your place in the queue

A chart can show a trade at your limit without showing enough opposing quantity reaching your order. Binance’s order-priority documentation illustrates price and time ordering. Without arrival and queue information, a price-only fill is an assumption to record, not a confirmed execution.

Models differ. Alpaca’s own paper-trading documentation explicitly excludes queue position, market impact and latency-related slippage from its simulation. That is an example of a documented model boundary, not a description of every simulator or of SharkRule’s implementation.

For a market order, the earlier quote is not a reserved price. Delay can change the available book, and execution may consume several price levels. A model can include spread, fees and slippage while still approximating them. Ask which reference price, delay and available quantity it uses; an unexplained result leaves those questions open.

Test an uncertain response, not only a successful trade

Consider a separate hypothetical sequence: at 10:00:00 an order is sent; at 10:00:10 the response times out; at 10:00:12 the existing order is found with a partial fill of 4 units. Those timestamps are illustrative, not a service-speed promise. The timeout did not mean zero units were bought.

Binance documents that a timeout can leave execution unknown and directs clients to check order status. A test that immediately turns every missing response into a rejection misses that ambiguity. Keep further Binance submissions blocked while the existing outcome is unresolved; inspect its status and fills before considering another action. Do not create a duplicate rule to work around the uncertainty.

Keep an evidence checklist for each run

Use a notebook or worksheet; this is a review method, not a claim that a dashboard exports every field. Mark each item observed, assumed or unknown. Keep unknowns visible rather than replacing them with a favorable default.

What to record and what the record can support
RecordQuestion it can answerLimit of the evidence
Rule version, mode, condition time and data timeDid this version react to the intended observation?It does not establish a live fill at that time.
Order type, requested quantity and fill assumptionsWhat would the model allow?A touched price alone does not establish queue priority or liquidity.
Filled quantity, price, fee amount and fee assetDo the modeled holdings and balances reconcile?A configured fee is not proof of the current account’s actual rate.
Partial fills, rejected requests, cancellations and missing responsesWhich failure paths were exercised?A failure never encountered or modeled remains untested.
Unsold holdings, open commitments and review timeWhat remains after the run?An unsold position is not a completed sale or a guaranteed exit value.

Common mistakes when interpreting paper results

  1. Comparing final cash while ignoring different quantities held. Reconcile cash, assets and outstanding orders separately.
  2. Assuming either that simulations have no costs or that modeled costs reproduce live costs exactly. Read the assumptions; Binance commissions can depend on the account, pair and applicable discounts.
  3. Resetting an unsuccessful run and keeping only the favorable one. Preserve the earlier rule version, assumptions and observations when changing a setting.
  4. Treating a quiet run as an outage test. Write down which delay, rejection, partial-fill and unavailable-data cases were actually exercised; mark the rest untested.

A clean test is not a forecast or a requirement to trade

There is no number of simulated days or completed trades that guarantees execution or returns. A short window may omit market conditions your rule would handle poorly. Virtual losses also do not show how you will respond emotionally to a real loss. These are limits on conclusions, not reasons to force a live experiment.

Real trading can lose money through price changes, fees and slippage. Orders may remain unfilled, and exchange outages, custody failures or account restrictions can prevent access or exits. We are not financial advisors. This guide explains a testing method, not which assets, allocations, sizes or trades to choose. SharkRule is independent software and is not affiliated with or endorsed by Binance.

Next step: review one virtual test with the checklist

Open the localized SharkRule simulator walkthrough linked in Sources below, review its virtual budget and choose one rule behavior to observe with this checklist. The current public walkthrough describes forward simulation with virtual funds and modeled costs; it does not require an exchange connection. Treat your observations as evidence about that test’s assumptions.

A simulation does not authorize real trading. Any later real-money setup requires a separate review of the available rule, budget, exchange permissions and account eligibility, followed by an explicit start. Use only what the current dashboard offers for your account and location; remaining in simulation is a valid choice.

Frequently asked questions

Does a profitable paper result mean the same rule will work live?

No. It records a result under a particular data sample and execution model. Different fills, fees, delays and future prices can change the outcome, including producing losses. Check rule behavior and unresolved assumptions rather than treating a virtual balance as a forecast.

Can a simulation include fees and partial fills?

Yes, if its model supports them. Their presence does not establish that the model reproduces your exchange account’s costs or queue position. Record the documented assumptions and mark any missing detail unknown.

Is a successful Binance test order evidence that a live order will fill?

No. The test-order endpoint checks a request without putting it into the matching engine. A subsequent real order still has to be accepted and matched; use its actual status and filled quantity to establish what happened.

Do I have to switch to real trading after a successful simulation?

No. You can keep learning with virtual funds or decide not to proceed. Testing does not remove losses or exchange risk. Live availability depends on the current product, your exchange account and location, and starting requires a separate deliberate authorization.

Official documentation and references

Prepared with AI assistance from the linked official documentation. Examples are hypothetical; no live account tests or return comparisons were performed.