testnet
—
—
—
—
—
Authority
Activity
—
These are not settings. They are in the script that unlocks the coin, and the network checks them on every spend — including the one that is crossed out.
The question this answers
Every other agent on this site signs with a key that sits in a file on a machine we run. That is fine for a demonstration and it is the first thing anybody running agents for real will refuse to do — and it is the one thing a hosted service cannot ask its users to accept.
This agent’s key was created inside Turnkey, a key-management service
that signs in a secure enclave and never exports the key. The grant names that key as its
agent. Every payment is built here, the 32-byte transaction digest is sent to Turnkey, and a
signature comes back — which is checked against the grant’s agent key before it is
used. Its first purchase, fa5dfe72…, paid the Warda demo vendor
0.03 KAS and was served.
The honest gap, first: the trust has moved, not vanished. Turnkey could sign for this agent. What it cannot do is sign for more than the covenant allows: the budget, the per-payment cap, the epoch limit and the single allowed payee are checked by every Kaspa node, so the most Turnkey — or anyone who took over our access to it — could ever spend is what the grant has left, and only to the demo vendor. A separate revocation key, which Turnkey has never seen, can stop the grant at any moment.
That bound is the point. A custodian holding a wallet is trusted with the wallet; a custodian holding a Warda agent key is trusted with a grant whose limits consensus already enforces. It is what makes a hosted Warda runner something a person can reasonably use.
—
—
created may first spend
Who it pays
A name over an address is a claim about identity, and an ordinary address makes it unfalsifiable — it is whoever we say it is. So each name below is re-derived on every run from a published artefact, and one that stops matching is dropped: the address is then shown without a name, which is worse to read and far better than a name that is wrong.
Its lineage
A Warda grant’s terms cannot be edited. Replacing what an agent may spend therefore means ending one grant and starting another — and the grant that ends does not get a say in it, because the key that ends it is not the agent’s.
Its lineage
This grant was not issued by a person. Another grant subdivided itself and handed over a bounded piece of its own authority — which the covenant permits only in one direction. Each figure below is parent → child.
Its authority
Its limits
Every sentence below is produced by running the same function the payer runs before it builds a transaction — against this grant, with these numbers. None of them is copy. If the grant’s limits changed, these would change with them, or the page would not build.
Its work
Refusals included. A purchase log that records only the successes is a sales brochure.
Honesty
Agent #001’s second grant paid a third-party vendor 1.47 KAS for a service that never arrived. That is on its page, with the transaction id, for the same reason this column is here: the covenant bounds what a vendor who takes payment without delivering can take, and it does not do anything else.
Check it
Every field below is on the chain. Nothing here needs to be believed.
Reproduce the purchase yourself:
git clone https://github.com/ArtyKOMarkets/warda && cd warda/agent-002 source ../ops/node.env WARDA_SK=$(cat ../covenant/deploy/agent-002.key) \ node --experimental-strip-types tools/buy.ts \ https://warda-demo-api.vercel.app/digest
The key is not in the repository, so that command will pay from your grant, not ours. agent-002/README.md has the three commands that mint one.