Why Direct?
Buying and selling remote execution takes more than making a machine reachable. Consumers need to find suitable capacity and judge whether it delivers the work they paid for. Providers need a way to offer that capacity and get paid, even when they have no prior relationship with the consumer.
Conventionally, consumers access these services through a centralized service provider. That company chooses the infrastructure behind its API, handles requests, and bills customers. Consumers depend on its capacity, pricing, and availability.
Direct brings independent providers into a shared market. Its design lets consumers use capacity across those providers, with providers verified by the marketplace, while the work and each payment travel directly between participants.
Reaching the infrastructure directly
The consumer's client and the provider's client establish a peer-to-peer connection. Requests travel over that connection to the infrastructure performing the work, without passing through a shared API gateway.
For providers, this makes their infrastructure accessible through the network without routing every request through a central service provider.
For consumers, removing that intermediate stop gives requests a shorter path. The client also maintains connections to multiple providers, allowing it to handle provider changes and recovery in the background.
Making provider choice meaningful
An advertised offering tells you what a provider sells, but not how well it delivers. Consumers need a way to judge unfamiliar providers without having to test each one themselves or rely solely on what the provider advertises.
Direct operates the verification infrastructure to give consumers an independent assessment of provider quality. This lets Direct apply consistent requirements to providers and take responsibility for the assessments it supplies. Providers earn access to consumers by demonstrating the quality of their service.
Checking a provider does not require carrying its customers' traffic. Direct can verify the service independently while consumers connect straight to the provider. This gives the market a trusted source of provider assessments without adding a central stop to every request.
Running the client on both sides
Running the Direct client on the consumer's machine lets it protect data before sending it and check results before returning them to an application. These protections become part of using the service, without each application having to implement them itself.
The protections depend on the work being performed. A service may support cryptographic checks of returned data or encryption to a verified confidential execution environment. On the provider's side, the local client checks payment authorization before allowing work to reach its infrastructure.
Paying for work as it happens
Payment needs to follow the work, even when different requests go to different providers. Requiring a separate billing arrangement with every operator would make that flexibility difficult to use.
Built-in payment lets consumers use different providers without arranging billing with each one. The client automatically includes payment authorization with requests, giving providers a way to verify that the work is authorized before accepting it.
Providers claim payment on chain in the background, straight from consumers' payment channels. Work can therefore proceed without waiting for funds to move for each request.