Provider capabilities
Direct checks what each provider can serve before routing requests to it. Capabilities describe additional history, methods, or tracing formats beyond the required recent RPC service. The gateway derives the requirements from the request; applications do not need to select capability flags.
Recent coverage
Every provider serves state at the network head and its 128 preceding blocks. Covered state methods must support EIP-1898 block-hash selectors and requireCanonical, allowing the gateway to preserve a selected block through retries. See Keeping data consistent.
Historical data
These are independent capabilities, not levels in a retention enum:
- Archive state: balances, storage, code, and execution state are available back to genesis.
- Full chain history: blocks, transactions, receipts, logs, fee history, and applicable uncle queries are available back to genesis, including the indexes needed for supported hash-based lookups.
The full-history flag is one Direct-defined bundle. It is announced only after checks exercise all included method families; individual storage or indexing features are not advertised as separate history flags. Either capability can qualify without the other. Historical proofs and tracing remain separately checked.
Checks sample known non-empty data across different historical periods and compare hash- and number-based lookups, receipt sets, log results, and transaction indexes. State probes use known historical values to distinguish a genuine answer from an ignored block selector. Probes continue over time; a successful genesis query does not establish complete coverage.
Matching historical requests
An old balance or contract call requires archive state. An old block, transaction, receipt, or log query requires full chain history. Requests can require both, as with replaying an old transaction. State retention does not imply historical proof support.
Hash-based requests use the block's age when known. When its age cannot be established, the gateway starts with a full-history provider; transaction-hash lookups follow the same rule. Missing data from a provider without the required coverage is not accepted as proof that the data does not exist.
Historical proofs
Historical eth_getProof support is checked independently of archive state. A node can retain account state without the historical trie data needed to construct a proof. Qualification exercises known old account and storage proofs; successful old balance queries alone do not qualify it.
Optional receipt and access-list capabilities
A provider can qualify for ordinary RPC service without supporting eth_getBlockReceipts or eth_createAccessList. The client detects each independently, and Direct-operated checks verify it before the capability is announced. Neither implies the other or grants a tracing capability.
Block-receipt checks compare the returned receipt set with the target block's transactions and individual receipts, including ordering, transaction identities, and an empty block. They also exercise Direct's whole-block limits. Native bulk support or equivalent client-side assembly can qualify if it preserves the response and budgets; providers also advertising full chain history must pass these checks on older blocks.
Access-list checks exercise the required parameters and selectors against known contract execution, verifying that the requested block is honored and the generated result is consistent with that execution. Qualification covers Direct's simulation and output rules, not every extension exposed by an upstream client. Archive providers advertising access-list generation are also checked on older execution contexts.
Network-specific methods
The applicable API is defined per network. An EVM-compatible chain is not assumed to expose every Ethereum extension. eth_blobBaseFee, for example, is advertised only where the network defines the corresponding blob-fee behavior and provider support is verified. An unrelated network's providers are not disqualified for lacking it.
Checks validate semantics against that network's rules, not just whether the method name is accepted. Network-specific support and the two optional capabilities above are additional to the ordinary block-count, transaction-position, and network-identity methods in the baseline.
Tracing capability groups
Tracing capabilities describe a complete set of methods and outputs, rather than an enabled debug or trace namespace. Each group is all-or-nothing: a provider that supports only part of the group does not advertise that capability. A failure in one group does not disqualify unrelated capabilities or ordinary RPC access.
| Group | Required methods | Required output |
|---|---|---|
| Debug call tracing | debug_traceTransaction, debug_traceBlockByNumber, debug_traceBlockByHash, debug_traceCall | callTracer, including onlyTopCall |
| Debug state tracing | The same four debug methods | prestateTracer, including diffMode |
| Trace calls and replay | trace_transaction, trace_get, trace_block, trace_replayTransaction, trace_replayBlockTransactions, trace_call, trace_callMany, trace_rawTransaction | Call traces; replay and simulation methods accept the trace output type |
| Trace state differences | trace_replayTransaction, trace_replayBlockTransactions, trace_call, trace_callMany, trace_rawTransaction | stateDiff, including requests that also ask for trace when both groups are supported |
| Trace search | trace_filter | Filtered call traces under Direct's range, pagination, and result limits |
Opcode tracing (vmTrace and debug's default opcode logger), arbitrary JavaScript tracers, and administrative debug methods are outside these groups. An unsupported output is rejected, not replaced with another format. Omitting the debug tracer does not implicitly select callTracer.
Method pages define supported formats and input limits.
Recent versus historical tracing
Tracing support and historical coverage are separate properties. A node can trace recent transactions without retaining state back to genesis. To replay a transaction, it needs the state before execution and may need to execute earlier transactions in the same block. To trace a block, it needs the state needed to execute that block. Simulation likewise needs state at the requested execution point. See the Geth tracing reference.
The consumer's client identifies the required tracing group from the method and options, then checks the target block or range. Within the recent window, only the tracing group is required. Older simulations additionally require archive state; historical transaction or block replay also requires full chain history. Transaction-hash methods require resolving the transaction's containing block; a range spanning recent and older blocks requires archive support.
This is a combination of existing capabilities, not an additional “archive tracing” flag. Qualification tests historical simulations when archive state and a tracing group are advertised together, and historical replay when full chain history is also advertised. Trace lookup and search can instead use verified historical trace indexes. Qualification tests the combination so a node cannot claim it based only on successful old balance reads and recent transaction traces.
The recent window includes any earlier state needed to execute its oldest permitted block. Trace lookup and search may use stored trace indexes instead of replay; those indexes must cover the advertised history as well. Direct specifies the results available, rather than requiring a particular storage strategy. The Erigon trace API distinguishes replay and simulation from lookup and filtering.
What qualification checks
The provider's client tests every method and required output in the group. Direct-operated checks independently verify that the offered service satisfies the same contract. Checks use known executions with nested calls and state changes to distinguish a genuine supported output from an accepted-but-ignored tracer option.
Checks cover block selection, output structure and content, required options, and recent-window boundaries. Historical claims are additionally sampled across older blocks. A node that traces a recent transaction successfully has not thereby demonstrated historical coverage.
Qualification exercises the input limits and complete-output behavior documented on each method page. The gateway enforces its own waiting deadline; checks cannot prove an upstream timeout setting. Representative workloads and ongoing observations establish whether the provider can serve the advertised tracing group reliably.
An individual expensive trace reaching the public deadline is not automatically a capability failure. Repeated inability to serve representative workloads within the contract, incorrect outputs, or a lower upstream limit that the client cannot accommodate can make the group ineligible. When archive and tracing are advertised together, historical failures affect eligibility for requests needing that combination until recovery is verified.
Probe selection and frequency remain part of the qualification policy; sampled checks are evidence of coverage, not an exhaustive proof for every block.