Kaspa x402

Kaspa x402 is a proposed native Kaspa binding for x402, the HTTP 402 payment protocol. It lets HTTP APIs and MCP tools charge native KAS per request, and lets servers verify and settle those payments directly against the Kaspa network.

Status

• Alpha reference: draft specs, JSON schemas, conformance vectors, and TypeScript packages under prerelease npm tags.
• Network target: kaspa:testnet-10 only.
• Hosted gateway: demo.kaspa-x402.org is the paid-canary-proven Alpha.10 Testnet-10 deployment. The unversioned site describes the active 0.1.0-alpha.10 source; the gateway reference records the deployed evidence.
• Mainnet: blocked. kaspa:mainnet is a reserved profile name; the blocking gates are listed in mainnet readiness. Do not use any of this with production funds.
• Standards: the kaspa:* network identifiers are draft binding names, not accepted x402 registry or CAIP entries.
• Stability: package names, schemas, and field names may change until the first tagged spec release. See the versioning policy.

Generated from commit 3075e524d061 (2026-08-10). Unversioned routes track the active alpha; immutable snapshots are listed under releases.

What is x402

x402 is an open protocol that turns the HTTP 402 Payment Required status code into a machine-payable flow: a server answers an unpaid request with a 402 carrying a machine-readable offer, the client retries with a signed payment payload, and the server verifies the payment, settles it, and serves the response. The same primitives work over HTTP headers and MCP _meta fields, so paid APIs and tools are usable by autonomous agents. See x402.org.

What is Kaspa

Kaspa is a proof-of-work layer 1 whose blockDAG consensus produces blocks at sub-second cadence with native UTXO semantics. See kaspa.org.

Why a native Kaspa binding

The claims below are engineering rationale, each specified or backed by testnet evidence. None of them is a mainnet claim.

• Settlement latency close to request latency. Paying per HTTP request only works when payment confirmation is not the slow path. Kaspa's block cadence makes one-shot native payments practical at request time; the live testnet report records executed end-to-end flows.
• Small per-request prices. Amounts are decimal strings in sompi (1 KAS = 100,000,000 sompi). KIP-9 storage mass depends on the complete transaction shape; Kaspa does not define a universal 0.1 KAS consensus dust floor. The reference runtime applies a conservative 10,000,000 sompi output policy. Batch-settlement vouchers can price individual requests below that application policy.
• Direct verification, no facilitator lock-in. Kaspa is UTXO-native, so a server can verify and settle against a node it trusts: payment identity is bound to transaction ids, outpoints, and script-public-key material rather than to a hosted intermediary. A self-hosted facilitator profile exists for x402 /supported, /verify, /settle compatibility, but it is optional.
• Escrow channels for repeated requests. For clients making many small or variable-cost calls, batch settlement creates one singleton KIP-20 genesis, signs lifetime cumulative ceilings off-chain, supports repeated partial claims and same-lineage top-ups, and ends with a timed refund. The stable covenant ID and A/S/T accounting survive successor rotation and runtime restart.

Payment schemes

The binding ships two schemes with different settlement shapes.

exact — fixed-price one-shot native transfer under kaspa-exact-v2. standard-native is the default ordinary KAS transfer. The optional additive profile consumes and recreates a reusable merchant KIP-10 head; the successor increase is the sole exact payment, with no second merchant output and no per-offer inventory reservation.

{
  "scheme": "exact",
  "network": "kaspa:<network>",
  "asset": "KAS",
  "amount": "<sompi>",
  "extra": {
    "binding": "kaspa-exact-v2",
    "profile": "standard-native"
  }
}

batch-settlement — repeated or variable-cost requests against a KIP-20 escrow lane. Its lifecycle is singleton genesis → repeated partial claims → top-up → refund. The current outpoint and V rotate while the stable covenant ID and lifetime A/S/T remain recoverable; R is the advertised minimum successor reserve. Spec: kaspa-batch-settlement-v2.

{
  "scheme": "batch-settlement",
  "network": "kaspa:<network>",
  "asset": "KAS",
  "amount": "<max per-request sompi>",
  "extra": {
    "binding": "kaspa-escrow-v2",
    "templateId": "kaspa-x402-escrow-v2"
  }
}

Start here

• Implementing: read the implementer guide, the core binding, the relevant exact or batch-settlement scheme, and the conformance vectors.
• Testing: use the hosted gateway reference and the browser demo.
• Reviewing: start with the threat model, live testnet report, and mainnet readiness gates.

Packages

Install with an explicit prerelease tag or exact version; latest dist-tags are not the recommended alpha install path.

npm install @kaspa-x402/core@alpha @kaspa-x402/covenant@alpha @kaspa-x402/client@alpha @kaspa-x402/server@alpha

Machine-readable: packages.json, site-manifest.json.