Luke Dunshea (@elldeeone) has spent recent months bringing native KAS, the currency used by Kaspa, into x402. x402 is an open protocol for paying for a software request. His contribution is native KAS payments for compatible AI applications and other software, so an AI can buy needed information or a tool one request at a time. On September 13 he published v1.0.0-rc.1, a Testnet 10 release candidate, and the next day he asked people to read the code, build against it, and try to break it before a final v1 (announcement, project documentation).
What the number 402 means
In order to understand this work, it is useful to consider what happens when a program asks a server for a file, a lookup, or a tool. The server replies with a short status code. That code tells the program whether the request succeeded, failed, or needs another step.
402 is the web response reserved for Payment Required (RFC 9110). The reservation has existed for decades. However, the number alone supplies no common checkout instructions. It does not name the product, the price, the payee, or the method used to check that money moved.
A person facing a website can still read a checkout page, create an account, and confirm a card payment. A normal checkout page is written for people, whereas the shared payment instructions are designed for programs to process.
x402 can be defined as a shared payment format built on that reserved code (x402 repository, x402 specification). The purpose of the format is to say what is being sold, how much it costs, where to pay, and how the payment is checked. Compatible software can read that offer and, once the buyer authorises the payment, retry with signed authorisation for the agreed amount.
Why a shared payment format is needed
A paid document, lookup, or tool can become necessary while an AI is already carrying out a task. Separately arranging every service's billing is awkward. Without a shared format, a builder has to teach the AI application each service's separate billing and payment process. One seller may collect a monthly fee through a website. Another may issue a private access token by email. A third may expect a private code that only its own software understands.
Those methods can work for people who have time to set them up. They are harder to reuse when an AI has to buy a single result from a service it has not been taught in advance.
A shared payment format does not teach an AI every tool's interface, and it does not remove a provider's authentication. In a participating service, the request can carry a price and a payment instruction that compatible software can read. Human-readable checkout pages and software-readable payment requests are different. The shared format is for the paid request itself. A service can still ask a person to sign in for other reasons.
When an AI needs paid data or a tool
An AI agent can be defined as an AI application that uses tools to carry out a task (x402 specification). The example that follows is hypothetical.
For example, consider an AI preparing a company research report. While it works, it discovers that it needs a paid document or a lookup. It requests that resource and receives a price and a payment offer that compatible software can read. The connected application or wallet then handles authorisation under the owner's rules. Once the payment has been checked, the data is supplied, and the AI continues the report.
The wallet or application must enforce permission, budgets, or approval rules. x402 supplies the payment messages. It does not contain built-in spending judgement. When a purchase has already been authorised under those rules, the owner need not be interrupted at a separate checkout.
The same possible pattern can apply to other AI work, such as paying for a specialised translation, an image-generation request, or a specialist calculation. An AI-tool provider could charge other compatible applications for each use rather than require a monthly subscription.
One KAS payment from request to answer
The purpose of kaspa-x402 is to put native KAS into that common flow. In the one-payment path, the buyer sends an ordinary KAS transfer of the advertised amount to the advertised recipient (native profile).
The hosted Testnet gateway is a public place to watch this path. An unpaid request for a protected report can proceed as follows.
- The program requests the report with no payment attached.
- The server answers with HTTP 402 and a payment offer that software can read. The offer names the Testnet 10 network, the asset KAS, the exact amount, and the recipient.
- The buyer authorises that agreed KAS payment. The program then retries with the signed payment attached.
- The server checks that the network has accepted the payment under its policy, and only then releases the report.
This is the one-payment path in the current Kaspa software. Applications still need KAS-aware signing, and services still need to support the flow.
Repeated charges and the current test target
When the same buyer expects many fixed-price calls, a full network transfer for every small request is a poor fit. The buyer first places KAS in a funded contract. Each later call adds an agreed amount to a running signed total. The provider can then collect several of those charges together, rather than putting each tiny request on the chain. Buyer authorisation and spending rules remain under the wallet or application. The agreed charge can still apply if the tool returns an error, and payment does not itself guarantee a useful result (batch settlement).
Michael Sutton asked about other KCC20 receiving and borrowing permissions, specifically the hash-chain method with one-time-password-like capabilities (question). The linked token-receiving design lets a wallet give permission for one reuse of an existing token-holding output for an incoming transfer, providing more control to the recipient. The permission is for token receiving rather than an AI spending budget or a lending scheme, and it is a proposed extension to consider, not something the release has announced as implemented.
Luke's contribution is native KAS in this common payment flow for compatible applications. Existing wallets and services do not gain that support automatically. Builders who want to try it can read the documentation, use the Testnet 10 gateway, inspect the source repository, and join the forum thread.
v1.0.0-rc.1 is a Testnet 10 release candidate for testing. Independent security review and further operational testing are required before mainnet use (mainnet readiness). The public starting point is the hosted gateway, where a program can already receive a software-readable 402 offer for a paid request.
