How to build a Solana copy trading bot: the infrastructure playbook

TL;DR

→  A copy trading bot mirrors a target wallet's trades into your own. On Solana the whole game is speed: you copy profitably only if you land close to the price the target got.

→  It's a detection race first. Polling is too slow. WebSocket lags under load. Yellowstone gRPC (plus ShredStream) is the production standard—10–40 ms vs 300+ ms for polling.

→  Slippage grows with every millisecond of latency. See the target's swap 300 ms late on a fast token and you're buying into a price they already moved—sometimes into their exit.

→  Three sizing models: fixed amount (capped risk), proportional (mirrors conviction), fixed ratio (predictable scaling). Most production bots blend them with hard caps.

→  Decode swaps in real time. Parse Raydium, Orca, Jupiter, and Pump.fun instructions to extract token, direction, size, and venue before you can size and submit.

→  Risk filters are not optional. Per-token caps, blacklists, honeypot checks, and slippage bounds keep a bad target trade from draining your wallet.

→  Infrastructure sets your floor. Detection and submission are both infrastructure-bound. A perfect decoder on public RPC still copies late. Dedicated, co-located, staked paths are the edge.

‍

A copy trading bot watches a target wallet and mirrors its trades into yours. The concept is simple; the execution is entirely a latency problem. You profit only if your fill lands close to the price the target got—and on Solana's fast-moving tokens, "close" is measured in milliseconds. This playbook covers the pipeline, the detection methods, the sizing models, and the infrastructure that decides whether you copy profitably or copy into someone else's exit.

The copy-trade pipeline

A copy trade is five steps, start to finish, and every one is on the critical path. The clock starts when the target signs a transaction and stops when your mirrored fill confirms.

Detect the target's transaction, decode the swap, size it to your capital, submit your own, and land your fill. The entire detect-to-submit budget for a competitive bot is under 60 ms. Miss that and you're not copying the trade—you're chasing it. The difference between the two shows up directly in your slippage against the target's entry, referencing the Solana transaction model for how each step maps to on-chain execution.

Detection: how you see the target's trade

Everything starts with seeing the target's transaction as fast as possible. There are four ways to do it, and they are not close in performance.

Polling—don't

Repeatedly calling getSignaturesForAddress on the target wallet is the naive approach and the wrong one. You poll on an interval, so your detection latency is bounded by that interval—hundreds of milliseconds to seconds. By the time you notice the trade, the price has moved. Polling is fine for a dashboard, useless for a competitive copy bot.

WebSocket logsSubscribe—better, but fragile

Subscribing to the target's logs over WebSocket cuts detection latency to a few hundred milliseconds and pushes events to you instead of making you ask. The problem is reliability: WebSocket subscriptions drop silently under load, lag during congestion, and give you no server-side filtering, so you process noise. It works until the exact moment it matters most—a busy market—and then it doesn't.

Yellowstone gRPC—the production standard

The right foundation is Yellowstone gRPC, which streams transactions and account updates with server-side filtering, so you receive only the wallets you're tracking. Detection latency drops to 10–40 ms, the stream is stable under load, and you can subscribe to hundreds of target wallets without drowning in traffic. This is what production copy bots run on.

gRPC plus ShredStream—the fastest path

Layering Jito ShredStream on top of gRPC gets your Solana copy trading bot the target's transaction as shreds propagate, before full block confirmation reaches slower nodes. That shaves detection to 5–20 ms, whether you run your own stream or read it through a Solana copy trader API. On fast tokens, where the target's own trade moves the price, that head start is the difference between mirroring their entry and mirroring their exit.

Decoding the swap

Seeing the transaction isn't enough—you have to understand it. A raw Solana transaction is a set of instructions against program accounts. To copy a swap you must parse those instructions and extract four things: which token, which direction (buy or sell), what size, and on which venue.

Each DEX encodes swaps differently. A Raydium swap looks different from an Orca Whirlpool swap, which looks different from a Jupiter route or a Pump.fun bonding-curve buy. Your decoder needs a parser per venue, matching on the program ID and instruction discriminator, then reading the accounts and data to reconstruct the trade. This runs in the hot path, so it has to be fast—microseconds, not milliseconds—which means precompiled instruction layouts, not generic reflection.

The output of the decoder is a normalized trade object: token mint, side, amount, venue. Everything downstream—sizing, risk, submission—operates on that clean representation, not on raw instruction bytes.

// Normalized trade extracted from the target's transaction
interface CopyTrade {
  tokenMint: string;     // the SPL token being traded
  side: 'buy' | 'sell';
  amountSol: number;     // size in SOL terms
  venue: 'raydium' | 'orca' | 'jupiter' | 'pumpfun';
  targetWallet: string;
  detectedAt: number;    // performance.now() for latency tracking
}

function decodeSwap(tx: ParsedTransaction): CopyTrade | null {
  for (const ix of tx.instructions) {
    const parser = PARSERS[ix.programId]; // per-venue parser
    if (parser) return parser(ix, tx);
  }

  return null; // not a swap we copy
}

Position sizing: translating their trade to yours

The target's trade is not your trade. They might have a 5,000 SOL wallet and buy 100 SOL of a token; you have 20 SOL and need to decide what that means for you. There are three standard models.

Fixed amount

You buy the same fixed size on every copy trade regardless of what the target did—say, 2 SOL per trade. Simple, predictable, and your per-trade risk is capped. The downside is that it ignores the target's conviction: a tentative 5 SOL probe and an aggressive 500 SOL entry both trigger the same 2 SOL copy.

Proportional

You match the target's trade as a percentage of their wallet. If they put 2% of their capital into a token, you put 2% of yours. This mirrors conviction—big bets get copied big, small bets small—but it requires you to track the target's total wallet value, which adds a data dependency and a source of error if your view of their balance is stale.

Fixed ratio

You copy at a fixed ratio of the target's trade size—say, 1:100, so their 100 SOL buy becomes your 1 SOL. Predictable scaling that tracks trade size without needing their wallet balance. The risk is whales: a target's unusually large trade can size you into a position bigger than you intended, which is why fixed-ratio bots always pair the ratio with a hard per-trade cap.

In practice, most production bots blend these: a proportional or fixed-ratio base with a hard maximum per trade and per token, so no single copied trade can blow up the account. The sizing engine sits between the decoder and submission, and it also runs the risk filters.

Risk filters: not optional

Copying a wallet blindly means copying its mistakes and its traps. A target you trust can still buy a honeypot, get sandwiched, or make a fat-finger trade. Your bot needs filters that run before submission and can veto a copy:

• Per-token and per-trade caps. Hard ceilings on how much you'll put into any single token or trade, regardless of what the target does.
• Token blacklists and allowlists. Never copy trades into known-bad tokens; optionally, only copy into tokens meeting liquidity or age thresholds.
• Honeypot and sell-restriction checks. Verify the token can actually be sold before you buy it. Copying the target into a token you can't exit is worse than not copying at all.
• Slippage bounds. If the price has already moved beyond a threshold versus the target's entry, skip the copy. Late is worse than never.
• Duplicate and rate guards. Don't copy the same trade twice from a re-broadcast, and cap how many copies you'll fire in a window to avoid runaway behavior.

These filters cost microseconds and save accounts. They are the difference between a bot that mirrors a good trader's edge and a bot that mirrors their worst day at full size.

The infrastructure that wins

Copy trading is two speed problems—detection and submission—bracketing a small amount of logic. Both speed problems are infrastructure-bound, which is why the same stack that wins snipes and liquidations wins copy trading.

The streaming layer subscribes to your target wallets over Yellowstone gRPC. The decoder parses swaps in real time. The sizing and risk engine translates and vets. And underneath it all, the RPC layer sets your floor: dedicated bare-metal nodes co-located with validators, a SWQoS-staked submission path that stays prioritized during congestion, sub-1-slot lag so your view is current, and sub-50 ms failover so a node hiccup doesn't cost you a copy. Every layer above is only as fast as this one.

Submission: land close to the target

Detection speed gets your copy trade bot to the decision fast; submission speed gets its transaction to the leader fast. Pre-signed transaction templates mean you mutate only the volatile fields at fire time, whether you build them yourself or wire them through a Solana copy trader API. A calibrated priority fee keeps you competitive during the congestion that fast tokens produce. Multi-relay, multi-region submission reaches whichever leader is producing the current slot. On the tokens worth copying, this is where the slippage battle is won or lost.

The economics: slippage vs latency

Everything above reduces to one curve: how much slippage you eat versus how fast your pipeline is. On a fast-moving token, the target's own trade moves the price, and every millisecond you lag their entry costs you.

The curve is steep and unforgiving on exactly the tokens worth copying. A bot detecting and submitting in under 60 ms copies at roughly 1% slippage—profitable if the target is. A bot on public RPC or polling, landing 800 ms late, copies at 18% or worse, which on a fast token often means buying the exact candle the target is selling into. Slow tokens forgive latency; the tokens that make copy trading worth doing do not. That's why the infrastructure isn't a detail—it's the strategy.

Copy-trade latency benchmarks by tier

Reference numbers from RPC Fast internal benchmarks, comparing copy-bot pipeline performance across infrastructure tiers, Q1 2026:

Numbers are illustrative aggregates and vary by target, token, and market conditions. The relationship is what matters: profitable-copy rate tracks detection and submission latency almost directly, and both are infrastructure-bound rather than code-bound.

What actually matters

A copy trading bot is a decoder and a sizing engine wrapped around two speed problems. The decoder and sizing logic are table stakes—necessary, but not where you win or lose. You win or lose on detection and submission latency, and both are infrastructure. See the target's swap in 15 ms and land your mirror in 45 more, and you copy their edge. See it in 500 ms and land in another 300, and you copy their exit at full size.

If your copy bot is consistently landing worse prices than the wallets it follows, the problem is almost never the sizing model or the decoder. It's the two latency numbers at the ends of the pipeline—and those live in the infrastructure, not the application code.