Troubleshooting

Cannot connect

• Check that you use the endpoint for your region and the correct protocol (gRPC or WebSocket).
• Check that your credentials are valid and passed as described in Authentication.
• Check that outbound traffic to the endpoint is allowed by your firewall or cloud security group.
• Look up the status code or close code in Errors.

Connection drops

• Configure keepalive: gRPC keepalive pings or WebSocket ping/pong frames.
• Reconnect automatically with exponential backoff and jitter.
• Log the close code or status for each disconnect. Support needs it to investigate.

Higher latency than expected

• Confirm that your server is in the same region as the endpoint. Measure the round-trip time with ping or mtr.
• Check clock synchronization (NTP or PTP) before relying on timestamp-based measurements.
• Check CPU saturation and garbage-collection pauses on the consumer. Move decoding off the receive loop.

Transactions do not land (Private TPU Send)

• Expired blockhash. A recent blockhash is valid for about 150 slots, roughly one minute. Fetch a fresh blockhash shortly before signing.
• Compute budget. Set a compute unit limit and a priority fee with the Compute Budget program. Transactions that run out of compute units fail.
• Errors in the transaction. Simulate the transaction through your RPC (simulateTransaction) before sending it.
• Account contention. Transactions that write to heavily used accounts compete for the same locks and may be delayed or dropped.
• Check the result. Track signatures through your RPC with getSignatureStatuses or a signatureSubscribe WebSocket subscription.
• Rebroadcast safely. Resending the same signed transaction until it is confirmed or its blockhash expires is safe. The network never executes the same signature twice.

No transactions arrive (Private Orderflow over gRPC)

• Check that your server is reachable on the address you sent to our support, and that your firewall allows incoming connections to it.
• Check that your auth service accepts our relayer's identity key and that BlockEngineRelayer calls with a valid access token are accepted.
• Check your accounts and programs of interest. If the lists are empty or do not match your strategy, the relayer has nothing to forward to you.
• Check that your server sends heartbeats back on the StartExpiringPacketStream stream.
• With several servers registered, each one receives only part of the stream. Compare the total across all of them.
• If volume drops under load, your server may be falling behind: our relayer drops messages a slow server cannot take. Move processing off the stream handler.
• Expect lower volume between the leader slots of validators in your stake pool. See Coverage and stake pool.

Duplicate messages (Private Orderflow)

The same transaction can be observed more than once, for example when the sender retries it or when it reaches more than one validator in our network. Deduplicate by transaction signature. See Private Orderflow.

Missing or out-of-order data (Shreds)

By default you receive entries that we have already reconstructed from shreds, in the order the leader recorded them. A slot arrives in several messages, and after a reconnect part of a slot can be missing: confirm outcomes through your RPC.

If your offer includes raw shreds, they can arrive out of order or be duplicated, and some may be missing. Group them by slot and FEC set and use the coding shreds to recover missing data shreds. See Raw shreds.

Still stuck?

Contact our support on Telegram: @ZoriDev. Include:

• the time of the issue in UTC
• the product and region
• the exact error message or close code
• the public IP address of your server