Routing requests and handling failures
Direct operates RPC infrastructure alongside the independent providers participating in the marketplace. Its distributed capacity gives the service a foundation that does not depend solely on independent operators joining or remaining online. Independent providers expand the available supply and can improve price and response time for particular workloads and locations.
The gateway can maintain connections to providers across that combined supply. When a node slows down or disconnects, it can choose another provider capable of answering the same request.
Direct-operated capacity and network infrastructure
Direct-operated RPC providers serve blockchain requests. They are distinct from the Direct-operated peers responsible for provider discovery and verification. A request sent to a Direct-operated RPC provider is being served by Direct’s node infrastructure; it is not passing through a central gateway to another provider.
Distributed capacity creates alternatives when a node or location becomes unavailable. Independent providers add alternatives outside Direct’s own operations. The value comes from having eligible capacity on other paths, not simply from counting provider identities.
Direct-operated capacity remains subject to request requirements and the consumer’s price ceiling. It does not authorize an automatic purchase above that ceiling or guarantee that every network and optional capability is always available. Supported chains and the live catalogue identify the supply relevant to the requested work.
Build a set of eligible providers
For each request, the gateway identifies the network, method, capabilities, and block it needs. It combines that with the consumer's price ceiling and current provider observations. A provider must pass all of those constraints before it can compete on price or response time.
| Information | Decision it supports |
|---|---|
| Verified offering and capabilities | Can the provider perform this method with these options and state requirements? |
| Reference block and provider observations | Can it serve the selected block on the expected chain? |
| Advertised price and consumer ceiling | Is the purchase authorized at this unit price? |
| Observed response time and consumer preference | Which eligible provider should receive the request? |
The gateway maintains connections to several candidates, rather than discovering a replacement only after a request fails. As prices, capabilities, and observations change, it reassesses which providers to keep available. Eligibility can be withdrawn even while a connection is still open.
Optional response verification needs enough eligible providers to meet its agreement threshold. It does not relax requirements to reach the desired count. Pricing documents the consumer controls.
Preserve the request when changing providers
A retry must preserve explicit block references, filters, capability requirements, and price limits. Under the shared reference-block design, a pinned read keeps the same block through recovery. Switching to a provider's newer state would answer a different question.
If no eligible alternative can complete the work, the gateway returns an error rather than raising the price ceiling, dropping verification, or querying a different block. Eligibility is established through provider checks, not inferred from price or a successful connection.
Recover through an eligible connection
After a transport failure, the gateway determines whether repeating the method is safe. For a repeatable read, it selects another eligible provider and sends the same logical request, including its selected block. An alternative connection being open does not establish that it still meets the request's requirements.
The failed attempt consumes part of the execution deadline. Recovery must fit within the remaining time rather than starting an unlimited new series of attempts.
A provider returning a valid RPC error is different from losing the connection. An execution revert or invalid parameter is an answer about the submitted call; automatically shopping that error among providers would not repair the request.
When automatic recovery stops
A successful retry returns the answer through the same application endpoint, with the added delay of the failed attempt. An error reaches the application if no eligible alternative is available, the deadline is reached, or the request cannot safely be repeated.
An HTTP batch is initially sent to one provider. Its calls must be considered individually before retrying: a failed connection does not establish that none ran, and the presence of a read does not make transaction submissions in the same batch safe to repeat blindly.
Repetition depends on the method
Reads can generally be repeated after a transport failure, but a second execution can still consume resources. Transaction submission requires retaining the original signed bytes and hash: an interrupted response does not establish that submission failed. Node errors about invalid parameters or contract execution are not normally repaired by changing providers.
Subscriptions belong to a live connection and cannot be recovered by replaying the original request as though nothing happened.
For application recovery steps, use Troubleshooting requests. Exact response formats and codes are listed in Errors.