Limits

Limits are part of your personalized offer. If your needs grow, contact our support to raise them: @ZoriDev.

When a limit is exceeded

Private TPU Send. Requests above your TPS limit are rejected immediately with HTTP 429 and are not queued. A rejected transaction is not forwarded to any leader, so you can safely resend it after a short pause. The limit is measured over a sliding one-second window.

Streams. A connection above the concurrent connection limit is rejected with gRPC status RESOURCE_EXHAUSTED or WebSocket HTTP 429. Existing connections are not affected.

See Errors for all status codes.

Staying within the TPS limit

• Rate-limit on your side with a token bucket set slightly below your agreed TPS. This keeps bursts from being rejected.
• Do not resend the same transaction to Private TPU Send many times per second. One send per slot (about 400 milliseconds) until it is confirmed or its blockhash expires is enough.
• If you see HTTP 429 regularly, your strategy needs a higher limit. Contact support rather than retrying faster.

Designing for bursts

Stream volume follows network activity and can spike sharply during volatile periods. Private Orderflow can reach several thousand transactions per second in bursts.

• Keep the receive loop minimal: read the message, put it in a queue, return. Decode and evaluate on separate workers.
• Monitor the queue length. A growing queue means your consumer is falling behind.
• Bound the queue. If it fills up, drop the oldest messages first: stale data is worth less than fresh data.
• Reconnect with exponential backoff and jitter. Do not reconnect in a tight loop.