A Backtest Is Not a Live Track Record: Three Kinds of Trading Evidence

A strategy can show a strong historical return and still fail when it reaches a real exchange. An order can be accepted on a follower account while its final position drifts away from the leader. A live return can look impressive while revealing little about the strategy version, fees, missing history or risk taken to achieve it.

These numbers are not necessarily wrong. They answer different questions.

EasyTrading starts with this distinction. XTester, CopyTrader and TradeStat cover different parts of the journey from an idea to a measurable live result. They are not yet one seamless technical system. The current EasyTrading ecosystem page describes the product roles and their public status. This article asks a narrower question: what must remain traceable when a strategy moves from research to execution and then into performance analysis?

Three claims, three different questions

Evidence	What it can show	What it cannot show on its own
Historical test	How defined rules behaved on selected data under declared simulation assumptions	Whether the result will survive new data or real execution
Execution record	What was submitted, accepted, filled, rejected or left unresolved on a specific account and venue	Whether the underlying strategy is robust or the follower will match the leader’s P&L
Live track record	What happened on connected accounts over a stated period	Whether the result is reproducible, complete or attributable to the strategy unless its source and lineage are clear

For a crypto algorithmic trading platform, the challenge is to keep these records connected without pretending that one proves another.

1. Model evidence: what happened inside the test

A backtest is evidence about a model. Its meaning depends on the code, data, market, period and execution assumptions used for that specific run.

XTester is the current EasyTrading research environment. It supports C# strategy development and historical testing across data from centralized exchanges and perpetual DEXs. Market types depend on the venue, while the simulation covers contracts, fees, funding and liquidations.

Other constraints still need to be declared and checked carefully. Quantity steps, minimum order sizes, spread, slippage, liquidity and fill assumptions can change a result. A historical run that ignores them does not become realistic merely because the strategy code is correct.

The same is true of methodology. A useful record should make it possible to recover at least:

• the immutable strategy version and parameters;
• the source and range of market data;
• the application and simulation settings;
• fees, funding and other declared costs;
• the distinction between development and unseen data;
• the run time, result files and any manual decisions made after seeing the output.

Out-of-sample and walk-forward checks can expose overfitting, but they are not certificates of future performance. They become useful when another person—or the same researcher weeks later—can reproduce the run and understand what changed between versions. The XTester backtesting guide covers the testing method in more detail.

AI can operate the experiment; it cannot certify the result

XTester’s Research Lab and local stdio MCP interface let a compatible AI client inspect a project, edit strategy files, compile code, run tests and compare outputs. This can shorten the mechanical part of research.

The same research mistakes remain possible: an agent can overfit, reuse a contaminated holdout or select a result after inspecting it. One operational detail also matters. Local stdio describes the connection to XTester, not necessarily where the language model runs. History downloads use the network and write locally; project edits, Git/GitHub operations and updates can change local or remote state. The documentation calls for confirmations, but enforcement varies with the installed tool catalogue, client and host. This MCP interface is for research, not live trading.

The useful record is therefore not “AI found a strategy.” It is the hypothesis, exact version, declared test, output and decision that followed.

2. Execution evidence: what the venue actually did

The next question is no longer “What did the model simulate?” It is “What happened on this account?”

CopyTrader is the current execution and White Label infrastructure in the EasyTrading ecosystem. It calculates proportional follower size, checks account settings before submission and sends orders to several centralized exchanges and Hyperliquid. The Hyperliquid release covers market and limit orders. CopyTrader also explains separately why a follower’s result can differ from the leader’s.

An accepted request is still not proof of a reconciled position. A complete execution record may need to distinguish:

• the leader event that triggered an action;
• the mapped follower instrument;
• the intended quantity and the venue-adjusted quantity;
• the submitted order and client/order identifiers;
• confirmed fills and remaining unfilled quantity;
• side, reduce-only and position mode;
• rejections, cancellations and stale account snapshots;
• the actual position observed after those events.

Think of this as the record an operator would want after a difficult execution. CopyTrader’s released scope covers order submission. Durable status and error logs, partial-fill reconciliation, reconnect recovery, idempotent replay and post-order position correction still need to be verified release by release.

That distinction matters because “copying an order” can refer to at least three different contracts:

1. reproduce the leader’s submitted order;
2. react to confirmed leader fills or position changes;
3. maintain a calculated target position on the follower account.

Each contract produces different behaviour when an order is partially filled, cancelled or replaced. A system should state which event is its source of truth.

Why CEX and DEX execution makes the distinction visible

Cross-exchange copying is not a ticker substitution problem. Two venues can expose similarly named BTC perpetual markets while using different contract specifications, collateral, price and quantity steps, minimum notionals, margin rules or position modes. A DEX can add wallet permissions, signing, transaction finality, gas or venue-specific execution risks. Market structure and liquidity can also differ.

The platform therefore needs an explicit instrument map and a compatibility decision. When that decision is uncertain, stopping the action and recording the reason is safer than sending a plausible but incorrect order. It protects this particular check; the wider trading system still has its own risks.

Position-based reconciliation is one possible architecture for handling drift. It compares a calculated target with the confirmed account position while accounting for the remaining unfilled quantity of active orders and their lifecycle. It is not identical to forwarding the leader’s order.

We explored this idea in an idealized reconciliation study, separate from production CopyTrader. Under specified rounding rules, the two modelled algorithms diverged. A sensitivity test also produced repeated corrections when it ignored quantity that had been submitted but not resolved. The experiment shows where to look for trouble, not how often or how severely it appears in production.

The practical conclusion is limited but useful: a successful API response tells the operator that a request was accepted. It does not by itself prove the final position, cost or economic result.

3. Live evidence: what the result represents

A live track record needs provenance. Without it, a return is only a number attached to a profile.

At minimum, the record should make clear:

• the account or data source;
• the strategy and version, where attribution is possible;
• the venues and instruments covered;
• the start and end of the measured period;
• the last synchronization time;
• whether fees and funding are included;
• whether trades, balances or periods are missing or hidden;
• whether the data comes from a backtest, simulation, paper environment or live account;
• which values can be edited manually.

Backtest and live results should not be merged into a single score. The backtest documents behaviour under declared assumptions. The live record documents events on connected accounts. Each has different sources of error.

TradeStat is a preview of the planned statistics product in the EasyTrading ecosystem. Its dashboard values are labelled as demonstrations, while the API, queues and event system for live data are still being connected. For now, it shows how the information may be presented rather than a set of verified trader results.

This status should remain visible even when the final product becomes more polished. A trustworthy page tells the reader what the data supports before presenting rankings or comparisons.

The contract that has to survive the handoffs

A research run, an exchange order and a performance figure become one traceable history only when they share stable identifiers and provenance.

To connect the products, we need clear answers to practical questions:

• Which immutable strategy version produced this research run?
• Which data and simulation settings were used?
• Which version and execution profile were approved for deployment?
• How was each instrument mapped for each venue?
• Which event triggered an order, and what happened afterward?
• Which fills and costs belong to the displayed result?
• What changed before the next version was created?

EasyTrading already has a .NET foundation with common abstractions and integrations for Hyperliquid, Aster and dYdX. These packages reduce duplicated work across DEX integrations. Broader CEX coverage and the links between products are separate work.

EasyTrading is meant to preserve the links between code, tests, execution events and results while keeping the tools responsible for different jobs.

Where EasyTrading stands today

Status checked against the product sites on 21 August 2026.

XTester is the released Windows environment for research and historical testing. CopyTrader runs multi-exchange copying and White Label infrastructure across centralized venues and Hyperliquid. TradeStat is a public demonstration of the planned statistics product; its live pipeline and real public strategy pages are still being connected.

The .NET packages provide common abstractions and integrations for Hyperliquid, Aster and dYdX. The final link—an end-to-end record from a research run to reconciled live statistics—remains product and architecture work. Today, a user can move through the stages, but the products do not yet present that journey as one self-service system.

What we are building toward

A working sequence should leave a trace:

1. record the hypothesis, strategy version, data and test assumptions;
2. approve a specific version and execution profile for controlled observation;
3. map instruments and account rules for the selected venues;
4. record orders, fills, unresolved state, skips and errors, then compare them with the observed account state;
5. calculate performance from labelled sources and return meaningful differences to the next strategy version.

Some steps already exist in the separate products; the handoffs are where the remaining work sits. Writing the sequence down makes that work measurable.

A strategy catalogue or marketplace comes later in this logic. Discovery is useful only when the history, execution limits and source of the displayed result are clear.

Risk and scope

This article describes product architecture and research practice. It is not investment advice and does not recommend a strategy, exchange or level of exposure. Backtesting, automation, AI assistance and copy trading cannot guarantee profit or prevent loss. Crypto trading also involves market, liquidity, operational, counterparty, smart-contract and wallet risks.

Automatic copy trading and management of follower accounts can be treated differently across jurisdictions. The UK Financial Conduct Authority, for example, notes that automatic copying may amount to portfolio or investment management depending on the arrangement. Operators and users need to assess their own legal position, permissions and controls.

The CFTC has separately warned that AI cannot turn trading bots into guaranteed money-making systems. Product testing and transparent records improve the quality of decisions; they do not remove trading risk.

The question behind the platform

The point is not to make a backtest look like live performance or an accepted order look like a reconciled position. It is to preserve enough context that each record can be interpreted correctly and traced to the stage that produced it.

That is the problem EasyTrading is trying to solve across research, execution and statistics. The products are at different stages, but the test for the next release is simple: can the record from one stage explain what happened at the next?

Frequently asked questions

What must remain unchanged when a strategy moves from research to execution?

At minimum, the approved strategy version, parameters, instrument definitions and execution profile must remain identifiable. If a venue requires a deliberate adaptation, that change should create a new mapped configuration rather than silently altering the research artifact.

Why is a successful API response not proof of a reconciled position?

The order can remain open, fill partially, be cancelled, or produce a different final quantity after venue rules are applied. Reconciliation needs confirmed account state and the remaining unfilled quantity of active orders, not only the initial response.

How should backtest, paper and live results be labelled?

Each result should name its environment, data source, period, costs, strategy version and update state. They should remain separate records rather than being combined into one performance score.