Solana shred feeds for token sniping

6 stages follow market creation

Token sniping is an attempt to enter a new market shortly after its creation or first usable liquidity. A raw shred feed can expose the creation transaction while the leader is still broadcasting the proposed block. It cannot reveal every order before inclusion, reserve the first position, or make an unsafe token safe.

The product is one raw UDP destination from Frankfurt for $100 and 30 days. The measured feed on 2026-08-31 was 54.3 Mbps, 5,585 packets per second, and 1,216 mean packet bytes, totaling 17.6 TB over 30 days. A receiver must absorb that entire stream to find the small fraction of transactions that describe a launch.

Speed matters because early liquidity can reprice in a fraction of a slot. Risk checks matter because new assets carry concentrated authority, transfer restrictions, mutable metadata, shallow inventory, and adversarial launch mechanics. The useful system makes both costs visible. A decision path with no safety budget is not low latency. It is incomplete.

A shred is not a pending-order queue

Solana has no public mempool. The market-creation transaction found in a shred is already part of a proposed block. The response cannot be inserted before that observed transaction through a public pending queue. It must reach a leader for a later position, subject to scheduling and transaction intake.

This removes a common false promise from token launch marketing. A feed can provide earlier observation than confirmed RPC, account subscriptions, or a parsed block stream. It cannot promise the first buy. Other traders may receive similar data, maintain closer leader connections, prearrange private order flow, or submit based on off-chain launch information before any shred exists.

The observation is also provisional. The slot can be skipped. The creation transaction can fail. A fork can disappear. A pool can be created and then modified by a later instruction in the same block. The strategy must keep a fork-labeled state and reconcile against confirmed history.

Detect the event, not a ticker string

The fast filter starts with program IDs and instruction discriminators for supported launchpads, automated market makers, and token programs. A symbol or mint address in arbitrary bytes is not enough. The detector should identify the instruction that creates the market, initializes reserves, or makes trading possible under the target protocol.

Account positions then supply the mint, pool, vaults, market authority, fee account, and relevant program-derived addresses. Token program choice matters because transfer behavior and extensions can differ. Address lookup tables must be resolved from a local cache. An RPC call to expand keys puts an uncontrolled network round trip into the critical path.

Slot, shred index, and FEC set index preserve order. Completion flags show when enough entry data is present. The leader signature supports authentication. The transaction signature becomes the stable deduplication and reconciliation key, though its presence does not prove success or finality.

The receiver should not decode metadata that cannot affect the first decision. Human-readable token names, images, and social links belong in a slower enrichment lane. The hot path needs executable facts: which program, which mint, which pool, what reserves, what authorities, what restrictions, and whether a prepared transaction can refer to the right accounts.

A defensible latency budget

Detection through submission totals 2.65 to 23 milliseconds. The arithmetic is direct: add each of the first five stages. Landing is separate because it is governed by leader timing, queue position, account locks, priority fees, compute, and transaction validity. A page that folds land time into an attractive local number conceals the largest uncertainty.

Detection means identifying a candidate event, not proving every property. Batch receive, fixed packet buffers, and a keyed dispatcher make the lower range plausible. Full signature verification, erasure recovery, and semantic parsing still have to happen under a stated policy. Cheap structural checks should precede expensive cryptography.

Decode reaches the lower bound when the transaction falls inside available data shreds. A missing fragment can block deserialization even when later shreds arrived. Coding shreds may reconstruct it, but recovery work adds time. Measure clean, reordered, and recovered paths separately rather than publishing one blended median.

Decision gets more budget than pure pool arbitrage because launch risk has more branches. The program must check mint authority, freeze authority, token-program variant, transfer extensions where applicable, initial reserve size, maximum ownership policy, price impact, and an allowlist or denylist of launch mechanisms. Each check should read local immutable or recently synchronized state.

A remote metadata API cannot fit this budget. If social identity is required, preload an allowlist before the on-chain event or accept that the strategy is slower. Missing context should cause a bounded rejection, not a synchronous call that stalls every candidate behind it.

The worked decision has a rejection path

Assume an entry reveals a supported pool initialized with 100 SOL and 10 million tokens. The displayed initial ratio is 0.00001 SOL per token before fees and curve effects. A planned 2 SOL purchase is 2 percent of the SOL reserve, so price impact is material even before competitors.

The local policy checks that the mint address matches a preannounced candidate, the market program is supported, vault derivations are correct, no forbidden authority remains under the strategy rules, and the transaction template can cap maximum input and minimum output. It then simulates the curve locally against decoded reserve values and subtracts fees plus an adverse-order allowance.

If the expected output falls below the minimum after a 5 percent contention haircut, the correct low-latency answer is no trade. Fast rejection preserves capital and submit capacity. The system should record which policy rejected the candidate so the desk can distinguish intentional restraint from decoder failure.

Transaction construction belongs before launch

The hot path should not discover program layouts, derive every address, or allocate a message graph. Templates can hold the payer, compute-budget instructions, supported program accounts, and fixed instruction structure. Detection supplies the mint, pool, vaults, amounts, recent blockhash policy, and any protocol-specific seeds.

Templates have limits. A new program version or account layout can make them wrong. Every template needs a version gate and a test vector. Unknown variants should route to analysis, not production signing. A transaction that is fast but names the wrong vault will fail, and repeated failures consume fees and leader goodwill.

The signer boundary is an explicit security decision. An in-memory key offers the stated fraction-of-a-millisecond target but increases host exposure. A remote signer or hardware boundary can add milliseconds. A desk may reasonably choose the slower policy. The budget must carry the real measured tail.

Submission and landing remain competitive

A warm submission route removes connection setup from the event path. It does not create leader capacity. The target can reject, delay, or omit the transaction. A recent blockhash can age out. Account locks can serialize execution. Priority fees affect scheduling but do not buy certainty.

Geography is asymmetric. Inbound data comes from Frankfurt. The scheduled leader may be elsewhere, and the user's receiver may be far from Frankfurt. Measure feed arrival to decision and decision to submit independently. A low local decode time cannot compensate for a long intercontinental route.

Success should be defined as a landed transaction with bounded execution price, not a sent datagram or accepted relay request. Track inclusion slot, position, actual token output, fee, price impact, subsequent liquidity, and fork outcome. A fill that lands early into adversarial liquidity can still be a bad fill.

Harm and market integrity

Token sniping can range from reacting to public market creation to exploiting launch mechanics that ordinary users cannot observe or contest. This page describes early observation and bounded execution. It does not provide instructions for bypassing access controls, manipulating a launch, congesting a leader, or inducing retail users into worse fills.

shredstream.sh provides raw network data. Our position is that speed does not excuse deceptive or abusive conduct. Teams should apply venue rules, applicable law, and explicit controls for market manipulation, privileged information, and user harm. If a strategy depends on hiding its mechanism from the people bearing the loss, raw latency is not the central problem.

Packet loss must fail closed

UDP has no ordering, retransmission, or backpressure. A launch detector that misses one shred may see the pool initialization without a preceding authority change, or see a liquidity addition without the market creation. Acting on partial context can be worse than missing the launch.

Track gaps by slot and FEC set. Apply a short reorder window consistent with the decision deadline. Use coding shreds for recovery. Mark state incomplete when required data remains absent. A secondary decoded source or later RPC view can reconcile outcomes, but it cannot retroactively make the first decision sound.

At 5,585 packets per second, packet processing deserves its own capacity plan. The receive thread should batch reads, timestamp early, avoid per-packet logs, and expose kernel and application drops. The firewall should admit inbound UDP from 64.130.40.90 to the chosen port. The 600-second challenge tests reachability before purchase activation, not sustained capacity.

When a shred feed does not fit

A launch desk should use confirmed or parsed data when its rules depend on metadata that appears seconds later, when opportunities remain open for minutes, or when it cannot maintain a decoder across protocol changes. Raw shreds exchange convenience for control over the first observable bytes.

The plan supplies one IP and port, not regional redundancy. Delivery is raw UDP, with no retransmission and no backpressure. A team requiring multiple destinations can purchase and verify them within the product limits, but each receiver still needs its own loss policy and health measurements.

Acceptance requires hostile launch cases

Replay supported launches with shallow reserves, retained authorities, transfer restrictions, unsupported token programs, misleading metadata, repeated pool initialization, and liquidity removed soon after creation. The detector should identify protocol facts while the policy rejects cases outside its declared boundary.

Run shadow orders against canonical state at the first slot they could have landed. Record expected and actual price impact, reason for rejection, fork outcome, and whether address lookup data was available at decision time. Test a missing shred before the initialization and verify that the strategy fails closed.

Enable capital only after the landed-price distribution, failed-fee cost, and policy coverage are known. First-detection rank is not an acceptance metric. Bounded execution and correct rejection are.

The final question is not whether shreds are fast. It is whether earlier launch observation leaves enough time for policy, submission, and uncertain landing while preserving a defensible risk boundary. That remainder, measured across real launches, is the only latency edge worth counting.