A mirrored trade is always a reaction to something that already happened. This note describes the delay honestly: where it comes from, what it costs, and what the system does when it falls behind or stops entirely.
In short
Mirroring is inherently reactive: a leader's fill has to be observed on-chain before it can be copied, so your fill lands later and at a different price. Under normal conditions the lag is seconds and shows up as tracking error rather than a different strategy. During an outage nothing is force-closed and no positions are abandoned — mirroring simply pauses, and on recovery the system reconciles against the leader's current state rather than replaying the trades it missed, so you do not enter a move that is already over. Throughout any degradation your capital stays in your own Hyperliquid account and your own signature is the only thing that can move it.
Why a mirrored fill can never be simultaneous
Copy trading is observation followed by action. The leader submits an order; it is matched and becomes a public fill; the fill is read; a corresponding order is submitted on your account; that order is matched at whatever the book offers at that moment. Every one of those steps takes time, and the last one is a fresh trade at a fresh price.
That means the correct mental model is not 'the same trade' but 'a very similar trade, slightly later'. In a calm market the difference is small enough to ignore. In a fast one — a liquidation cascade, a funding reset, a news candle — it is exactly the moment the difference is largest, because the price is moving fastest precisely when the leader is most likely to be trading.
This gap is called tracking error, and it is a permanent property of any mirroring system, including this one. It is not a bug that gets fixed; it is a cost that gets measured.
Your entry and exit prices differ from the leader's, in both directions.
Slippage grows with market speed and with sleeve size relative to book depth.
The effect is largest on the trades that matter most.
What the delay actually costs
The cost is not a single number, because it has several independent sources. Detection lag is the time between the leader's fill becoming public and the system acting on it. Execution slippage is the difference between the price you expected and the price you got. Spread is paid on every entry and exit. Funding accrues while a position is open, and your funding clock starts later than the leader's, so a carry position captures slightly less than theirs.
Over many trades these differences do not cancel to zero, and they do not compound into ruin either. They show up as a persistent, measurable divergence between your realised result and the leader's. A high-frequency leader who takes many small positions produces more of this divergence than one who holds for days, which is one reason turnover and holding behaviour are part of how leaders are assessed rather than return alone.
The separate note on tracking error goes through this arithmetic in detail.
What happens when the system goes down
Assume the worst version: the mirroring infrastructure stops responding while you have open positions in several sleeves. Here is what that does and does not mean.
Your positions remain exactly as they were. They live in your own Hyperliquid account and sub-accounts, on-chain, subject to Hyperliquid's margin engine — not to ours. They are not force-closed by an outage, they are not transferred, and they are not visible to or controllable by anyone but you. If a position would be liquidated by the market during that window, it is liquidated by Hyperliquid on the same terms as any other position on the venue, which is a market risk you already carry.
What stops is new mirroring. The leader's subsequent entries and exits are not copied while the system is unavailable. That cuts both ways: you miss the leader's good exits as well as their bad entries, and there is no honest way to characterise that in advance as favourable or unfavourable.
Because your funds never left your account, the outage does not create a counterparty exposure. You can always open Hyperliquid directly, close positions yourself, and revoke the agent approval on-chain without anything on our side working at all. That property is the entire point of the non-custodial structure, and downtime is where it earns its keep.
Nothing is force-closed or transferred during an outage.
New mirroring pauses; existing positions stay under Hyperliquid's normal rules.
You retain unilateral control: close manually, or revoke the agent, at any time.
Catch-up: reconcile state, do not replay history
The tempting behaviour after an outage is to replay everything that was missed — fire off all the trades the leader made while the system was blind, in order, as fast as possible. That is the wrong thing to do, and it is worth being explicit that it is not what happens.
Replaying a queue of stale signals means entering moves that have already played out and exiting ones that already reversed. You would pay full turnover to arrive late at every single one, and the resulting book would reflect neither the leader's current positioning nor any coherent strategy.
The correct behaviour is reconciliation: compare what the sleeve currently holds against what the leader currently holds, and close the difference. If the leader opened and closed a position entirely during the gap, there is nothing to do — that trade is gone and chasing it is pure cost. If the leader is now holding something the sleeve is not, the sleeve moves toward the current target at current prices, with the honest acknowledgement that the entry is worse than the leader's was. If the leader has exited something the sleeve still holds, the sleeve exits.
The result is a book that converges on the leader's present state rather than their recent history. It leaves a real, unrecoverable gap in the result for the outage window, which is preferable to manufacturing a fictional one.
How this interacts with the replacement policy
Evaluation lag deserves naming here because it is the same family of problem. Leader assessment runs on cached snapshots of public data, so a leader's deterioration is visible to the policy slightly after it begins, and soft issues additionally have to repeat across three separate UTC strike-days before a replacement happens. Emergencies — account value below roughly $1,000, or no fill for 96 hours or more with zero trades in 7 days — are the only conditions that act immediately.
So there are two distinct delays in the system, and they should not be confused. Execution lag is measured in seconds and costs you basis points per trade. Evaluation lag is measured in days and is a deliberate design choice to avoid cutting good leaders on noise. Both are disclosed rather than smoothed over, and the full rule set is published in the documentation.
What you can verify yourself
None of the above requires trusting a description. Every mirrored fill sits under your own address on a public venue, so you can compare your fills against the leader's fills and measure the lag yourself. The dashboard shows your recent mirrored trades, your account value, your open positions and your margin used, drawn from the same on-chain state anyone else can read.
If the numbers you measure disagree with what you read here, the measurement is the authority.
Past performance is not indicative of future results. Perpetual futures are leveraged instruments and carry a substantial risk of loss, including the loss of your entire position.
Keep reading
How the diversified approach is implemented
If the structural argument above holds, the interesting question is the implementation: how leaders are scored, how weights are set and how replacement is triggered.
