Jito-Compatible Client
cubestech sends raw shreds in a format compatible with the Jito proxy and client receiving path. Keep your deshredder and strategy pipeline. Change the upstream destination provisioning.
Map your configuration
| Existing concern | cubestech setting |
|---|---|
| Receiver listen address | 0.0.0.0:<UDP_PORT> |
| Delivery target | Your public IPv4:UDP_PORT |
| Upstream authentication | None inside the UDP packet |
| Network | Solana mainnet |
| Provisioning | Active node details, UDP challenge verified |
Run the receiver
Bind your Jito-compatible receiver to the local UDP port. If it runs behind network address translation, forward the public port to that local socket.
Start the receiver before saving the destination. Copy the complete
SHREDCAST-VERIFY <destination id> <token> challenge it receives and paste it into the
Shredstream panel to activate delivery.
# Confirm the process is listening.
sudo ss -lunp | grep 20000
# Confirm packets reach the host.
sudo tcpdump -n -i any "udp and dst port 20000"Validate before cutover
Run the existing and replacement feeds in parallel. Compare:
- Slots and shred indexes observed
- Complete and incomplete erasure sets
- Reconstructed entries and transactions
- Duplicate and decode counts
- Receiver CPU, memory, queue depth, and packet drops
Tag each upstream before shared processing so deduplication does not hide a feed-specific gap.
See the official Jito proxy repository for the receiver implementation. Jito's official service documentation announces a September 5, 2026 shutdown of its hosted ShredStream service.