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 address and the UDP port is between 1024 and 65535. Save again after correcting it.

Status is awaiting verification

Capture UDP on the configured port and copy the token from the SHREDCAST-VERIFY <id> <token> packet into the verification field. If the packet did not arrive or the token no longer works, select Resend challenge; every resend issues a new token. A token 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.

Status is paused

The gateway paused the destination because the account is disabled or runs more destinations than it is allowed. Delivery follows what the account currently pays for: the destinations your plan includes, plus the purchased destinations you hold. When the allowance drops below the number of destinations you are running, the newest destinations are paused first, so the address you have been running longest keeps receiving. A paused destination resumes by itself when the allowance returns; you cannot resume it yourself. A scheduled cancellation keeps delivery through the paid period.