@Brociferous You have completely misunderstood what “interop” means here. The vector tests whether different CODING language implementations produce identical Kaspa results. It has nothing to do with multi-network offers, asset selection or cross-chain settlement.
Your claim about agents without a KAS wallet is also incorrect. A standard x402 facilitator verifies client-provided payment authorisation and submits it for settlement on behalf of the resource server. It does NOT custody the buyer’s KAS or create the buyer’s signature. Session-gated signing requires a separate wallet or custody layer, even if one service chooses to perform both roles.
If you are relying on an LLM to interpret this work, I suggest using a more capable one. Something such as Sol 5.6 and giving it the actual specification and thread context, because this response has missed the subject entirely.
Also multi-network offers, VidaWallet and your gateway are separate topics. Please start another thread for them instead of inserting them into the technical review of this Kaspa binding.
Identifier convention — no objections. I’ve been running kaspa:mainnet and kaspa:testnet-10 in production (a few gateways plus a payer client) and they match what wallets and explorers already use. Good to lock them in before the 24th.
Spec review from the WASM SDK side — I’ve built on the 2.0.0 nodejs SDK, two things worth flagging. First, npm’s kaspa-wasm is a different/older ABI and dies with “memory access out of bounds”; you need the official v2.0.0 SDK release asset, and that probably deserves an explicit line in the docs since it cost me a while to figure out. Second, an actual verification bug: on the already-accepted path the check rejects a valid v0 tx because api.kaspa.org reports compute_budget as null/absent while the SDK’s safe-JSON serializes it as 0, so null !== 0 throws. Normalizing missing to 0 fixes it. I wrote it up with a patch in
issue #6.
Early external implementer — yes, count me in. The payer I’ve been building (kx402) already settles real exact payments on mainnet against the binding, so I’m implementing it either way and happy to keep reporting back as I go.
Corrections — one on the pricing examples: they predate Toccata, which bumped the min fee rate from 1 to 100 sompi/gram, so the exact fee math is worth a refresh. The ~0.1 KAS storage-mass floor itself is a separate KIP-9 parameter and hasn’t changed, so that part still holds.
For this version, additive is successor-delta-only, and alpha.9 itself won’t change underneath you. But I’m not presenting that as the final form of the Kaspa binding. It is still alpha and may evolve as more independent implementations and external reviews come in. Any breaking change would be made in a new version though.
I haven’t really thought about tokens yet, but both points seem valid. Acceptance doesn’t override issuer controls, and exact’s P2PK model won’t cover every covenant-authorised token transfer. Batch is a specific KAS escrow, not a general token model.
Tokens remain out of scope for now, but both points should be revisited if that changes.
Update: I’ve opened a CASA pull request proposing registration of the kaspa namespace, including CAIP-2 profiles for kaspa:mainnet and kaspa:testnet-10 and a CAIP-10 profile for Kaspa addresses:
I did my own implementation of x402, but yours seems cleaner, is there already a working demo and sdk ? Can I start tests? we have a bunch of public apis that we need to add payments to, and I’m checking for x402 coinbase for now, any ETA so I don’t do that @elldeeone
Thanks mate! Yep, pls feel free to start testing now. Great timing too, because I just shipped the latest alpha version, alpha.10.
I think this will likely be the last major alpha design change before a RC. There is still more testing and external review (hopefully from people like you ) to do before I call it stable, but I think the design is very close.
For your public APIs, I would start with exact using the default standard-native profile. It uses an ordinary KAS payment and requires no seller-side covenant or KIP-10 infrastructure.
exact also has an optional additive profile that uses a reusable KIP-10 merchant head. Separately, batch-settlement is designed for repeated, very small, or metered requests using prepaid covenant funds and off-chain vouchers.
BTW the naming has been versioned as the design evolved through alpha. For the release candidate and upstream submission, I intend to simplify it and use clean, consistent names that follow x402 conventions.
For now, testing is on TN10 while I finish the alpha work and prepare an release candidate. Once it has had enough testing and external review, my intention is to take the cleaned up proposal upstream to x402 (I don’t think we’re far off though).
Appreciate any feedback that you have as this will help me arrive quicker at the release candidate.
Default exactstandard-native flowis just a native KAS tx (there is an optional additive profile though that uses a KIP-10 tx which should be the same speed).
Opening a batch channel definitely would be more efficient for lots of small repeated (or metered) requests. There is a slight initial delay while the buyer opens and funds the channel and seller verifies but subsequent paid requests will rip.
@elldeeone Sorry for delay, we ran into so many issues since some request are for the platform which needs to be open for our apps and paid for external etc, right now I just rate limited whoever was doing 3 mil req to us a day. Hopefully will find simpler solution for this.
Quick update. I’ve moved Kaspa x402 from the alpha series to v1.0.0-rc.1.
The payment design is basically the same as Alpha.10. Most of the work since then has been security review and getting everything into shape for a proper release.
I ran the full repo through a deep security scan using Codex Daybreak Blue (xhigh). It found 23 issues. Nothing was a complete disaster, but there were quite a few things that needed buttoning up around payment authorisation, replay protection, concurrency, state recovery, chain evidence and resource limits.
I worked through and resolved all 23 findings, then ran a separate security-diff scan over the remediation. After that I reran the full validation suite and a fresh funded Testnet run against the exact RC commit.
The other thing I had been waiting for was the official SilverScript v1.0.0 release. The covenant is now finalised against that version, with the generated contract bytes and compiler provenance verified.
This is still TN10 only. I’ve released it as RC1 so it can get more eyes on it before I call it stable.
Please have a look, try implementing from the specs, try to break the gateway and tell me where I’ve made mistakes. If you find something, I want to fix it quickly and get this ready for the proper 1.0.0 release.
) to do before I call it stable, but I think the design is very close.