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.

shredstream.sh sends raw UDP from Frankfurt to one IP and port. One destination costs $100 for 30 days. The feed measured 54.3 Mbps, 5,585 packets per second, and 1,216 mean packet bytes on 2026-08-31, totaling 17.6 TB over 30 days. A follower must process that stream while acting on a tiny wallet set.

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

Solana has no public mempool. A watched trade decoded from a shred has already been included in the current leader's proposed block. The follower is not copying a pending instruction before execution. It is reacting to an early observation of proposed 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.

The slot can also be skipped, the watched transaction can fail, or a fork can replace it. Copy logic needs a provisional state and a confirmed reconciliation state. A signature seen in a shred is a trigger identifier, not proof of 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.

Slot, shred index, FEC set, and entry order preserve observation sequence. Completion flags release usable entry ranges. The leader signature authenticates the producer. The transaction signature deduplicates the same trigger. Every field has a narrow job and none supplies motive.

A defensible latency budget

Detection through submission totals 2.75 to 27.35 milliseconds. Decision receives more time than an account-only alert because the follower must translate someone else's trade into its own risk. Landing adds 60 to 550 milliseconds under the planning assumptions and can exceed that range.

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 detection-to-send, send-to-land, price difference, size difference, 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

UDP has no ordering, retransmission, or backpressure. A missing fragment can conceal one leg of a multi-hop route. A duplicate transaction can trigger a duplicate follower order if signatures are not deduplicated. Out-of-order entries can reverse the apparent sequence of a buy and sell.

Group by slot and FEC set, reorder by index, recover with coding shreds, and release only complete entry data under the decoder's rules. Mark fork state incomplete when a deadline expires. Reconcile against confirmed blocks and repair wallet histories.

The receive path should batch datagrams, reuse buffers, and keep logs off the packet thread. At the measured 5,585 packets per second, small per-packet costs compound. Bound queues and export packet age so overload cannot masquerade as low-latency processing.

Allow inbound UDP from 64.130.40.90 to the purchased destination port. The verification challenge remains valid for 600 seconds. A successful challenge shows that one datagram arrived. It does not show that address 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.

When raw shreds are the wrong source

A follower using minute-scale rebalancing, manual review, or broad identity research gains little from millisecond input. A parsed transaction service reduces decoder work. Confirmed state is better for statements, performance reporting, and tax records.

Raw UDP to one IP and port provides no retransmission, ordering, backpressure, or regional redundancy. A team without an operational packet pipeline may produce more stale or incorrect signals than it gains through early arrival.

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, the decision inputs, the quoted minimum output, and the deadline. Compare that hypothetical order with canonical state at the first slot where it could have landed. 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.

The honest latency claim is narrow. Shreds can 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.