Crypto backtest sizing: which equity is available?

Crypto backtest order sizing should use an equity snapshot whose prices, fills and account updates were observable when the quantity was decided. Freeze that snapshot before the new order can earn or lose money, and check spendable funds separately. A backtest that credits an open trade's eventual profit before sizing an earlier order lets future capital influence the past, even if its entry signals use only historical data.

The percentage can be correct while its denominator is wrong. This article isolates that timing problem. The stop-distance sizing worksheet covers converting a chosen loss budget into quantity; here, the question is which account state may supply that budget.

Give the equity snapshot its own timestamp

A useful sizing record distinguishes four events: the valuation observation, receipt of that observation, the decision that fixes quantity, and the eventual fill. A candle timestamp alone does not establish all four.

For an unleveraged spot account, a declared marked-equity convention might add quote cash to the current value of holdings. Each holding needs an eligible price, including a policy for missing or stale prices. A realized-capital convention instead starts with initial capital and adds booked net results and external flows, leaving open P&L out of that sizing denominator. Both can be deliberate research policies. They produce different sizes and should have different labels.

Equity is also different from free quote cash. A holding can increase total marked wealth without creating cash available for a second spot purchase. Derivatives add product-specific collateral, liabilities and margin rules; a spot valuation does not establish their buying power.

Software settings can hide these distinctions. TradingView's strategy properties describe percentage sizing relative to available equity when a trade opens. They also distinguish recalculation after fills from processing orders at the close. Those are TradingView emulator settings, not a universal execution schedule. Record the engine, version, settings and whether quantity is fixed at decision time or calculated later under a declared order model.

Reconstruct one overlapping pair of trades

Consider this original hypothetical account, measured in USDT. It starts with 10,000 USDT, uses unleveraged spot trades, has no deposits or withdrawals, and excludes fees and slippage solely to isolate timing. Prices are invented. Trade A buys 40 units at 100; trade B later allocates 20% of the chosen equity denominator. B's assumed entry price is 50.

Assume the 10:00 mark was received before B's quantity was frozen and the declared policy permits that snapshot. B's budget is 10,400 × 20% = 2,080 USDT, giving 2,080 ÷ 50 = 41.6 units. The 10:01 fill transfers cash into a holding; it does not itself create profit under these assumptions.

Now imagine a shortcut that processes a completed-trade list. It takes A's entry, immediately books its eventual 40 × (120 − 100) = 800 USDT profit, and then sizes B because B is the next entry in the list. The simulator has advanced A to 12:00 while B still belongs at 10:01.

The faulty version assigns B 80 USDT more than the marked-equity policy, or 1.6 extra units. A's eventual loss could create the opposite distortion. Neither direction repairs the chronology.

Sorting completed trades by entry time does not solve overlapping lifetimes. Sorting by exit time does not solve early entries either. Account events must be processed in an explicit time order, with position valuation available at each sizing decision.

Freeze quantity, then test whether it is affordable

In the example, marked equity is 10,400 USDT but only 6,000 USDT is cash. If three simultaneous new signals each request 2,080 USDT, their combined request is 6,240 USDT. Every calculation can use an eligible snapshot while the batch still exceeds cash by 240 USDT, before costs.

Declare how the batch competes for that cash: deterministic priority, proportional allocation, rejection, or another documented rule. Reserve funds as orders are accepted rather than allowing every request to read the same unreserved balance. Reversing input row order should not change allocations unless row order is the declared priority.

Freqtrade's configuration documentation provides a concrete software example of dynamic stakes using available balance and remaining trade slots. Its tradable-balance section also distinguishes current balance from a fixed cash reserve. These definitions illustrate why “20% sizing” alone is incomplete; they do not establish how another simulator allocates funds.

Restore fees, quantity increments and adverse execution assumptions before treating a fixture as an executable request. If quantity is frozen using an assumed entry price, a worse fill can change its notional and affordability. If the order is a quote-currency budget instead, acquired units can change. State which object is fixed and how an unaffordable order is handled.

Resolve events that share a candle

Suppose an existing exit and a fresh entry both occur somewhere inside one candle. Funding the entry with the exit proceeds requires evidence or a declared assumption that the exit happened first and its update was available. A shared candle label cannot establish that ordering.

TradingView documents that recalculation after fills can expose finalized historical bar prices to an earlier intrabar calculation, creating look-ahead bias. Its strategy execution discussion shows why adding calculations does not automatically add genuinely observable information. Smaller bars can narrow an ambiguity; the intrabar-data guide explains their remaining limits.

Keep economic time and receipt time distinct. A fill economically occurring at 10:00:00 but acknowledged after the next decision cannot silently supply that decision with confirmed proceeds. A model can assume a notification delay, but must identify that delay as modeled when no receipt log exists.

The research cutoff is another boundary. A forced closing trade at the end of the test cannot retrospectively fund earlier positions. The open-trades-at-end guide compares terminal liquidation and valuation policies; keep that reporting choice separate from the capital previously available to size entries.

Audit one quantity before reading the final return

For a selected order, retain the snapshot identifier, eligible marks and their receipt times, booked cash events, open holdings, reserved funds, sizing convention, quantity-freeze time and submitted quantity. Another reader should be able to reproduce that quantity without opening any later trade result.

Then change only A's exit after 10:01 in the worked fixture. B's frozen quantity must remain 41.6 under the stated marked-equity policy. Its later performance and subsequent orders may change. Repeat with a later price update and a delayed fill acknowledgement to exercise other dependencies. This is a targeted check, not proof that the whole engine is causal; the broader look-ahead audit examines signal inputs too.

Model evaluation has a separate clock problem: training labels can extend across an evaluation boundary. Purged validation and embargo address overlapping label intervals. They cannot repair a wallet ledger that books future proceeds early. Check both when a learned signal feeds dynamic sizing.

Method and limits

Prepared with AI assistance from the linked primary software documentation reviewed on 23 October 2026. The overlapping trades, account states and audit fixture are original hypothetical examples; their arithmetic was recomputed. No market dataset, live account or KLINEO sizing control was tested. Consult the published backtest methodology for the scope of KLINEO's historical evidence. Correct timing improves the integrity of a simulation; it does not establish future returns.