Copy-Trading on Solana: The Infrastructure Behind It

What copy-trading actually is

A copy-trading bot does three things in a loop. It watches a target wallet - usually one with a track record worth following. It detects when that wallet buys or sells a token. And it mirrors the trade with its own capital, scaled to its own size and risk.

That's the entire concept. The appeal is obvious: outsource the alpha, automate the execution. Pick a wallet that's good at finding new launches or timing entries, and ride along. The strategy is borrowed; only the plumbing is yours.

Which is exactly why copy-trading lives or dies on infrastructure. The decision of what to trade was already made by someone else. Your only job is to see it and act on it faster than the edge decays.

The hard part is speed

Here's the uncomfortable truth: when you copy a trade, you are racing the same opportunity the target saw. They bought into a pool at one price. By the time you observe their transaction, decide to mirror it, and land your own, that pool has moved - partly because of their trade, partly because every other copycat watching the same wallet is racing you too.

Slow copy-trading doesn't copy the edge. It copies the loss - you get the worse fill, the moved pool, and the slippage the target avoided by being first.

So the latency budget is brutal. The gap between the target's trade and yours is paid in price: slippage on a thinner book, a pool that's already absorbing demand, or simply other bots landing ahead of you. Win that race and copy-trading works. Lose it and you've built a machine that systematically buys tops and sells bottoms.

Every piece of the infrastructure below exists to shrink one segment of that gap.

Detecting the target's transactions

You can't mirror what you can't see, and you can't win the race if you see it late. There are two tiers of detection, and serious copy-trading often uses both.

Yellowstone gRPC for live state. Open one long-lived stream and filter it server-side to the target wallet, so the validator pushes you that wallet's transactions and account changes the instant they're processed - no polling, no fanning out WebSocket subscriptions. This is the streaming backbone for most copy strategies; if you're new to it, start with Yellowstone gRPC vs Standard RPC and the gRPC product page.

Decoded shreds for first-seen detection. One layer further upstream, you can decode the target's transaction directly from shreds - the erasure-coded packets a leader broadcasts before any block is assembled. That's a pre-confirmation, first-seen view: you observe the target's trade while its block is still in flight, ahead of where gRPC would surface it at processed commitment. For copy-trading, that head start is often the difference between landing with the target and landing behind the pack. See decoded shreds and the deep dive on reading decoded transactions before confirmation.

The trade-off is the usual one: gRPC is simpler and certain enough for many strategies; shreds are faster but provisional. Pick the tier that matches how tight your race is.

Deciding what to mirror

Detection hands you a decoded transaction. Before you copy it, you decide whether it's worth copying - and that decision has to be fast, because the clock is already running.

• Filters. Not every trade the target makes deserves a mirror. Skip dust, skip tokens you can't exit, skip programs you don't support. Decode the swap, read the mint and the size, and gate on rules you can evaluate in microseconds.
• Sizing. You're not the target. Mirror their intent, not their lamports - scale to your own capital and per-trade risk. A fixed fraction, a capped notional, whatever your book can survive.
• Slippage. Because you land after the target, the price you get is worse by construction. Set a slippage bound that reflects that reality, and let the trade fail rather than fill at a price the edge can't support.

Keep this stage lean. Every branch you add between detection and send is latency you're handing to the next copycat in line.

Landing your mirror trade fast

Detection only buys you a head start; the sender decides whether you keep it. Once you've decided to mirror, the transaction has to reach a leader before the opportunity closes - and routing it through a generic RPC's send path adds hops and queueing you can't afford in a race this tight.

A direct transaction sender cuts that path down: it gets your signed transaction to the current and upcoming leaders with as little intermediation as possible. In copy-trading, where you're already landing behind the target by design, shaving the send leg is often what keeps your fill inside the slippage you set rather than outside it.

The first-seen discipline

If you detect from shreds, you're acting on pre-confirmation state - and that comes with a rule you don't get to skip. A first-seen transaction can still be dropped, skipped, or land on a fork that loses out. The target's trade you raced to copy might never finalize.

So the discipline is the same one that governs all pre-confirmation strategies: react on first-seen, reconcile on finality. Let the early view drive your decision to mirror, but confirm the target's transaction actually finalized - and confirm your own did too - before you book anything as real. Bound the size so a reorg is survivable, and make the pipeline idempotent so re-seeing a transaction doesn't double your trade. The full discipline is laid out in reading decoded transactions before confirmation.

Co-location as the tiebreaker

When two bots run the same target wallet with the same detection tier and the same sender, the race comes down to physics. Light takes time to cross a data center, and copy-trading is decided in exactly that kind of margin.

Running on dedicated nodes co-located with the cluster collapses the round trip on both ends of the loop: your detection stream sits next to the data, and your sender sits next to the leaders. When everything else is equal, proximity is the tiebreaker - and in a contest where the opportunity was already someone else's, the tiebreaker is frequently the whole margin.

A filtered subscription

The core of the detection loop is one stream, filtered to the target wallet, decoded server-side so you act on a swap instead of raw bytes:

// watch one target wallet, first-seen, decoded
const stream = await rpcedge.subscribe({
  endpoint: "grpc://iad1.rpcedge.com:443",
  source: "shreds",            // first-seen; use "grpc" for processed
  decode: true,
  filter: { accountInclude: [ TARGET_WALLET ] },
});
 
for await (const tx of stream) {
  const swap = decodeSwap(tx);        // mint, side, size
  if (!shouldMirror(swap)) continue;  // filters + sizing + slippage
  await sender.send(buildMirror(swap)); // land it now
  reconcile(tx);                      // verify on finality, don't double-act
}

One stream in, one filter, a lean decision, an immediate send, and a reconciliation pass behind it. Everything that makes copy-trading work or fail is in how fast each of those lines runs.

The takeaway

Copy-trading is a simple idea wrapped around a hard infrastructure problem. The strategy is borrowed; the only thing you own is the speed of the loop. Detect the target as early as you can - gRPC for live state, shreds for first-seen - decide in microseconds, land through a direct sender, and let co-location settle the ties. React on first-seen, reconcile on finality, and bound the exposure in between. Get the plumbing right and you ride the target's edge instead of their wake.