Two Ways to Copy Trades—and When They Produce the Same Result

Copy trading sounds simple: when a trader changes a position, the system should reproduce that change in a follower account. In practice, the exchange rounds quantities, an order below the minimum size may not be accepted, and a submitted order can remain unfilled for some time. Those details can create a gap between the trader’s and follower’s positions.

The EasyTrading team compared two ways to copy a position:

• copy each change: if the trader increases a position by 0.2 BTC, submit the same 0.2 BTC change for the follower;
• reconcile to a target: compare the required position with the current one, add quantity from orders already submitted, and correct the remaining gap.

The second approach looks more sophisticated. But does it actually behave differently when both algorithms receive the same data and account for submitted orders in the same way?

The short answer is no, not in the specified idealized model. A difference appeared after rounding was added and the rules for tracking submitted orders were changed.

For a user, the formula itself matters less than the outcome: how closely the system follows the trader’s position and how many orders it needs to do so.

Why two algorithms can submit the same order

Suppose the trader’s position rises from 0.5 to 0.7 BTC.

The first algorithm sees a change of +0.2 BTC and submits +0.2 BTC.

The second sees a target position of 0.7 BTC. If the current position plus quantity already awaiting execution totals 0.5 BTC, it also submits +0.2 BTC.

0.7 BTC − 0.5 BTC = 0.2 BTC

The result remains the same while both algorithms see the same signals, the exchange does not round quantity, and the system remembers orders that have been submitted but not yet filled.

A more complicated formula does not create different behavior by itself. It needs a gap to correct.

How we tested it

We built a simulation using data from one day, 28 July 2026. It included BTC and ETH positions from three public Hyperliquid traders. Replication was modelled under Binance Futures and Bybit rules with delays ranging from 0.25 to 30 seconds.

This produced 40 comparison scenarios, but they were not 40 independent experiments: all of them reused data from the same day. The result describes algorithm behavior under the selected conditions, not the market as a whole.

No real orders were submitted. The simulation used public trades only as price references and did not model the order book, queue position, or actual execution.

Result 1: the algorithms matched in the idealized model

With the same data and accounting rules, both algorithms submitted identical orders in all 40 scenarios. Their order counts, calculated turnover, hypothetical fee proxy, and tracking error—the gap between target and simulated positions—also matched.

Across the tested trajectories, scenarios with greater imposed latency had higher tracking error. But latency affected both algorithms in the same way and did not create a difference between them.

This does not prove that the two approaches are always equivalent. Only two specific implementations matched in the specified idealized simulation.

Result 2: the algorithms diverged after rounding

An exchange accepts quantities only in permitted increments and may reject an order that does not meet the minimum notional value.

We applied a 29 July 2026 snapshot of these constraints under two specified rounding rules. This was a sensitivity check, not evidence that every simulated order would have been accepted on 28 July.

Under each of the two rounding rules, target-position reconciliation produced a smaller simulated position gap in all 40 scenarios—80 comparisons in total. Closer tracking required more activity:

• mean dollar-denominated tracking error (TE_usd) fell by about 95.7%–97.6%;
• calculated turnover rose by 4.1%–7.9%;
• order count rose by 21.0%–35.9%.

The ranges were calculated across 16 combinations of rounding rule, venue, and latency. Each value was an unweighted mean of the five eligible one-day trajectories.

These figures do not predict future returns, actual fees, or production CopyTrader results. They describe only the selected simulation, position scale, and exchange-constraint snapshot.

Result 3: the system must remember an order already submitted

We separately tested a rule that looked only at filled position and ignored an order already submitted to the exchange.

Imagine that the follower is 0.2 BTC short of the target. The system submits an order, but no fill has been confirmed. If the next reconciliation cannot see the quantity already in flight, it again concludes that 0.2 BTC is missing and submits another order. In high-frequency simulation scenarios, this led to repeated submission of the same quantity.

We did not test production CopyTrader or find such a bug in it. The result applies to this model’s state rules: reconciliation must account for quantity already submitted, or the same correction can be generated again. Real rejects, partial fills, and cancellations were not tested in this pilot.

What this means for CopyTrader

The choice between two algorithms is not simply a choice between a simpler and a more sophisticated formula. In the idealized model, they submitted identical orders. Differences in the pilot appeared under the specified rounding rules and when the accounting for submitted quantity was changed.

The next validation should cover the full lifecycle of a real order: submission, acknowledgement, partial fill, rejection, cancellation, and reconnect recovery. Only then can copying accuracy, actual fees, and operational risk be compared.

For a user, the takeaway is simple: copying quality depends not only on the trader’s signal, but also on how the system handles an order after submission.

Limitations

This was a one-day research simulation, not a live-trading test. The candidate traders were selected from a leaderboard snapshot obtained after the test day, creating possible survivorship bias. We submitted no orders, used no user accounts, and did not calculate profit or loss.

The model did not include the order book, queue position, slippage, market impact, or actual fees. Production CopyTrader was not part of the experiment.

Conclusion

In the specified idealized model, the two ways of copying a position produced the same result. The exact match disappeared after the specified rounding rules were applied and when accounting for submitted orders was changed. Real execution failures were not tested in this pilot.

In the tested rounding scenarios, target-position reconciliation tracked the target more closely but increased calculated turnover and order count. The next step is to test whether that advantage remains under realistic execution and whether it justifies the additional cost.

---

This study was prepared by the EasyTrading team. AI was used to check code, calculations, and text under the team’s supervision. The results were not independently audited or externally peer-reviewed and are not investment advice.