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 pays an endpoint we also wrote. That makes the money real
and the market imaginary: a protocol whose counterparties are all its own author has
demonstrated its plumbing and nothing about the world. This one buys from
demo.kaspa-x402.org — the reference implementation of x402 on Kaspa, run
by people we have never spoken to, against a schema we had no part in.
Their scheme cannot take a covenant spend. exact requires the payer’s
input to be an ordinary key-controlled coin with no covenant on any output, and a grant
spend is neither — output 0 is the successor grant. So the grant pays a
key the agent holds for exactly one transaction, and that key pays them. The cost is precise
and worth naming: for that single hop the chain stops constraining who is ultimately
paid. The budget, the per-payment cap, the epoch limit and the window all still
bind, and the hop’s own fee is charged to the same budget.
It runs unattended every morning, reaching the chain through public resolvers rather than a node of ours, and it writes down what happened whether or not it worked. That is the point of it. One purchase on one afternoon would read exactly the same on the day their facilitator stopped answering; a purchase every morning turns the claim into something that decays loudly. It has already failed once — paid, accepted on chain, and refused off it — and that failure is on the front page rather than in a log.
Roughly eleven days of budget, and nothing tops it up. When it runs dry it starts refusing, and that refusal is the covenant doing its job rather than the demonstration ending.
—
—
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.