Agent #001

It has a job.
It has money.
It has rules.
It makes purchases.
Sometimes those purchases fail.
It cannot change its own rules.
You can verify every line of this.

—

The limits are in the script that unlocks the coin — not in the process holding the key. So they hold if the agent is confused, if it is jailbroken, and if someone takes the key outright. A thief inherits the limits.

The job

What Agent #001 does

It reads the Kaspa network on a schedule and publishes the difference between two readings. It never asks the chain what happened yesterday — it asks where the chain is now, writes that down, and yesterday’s answer is the file it wrote yesterday. No indexer, no archive node, no history.

Last run—

Runs—

Services used—

Spent on this run—

—

Every figure there is the difference between two counters the network keeps for its own reasons. Nothing is sampled or extrapolated; the hashrate is the node’s own estimate and says so. Both readings are kept, so anyone with a node can take their own pair and get the same differences.

Authority

What it is allowed to do

Budget—

Spent—

Remaining—

Max / payment—

Per epoch—

Authorized payees—

Delegation depth—

Held on chain—

The payee count is the length of the allowlist, not a headline. A grant commits to its payees at genesis and cannot add one afterwards — so one authorized address means there is exactly one address in the universe this agent can pay. That number grows when a new grant is issued, never when the agent decides it would like to buy something else.

Refused

What it cannot do

None of these sentences was written for this page. Five are produced by running the same check the payer runs before it builds anything; if a refusal stopped happening, the page would fail to build rather than keep the claim.

Economic history

Every payment it has ever made

Payments—

Paid—

Outside the allowlist0 KAS

Warda enforced the authority. It did not guarantee the vendor. These went to a vendor nobody here controls — the demo endpoint of the reference kaspa-x402 implementation. It refused to serve the request each time, for a reason still unknown; the money moved anyway, because a spend the chain accepted is final whatever the vendor thinks. It is not about covenants: the same endpoint refuses a payment from an ordinary wallet, which is the control that settled it. Eight attempts and everything ruled out is written up in full. It is an honest thing to show: the covenant did its job, and the market has not arrived yet.

Scope

What this does and does not protect you from

The payments above went through and the service did not arrive. That is not a gap in the demonstration — it is the boundary of what an authority layer can promise, and it is worth stating before anyone discovers it with real money.

Warda guarantees

Only an authorized agent key can spend
Never more than the per-payment cap
Never more than the epoch allowance
Never more than the lifetime budget
Only to payees committed at genesis
Delegation only within the parent’s own limits
Revocation and reclaim by the principal, at any time

Warda does not guarantee

That the service you paid for arrives
That the vendor is honest
That you can get a refund
That the price was fair
That the agent chose well

Warda is not escrow. It bounds what an agent may spend; it says nothing about what it receives. Escrow is a different mechanism and kaspa-x402 built one — a covenant holding funds against a server key until a claim settles. The two compose: an escrow channel funded from a grant is bounded on the way in and conditional on the way out. Neither replaces the other, and anything claiming to do both at once is worth reading twice.

Identity

The dashboard is not the source of truth

Kaspa is. Everything above is derived from these, and you can derive it yourself.

Agent ID—

Network—

Grant address—

Agent key—

Principal—

Covenant ID—

Template—

—

—