Tron limits

Tron requests on Triport are metered per second in two buckets: tron_read_rpc for ordinary reads and tron_read_rpc_heavy for log scans, full blocks and contract execution, which get a much smaller budget. This page lists the per-tier budgets, which calls are heavy, the eth_getLogs range cap, and how a 429 tells you which budget you hit.

Endpoint and plans: Tron RPC endpoint.

Budgets per tier

Values are sustained RPS / short burst capacity. The included 2× burst buffer absorbs brief traffic spikes at no extra cost and refills at the sustained rate. There is no quota on the number of bursts. Size ongoing traffic to sustained RPS; unlimited categories have no numeric burst ceiling. See Burst capacity.

CategoryFreeBasicProBusinessEnterprise
tron_read_rpc15 / 3020 / 40100 / 200250 / 500unlimited
tron_read_rpc_heavy2 / 45 / 1020 / 4080 / 160unlimited

Both rows are unmeasured operational defaults, inherited from the Polygon budgets of the same tier until a dedicated Tron capacity test. They are throttles on your key, not a statement about upstream capacity. An Enterprise "unlimited" entry means no configured tier cap, not unlimited physical capacity. The Free column is the 7-day trial: EU region only, one API key.

There is no daily or monthly request quota: the only limit to plan around is the per-second budget of each category.

Which calls are heavy

Three of the 24 published calls are heavy. Everything else, on both the EVM JSON-RPC endpoint and the native wallet HTTP endpoint, is tron_read_rpc.

On Pro, for example, a contract read through triggerconstantcontract has a budget of 20 per second, while the same key can make 100 getaccount calls per second. If you only need the current state of a contract's storage slot, eth_getStorageAt is the cheaper bucket.

eth_getLogs range

One eth_getLogs request may span at most 100 blocks. A wider range is rejected with -32602, so split larger scans into adjacent 100-block windows and pace them against the heavy budget: on Basic that is 5 windows per second, or 500 blocks per second of scanning.

How requests are counted

  • A JSON-RPC batch is charged one request per element, not one per HTTP call: a batch of 10 eth_getLogs windows spends 10 of the heavy budget.
  • Historical state is not supported for eth_call, eth_getBalance, eth_getCode and eth_getStorageAt; send latest. See Tron errors.

When you hit a limit

Going over sustained + burst returns HTTP 429 with "error": "rate_limited". The body names the budget you hit — category (for example tron_read_rpc_heavy), current_tier, limit_rps and burst_capacity — and the Retry-After header gives the wait in seconds, never less than 1. Wait that long, then retry with exponential backoff and jitter. A 429 is backpressure, not a sign that the method is unavailable. A method above your tier is a different answer: 403 tier_insufficient.

See Rate Limits and Tiers for the shared model, response headers and code samples.