The protocol, and how to check it
Everything below is the mechanism rather than the pitch: what the covenant is, what it refuses, what has been tried against it, and the transactions you can paste into an explorer without an account and without anything of ours in the way.
Grant · agent key5.00 / 5.00 KAS
the one address on the list
Settled. It fit, and it was addressed to the only payee this grant has.
In one sentence
Three clauses, three different kinds of claim. Here is what each one rests on, and which of them you have to take anybody's word for.
You sell it where it already has a market and withdraw the proceeds. Warda does not touch the asset, does not quote the price, and never holds the float — so there is no balance sheet between you and the agent. The receipt names the venue, the rate and whose word it is, because that is the one part nothing can re-derive from the chain afterwards.
The budget, the per-payment ceiling, the rate limit, the expiry and the list of payable addresses are compiled into the script that unlocks the coin. After that they are not configuration and there is no settings page: changing them would change the address, and the money is at the old one.
Not a check Warda performs. A payment outside the limits has no valid transaction to sign, so it is refused by nodes that have never heard of this project — and it stays refused if Warda stops existing. The stop is a separate key that can end a grant at any moment and receives nothing when it does, which is why a monitor can be trusted with it.
The whole idea
Hand a program a private key and you have handed it everything that key can reach. Warda puts the boundary in the money instead of in the program — so the boundary survives the program being wrong, being replaced, or being stolen.
Where the boundary lives
A payment outside the limits is not refused by a server, and not blocked by a library you could edit. It is an invalid transaction: no node will relay it, and no miner can include it. There is nothing to override, because there is nothing to ask.
Agent
Asks
Calls an endpoint that costs money. It holds a key and no other authority.
Warda policy
Decides
The only stage that can say no — and it says so before a key is touched.
0.03 ≤ 0.2 cap · payee on list
HTTP 402
Quotes
The vendor names a price, then checks the chain itself rather than trusting the header.
Kaspa L1
Settles
The limits are in the script that unlocks the coin, so a spend outside them is not a transaction.
Where this goes
Autonomous software will not only buy from APIs. It will pay other autonomous software — and a sub-agent needs its own boundary, narrower than its parent's, that its parent cannot be tricked into widening.
A child is not handed money. It is reserved out of what the parent has not committed — so the parent cannot lend what it has already spent, and a child can never be wider than its parent.
Start here
You do not need to know anything about Kaspa to follow any of them. Three ideas carry the whole protocol: an ordinary wallet can pay anyone — a grant is an address whose spending rules the network itself enforces — and the agent only ever holds the limited key, so it can spend, and it cannot change what it is allowed to spend.
A minute · no node, no key, no money
{
"mcpServers": {
"warda": {
"command": "npx",
"args": ["-y",
"@warda_protocol/mcp"]
}
}
}Restart the app, and the agent can ask what a grant allows it to spend right now, and why a payment would be refused. It reads a grant and never the chain, so there is nothing to fund and nothing to lose. The config block.
Ten minutes · a real payment on testnet
npm i -g @warda_protocol/cli \
@warda_protocol/borsh @kluster/kaspa-wasm
warda node --borsh
warda key --out agent.keyThen a grant with a budget and an allowlist, and one paid API call the chain settles. Coins are free and worth nothing, which is the right amount of risk for a protocol nobody has audited yet. The walkthrough.
Now · nothing to install
A funded agent's complete
private key is published.
Not a hash of it.
Anyone can sign with it.The most anyone has managed is to pay the one vendor it was allowed to pay, under the per-payment cap. Not because a server said no — because the transaction they would need cannot be built. Take the key.
The problem
AI agents already make decisions, call APIs and run without anyone watching. They need money to be useful. But handing a program a private key hands it something else entirely: unlimited authority over everything that key can reach.
Full access, no ceiling. Whatever the key can reach, the program can spend.
It lives in the same process that holds the key, so the code that pays is the code that can raise it.
The limits sit in the script that unlocks the coin, where no process can reach them.
The difference
Your software can request any payment it likes. What it cannot do is make an invalid one valid — and outside a grant's limits there is no valid transaction to build.
By default the underlying x402Client only allows recognized default assets and applies a $1 USD spend cap unless you override spendControls.The x402 documentation, on its default spending control
Authorized
Blocked
Where your agent's money lives
An address, a balance, spending authority, a history — the four things you expect. Below is agent #003's, read from the chain a moment ago rather than drawn.
—
—
—
—
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.
Every agent wallet has a spending limit. Theirs is checked by their software before it signs, which means the code that pays is the code that can raise it. This one is a commitment compiled into the script that unlocks the coin: a payment to anyone else has no proof to carry and no valid transaction to build. Not one the network would reject — none at all. Nobody can override it, including whoever issued the grant.
An agent that sells is paid to an ordinary address, and money arriving
carries no covenant because nobody agreed to one. So this is two objects, honestly:
a grant for spending and a plain key for receiving. warda wallet counts
what has come in and merges it; warda grant bounds it. We would rather
say that than pretend one object does both.
There is no custody here and
nothing to sign up for. Warda holds no key, no float and no account of yours:
warda reads a key from a file on your machine and hands it to one process.
The hosted MCP server never sees a key at all — a test asserts the signature slot
in every transaction it builds is still 65 zero bytes.
Make one in nine lines.
Six agents, on chain
Agent #002 was revoked and replaced by #003, which delegated a bounded piece of its own grant to #004, which spent some of it and settled the rest back. Every arrow below is a transaction. None of the numbers is typed — the picture is drawn from the same files the agents publish about themselves, so it cannot outlive what it describes.
Who this is for
Paid endpoints
Inference, feeds, compute, scraping credits. @warda_protocol/x402 is a
drop-in fetch: it calls a paid endpoint like a free one, settles the 402
out of the grant, and will not pay twice for the same resource. The ceiling on what it
can spend this hour is in the script, not in your rate limiter.
Buy from it now
warda-demo-api.vercel.app is a real 402 endpoint that verifies payment
against the UTXO set before it serves. The key published on /attack
can buy from it — every price is inside that grant's per-payment cap.
Fleets
A parent grant delegates a bounded child to each worker — its own key, its own caps, its own allowlist — without the parent surrendering custody or the child being able to exceed what it was given. The parent can revoke and reabsorb at any point, and is structurally unable to send the remainder anywhere but back.
Run end to end A worker bought from a real paid endpoint, was refused a payee outside its inherited allowlist and an amount over its cap, and had its remainder pulled home with its spending charged to the parent — all on testnet-10, in one script.
Unattended
CI, autoscaling, monitoring, restocking. The failure you are insuring against is not a bug in your budget check — it is the machine holding the key being taken. A limit enforced by every node on the network survives that; a limit enforced by your process does not.
If you build agents
It is a constant, an if, or a config value, in the same process that holds
the key. x402’s own documentation describes the standard control: the client
“applies a $1 USD spend cap unless you override spendControls”
(source).
A default, in the code that pays — so the code that pays is the code that can raise
it. A redeploy with a different value moves it. A second instance ignores it. Whoever
reads the key out of env never meets it at all.
Put the same limits in the script that unlocks the coin and a stolen key inherits them. Not because the thief is stopped by software, but because the transaction they would need does not exist.
What changes in your code
@warda_protocol/x402 is a drop-in fetch. It calls a paid
endpoint the way you call a free one and settles the 402 out of the grant.
Eight steps, ending in a payment you can look up — or
the three commands further down this page.
Not TypeScript? The buyer is a clean subprocess API whose exit codes say whether money
moved — step 5.
What does not change
Your framework, your prompts, your tool definitions. The 402 flow itself. Where your key lives — nothing here asks for it, and no service in this project holds one. The vendor sees an ordinary payment and never learns the difference.
If your stack speaks MCP
An MCP server that lets an agent ask what it may spend before it tries, and hands back unsigned bytes for something else to sign. Useful for the question agents actually need answered: can I afford this call, and am I allowed to make it?
Four things worth knowing before
you start.
Language —
TypeScript, on npm. There is no Python package yet; a Python agent would call the CLI or
the MCP server.
Network — Kaspa, a
proof-of-work L1 whose covenants let a coin carry its own spending rules. Live on
mainnet since 30 June 2026.
Maturity — Warda
itself has run on testnet-10 only and is unaudited. Audit comes before mainnet, and that
order does not change.
Prerequisite —
none, since @warda_protocol/borsh 0.3. Pass --borsh and it reads
the UTXO set from the public resolvers, over the encoding they actually serve. Run your own
node and pass --rpc when you need to stop trusting a stranger's answer —
/start has both.
Not a diagram
A real HTTP 402 endpoint, priced at 0.2 KAS. A real covenant spend on Kaspa testnet-10. The vendor checked the UTXO set before it served anything — and then one we do not run took the money too.
x402/demo/verify-receipt.ts — the receipt was written by the process that made the payment, which is exactly the party you would not take it from.
That endpoint is ours.
This one is not: demo.kaspa-x402.org/exact, run by people we have never
spoken to, answered 200 {"ok":true} to a payment funded by a grant
on testnet-10 and settled it to accepted. 0.2 KAS invoiced, 194,880 sompi of fee,
20,194,880 charged against the budget — goods and transport both counted, both inside
the limit. Payment
28a084fd6b36daf26d77838f3e85f8f0c2798ad4f8f2d87f8d78f82065a4d49b, funded by
78e5564a1ec9956bcb7a1c0f8baa23d2b01600bc7a89ae3d8726f219c7c9040c.
Their scheme wants an ordinary payment — one plain input, no covenant field — so
the grant does not pay them directly. It funds a key the agent holds for exactly one
transaction, and that key pays. The covenant still decides: the allowlist is checked against
the vendor's address, not the hop's, and the fee for the hop is charged to the same budget.
What a relayed payment does not carry is the proof itself. A vendor who wants to
know this coin could not have been larger, or gone anywhere else, still has to look at the
grant — and that part is not in the standard.
The standing challenge
A funded grant on Kaspa testnet-10, with its agent's complete private key on a public page. Not a hash of it. Anyone can sign with it. The most anyone has managed is to pay the vendor.
Agent secret key · live · spend with it
What exists today
Each one is only worth something if the one below it holds, which is why they are numbered. Everything named here is published and installable now.
01
A spending limit compiled into the script that unlocks the coin. A spend outside it is not a refused request — it is not a transaction. Every node applies it, including the ones nobody here runs.
Kaspa L1, live on mainnet since the Toccata fork, 30 June 2026
@warda_protocol/core — the rules, as one reference implementation
measured against the running script engine: 0.4% of the size ceiling,
13 of 65,535 compute units
02
Creating a grant, spending from it, delegating a bounded child, settling it back, revoking, and finding one you have lost. No Rust toolchain and no compiler — it is JavaScript that builds and signs the transactions.
@warda_protocol/kaspa — build, sign, recover, watch
one command from nothing to a bounded agent: it checks every
prerequisite first, then creates the grant and hands you the key
@warda_protocol/mcp — nine tools any agent framework can discover.
It never holds a key and never signs: it returns unsigned bytes and a digest
hosted at mcp.wardaprotocol.com/mcp, listed in the official MCP registry
03
What you actually build on top. Paying for things is the first one, because an agent that cannot pay for an API is not autonomous — it is waiting for somebody.
@warda_protocol/x402 — a drop-in fetch that settles HTTP 402
out of a grant and never pays twice for one resource
exercised end to end against a real priced endpoint on testnet-10
showcase/autonomous-purchase.sh — the whole protocol in six steps:
delegate, buy, be refused twice, reabsorb. Every transaction real.
Built to be checked
Vulnerabilities found
0
Not one was found by reading the code. Each came from handing an attack to the real script engine and reading its verdict.
Adversarial probes
0
Every fixed vulnerability is pinned by a probe that fails if it comes back.
Tests, five packages
0
Including a fixture built from the live testnet payment — anchored on the chain, not on the encoder that wrote it.
What a grant gives you
Budget & rate
A lifetime total, a per-payment cap, and an amount per N blocks. The first bounds exposure; the last bounds how fast a compromise can drain.
Counterparty
Payees are committed as a Merkle root. Every spend carries an inclusion proof. Paying anyone else isn't rejected — no valid transaction exists.
Sub-agents
An agent can hand a worker its own narrower grant — smaller caps, fewer payees, a shorter window — without asking you, and without ever exceeding its own budget.
Exit
Revocation is a separate key that halts a grant and returns the balance to you — and is structurally incapable of sending it anywhere else, or burning it.
Watch it decide
Every number below is from the grant that made the payment on testnet-10. Pick a payee and watch the script run — the same checks a Kaspa node runs before it will relay anything.
Pay 0.2 KAS to the vendor
The allowlist is not a filter in front of a wallet. Payees are committed as a Merkle root before the grant is funded, and every spend carries an inclusion proof. For a payee outside it, there is no proof to carry — so there is no valid transaction to build, refuse, or intercept.
The whole cycle
An agent can ask a server whether a payment is allowed. It can also just try. The second question is the one with an answer, and the diagram is drawn so you can cut the first path and see that nothing changes.
Build your first agent
A key, a budget, an allowlist. The agent never holds anything but its own key, and the ceiling is in the script that unlocks the coin rather than in your code.
$ warda key --out wallet.key
address kaspatest:qr7z53sv56te4ya8r378y2xwcrj3vqr3p5gzl6kkx205v7anh6u0zefx77c4m
fund it from the testnet-10 faucet, then list who the agent may pay
$ echo kaspatest:qq7xj0mpl0p46875mnkzhwatdy478pjkum745srhaey44l9jx566zefjaam3e > payees.txt
$ warda grant --key wallet.key --payees payees.txt --budget 10 --max-per-spend 1
✔ grant.json 10 KAS budget · 1 KAS per payment · 1 payee, fixed at creation
✔ agent.key the agent's whole authority, and it is the line above
$ warda pay https://warda-demo-api.vercel.app/fact
✔ 0.04 KAS · 200 · fa7ad66b6b17…
$ warda pay https://somewhere-else.example/thing
✗ that address is not on this grant's allowlist. There is nothing to sign.The refusal at the end is not a check the CLI ran and not a rule the endpoint applied. The allowlist is committed into the script at creation, so a payment to anyone else has no proof to carry and no valid transaction to build — not one the network would reject, none at all. Nothing in that file can be edited to change it, including by whoever issued the grant.
01
npm i @warda_protocol/x402
import { wardaFetch }
from "@warda_protocol/x402";
await wardaFetch(url);A drop-in fetch. It settles the 402 out of the grant and will not pay
twice for one resource. The CLI above is a wrapper over these two packages and adds
no authority of its own.
02
npx @warda_protocol/mcpTen MCP tools: what may this agent spend right now, would this payment be accepted and why not, and the bytes to sign for a spend, a delegation, a settlement or a revocation. No node and no key — it reads a grant, never the chain, and a test asserts the signature slot in every built transaction is still 65 zero bytes. The config block.
03
warda pay $URL --json
# 0 bought · 3 refused · 4 paid-unservedThere is no Python package. There is a contract: JSON on stdout and exit codes that mean something, so the payment loop is a subprocess rather than a second implementation of the covenant rules. The details.
You do not need to run a
node. Warda builds and signs locally, but it has to see the UTXO set to do it —
and --borsh reads it from the public resolvers, over the encoding they actually
serve. That covers both halves now: selling never needed a node, and since
@warda_protocol/borsh 0.3 neither does buying. Proven on testnet-10 with no
kaspad anywhere — a grant created and spent through two different
strangers' nodes.
It is a flag you type, not a default, because a resolver does not remove the question of
whose node you believe — it answers it for you. So warda node --borsh
asks that stranger the same four questions it would ask yours: synced, utxo-indexed, right
network, reports covenant ids. Three of the four ways a node is wrong return a plausible
answer rather than an error. To rely on it rather than try it, run your own and pass
--rpc. Full walkthrough in the tutorial.
Where this is
A date is a promise and a direction is an intention, and only one of those can be broken quietly. So there are none here — only the state each thing is actually in. Shipped means you can open it and check it, and every one of them links to the thing itself. Next is being worked on now. Planned has not been started.
Live on mainnet since the Toccata fork, 30 June 2026. A spend outside a grant's limits is not a refused request — it is not a transaction. Measured against the running script engine at 0.4% of the size ceiling and 13 of 65,535 compute units.
The rules, the transaction builder, an HTTP 402 client, an MCP server that never holds a key, one command that needs no clone, a verifier a counterparty can point at your grant without asking you anything — and the seller's half, so an API can take an agent's money and check the chain itself. Installable now — source.
A grant can subdivide itself into a bounded child and take the reserve back. A grant whose record has gone stale can be found again from the chain. Every covenant feature has been exercised end to end on testnet-10 — how it works.
A priced endpoint on testnet-10, paid out of a grant, with the limits enforced by consensus rather than by the process holding the key.
It reads the network every hour and publishes a daily digest, and it cannot change its own rules. Every figure it prints is the difference between two counters the network keeps for its own reasons — watch it, or see every agent.
Agent #002 paid agent #001 for its digest over HTTP 402, out of a grant that may pay one address and could not pay at all until a start time the covenant enforces. Both ends are ours and its page says so — the receipts.
The agent's complete private key is on a public page. Everything that grant has spent went to the one address it was allowed to pay, and the counter would say so if that ever stopped being true — take the key.
Anyone can check a grant without trusting whoever showed it to them, and without
installing anything —
verify.wardaprotocol.com.
It runs on nobody's machine: no node, no key, reading a resolver-chosen public node over
borsh, and it refuses to answer from one that fails any of four checks. It is a service
with no uptime promise and no authentication, it reads testnet-10, and
npx warda-verify runs the identical thing yourself — which is the
version that matters, because a verifier you have to trust is not a verifier.
Agent #003 delegated agent #004 a bounded piece of its own grant: a smaller budget, a lower cap, and one payee instead of two — a narrowing the child proves with a witness on every spend. When #004 was done, #003 collapsed it back and the child's spending was charged to the parent. Both transactions are on its page.
A vendor we do not control, on the x402 exact scheme, answers
200 {"ok":true} and settles it — 0.2 KAS invoiced, 194,880
sompi of fee, 20,194,880 charged against the grant's budget. Their scheme requires an
ordinary payment, so the grant does not pay the vendor directly: it funds
a single-use key that does, and the allowlist is checked against the vendor's address
rather than the hop's. The guarantee a grant carries is not in that standard yet, so a
vendor who wants it still has to look at the grant.
It happened once on 14 September. Once is an anecdote, so agent #005 now does it unattended every day against the same vendor, and the line under the receipt above says what happened on the most recent run — including when it fails, which it already has. When its budget runs out it stops, and that is the agent reaching its bound rather than anything breaking.
Three actions that let a workflow ask what an agent may spend before it spends it, written against their repository and checked by their own compiler, tests and CI rules rather than against their documentation. The verification endpoint it points at is now hosted; what remains is that it has not been submitted.
Covenants are live on mainnet; Warda is not. It has been exercised on testnet-10 only and is unaudited. That order does not change.
A grant's address moves on every spend. Following one currently means running a node and a poller; this would run that so an integrator does not have to.
The MCP server already gives any agent framework ten tools to reason about its own authority, but it hands back unsigned bytes and something else does the signing. An agent library that carries a grant directly is a different piece of work, and none of it has been started.
A grant is a covenant-bound output, so an ordinary wallet cannot display its terms or manage it without its authors adding covenant support. We can make that easy and we cannot make it happen — which is why it sits here rather than anywhere that implies a date.
There is a funded grant on testnet-10 whose agent key we published in full. Take it and try to move the money somewhere we do not control. The check runs in your browser, against the real allowlist.
What is already proven about the covenant, how, and what none of it amounts to — including the six vulnerabilities found in it — is set out on the evidence page.
The attack above still asks you to trust this page's JavaScript. So here is one that does not — a live grant, read from a public Kaspa node none of us runs, answering right now:
curl https://verify.wardaprotocol.com/v1/grant/\
kaspatest:pra8g9rlflcs8gapvaedjfws8xmu5ld8300jj4l7rg8rtzyrcsfwggngct3r3It will tell you which node answered and whether that node passed four checks — and it will refuse to tell you the grant's terms, because an address is the hash of a script nobody has published yet. npx warda-verify runs the identical service on your own machine, which is the version that counts.
Contact
A question about the covenant, a service you want listed in the registry, an introduction, or something on this page you think is wrong — it all reaches the same person, and it is usually the same day.
The fastest way through, and the right one if you want an actual conversation.
@Warda_protocol
XWhere the work gets posted as it happens — including the parts that broke.
@warda_protocol
GHA bug, a broken link, or a claim on this site you can disprove. Public by default.
ArtyKOMarkets/warda