NoLimitNodesDocs

Shredstream Troubleshooting

Diagnose provisioning, UDP routing, packet receipt, deshredding, duplicates, gaps, and fork behavior.

Status is error

Check the error in the node's Shredstream delivery panel. Confirm the target is a public IPv4 or assigned 10.250.0.x receiver and the UDP port is between 1 and 65535. Save again after correcting it.

Status is awaiting verification

Capture UDP on the configured port and copy the complete SHRED-FANOUT-VERIFY/1 ... message into the verification field. If it expired, select Resend challenge. A challenge for a previous destination cannot verify its replacement.

Status is active, but no packets arrive

  1. Confirm that the dashboard target matches the host's public IP and port.
  2. Run tcpdump on the host.
  3. Check the cloud security group and host firewall.
  4. Check NAT and container port forwarding.
  5. Confirm that your process listens on 0.0.0.0, not only 127.0.0.1.
sudo tcpdump -n -i any "udp and dst port 20000"sudo ss -lunp | grep 20000

Packets arrive, but the client decodes nothing

Confirm that your receiver accepts the Jito-compatible raw shred format. Record bounded packet samples, then inspect packet size, slot, index, shred type, and deshred errors. Do not log the full feed in production.

You see duplicates or gaps

Duplicates, reordering, and incomplete sets can occur in raw UDP delivery. Deduplicate by protocol identifiers. Use coding shreds for recovery. Track incomplete sets and expire them rather than allowing unbounded memory growth.

A detected transaction never confirms

The transaction may have failed execution or belonged to a losing fork. Raw shreds contain neither execution status nor commitment. Confirm through Yellowstone gRPC or HTTP RPC.

Delivery stopped after a plan change

Shredstream requires an active Stripe-card Ultra plan. Moving off Ultra removes the destination. A scheduled cancellation retains delivery through the paid period and removes it when the cancellation becomes effective.