Provider discovery and verification
This chapter explains how service checks establish whether a provider delivers what it advertises, and how the results help consumers choose providers over time.
What a service check does
A service implementation defines integrity checks to verify that a provider delivers the work and capabilities it advertises. Each check specifies one or more requests and rules for validating the returned data, using cryptographic verification where supported, comparison with reference data, or other service-specific tests.
Running integrity checks also reveals whether requests succeed and how quickly responses arrive. Direct can therefore track three separate aspects of each provider's service: health, integrity, and performance.
| Aspect | What is assessed |
|---|---|
| Health | Whether requests complete successfully, fail, or time out |
| Integrity | Whether responses meet the service's correctness requirements and demonstrate the advertised capabilities |
| Performance | Request latency and, for streamed output, the delay before output begins and its delivery rate |
A provider that answers quickly can still return incorrect data. Another may return correct data but take too long. Separate observations let the client distinguish those cases when choosing providers.
Validating results in practice
Suppose a blockchain RPC provider offers historical Ethereum data. An integrity check asks for account balances at old blocks and compares each answer with the known balance at that block.
Comparing answers works here because the requested balances have known values. Other services may need different checks. For example, AI inference can produce different answers to the same prompt, so matching text alone cannot establish integrity. Each service implementation defines validation suited to the data it delivers and what can meaningfully be verified about that data.
How Direct performs the checks
Direct-operated peers connect to providers and ask them to perform the work defined by the service checks. To the provider, these look like requests from an ordinary consumer: the connection does not announce that it is being used to assess the service. This helps Direct measure how providers treat consumer traffic, rather than how they respond to an identified monitor.
The monitoring peers frequently rotate the public-key identities used for these connections, making it harder for providers to recognize returning monitors and reserve better service for them. Checks are repeated regularly, so the observations reflect how the service behaves over time.
Direct-operated peers are also widely distributed around the world. They reach providers from different locations and network paths, allowing Direct to observe regional differences in service quality instead of relying on measurements from one location.
Qualifying and monitoring providers
When a provider submits an offering, Direct-operated peers begin checking its service. They repeat the required checks multiple times to verify that the provider consistently delivers what it advertises. Only after this initial verification do they add the offering to the provider directory and announce it to consumers seeking compatible providers.
Continued checks keep the directory up to date. If the provider stops answering, returns incorrect data, or slows down under load, new observations give consumers a basis for changing their selection.
Verifying samples from live traffic
Direct also checks samples of work delivered to ordinary consumers. A sampling rate in the signed network definition determines how frequently consumer clients submit completed requests and responses for inspection.
To make these samples verifiable, providers include a signature with every response, binding the request identifier, request hash, and response hash to the offering served. After receiving the full response, the consumer's client randomly selects samples and submits them along with this signature to Direct-operated peers in the background.
Direct-operated peers can then verify the signature against the provider's public key and check that the request identifier, offering, and hashes match the submitted data. They then assess the response using the service implementation's verification rules, allowing real consumer traffic to be checked in the background without delaying delivery or interrupting the application.
Service implementations can exclude requests executed within a trusted execution environment from such sampling to preserve data confidentiality. Attestation already lets the client verify the integrity of the provider's environment before sending requests to it. In these cases, confidentiality therefore takes priority over additional inspection, and plaintext requests and responses will not be forwarded to Direct.
Discovering suitable providers
Consumers need to know both what a provider offers and how well it delivers. They receive this information from Direct-operated peers through the provider directory, which includes the advertised offerings and the results of Direct's verification checks.
The client uses this information to narrow the candidates before comparing price and performance:
- Require passing integrity checks. Providers whose integrity does not meet the service's requirements are excluded, regardless of price or speed.
- Match the required capabilities. The service implementation identifies what the request needs and filters for compatible offerings. A historical blockchain RPC query, for example, requires access to data at the requested block.
- Prefer healthy providers. If any remaining providers are healthy, only those are considered. If none are healthy, the client can attempt one of the others.
- Rank by performance and price. The client scores the candidates according to the consumer's preferences, favoring lower latency, lower cost, or a balance of both.
To keep provider selection up to date, the client continuously receives fresh verification results from Direct-operated peers and reassesses the available providers.
Learning from live usage
While capability and integrity verification remain Direct's responsibility, the client can refine its view of provider health and performance through its own requests. This adds a picture of how providers behave from the consumer's location and under its particular workload.
The client records successful requests, errors, interrupted responses, and delivery times. It uses this local history alongside Direct's observations when selecting providers, gradually learning which serve its needs most reliably.