Solana shred feeds for token sniping

6 stages follow market creation

Token sniping attempts to enter a new market soon after creation or first usable liquidity. A raw shred feed can expose its creation transaction during leader broadcast of candidate block bytes. It cannot reveal every order before inclusion, reserve first position, or make an unsafe token safe.

The launch detector receives the complete raw stream from Frankfurt through one address on its UDP socket. A $100 purchase supplies that destination for 30 days, and no standalone feed listing has a smaller price. The desk's real unit cost is each launch candidate surviving local safety checks.

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.

Shred visibility begins during block production

A launch detector has no public Solana pending queue to inspect. Market creation first appears after it enters candidate block data. The response cannot move ahead of that observed transaction through public pending flow; it must reach a leader for a later position, subject to scheduling and 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. Skipped slots, failed creation transactions, and losing forks all remain possible. A later instruction within the block can modify a newly created pool. Keep fork-labeled state and reconcile against confirmed history.

Detect the event, not a ticker string

The fast filter begins from program identity and known instruction discriminators for supported launchpads, automated market makers, and token programs. A symbol or mint address in arbitrary bytes is insufficient. Identify the instruction creating the market, initializing reserves, or enabling trades 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.

Order is preserved through slot, fragment position, and recovery-set position. Completion flags show when enough entry data is present. Leader signature supports authentication. Transaction signature becomes the stable deduplication and reconciliation key without proving 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.

Split launch speed from safety time

The five pre-landing stages add to 2.65 through 23 milliseconds. Landing stays separate because slot timing, admission queue, account locks, priority fees, compute, and transaction validity govern it. Folding that wait into an attractive local number would conceal 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

Keep program-layout discovery, exhaustive address derivation, and message-graph allocation off the hot path. Templates can hold payer, compute-budget instructions, supported accounts, and fixed instruction structure. Detection supplies mint, pool, vaults, amounts, recent blockhash policy, and 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

The launch detector's raw UDP offers no ordering, retransmitted gaps, or backpressure. Missing one shred may expose pool initialization without a preceding authority change, or liquidity without market creation. Acting on partial context can be worse than missing the launch.

Track gaps under slot-specific FEC-set keys. Apply a short reorder window consistent with the decision deadline and use coding shreds for recovery. Mark state incomplete when required data remains absent. Later canonical commitment can reconcile outcomes, but it cannot retroactively make the first decision sound.

Packet processing deserves its own capacity plan. The receive thread should batch reads, timestamp early, avoid per-packet logs, and export drop counters from both kernel and application. At the launch host, only the chosen UDP socket may admit documented address 203.23.178.228. Launch verification tests pre-activation reachability for 600 seconds, not sustained capacity.

Build for first-observation decisions

Launch rules extract the most timing value from raw shreds when they act on on-chain data in the first observable bytes. Preload identity and metadata policy, version-gate supported decoders, and keep the decision path local and bounded.

The plan supplies one Frankfurt-origin destination at a configured IP and port. Its raw UDP packets arrive without sequence guarantees, gap repair, backpressure, or regional redundancy. A team can purchase and verify multiple destinations within the product limits, and each receiver 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.

For each shadow order, compare canonical state at the first slot available for landing. Record expected and actual price impact, rejection reason, fork outcome, and availability of address lookup data at decision time. Test a missing pre-initialization shred and verify that 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.