KASPA·X402

Kaspa · x402 · private payments

Pay a service privately

An agent can pay any kaspa-402 service without its funding wallet being linkable to what it buys. The payment settles from a Kaspa shielded pool — a Groth16 ZK privacy primitive on Kaspa L1 — so the address that pays shares nothing with the address that funded it.

This is privacy for agent commerce: the service still gets paid on-chain, per call, with no custodian — but an observer can’t tie the payment back to the payer’s treasury.

Research demo · testnet-10

The shielded pool here is unaudited, runs a single-party trusted setup (so it is forgeable / drainable), and lives on kaspa:testnet-10 only. It is a proof of concept — not for real value. A mainnet version needs an MPC trusted-setup ceremony and a ZK audit.

The loop, end to end

Terminal recording: a Kaspa mining reward is shielded, withdrawn to a fresh unlinkable address, and used to pay an x402 service.
Recorded on testnet-10. mine → shield → withdraw (fresh address) → pay.

How it works

1 ·mine

A Kaspa block reward lands at the miner’s address — ordinary, public, fully linkable.

2 ·shield

The reward is deposited into the shielded pool as a Groth16 commitment, joining the anonymity set.

3 ·withdraw

After a proof-of-innocence screen, the note is withdrawn to a fresh address that shares nothing with the miner.

4 ·pay

That fresh address pays the x402 service. The service is paid; the payer is unlinkable to where the funds were mined.

The only linkable moment is the deposit — after that, the note is one of many in the pool. The withdrawal proves, in zero knowledge, that it corresponds to some unspent deposit in a governance-approved set, without revealing which. So the fresh payer address is indistinguishable among every note in the pool.

Proof on testnet-10

every step is a real on-chain transaction

The payer kaspatest:qz33np6wakmg… was funded only by shielded-pool withdrawals — it has no shared history with the mining address. Links resolve on the testnet-10 API.