Endpoint-free RPC

Endpoint-free RPC lets the Gateway return shared cached results for supported request shapes before accessing an Endpoint. A matching read can return through the same Access Point without an Endpoint on your Gateway.

In brief

Endpoint-free RPC covers the exact methods and parameter forms listed on this page.
A hit returns the shared result without an upstream call. A miss continues through the configured Route to an Endpoint.
Authentication, rate limits, and Usage accounting apply to both hits and misses.

Pair Endpoint-free RPC with an Endpoint-backed Route for stable coverage across additional data, methods, and parameter forms.

Free to use and Endpoint-free RPC

Term	Meaning
Free to use	Describes the RPC Gateway service. Authentication, rate limits, and Usage accounting still apply.
Endpoint-free RPC	Supported request shapes check the shared cache before Endpoint selection.
Cache miss	The request continues through the configured Route to an Endpoint.
Endpoint-backed Route	Provides stable coverage for writes, additional methods, parameter variants, and cache misses.

See Free RPC Gateway for the service-level overview.

Request flow

The Gateway validates the App API Key, Host, chain, and network.
The Gateway classifies the method and parameters against the Endpoint-free RPC policy.
A cache hit returns the result immediately.
On a miss, the Gateway continues through its Route to a configured Endpoint.

Authentication, rate limits, and Usage accounting apply to both paths.

Request flow: authentication and rate limiting precede the Endpoint-free RPC policy check; a cache hit returns the shared result, while a miss forwards through the Route to an Endpoint.

How concurrent cache misses are handled

Concurrent requests for the same eligible cache key are combined while one cache load is in flight. Within a worker, waiting requests reuse the local flight result once it is published. Across workers, distributed flight contention uses a bounded wait; if no result is published within that interval, a request can continue without a cache result.

Supported methods and parameters

Use these exact request forms for Endpoint-free RPC. Configure an Endpoint-backed Route for additional reads, writes, and parameter variants.

Protocol	Method	Supported `params`
EVM	`eth_blockNumber`	omitted or `[]`
EVM	`eth_getBlockByNumber`	`["latest", false]` or `["<explicit hexadecimal block height>", false]`
EVM	`debug_traceBlockByNumber`	`["<explicit hexadecimal block height>", {"tracer":"callTracer","tracerConfig":{"withLog":true}}]`
Solana	`getSlot`	omitted, `[]`, or `[{"commitment":"finalized"}]`
Solana	`getLatestBlockhash`	omitted, `[]`, or `[{"commitment":"finalized"}]`
Solana	`getBlock`	`[<slot>, {"encoding":"json","commitment":"finalized","rewards":false,"maxSupportedTransactionVersion":0}]`
Bitcoin / Litecoin	`getblockchaininfo`	omitted or `[]`
Bitcoin / Litecoin	`getblockhash`	`[<non-negative block height>]`
Bitcoin / Litecoin	`getblock`	`["<block_hash>", 3]`
TRON JSON-RPC	`eth_blockNumber`	omitted or `[]`

The EVM scope covers Ethereum, Polygon, BNB Smart Chain, Arbitrum, Optimism, and Base. For eth_getBlockByNumber, Endpoint-free RPC accepts only ["latest", false] or an explicit hexadecimal height with false. ["latest", true], the safe and finalized tags, decimal heights, and all other variants require an Endpoint-backed Route. The latest form uses a short-lived shared cache. During refresh fallback, it may return a stale cached value, so do not treat it as strongly consistent. debug_traceBlockByNumber still requires an explicit hexadecimal height.

For Solana getBlock, encoding may be json or jsonParsed; commitment must be finalized, rewards must be false, and the supported maximum transaction version is 0. transactionDetails may be omitted or set to full.

The TRON native HTTP API supports these Endpoint-free RPC request shapes:

Path	Supported request
`POST /wallet/getnodeinfo`	No query parameters and no request body
`POST /wallet/getblockbynum`	No query parameters and a JSON body containing only `{"num":<non-negative integer>,"visible":true}`

Examples

This Ethereum Mainnet request uses an Endpoint-free RPC request shape. A current cache entry returns the latest cached height:


curl '<ethereum_access_point>' \
  -H 'Authorization: Bearer <app_api_key>' \
  -H 'Content-Type: application/json' \
  --data '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'

Request the latest block without full transaction objects:


curl '<ethereum_access_point>' \
  -H 'Authorization: Bearer <app_api_key>' \
  -H 'Content-Type: application/json' \
  --data '{"jsonrpc":"2.0","id":2,"method":"eth_getBlockByNumber","params":["latest",false]}'

Production guidance

Configure an Endpoint-backed Route for stable coverage across block heights, slots, block hashes, and cache refreshes.
Use upstream-backed reads and chain-specific confirmation rules for pending state, mempool state, newly submitted transactions, and decisions that require irreversible confirmation.
Configure an Endpoint for stable coverage, writes, and additional methods.
Use JSON-RPC requests with an id when the application needs a response body and cache-result visibility.
Endpoint-free RPC covers single JSON-RPC HTTP requests and the two exact TRON native HTTP API request shapes above.
Use the complete RPC Method Catalog in the dashboard for Route configuration and this page for the Endpoint-free RPC request set.

Use Errors and recovery as the reference for Gateway error codes and recovery actions.

TRON native HTTP API Errors and recovery JSON-RPC Routing and reliability