# Public Proposal Draft

Status: draft for community review. No external issue, pull request, or
standards submission has been opened from this repository yet.

Kaspa x402 proposes native Kaspa bindings for x402 v2 payment flows. The
current native alpha surface defines two scheme/network profiles:

- `exact` for fixed-price one-shot transfers;
- `batch-settlement` for repeated or variable-cost micropayments backed by
  escrow/channel state.

The network strings are `kaspa:testnet-10` for alpha validation and
`kaspa:mainnet` as a reserved profile name. They are draft binding identifiers,
not proof of CAIP or x402 registry acceptance. The current implementation and
live evidence are testnet-only. Mainnet use is blocked by the gates in
`docs/mainnet-readiness.md`.

## Why These Profiles

Kaspa payments do not all have the same settlement shape.

`exact` is the simplest fit when the resource has a fixed price and the client
can pay directly with a native transaction.

`batch-settlement` fits repeated small requests and bounded variable-cost
requests. A client funds an escrow channel, signs cumulative vouchers per paid
request, and the server can claim later while preserving refund paths for
remaining value.

Keeping these profiles separate avoids overloading one x402 scheme with
different settlement semantics.

## Kaspa Binding

The Kaspa binding is UTXO-native:

- amounts are decimal strings in sompi;
- payment identity is tied to outpoints, transaction ids, output indexes, and
  script-public-key material;
- covenant-backed profiles validate successor output state rather than assuming
  an account-style global contract;
- transaction-v1 claim/refund artifacts include compute-budget and hash context
  evidence.

The public wire format uses x402 v2 transport primitives. HTTP uses
`PAYMENT-REQUIRED`, `PAYMENT-SIGNATURE`, and `PAYMENT-RESPONSE`; MCP uses the
standard `_meta` payment fields.

## Facilitator Lock-In

The reference implementation is direct-mode first. Servers can verify and settle
payments without depending on a hosted facilitator. A self-hosted facilitator
package exists for compatibility with x402-style `/supported`, `/verify`, and
`/settle` flows, but it is optional and not part of the initial alpha package
set.

## Evidence

The repository contains:

- specs in `spec/`;
- JSON schemas in `schemas/`;
- conformance vectors in `vectors/`;
- transaction-v1 claim/refund reference vectors for the escrow profile;
- a review closure ledger in `docs/review-closure-ledger.md`;
- mock HTTP, MCP, facilitator, and recovery examples in `examples/`;
- a live `kaspa:testnet-10` report in `docs/live-testnet-report.md`;
- a threat model in `docs/security-threat-model.md`;
- a mainnet readiness profile in `docs/mainnet-readiness.md`.

The live testnet report is evidence that the reference flows can execute on
testnet. It is not a production approval, audit result, or mainnet safety claim.

## Proposed Community Path

1. Share this proposal with the x402 and Kaspa communities.
2. Open a focused x402 discussion or issue for `kaspa:*` network binding names,
   CAIP namespace alignment, and the native KAS asset convention.
3. Keep the first external discussion grounded in spec text, vectors, and live
   testnet evidence rather than production claims.
4. Iterate on naming, schema shape, and compatibility with existing x402
   conventions before tagging a stable spec.