x402 Work: Paying for API Calls With Proof of Work Instead of USDC
x402 Work is a proposed x402 payment scheme, opened as a pull request on October 29, 2026 and presented by Quai Network as its own, in which a client pays for a request with a proof-of-work solution instead of a token transfer. The 402 response carries a mining job, the client solves it on a CPU, GPU or ASIC, and the facilitator verifies it before the server responds.
What was proposed
Quai Network announced x402 Work on October 29, 2026, describing it as "micropayments powered by your CPU, GPU, or ASIC." The same day, GitHub user 0xalank opened pull request #4057 against the x402 Foundation's repository, titled "feat(work): add proof-of-work payment scheme." Quai's announcement presents the scheme as its own work, though the pull request itself does not state the author's affiliation. As of November 4, 2026 that pull request is open and unmerged, so x402 Work is a proposal, not part of the standard.
Structurally it is a new payment scheme, a sibling of exact and upto, not a new protocol. The 402 flow, the headers and the facilitator roles stay the same. What changes is what the client hands back: a mining solution instead of a signed token transfer. The pull request adds the scheme spec, a @x402/work TypeScript package with client, server and facilitator pieces, and three initial profiles for Quai: quai/sha256d-v1, quai/scrypt-v1 and quai/kawpow-v1. Quai's announcement maps them to hardware: SHA-256d on CPU, GPU or ASIC, KawPoW on GPU, and Scrypt on ASIC. The scheme itself is written to be chain-agnostic, with profiles carrying the chain-specific rules.
How a work payment flows
The challenge is a mining job. The 402 response carries a payment requirement with scheme: "work", asset: "hash", a payTo reward address, and a current native mining job in extra.job, including an id, an expiry and an optional refresh time.
The price is expected trials. amount is the expected number of proof attempts. The client derives the target as floor(2^256 / amount) - 1. The target is never sent as a separate field, which removes one way for client and server to disagree.
The client mines and retries. It searches for a solution whose score meets the target, then returns it in the payment payload. At the job's refresh or expiry time it must stop and request a fresh job.
The facilitator verifies, then consumes. Verification checks that the accepted requirement matches, the job is fresh and bound to payTo, the proof is valid and the score meets the target. Settlement atomically consumes a fingerprint of the solution in a durable replay store shared by every facilitator process. That fingerprint is the settlement transaction. No token moves as part of the payment.
Where the provider's value comes from
A payment-valid solution is usually far easier than one the chain would accept. When a solution also happens to meet the native network target, the provider may submit it for native credit, but the spec is explicit that native acceptance never decides whether the x402 payment succeeded. For a payment amount a and native workshare expectation w, the chance that a payment-valid solution is also native-eligible is roughly a / w. The provider is paid in probability: revenue is the expected value of those rare eligible solutions, credited to its own reward address.
Miners do not speak HTTP
Ordinary GPU and ASIC miners use a persistent mining protocol, not x402 requests. The spec describes a local Stratum adapter on the client side that presents the 402 job to the miner as a fresh job and converts its submission back into the payment payload. That is a transport detail, but it is the piece that makes ASIC payment practical.
Trade-offs against paying in USDC
The unit is not a unit of account. A USDC price means the same thing to every caller. A price in trials costs a different amount for every caller, depending on hardware efficiency and electricity, and its value to the provider depends on the native asset. The spec also notes that work from different profiles is not economically interchangeable.
Latency is probabilistic. amount is an expectation. Any single solve can take much longer or much shorter, and a job that expires mid-search means starting over. The spec tells providers to choose difficulty so the expected solve time fits the job window. A CPU-only agent pays the same number of trials as an ASIC, just far more slowly.
The provider carries the variance. With USDC the seller has the money when settlement confirms. With work, income arrives only when a solution clears the native target.
There is no payer. A successful work settlement omits the payer field. That is the privacy property Quai highlights, and it also means no customer ledger, no refunds and no per-customer billing.
More infrastructure. The provider needs a live job source (a pool, node or Stratum session) and a durable shared replay store. A third-party facilitator may advertise a profile only if it can authenticate the job and verify its reward binding.
Spend controls change shape. hash is not a default asset in the reference client, so an operator must allow it explicitly, and the cap is expressed in trials rather than dollars. The spec adds that clients should enforce local device and energy-use policy.
When each one fits
Work payments fit callers that have idle hardware and no wallet, and providers who want to price access without onboarding anyone, including as an abuse filter on a free tier. The first service built on the scheme, according to Altcoin Buzz's report on the launch, is Hashference, an inference API that also accepts credits and other payment methods. It is Quai's own team's product rather than an independent adopter, and its operation is vendor-reported. Practical adoption depends on what the pull request cannot settle: hardware cost, energy cost and whether facilitators support the profiles.
USDC fits when either side needs a predictable price, when the agent runs in a cloud environment with no accelerator, or when the provider needs revenue it can book. The operator also gets a cap in the unit the budget is written in. That is the case CryptoCadet is built for: a non-custodial, Base-only rail where an agent spends USDC from a session-key bounded float held under OS-keychain custody, and every limit is a dollar amount rather than a hash rate.
Frequently asked questions
- Is x402 Work part of the official x402 standard?
- Not yet. The work scheme was submitted as pull request #4057 to the x402 Foundation repository on October 29, 2026, and as of November 4, 2026 it is open and unmerged. Treat it as a proposal whose details may change in review. The base x402 flow it builds on, the 402 challenge and paid retry, is unchanged.
- Does an agent need a wallet to pay with x402 Work?
- No. Quai's announcement says no account, wallet or API key is needed, and in the spec the client returns only a mining solution. The settlement response omits the payer entirely. The provider is the side that needs an address: `payTo` is the reward destination the mining job is bound to.
- Can any facilitator verify proof-of-work payments?
- Only facilitators that implement the specific profile. The spec says a facilitator must advertise only profiles for which it can authenticate the issued job and fully verify the proof, freshness and reward binding, and servers must confirm support before issuing a job. A facilitator that supports USDC payments does not automatically support work payments.
- Is paying with work cheaper than paying in USDC?
- There is no general answer, because the cost depends on the caller. The price is a number of expected trials, so its real cost is set by the caller's hardware efficiency and electricity price, and its value to the provider by the native asset. A USDC price is the same for everyone, which is why budgets and caps are easier to reason about.