Traditional API
Payment sits beside the protocol.
RequestAPI keyBilling systemResponse
Accounts, subscriptions, invoices and webhooks connect access to payment through application-specific infrastructure.
Axiom Research Mapping
Payment Becomes Native to the Protocol.
A semantic mapping of Kaspa x402 through the Axiom Economic Lifecycle.
How an HTTP-native, UTXO-based payment protocol turns machine requests into economic actions — and how those payments fit into the wider architecture of autonomous commerce.
Protocol-native paymentsMachine commerceSemantic mappingKaspa settlementTestnet alpha
01 · Architectural shift
Payment becomes part of the protocol — not a separate checkout system.
x402 moves payment into the request-response loop. A client can discover a price, authorize value and retry the same operation without leaving the machine-readable protocol surface.
x402
Payment becomes protocol-native.
Request402 offerPayment proofResponse
The price, payment evidence and settlement result travel inside the same machine-readable request flow.
Axiom
Payment sits inside a wider economy.
IntentAuthorizationPaymentSettlementAudit
Axiom abstracts the recurring economic responsibilities around the payment mechanism so different protocols can be compared.
Core thesis
The protocol coordinates payment. Axiom describes the economics.
x402 specifies how a request is priced, authorized, verified and settled. Axiom names the economic roles surrounding those mechanics — and makes visible which relationships are direct, conditional, implementation-dependent or not applicable.
02 · Machine-native commerce
An autonomous client can become an economic participant without a human checkout flow.
The architectural significance is not merely faster payment. It is that software can discover terms, authorize expenditure and purchase a resource within the same interaction loop.
Agent-readable pricing
A 402 response exposes payment terms in a format software can inspect and evaluate without a human interface.
Policy-bounded authorization
Wallets or runtimes can authorize a specific amount, recipient, route and expiry instead of granting open-ended payment access.
Composable fulfillment
A paid response can immediately become an input to the next tool, model or service in an autonomous workflow.
03 · Semantic relationship
Not every Axiom function appears equally in every protocol.
The mapping distinguishes direct correspondence from relationships that are conditional, implementation-dependent or not applicable. The purpose is to reveal differences rather than force completeness.
Mapping discipline
A useful mapping must be allowed to show friction.
Kaspa x402 aligns strongly with authorization, information, payment and settlement. Escrow appears only in the batch-settlement path. Auditability is derived from transaction evidence, receipts and durable replay state rather than defined as a universal protocol domain.
Semantic relationship
Direct
Direct semantic correspondence with an explicit protocol responsibility.
Conditional
Correspondence exists only in a specific payment mode or profile.
Implementation-dependent
The relationship emerges through implementation evidence rather than a protocol-native domain.
Not applicable
No meaningful semantic correspondence is present in the protocol.
04 · Lifecycle mapping
Where Kaspa x402 maps directly, conditionally or through implementation evidence.
The table distinguishes protocol-native responsibilities from conditional payment paths and implementation-dependent evidence without forcing complete correspondence.
Axiom Semantic Namespace
Axiom describes economic meaning, not software architecture.
The .igra namespace denotes semantic primitives defined by the Axiom Reference Model. It is independent of any specific execution environment and does not imply implementation dependencies.
Protocols may be mapped to these primitives regardless of how they are implemented. Kaspa x402, for example, settles natively on Kaspa L1 and has no dependency on Igra, while being conceptually mappable to Axiom's semantic vocabulary.
01
Intent
intent.igra
DirectEconomic function
Expresses the requested resource and the economic objective.
Kaspa x402 expression
HTTP request + normalized request hash
The client requests a protected API, tool or MCP operation. The request hash binds payment authorization to that specific economic action.
02
Authorization
auth.igra
DirectEconomic function
Proves that the payer authorized this request and payment.
Kaspa x402 expression
Wallet signature + request-authorization digest
Kaspa x402 combines transaction signatures with a separate request authorization so the same value transfer cannot be reused for another route or operation.
03
Information
data.igra
DirectEconomic function
Carries the price offer, resource context and payment terms.
Kaspa x402 expression
402 Payment Required + PaymentRequirements
The server publishes scheme, network, amount, recipient, timeout, profile and finality policy as machine-readable terms.
04
Escrow
escrow.igra
ConditionalEconomic function
Reserves value before repeated consumption when required.
Kaspa x402 expression
Batch-settlement covenant deposit
For micropayments, funds are locked once in a Kaspa covenant and consumed through signed cumulative vouchers before claim or refund.
05
Payment
pay.igra
DirectEconomic function
Transfers economic value for access to the resource.
Kaspa x402 expression
Exact native KAS transfer or signed voucher increment
The exact scheme pays once on-chain. Batch settlement amortizes many low-value requests through off-chain cumulative vouchers.
06
Settlement
settle.igra
DirectEconomic function
Establishes the economic outcome under a stated finality policy.
Kaspa x402 expression
Verify → broadcast → accepted/confirmed → applied
The facilitator recomputes transaction facts, verifies signatures and chain state, broadcasts, observes finality and persists a recoverable settlement state.
07
Audit
logs.igra
Implementation-dependentEconomic function
Preserves evidence for replay protection and reconciliation.
Kaspa x402 expression
Transaction ID, payment identifier, receipts and durable state
Payment and request identities are consumed durably so retries can return the same result without repeating protected work.
05 · Payment paths
Two payment modes serve different economic frequencies.
The exact binding handles one-shot purchases. Batch settlement introduces covenant-backed escrow and cumulative vouchers for repeated micropayments.
One-shot path
exact
Request402 offerSignSettleResponse
Best suited to fixed-price requests above the practical output floor. Each purchase is represented by its own signed Kaspa transaction.
Micropayment path
batch-settlement
EscrowVoucherVoucherVoucherSettlement
One on-chain deposit · many off-chain increments · one final claim or refund
Best suited to repeated low-value requests. The chain secures the escrow boundary while signed vouchers account for incremental consumption off-chain.
06 · Kaspa settlement
Kaspa changes the settlement mechanism — not the economic vocabulary.
The lifecycle remains recognizable across payment networks. Kaspa contributes fast native settlement, UTXO-native proofs and covenant-based state transitions beneath that shared economic structure.
Fast native value transfer
The exact path can settle native KAS directly without token approvals, account allowances or a contract-based payment asset.
UTXO-native evidence
Payment is identified through transaction inputs, outputs and authoritative UTXO state rather than account-level permissions.
Covenant-based continuity
Additive heads and batch escrow show how recurring payment state can be represented as constrained UTXO transitions.
07 · Exact profiles
The same economic role can be implemented through different state models.
Both profiles express payment and settlement, but they differ in transaction structure, concurrency behavior and recovery requirements.
standard-native
DefaultA signed native-KAS transaction contains exactly one merchant output for the advertised amount, plus optional payer change.
- One-shot fixed-price payment
- UTXO-native transaction verification
- Explicit request-to-payment binding
- Default fallback for broad interoperability
additive
OptionalA KIP-10 head UTXO advances to a successor whose value increases by exactly the advertised amount.
- Covenant-based state transition
- Atomic expected-head claim
- Sharded heads for concurrency
- Requires lineage-aware reconciliation
Alpha.9 evolution
0.1.0-alpha.9The release moves from a fast-changing prototype toward an independently implementable testnet binding.
Earlier alpha releases centered the exact path on a KIP-10 reservation construction. Alpha.9 preserves the kaspa-exact-v2design introduced in alpha.8: ordinary standard-nativetransfers remain the default, while KIP-10 additive remains an optional stateful profile. The main alpha.9 advance is a more complete interoperability surface: specifications and vectors now define the behavior needed for independent implementations.
Published reference packages
Version 0.1.0-alpha.9 is published for the core, covenant, client and server packages through the npm alpha channel.
Live testnet gateway
The hosted integration gateway on Kaspa testnet-10 has passed a funded standard-native exact-payment canary.
Independent implementation surface
The exact and batch-settlement bindings now define wire formats, construction rules, verification order, expiry semantics and commitment preimages through specifications and conformance vectors.
Funded lifecycle evidence
Recorded TN10 runs cover both exact profiles, idempotent replay, cross-resource rejection and the batch deposit, voucher, claim and refund lifecycle.
Alpha.9 remains testnet-only and unaudited. Published packages, hosted canary evidence and interoperability vectors do not imply mainnet readiness.
08 · System architecture
A payment request crosses five distinct trust boundaries.
The architecture separates HTTP coordination, payer authorization, trusted verification, network settlement and application-side durability.
01
HTTP coordination
The resource server advertises machine-readable terms through HTTP 402 and receives payment evidence on retry.
02
Economic authorization
The payer signs both the Kaspa transaction and a digest binding it to the requested resource and accepted terms.
03
Trusted verification
The server or facilitator resolves authoritative UTXOs, recomputes identifiers and validates scripts, mass, fees and signatures.
04
Kaspa settlement
The verified transaction is broadcast and observed under the configured accepted or confirmed finality policy.
05
Durable application state
Replay evidence, handler results and settlement stages are persisted so retries remain idempotent and recoverable.
09 · Research boundaries
What this mapping does — and does not — claim.
The distinction matters because x402 is a concrete protocol binding while Axiom is a conceptual reference architecture.
x402 is a payment protocol, not a complete commerce stack
It coordinates pricing, authorization, verification and settlement for an HTTP request. Identity, discovery, reputation, negotiation and governance remain external concerns.
The Axiom mapping is semantic, not an implementation claim
Axiom does not assert that Kaspa x402 implements Axiom primitives. It uses the lifecycle as a neutral vocabulary for comparing economic responsibilities, including roles that are conditional, partial or absent.
Not every function is expected to appear equally
This mapping highlights direct, conditional and implementation-dependent semantic relationships rather than forcing complete correspondence.
Verification is implementation-specific
Cryptographic, consensus and facilitator checks enforce the lifecycle but are not presented as a universal economic stage in the Axiom model.
Alpha status matters
The Kaspa binding is testnet-only, the wire format is not frozen, the CAIP namespace is proposed and production use remains gated by review and audit.
10 · Specification under independent verification
A second implementation is testing whether the specification can stand on its own.
Alpha.9 significantly expands the interoperability surface through published specifications, conformance vectors and hosted testnet evidence. The remaining questions below should therefore be read as areas for continued implementation maturity rather than missing foundations.
Canonical transaction encoding
Independent implementations need a fully normative definition of the safe JSON transaction format and explicit hash-preimage fixtures.
Authorization and challenge expiry
Ordering and responsibility across maxTimeoutSeconds, challenge expiry and authorization expiry should be unambiguous across clients, servers and facilitators.
Finality policy
Accepted and confirmed are policy levels, but adapters still need precise operational thresholds and reorg-handling rules.
Additive head availability
Publicly advanceable heads introduce contention and churn. Sharding, thresholds, authentication and standard-native fallback reduce but do not erase that trade-off.
Conclusion
x402 defines how autonomous requests get paid. Axiom defines how autonomous economies work.
Kaspa x402 is a concrete protocol for machine-native payment over HTTP. Its exact and batch-settlement schemes map to much of the Axiom lifecycle, but not uniformly. Axiom makes the differences visible: escrow is conditional, audit is implementation-dependent, and major responsibilities remain beyond payment itself — including discovery, identity, negotiation, reputation, governance and broader coordination.