Copy trading is usually reviewed as a signal question. Is the wallet any good, does the edge survive costs, how much capacity does it have. The execution question gets asked later and it is the one that determines whether the strategy quietly stops working. If your fills are a deterministic function of a feed that other people also read, you have not bought a signal. You have published a schedule.
The Whale Alerts feed is public, timestamped and dense. At capture it showed 21,160 total events over the selected 48 hour window, split into 7,395 entries, 5,972 exits, 6,641 size changes, 849 token buys and 303 token sells. The panel auto-refreshes every 60 seconds, and the engine header on the tracker reports a median latency of about 12 seconds. Those four numbers are the whole problem.
What an observer can reconstruct from your prints
Assume an adversary has the same feed, which costs nothing, and a tape of prints on the venues you use, which is public on chain and available on most centralised venues. They do not need to identify you. They need to notice that a cluster of prints keeps appearing a stable interval after feed events of a particular shape.
Fitting that is a one-parameter problem. If your delay is fixed, the cross-correlation between feed events and your prints has a single sharp spike, and a sharp spike in a cross-correlation is visible by eye long before anyone reaches for statistics. Once the delay is known, every future event of the right shape carries a prediction of your arrival with a known timestamp, a known direction and, if your sizing rule is proportional, a reasonable estimate of your clip.
The asymmetry worth naming is that the whale is not the one leaking. The whale's action is already on chain and already priced by whoever was watching. You are the second mover, and second movers are the only participants in this chain whose behaviour is predictable from public data. The tracked wallet has optionality about when to act. You have surrendered yours by construction.
The arithmetic of the matching problem
Whether the adversary's job is easy depends on how many candidate events compete for each of your prints, and the feed counters give you that directly. 21,160 events over 48 hours is roughly 441 per hour, or about 7.3 per minute across the whole unfiltered stream.
But you do not trade the whole stream. Suppose your rules only fire on entries above a size threshold, and suppose that leaves you acting on one event in fifty. That is roughly nine actionable events per hour, or one every seven minutes. Now the matching problem has collapsed: for any print of yours, the number of feed events inside a plausible window is close to one, so a single observation is close to a link and a dozen observations pin the delay to the second. The denser the filter you apply, the more identifiable you become, which is an uncomfortable inversion of how selectivity is normally supposed to work.
The 60 second refresh sets the other boundary. Everyone reading the panel in a browser sees a given event somewhere inside the same 60 second bucket. A delay meaningfully under a minute does not put you ahead of that crowd, it puts you inside it, competing for the same liquidity as every other reader of the same row. A delay of several minutes puts you behind the crowd but makes you the only identifiable participant in the tail. Neither end of that range is comfortable, which is the point.
Randomisation that actually removes the signature
The instinct is to add jitter. Jitter helps only if it is wide relative to the spacing between candidate events, because the adversary's problem is a matching problem, not a timing problem. Uniform noise of plus or minus ten seconds around a fixed delay leaves the cross-correlation spike intact and merely blunts it.
Three rules that do more.
- Draw the delay from a distribution whose spread is comparable to the inter-arrival time of your actionable events, not to your latency. Using the example above, that means minutes of spread rather than seconds. The test is whether a print of yours could plausibly have come from two or more different feed events. If the answer is always no, the distribution is too tight.
- Break the deterministic link between event size and your clip. Proportional sizing off a published Value field means the adversary can read your size off the feed row before you send. Quantise into a small number of fixed clips, or size from your own risk budget rather than from the whale's notional.
- Sometimes do nothing. A rule that fires on every qualifying event is fully specified by the feed. A rule that declines a random subset of qualifying events cannot be inverted into a schedule, because absence carries no information the observer can use.
Venue policy carries the rest. Routing every copy through one venue makes the tape trivially separable. Splitting across venues, and varying which venue leads, means the observer has to solve several matching problems at once with partial tapes for each.
What randomisation costs, stated honestly
Every one of those rules costs you something measurable, and a desk that adopts them without pricing the cost has traded one unquantified risk for another.
Widening the delay distribution means your average fill happens later, and any decay in the signal is paid in full on every trade. Quantised sizing means your position is sometimes larger and sometimes smaller than your conviction warrants. Declining a random subset reduces the number of observations behind your track record, which lengthens the time before your own performance is measurable at all. That last one matters more than people expect: if you skip a third of qualifying events, the sample supporting your attribution grows a third more slowly, and the review that asks whether the sleeve works arrives with less evidence.
The way to settle it is to measure the decay directly rather than argue about it. Log the feed timestamp, your decision timestamp and your fill timestamp on every trade, then bucket realised slippage against your own delay. If slippage is flat across the range of delays you are considering, randomisation is close to free and you should take it. If it slopes steeply, you have a real trade-off and it belongs in the strategy document rather than in an engineer's config file.
What the file has to show in a review
The question you will be asked is not whether you leaked. It is whether you knew you might and what you did about it. That is answerable with four artefacts, and none of them require new infrastructure.
Record the delay policy as a distribution with its parameters and the date it was last changed, not as a single number in a config. Record the sizing rule and specifically whether it references any field from the feed. Record the venue split policy. And keep the slippage-versus-delay measurement current, because it is the only one of the four that can tell you the policy has stopped working.
Then add the check nobody runs. Once a quarter, take your own fills and the public feed and try to fit your delay yourself, using nothing but data an outsider would have. If you can recover it in an afternoon, so can they, and the policy needs changing before the next review rather than after it.