Solana shred feeds for copy trading

6 stages follow an action that already happened

Copy trading observes a selected wallet and sends a separate transaction intended to reproduce part of its economic exposure. A shred feed can reveal the watched transaction during proposed block production. It cannot place the follower in the same execution position, reproduce private context, or guarantee the same price.

A follower listens at a registered address and port for the complete raw stream originating in Frankfurt. For this follower, 30 days cost $100, lower than every other standalone listing and leaving the desk to measure cost per watched-wallet decision rather than per byte.

The speed case is straightforward: an earlier wallet observation can start the follower pipeline before a conventional parsed or confirmed API. The risk case is equally important: the follower always acts with less context and later state than the watched trader.

No public mempool means no shared entry point

Without a shared pending queue on Solana, the follower first sees a watched trade after the current leader commits it to the block candidate. This is not a copy of an instruction awaiting execution. It reacts to an early observation of execution.

The next available price may be worse because the watched trade moved the pool. Other followers may move it further. The watched wallet may be hedging an off-chain position, closing a leg opened elsewhere, transferring between controlled accounts, testing a program, or intentionally trading through a route the follower cannot access.

Skipped slots, failed watched transactions, and replacement forks remain possible. Copy logic therefore needs provisional state plus confirmed reconciliation. A transaction signature found in shred data identifies the trigger without proving economic intent.

Wallet identity is a model, not a field

Transaction account keys show signers and touched accounts after full message resolution. They do not prove that one person controls every related wallet. An address lookup table can hide keys from a naive static-key parser. Program-derived authorities and delegated accounts can separate the initiating signer from the economic owner.

The desk should define why an address belongs on the watched list, when that attribution expires, and which programs count as trades. A transfer to a vault is not automatically a buy. A swap can be one leg of a larger atomic route. A liquidity deposit changes exposure differently from a market order.

Instruction discriminators and account roles identify supported actions. Amounts need token decimals and protocol-specific interpretation. For exact-output swaps, maximum input is a limit, not necessarily the amount spent. For multi-hop routes, intermediate transfers are not separate investment decisions.

Observation sequence combines slot, shred position, recovery group, and entry position. Completion flags mark ranges ready for use. The producer's leader signature supplies authentication, while transaction signature deduplicates the trigger. Every field has a narrow job and none supplies motive.

Reserve decision time for follower risk

The copy desk spends 2.75 to 27.35 milliseconds across its five local stages before sending. Decision receives more time than an account-only alert because the follower must translate someone else's trade into its own risk. Landing then adds 60 to 550 milliseconds under the model and can run longer.

The decode lower bound assumes the message keys are resolvable from local address lookup table state. Fetching a table over RPC on the event path can add an unpredictable round trip. Keep tables synchronized in advance and reject unresolved messages within the deadline.

The decision stage must be bounded. Identity confidence, asset allowlist, program version, liquidity, expected price impact, follower balance, per-wallet allocation, total portfolio concentration, daily loss, and token authority policy all need deterministic local answers. A missing answer should reject the trade.

Signing speed assumes a hot local key. If follower assets require stronger custody, a remote signer may be the correct choice even with higher latency. State that cost. Submission speed assumes no DNS, TLS, or connection establishment after the trigger.

Work a scaled follower example

Assume a watched wallet swaps 100 SOL into token X through a supported pool. The follower's policy is not to copy 100 SOL. It allocates 0.5 percent of a 400 SOL portfolio, so the initial cap is 2 SOL. A separate rule caps follower size at 1 percent of observed pool reserves.

The watched trade leaves 500 SOL in the input-side reserve under the local proposed model. One percent is 5 SOL, so the portfolio cap remains tighter. The engine estimates 1.2 percent price impact at 2 SOL, adds a 2 percent contention allowance, and sets a minimum output consistent with a total 3.5 percent slippage ceiling including fees.

If the pool price has already moved beyond that ceiling when the follower transaction executes, it should fail rather than buy at an unbounded price. That failure can still cost fees. The expected cost of failed attempts belongs in portfolio results.

If the watched route uses an unsupported transfer extension or a mint with a forbidden authority under the follower policy, the engine rejects it. The fastest safe response is often no transaction.

Later execution changes the trade

Copy-trading returns should be compared against the watched wallet at the follower's executable time, not the watched wallet's original price. The difference includes pool movement from the watched trade, intervening trades, priority, route choice, fees, and failure.

A watched wallet may receive rebates, private routing, or off-chain consideration the follower does not receive. It may have a lower cost basis, a hedge, or a longer horizon. Public on-chain action is incomplete strategy information.

Measure time from detection until send, outbound-to-land duration, price and size differences, failed fees, later markout, and fork outcomes. Separate apparent copy success during rising markets from risk-adjusted performance. A fast system can reproduce losses faster.

Avoid manipulative feedback loops

Large groups following a visible address can move price after its trades and create an exit opportunity for the watched party. That dynamic can be organic, coordinated, or deceptive. A desk should monitor concentration, thin liquidity, repeated follower slippage, and addresses that sell into predictable follower demand.

This page does not advise evading market rules, amplifying deceptive promotions, or bypassing access controls. shredstream.sh provides raw data, not an endorsement of a wallet or strategy. Users remain responsible for applicable law, venue terms, and the effect of automated demand on other participants.

Hard size caps, liquidity floors, asset policies, and kill switches reduce exposure. They do not establish that a watched trader has skill or aligned incentives.

Packet handling affects account truth

Raw UDP gives the follower neither ordered delivery nor retransmission, and the sender applies no backpressure. One missing fragment can conceal a leg of a multi-hop route. Duplicate transactions can trigger repeated follower orders unless signatures are deduplicated, while reordered entries may invert the apparent buy-and-sell sequence.

Partition packets under slot and FEC-set keys, restore index order, recover with coding shreds, and release only entry data that satisfies decoder completeness rules. Mark fork state incomplete at deadline, then reconcile against confirmed blocks and repair wallet histories.

The receive path should batch datagrams, reuse buffers, and keep logs off the packet thread. Small per-packet costs compound at high rates. Bound queues and export packet age so overload cannot masquerade as low-latency processing.

At the follower's purchased UDP destination, admit only source 203.23.178.228 without exceptions. The verification window lasts 600 seconds. Success shows that one datagram arrived, not that lookup tables are current, packets are loss-free, or follower orders can land.

Submission and custody are separate choices

The feed has no transaction submission feature. The follower needs its own path, fee policy, blockhash management, retry policy, and reconciliation. Retrying without a deduplication and validity design can create repeated exposure. Not retrying can lower land rate.

A signer should enforce program allowlists, token amount caps, fee caps, and destination accounts independently of strategy code. A compromised detector should not gain arbitrary transaction authority. Keep enough balance for the intended risk but not an unbounded treasury on the ingest host.

Leader geography changes over time. Frankfurt is the feed origin, not a claim about proximity to every leader. Measure outbound routes independently and avoid presenting local process time as end-to-end execution.

Build for fast automated following

Automated followers benefit most when raw-shred identity data is local, program parsers are prepared, and decisions take milliseconds. Record canonical state for statements, performance reporting, and tax records.

Frankfurt's raw UDP enters the follower through its single registered socket. Packet sequence, gap replay, flow control, and regional replicas remain the follower's responsibility. A working receiver batches packet reads, deduplicates transactions, tracks completeness, and isolates stale work from the current stream.

Acceptance starts in shadow mode

Replay a representative set of watched-wallet transactions before enabling a signer. The parser should reproduce asset, direction, effective amount, route, and success status for every supported program version. Unknown instructions must reject rather than being interpreted through the nearest familiar layout.

Next, run the live strategy in shadow mode. Record the follower message it would have signed, decision inputs, quoted minimum output, and deadline. Compare the hypothetical order against canonical state for the first slot where landing was possible. This reveals price decay without spending capital or attributing every missed fill to the feed.

An acceptance report should separate watch detections, supported trades, policy rejections, unresolved lookup tables, signed orders, submitted orders, landed orders, failed orders, fork-lost triggers, and duplicate triggers. Report return after fees and against a time-matched benchmark. Comparing only with the watched wallet's earlier execution flatters the follower path.

Test a watched address that transfers to itself, adds liquidity, routes through three pools, signs through a delegate, and sells shortly after followers buy. The system should show which facts it knows and which inference it refuses. Wallet attribution and economic intent remain model outputs.

Set a hard maximum age at signing and again at submission. If a queue or signer delay crosses it, discard the order. A late copy with a valid message can be more dangerous than an explicit miss. This behavior should be tested under packet bursts and outbound timeouts.

Shreds start detection earlier. A prepared follower can decide and submit within about 3 to 27 milliseconds locally. The watched trade remains earlier, and landing remains uncertain. Copy quality depends on price, context, limits, and discipline after that head start.