How it works
This chapter follows the journey of a request from an application to a provider and back, showing how the Direct clients on both sides work together. It begins with joining the network, then covers provider selection, connections, and payment.
Finding Direct-operated peers
When the Direct client starts, it finds and connects to Direct-operated peers through the Holepunch stack. A trust anchor embedded in each client release then lets it cryptographically verify that those peers are authorized by Direct before trusting the connections.
Providers announce their offerings, such as access to a particular blockchain or AI model, to Direct-operated peers. These peers maintain a provider directory describing what providers offer and what they charge, alongside Direct's observations of their health, integrity, and performance. Consumers use this information to find suitable providers.
Direct-operated peers are distributed globally and are independently reachable. If a peer is unavailable, the Direct client can connect to others.
Finding and connecting to providers
The consumer's application sends requests to the local API exposed by the Direct client, just as it would to a hosted API. The client then determines which providers can handle that request - for example, a blockchain RPC call to Ethereum needs a provider offering access to that network.
When the first request for an offering arrives, the client asks Direct-operated peers for matching entries from the provider directory. It then scores eligible providers using their prices and observed service quality, and opens encrypted connections to several suitable candidates using the connection information in the directory.
As new provider information arrives, the client updates its pool of open connections to keep the providers it considers best suited ready to serve requests. It handles these choices in the background while the application continues making ordinary API calls to the same local endpoint.
Performing the work
Once a connection has been selected, the local Direct clients exchange requests and responses directly, forwarding application requests to the provider’s underlying infrastructure to perform the work.
Because data flows through the local clients, service implementations can add protections before requests leave the consumer’s machine or responses reach an application. These protections can include end-to-end encryption of data sent to a trusted execution environment or verifying responses before returning them to the application.
Responses can arrive all at once or stream back as the provider produces them. In either case, the connection remains open afterward, ready to carry subsequent requests without repeating connection setup.
Authorizing and paying for work
Direct's payment flow is built around the x402 protocol. For each request, the consumer authorizes payment with a signed voucher, which the provider can cryptographically verify before starting the work.
After performing the work, the provider signs a record of execution together with the voucher, stating that the request was fulfilled and payment is due. The signature authenticates the provider's claim; service checks and supported local validation assess the correctness of the result.
Providers later claim these payments on chain, in batches, and the contract deducts Direct's protocol fee in the same step. Requests can therefore proceed without waiting for each payment to settle.
The payments chapter explains funding and settlement in more detail.
The following chapters explore the design in more detail, starting with the local Direct client.