Kaspa x402

Transaction V1 Plan

This plan defines the transaction-builder requirements for Kaspa x402 batch-settlement support. It is intentionally executable as a checklist: no mainnet builder should ship until each production path has a vector with a serialized transaction body/projection, transaction id, hash, sighash input, compute budget, and fee accounting.

Batch claim and batch refund have reference transaction-v1 vectors under vectors/tx-v1/. The transaction-v1 vectors are cross-validated against kaspa-consensus-core 2.0.1 at commit ef1a093bcf8560fe05221b56f0c896f97e7d8d77 by npm run validate:tx-v1-consensus. In those vectors, serializedTransaction is the deterministic transaction hash preimage/projection, not a submit-ready RPC transaction payload. The mass field is contextual storage mass and must not be replaced with serialized-size estimates.

Canonical transaction-v1 semantics used by the vectors:

Batch Settlement Claim

Batch Settlement Refund

Implemented Vectors

Source: /spec/transaction-v1-plan.md