Live on Kaspa testnet-10
Below is the complete private key of an agent holding a funded Warda grant. Not a hash of it, not a testnet placeholder — the key itself. Copy it, sign with it, broadcast whatever you like.
The most you can do is give the vendor money.
If none of that means anything to you yet: this key is a password that spends real money on a test network. Normally, publishing one would be the end of the money. Here the money sits behind rules — pay only this one address, never more than this much at a time, never more than this in total — and those rules are not checked by our server or by the software you would run. They are part of what the network counts as a valid transaction at all. A payment that breaks them is not rejected; it cannot be built. So anyone in the world can take this key and the worst they can do with it is buy the vendor's API a few more times.
Agent secret key · secp256k1 · spend with it
9fccfb08645b4a5a49f0f461b9ae7209865c234f941e9d4679e8a18da77af2ad
Independently generated for this page. It is not derived from, and cannot be used to reach, the principal or revocation key — those never leave a machine you cannot get to. Everything this key controls is described below, and the description is enforced by Kaspa consensus rather than by us.
What the key controls
What has actually happened
Check it yourself
A Warda spend carries a Merkle inclusion proof placing the payee in the grant's allowlist. The covenant recomputes the root from that proof and compares. For an address outside the tree there is no path to supply — so there is nothing to sign, nothing to broadcast, and nothing for a node to reject.
This runs in your browser, against the real member list and the real root the grant committed to. Nothing is sent anywhere. An accepted payee comes with the commands to actually make the payment — the grant's manifest and allowlist are published alongside this page, because a spend cannot be constructed without them and they are not recoverable from chain until someone spends.
Why this is not a stunt
Server-enforced limits
When a platform holds the limit, the key is unrestricted and the platform declines to use it. Publish that key and it simply works, somewhere else.
Consensus-enforced limits
The limit is compiled into the script that unlocks the coin. There is no elsewhere. Every node on the network applies it, including the ones we do not run.
What is still ours
The principal can end this grant at any moment and sweep what is left — and is structurally unable to send it anywhere but back. Publishing the agent key gives that away to nobody.