Routing and reliability
The Gateway checks Accelerator first, then a Route connects the public entry point to one or more Endpoints. Endpoint selection, failover, and fallback retries apply only when the Route has usable targets.
Routing strategies
Priority failover
Uses Endpoints in configured order. It tries the next Endpoint only when the current target is filtered, blocked by its Circuit, or encounters a retryable failure.
Use this when you have an explicit primary and ordered backups. Health alone does not unconditionally change priority.
Load balance
Samples candidates by weight, then considers observed health and latency. Weights are relative traffic preferences, not fixed percentages.
Use this to share traffic across equivalent upstreams. A single remaining candidate can still be selected, so load balancing is not an availability guarantee.
Candidate filtering
A Route can filter Endpoints by:
- enabled state;
- minimum trust level;
- observed latency over the Route limit;
- a Circuit temporarily blocking attempts;
- matching chain, network, and protocol.
An Endpoint with no latency observation is not excluded merely because its latency is unknown.
Retry policies
safe_only and idempotent describe retryable failure types. The Gateway does not infer idempotency from a method name.
| Policy | Behavior |
|---|---|
safe_only | Fails over only for connection, configuration, and selected upstream rejection cases that do not clearly produce a business result |
idempotent | Also permits bounded retries for timeouts, interrupted responses, and selected 4xx/5xx responses |
Write calls should normally use safe_only. Use idempotent only when duplicate submission is safe for the application. A valid upstream JSON-RPC application error is final and does not trigger failover.
Attempts are bounded by both the Route and deployment limits. Multiple Endpoints do not mean every call will try every target.
Rate limits
JSON-RPC and TRON HTTP API have independent capacity and may be limited by global, IP, Account, and App policies. Production RPS values are controlled by platform policy and are not fixed by this documentation.
- JSON-RPC: HTTP
200, error code-32029,data.retry_after_ms, and aRetry-AfterHeader. - TRON HTTP API: HTTP
429and aRetry-AfterHeader.
Retry with exponential backoff, random jitter, and a bounded attempt count.
Accelerator and fallback
Accelerator covers only its explicit methods and parameters. A hit bypasses Endpoint selection; a miss proceeds to the Route. Without an Endpoint, a miss returns -32004 and never falls back to an unknown public node.
Cached results may lag briefly, and not every historical height, slot, or hash is guaranteed to exist. Validate time-sensitive data according to chain semantics rather than relying on a guaranteed cache hit, fill, or refresh. The TRON HTTP API does not use Accelerator.