Payments
A provider needs authorization before serving work, but moving money for every request would add a separate exchange to the service path. Direct's x402-based design separates these steps: signed vouchers authorize usage locally, and payment settles later in batches.
Consumers pay from their own funds on Base. Direct never holds them or pays providers: providers claim payment on chain, and a contract deducts Direct's fee in the same step.
Authorizing work with vouchers
The consumer's client supplies a signed voucher authorizing payment for work. The signature comes from a payment key of the consumer's device, which holds no funds. If the consumer's account freezes that device, providers refuse its vouchers. Before serving work, the provider checks the signature, the payment relationship it refers to, and the amount available for usage. A voucher issued for one relationship cannot simply be presented as authorization to charge another consumer or provider.
Authorization is cumulative. If a newer voucher raises a limit from 10 to 20 units, it permits 20 in total, rather than 20 more. The client advances that limit as usage continues, and the provider only serves work within the authorization it has received.
The service determines how usage is counted and how authorization accompanies its requests. A blockchain RPC service counts billable requests; inference measures tokens. The voucher supplies the spending limit while the service measures the work against it.
After performing work, the provider signs a record of execution together with the voucher, stating that the request was fulfilled and payment is due. This authenticates the provider's claim. Provider verification and supported local checks assess the quality and correctness of the work separately.
Funding a payment channel
Each device pays each provider through an x402 payment channel backed by USDC in escrow on Base, funded from the consumer's own balance. Signed vouchers authorize claims against its available funds.
The provider can verify that authorization locally. It does not need to wait for a new on-chain transaction before serving each request. Settlement later claims the authorized payment from the channel, with Direct's protocol fee deducted.
Funds in a channel stay the consumer's: what the provider has not claimed comes back when the channel closes. The consumer's ability to authorize further usage depends on the channel's available funding.
Claiming payment
The provider claims what its vouchers cover in batches, across channels and consumers, in one on-chain transaction. The contract pays the provider's share and keeps Direct's protocol fee in the same step. Each claim tracks the amount already paid for each payment relationship, so updated authorization does not create a second claim on usage already settled.
For example, suppose a valid claim covers a cumulative payment of 10 USDC and has been settled. A later claim for the same relationship brings the cumulative amount to 15 USDC. Only the additional 5 USDC remains payable. Submitting either claim again does not create another payment for the same usage. The voucher's authorization limit bounds the claim; it is not an extra charge added at each settlement.
When further work cannot be authorized
The provider stops serving additional work when valid authorization runs out. Without a valid voucher and enough funds in the channel, an existing connection alone does not permit further spending.
Usage still requires sufficient channel funding and valid vouchers. Opening and settling channels also depends on the underlying payment infrastructure.
The blockchain RPC pricing guide explains that service's units and payment behavior.