Qualifying providers
Direct RPC combines Direct-operated node infrastructure with independent providers. A common set of requirements makes that combined supply usable through one API: applications can change providers without having to discover each node’s limitations themselves. Only offerings that meet the baseline enter the set consumers can choose from.
The same requirements for every provider
Qualification checks the service exposed through the provider's Direct client, not just whether its node accepts a connection.
| Requirement | What must hold |
|---|---|
| Network identity | The node serves the advertised chain and network |
| Standard methods | The baseline API is available with the documented parameters and response behavior |
| Block-hash state reads | EIP-1898 selectors and requireCanonical work for the covered state methods; unsupported nodes do not qualify |
| Recent chain history | Blocks, transactions, receipts, logs, and applicable uncle methods cover Direct’s required recent window |
| Recent state | State is available at the network head and its 128 preceding blocks |
| Public limits | The service honors Direct’s input limits and complete-result rules, including adapted log queries; the gateway enforces its own response ceiling and waiting deadline |
| Health and integrity | Responses meet service checks and the node remains synchronized |
The exact method set is documented in Supported methods, alongside its method limits. The baseline applies to Direct-operated and independent RPC providers alike; price does not compensate for a failed check. Recent coverage is measured against the network head so a stale node cannot qualify against its own outdated view.
Establishing which requests a provider can serve
The provider's client detects support, and Direct-operated peers verify it through service checks. Provider capabilities defines archive state, full chain history, optional methods, and tracing groups, including how historical requests combine them.
Historical uncle coverage
On applicable networks, uncle-query coverage back to genesis is part of the full chain history bundle, independent of archive-state support. Checks sample known historical blocks containing uncles and verify both their counts and returned uncle data. They also test blocks with no uncles and compare number- and hash-based queries.
Recent Ethereum blocks alone cannot establish this coverage because post-Merge blocks contain no uncles. Missing historical data must not pass qualification by returning zero or null as though the known uncle did not exist. Sampling supplies evidence of the full-history requirement, rather than exhaustively checking every block.
Verify the advertised service
The provider's client tests its upstream before announcing an offering. Direct-operated peers then exercise the advertised RPC service and compare observations with the requirements. A successful local test establishes reachability and detected support; it does not independently qualify the offering for consumer traffic.
Checks need to examine both successful execution and the meaning of returned data. A historical-state test, for example, must distinguish a genuine answer at the requested block from an upstream that ignores the block parameter. Capability checks must use the specific methods and options being advertised.
These observations establish the eligible supply consumers discover. Provider discovery and verification explains the infrastructure checks and sampled live traffic that support that assessment. Probes remain evidence of support, not an exhaustive test of every possible query.
Checking tracing support
Qualification tests every method and output in each advertised tracing group, including nested calls, meaningful state changes, options, and the recent-window boundary. Historical combinations are checked on known older executions. An accepted but ignored tracer option does not pass.
The gateway can stop waiting at its own deadline, but cannot establish an upstream timeout configuration through probes. Repeated early failures on representative work affect eligibility; a single unusually expensive request timing out does not by itself disqualify a capability.
Accommodating upstream log limits
The provider's Direct client adapts smaller native log ranges without changing the public service. For example, a node limited to 2,000 blocks can serve a 10,000-block Direct request through five non-overlapping upstream queries. The client preserves the filters and combines the results in block, transaction, and log order. Internal splitting remains one consumer request.
A recognized range-limit rejection can trigger smaller subqueries; unrelated failures are not treated as range-limit errors. Moving block tags are resolved before splitting. If chain changes invalidate the assembled view, the client retries within the request deadline or returns an error. It does not return a successful partial result.
Adaptation cannot supply pruned state or unsupported methods. All parts must complete within Direct's execution and response-size limits. Limits defines the consumer-facing range; Run a provider covers upstream configuration.
Maintaining eligibility as nodes change
Qualification is not a permanent certificate. Direct repeats checks as nodes change configuration, fall behind, or lose access to data. Baseline failures remove an offering from selection; loss of an optional capability excludes it from requests needing that capability. Recovery requires new evidence of support.
A consumer also excludes a provider from a particular request if it cannot serve the selected reference block. That immediate decision differs from declaring a sustained service failure. Keeping data consistent explains the distinction.
To configure and troubleshoot a node, use Run a provider and Checking your provider's status.