Move from a self-run shred listener to shredstream.sh

Migration in one line

$100 and one destination define the target.

Do not move if the self-run listener already has the network position and engineers. It is likely cheaper and faster than paying us. Add shredstream.sh only when the maintained Frankfurt source solves a real operating gap.

shredstream.sh sends raw UDP from Frankfurt. One purchase covers one ip:port destination for 30 days. Payment is USDC or SOL only. There is no free trial and there are no refunds. Each account can hold at most five destinations. The packet source is 64.130.40.90.

The feed was measured at 54.3 Mbps and 5,585 packets per second over a 5.6-hour window on 2026-08-31. The maximum published datagram size is 1,228 bytes. Those numbers define the known operating boundary, but the migration decision still needs a capture from the intended production host.

Define what is moving

A self-run listener may combine network position, intake, forwarding, reconstruction, and monitoring in one deployment. Separate those roles before retiring anything. The paid feed replaces a packet source, not the receiver, decoder, business logic, or confirmation path.

Write the boundary as a sentence before opening a firewall. Name the old source, the new source, the receiver process, the decoder, the filters, the decision engine, and the confirmation path. Mark which components change and which stay fixed.

This step prevents a price migration from becoming an accidental application rewrite. It also exposes hidden dependencies. A service may supply authentication, decoding, filtering, replay, monitoring, or a broader bundle around the shred line. shredstream.sh supplies none of those layers beyond raw UDP delivery to the verified destination.

The honest default is to keep the self-run source. Remove it only when its staffing, network position, or maintenance burden costs more than the advantage it delivers.

Inventory the current behavior

Record the incumbent source address, destination, transport, payload boundary, framing, authentication, reconnect behavior, server-side filters, client-side filters, queue policy, and alert thresholds. Record the current region and the physical location of the receiver.

Do not document only the intended behavior. Capture what the process actually does during a restart, a network flap, a CPU spike, and a malformed packet. Old assumptions often live in wrapper scripts, firewall objects, environment variables, and dashboards rather than in the decoder itself.

Save a short packet capture and the current metrics names. Keep secrets out of the migration document. The goal is a reproducible behavioral baseline, not a copy of production credentials.

The configBefore field on this page is an inventory shape. It is not claimed as vendor copy-paste syntax. Translate the real deployment into that shape, then review every line with the owner of the current receiver.

Build the new path beside the old one

Provision a different UDP port for shredstream.sh when possible. Allow traffic from 64.130.40.90 to that port. Bind the receiver to the intended public interface or to the verified NAT mapping. Confirm the verification datagram before expecting the feed.

A separate port makes attribution unambiguous. If the same process receives both sources, preserve sender address and ingress timestamp before any shared queue. If both feeds enter through a load balancer or packet forwarder, confirm that the original source remains observable.

A destination change can be made three times per day and triggers verification again. Plan the port and public address before using those changes. An expired destination retains its verified address for 90 days, but active packet delivery still depends on the paid term.

Reconnection semantics change

UDP has no connected upstream session in the transport sense. There is no login exchange, subscription acknowledgement, keepalive, stream cursor, or server-side replay in the shredstream.sh wire contract. A receive loop binds a socket and waits for datagrams.

That means a reconnect loop should not wrap the candidate path. Process restart behavior becomes local: reopen the socket, restore buffers, resume counters, and accept new packets. Anything missed while the socket was unavailable stays missed. The sender does not know that the process stopped.

Health checks must follow the new model. A connected flag proves nothing for UDP. Track last packet time, packet rate, source address, kernel drops, parse failures, slot progress, and the gap between receive and decode completion.

Filtering behavior changes

Raw UDP shreds cannot be filtered by a transaction attribute before the transaction has been reconstructed. Program, account, vote, and instruction filters belong after sufficient data shreds and coding shreds have been grouped and entries decoded.

If the incumbent supplied server-side filters, preserve their definitions as application requirements, not as transport settings. Reimplement them after reconstruction and compare output against the incumbent during shadow mode. A filter that appears equivalent can differ on failed transactions, vote handling, incomplete slots, or data seen before confirmation.

If the incumbent already sent raw UDP, keep the current filter path and change only source attribution first. Do not combine a source switch with a new filter engine unless there is no alternative, because a result mismatch will be harder to diagnose.

Payload and framing assumptions

The shredstream.sh maximum packet size is 1,228 bytes. The measured mean was 1,216 bytes. Receive into a buffer that accepts the published maximum and preserve the exact datagram boundary. UDP datagrams are messages, not pieces of a byte stream.

Remove any assumption that every packet has the same length. Rejecting a valid shorter packet because it differs from the mean would turn a measurement into a faulty protocol rule. Also remove any incumbent-specific prefix only after confirming that it is not part of the Solana shred.

Count oversize, undersize, malformed, and unsupported packets separately. Do not let one parse-error total hide whether the issue is socket truncation, framing, or a decoder version mismatch.

A slow consumer loses packets

shredstream.sh has no backpressure. The sender does not wait for the receiver, and the receiver cannot ask for a slower rate. When the application falls behind, queues fill and packets are dropped in the kernel or in the process.

Bound every queue. Record queue age as well as queue depth. A deep queue can preserve coverage while making the signal too late to use. A latency-sensitive path may prefer a controlled drop to processing stale work, but that policy belongs to the application.

Keep receive, reconstruction, decoding, filtering, and business logic separable in metrics. If packet intake remains healthy while decode lag rises, more upstream bandwidth will not solve the problem. If kernel drops rise while CPU is idle, inspect socket and host networking instead.

Ordering, duplicates, and recovery

UDP does not preserve order and does not retransmit. The receiver must use slot, index, shred type, and recovery-set information rather than arrival sequence. It should tolerate duplicates and late packets without treating them as new business events.

Coding shreds can recover some missing data, but recovery is conditional. Track how many gaps close later and how many remain unresolved. A packet-loss percentage without recovery outcome says too little about application coverage.

During migration, match identities across feeds before deduplication. Record the first arrival per source and retain whether another copy arrived later. This supports both latency and coverage analysis without counting duplicates as extra information.

Parallel operation is the default

Run the incumbent and shredstream.sh at the same time. This is the recommended migration, not an optional final check. The candidate firewall, socket, parser path, source labels, metrics, and shadow output already constitute most of the finished integration.

Keep the incumbent as the production decision source at first. Let the candidate produce shadow decisions that cannot submit orders or mutate state. Compare those decisions against the incumbent and against later confirmed outcomes.

A parallel run reveals problems that a synthetic packet cannot: leader variation, burst handling, loss recovery, decoder edge cases, route changes, and the operational effect of restarts. It also gives the rollback plan a working path rather than a document.

Measure equivalent events

Timestamp candidate and incumbent packets as close to ingress as possible with a monotonic clock. Use the same host when comparing network paths. If the paths require different hosts, synchronize clocks and state the remaining error in the result.

Compare only matched shred identities for arrival distributions. Report unmatched identities as coverage. Then compare the later milestone that matters to the strategy, such as a decoded transaction reaching the shadow decision function. Raw arrival can win while slower reconstruction loses the application race.

Report median and tail behavior, not one fastest sample. Split the result by source, leader, and time window when enough data exists. Save the receiver build, host settings, and test interval with the output.

Validate business semantics

A shred is an early proposal, not confirmed state. Slots can be skipped and transactions can fail. The migration must preserve reconciliation against an executed and confirmed source.

Compare how vote transactions, failed transactions, duplicates, incomplete recovery sets, and unsupported shred variants flow through the two paths. A lower event count may be correct filtering or silent loss. A higher count may be duplicates rather than better coverage.

For any strategy that acts on the early signal, run the candidate in shadow and compare what it would have done. Network timing is necessary evidence, but matching business behavior is the acceptance condition.

Write the cutover rule in advance

Define the minimum test duration, acceptable unresolved-gap rate, arrival-time distribution, decoder error rate, queue-age limit, and business-output match before looking at results. The exact thresholds belong to the application and are not product facts supplied by shredstream.sh.

A prewritten rule prevents a favorable sample from becoming the decision. It also makes failure useful: the result points to a receiver, route, payload, or product mismatch that can be investigated.

Treat shredstream.sh as a candidate or redundant source first. Retire the self-run source only after measured results and operating cost support that decision.

Keep rollback small

A source selector, port mapping, or feature flag should control which decoded path can affect production. Cut over without deleting the incumbent configuration. Watch packet rate, slot progress, kernel drops, reconstruction success, decode lag, and business output through the rollback window.

Rollback if the written condition fails. Do not debug an unexplained loss while the candidate remains authoritative. Restore the known path, preserve captures and counters, then diagnose away from the production decision loop.

Ending an incumbent service may be irreversible or governed by notice terms. Treat contract cancellation as a later step than technical cutover.

Commercial differences

shredstream.sh charges $100 for one destination and 30 days. There is no free trial and no refund, so the parallel evaluation occurs inside the paid term. Crypto payment in USDC or SOL must fit the buyer's controls.

One account supports at most five destinations. Do not use the migration to create an unsupported global fanout design. A Tokyo or New York receiver should not move to a Frankfurt-only source without direct evidence, and a distributed system may need a provider with several origins or its own relay layer.

Price is meaningful only after the candidate passes. A lower bill attached to the wrong route, payload boundary, or operating model is not a saving.

Completion checklist

The migration is complete when the destination is verified, packets from 64.130.40.90 are visible, maximum-size datagrams are not truncated, source labels survive ingestion, local drops are monitored, reconstruction works, filters match, business shadow output agrees, and confirmation reconciliation remains intact.

The cutover and rollback controls must both be tested. The incumbent can then be retired according to its contract, unless it remains as a second source for redundancy or continuing measurement.

The result should be boring: one deliberate source change backed by packet evidence. That is the standard worth applying to a self-run listener, to shredstream.sh, and to any future feed.