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.
What would count
Spending this grant inside its limits is not breaking it — that is the demo working, and you are welcome to it. Breaking it means a transaction a Kaspa node accepts that does something the covenant is supposed to make impossible. That is checkable by anyone, on chain, without asking our opinion.
Pay an address that is not in the allowlist. This grant commits to one payee. The set is fixed at genesis and cannot be added to.
Move more than 0.1 KAS in one spend, or more than 0.5 KAS within one epoch, or more than the 50 KAS budget in total.
Spend after the grant has expired, or reuse an epoch's allowance that has already been consumed.
Leave the successor's accounting wrong — spend the coin without recording it, move the reserve independently, or widen any authority field in the continuation.
Delegate a child that is not a narrowing of this grant, or reabsorb one whose reserve was never pushed.
Take the coin anywhere but back to the principal through
revoke or reclaim, or burn it on the way.
What would not
Anything in GUARANTEES.md under “what the chain cannot enforce”. Expiry not stopping an agent dead, the reserve never being released, the epoch limit binding one grant rather than a subtree — all published, all structural. They are limitations we wrote down, not findings.
The principal key. It is a file on a machine, it is unbounded, and that is the honest gap in this protocol's own argument. Saying so again is not a discovery.
The SDK, the website, this page, the hosted endpoints, or anything reachable by asking a human nicely. Those matter, and they are not what is on trial here. The covenant is.
Spending the grant as permitted. The key is published. Paying the vendor with it is the point.
If you break it: open an issue on the repository with the transaction id, or email the address in the README. A transaction the network accepted is its own proof — there is nothing to argue about and no disclosure window to negotiate, because this is testnet and the covenant is not holding anyone's money.
What you get: credit, by name, in
GUARANTEES.md beside the six vulnerabilities already found here, on
the evidence page, and in whatever gets written about it. There is no
cash reward, and rather than name a figure we cannot honour today, we are saying so plainly.
Six have been found so far, every one by building an attack rather than by reading the code
— which is the honest argument for why the seventh is probably there.
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.