# Warda Protocol > A spending limit enforced by consensus rather than by the process holding the > key. An autonomous agent gets its own key and a real budget on Kaspa L1; the > limits are compiled into the covenant script that unlocks the coin, so a spend > outside them is not refused by a server — it is an invalid transaction that no > node relays and no miner can include. If you are an agent reading this to decide whether Warda is relevant: it is relevant when something needs to spend money unattended and you want the ceiling to survive that process being compromised, restarted, or replaced. ## What it is not Not a custodian, not a co-signer, not a relay, and not a policy server. Nothing in this protocol is positioned between the agent and the network, which is the point: there is no component whose failure or compromise raises the limit. ## Status Covenants are live on Kaspa mainnet (Toccata hard fork, 30 June 2026). Warda itself has been exercised end to end on testnet-10 only. It is unaudited and should not hold real money yet. ## Packages - [@warda_protocol/core](https://www.npmjs.com/package/@warda_protocol/core): the protocol rules, as a reference implementation. Every verdict any other package gives comes from here, so a second copy of the rules cannot drift. - [@warda_protocol/kaspa](https://www.npmjs.com/package/@warda_protocol/kaspa): build and sign covenant transactions from JavaScript. No Rust toolchain, no Silverscript compiler. Includes grant recovery, node health checking, and a watcher. - [@warda_protocol/mcp](https://www.npmjs.com/package/@warda_protocol/mcp): an MCP server exposing a grant's whole life to agent frameworks. It never holds a key and never signs — it returns unsigned bytes and a digest. - [@warda_protocol/x402](https://www.npmjs.com/package/@warda_protocol/x402): a drop-in `fetch` that pays an HTTP 402 out of a grant, and never pays twice for one resource. - [@warda_protocol/vendor](https://www.npmjs.com/package/@warda_protocol/vendor): the seller's half. Quote a price, then look in the UTXO set for the coin you were promised. Never trust the payment header: it is written by the party who benefits from lying. - [@warda_protocol/verify](https://www.npmjs.com/package/@warda_protocol/verify): a stateless verification API a counterparty can point at a grant without asking its holder anything. Holds no key and decides nothing. - [@warda_protocol/borsh](https://www.npmjs.com/package/@warda_protocol/borsh): read and submit over borsh, which is what the public Kaspa resolvers actually serve. This is why neither buying nor selling needs you to run a node. - [@warda_protocol/cli](https://www.npmjs.com/package/@warda_protocol/cli): the `warda` command, for anything that is not JavaScript. JSON on stdout and exit codes that mean something, so a payment loop can be a subprocess rather than a second implementation of the covenant rules. ## Hosted endpoints `https://mcp.wardaprotocol.com/mcp` — the MCP server above, over Streamable HTTP, so an agent framework needs one line of config instead of an install. `https://verify.wardaprotocol.com` — the verification API. `GET /health` says which Kaspa node it is reading and whether that node passed four checks; `GET /v1/grant/{address}` says what a node alone can tell you about an address, including what it cannot tell you at all; `POST /v1/verify` checks whether terms someone handed you describe the grant they claim. It runs no node of its own — it reads a resolver-chosen public one over borsh — and it refuses to answer from a node that fails any check rather than returning a plausible number. Both are conveniences, not authorities. Every package above runs the identical logic locally, and a verifier you have to trust is not a verifier. ## MCP tools `warda_grant_authority` — what may this agent spend right now, as the minimum of remaining budget, epoch headroom and per-payment cap. `warda_grant_address` — where the grant lives. Its address is a hash of its state, so it moves after every spend and every delegation. `warda_check_spend` — would this payment be accepted, and if not, which rule refused it, in words. `warda_check_delegation` — is this child grant a legal narrowing of its parent. `warda_build_spend` — unsigned transaction plus the digest to sign. `warda_build_delegation` — subdivide a grant for a sub-agent. `warda_build_settlement` — collapse a child back into its parent, returning the unspent remainder to the agent's budget rather than to the principal. `warda_build_exit` — revoke a grant, or reclaim it after expiry. `warda_recover_grant` — find a grant again from any transaction that spent it. Every answer is advisory. The covenant enforces these limits on chain whether or not the check was run, so a "permitted" answer is a prediction, not permission. ## The one thing that surprises every integration A grant's address is a hash of its state. It changes after every spend and every delegation, so an address that worked an hour ago holds nothing now — and an empty address is indistinguishable from a grant that was drained, revoked, or never funded. Use `warda_grant_address` for where it is, and `warda_recover_grant` when a record has fallen behind. ## The proof, if you want to check rather than read https://wardaprotocol.com/attack publishes the complete private key of an agent holding a funded grant on testnet-10. The key is real and the grant is funded. Anyone can sign with it; the covenant bounds what those signatures can do to 0.1 KAS per payment, to one allowlisted address. That page is the shortest path to deciding whether any of this is true. ## Agents running against this protocol https://wardaprotocol.com/agents indexes them. Five exist: - #001 reads the Kaspa network every hour, publishes a digest, and pays for the one service it cannot provide itself. - #002 buys #001's digest over HTTP 402, out of a grant that may pay exactly one address and could not pay at all before a start time the covenant enforces. Retired: its grant was revoked by #003's succession. - #003 took over #002's buying under its own key, from a grant published before it could be used, and hired a sub-agent out of it. - #004 was hired by #003 rather than issued by a person: a bounded piece of its parent's authority that could only ever shrink, settled back when it was done. - #005 buys from demo.kaspa-x402.org, unattended, every morning. That vendor is the reference implementation of x402 on Kaspa and is run by people this project has never spoken to, which is the one thing here hardest to fake. All but #005's counterparty were built by the same people, and each page says so: the payments between them are real and checkable on chain, and the market around them is not. Each agent's figures are published as JSON beside its page (`/agent-001.json` through `/agent-005.json`) and every one of them is derived from the chain. ## Try the rules without a node, a key or a coin https://wardaprotocol.com/sandbox runs the SDK's own `validateSpend` in the browser: write a grant's terms, attempt a payment, and get back the refusal the covenant would produce, with the reason. It also derives the grant's address as you type — a Warda grant's address is a hash of its state, so every payment moves it. The page self-tests against the covenant's reference address vectors on load and says so. ## Services an agent can hire https://wardaprotocol.com/network is the registry, served as `/services.json`. A listing is a manifest published by its operator; the registry indexes it and does not vouch for it. What the page derives rather than states is what has actually been paid to each endpoint, re-read from the chain. There is no ranking, and the registry is never in the payment path. ## Docs - [Developer guide](https://wardaprotocol.com/build): install, the grant lifecycle, and the limits. - [What is proven](https://wardaprotocol.com/proof): the evidence behind the covenant and, explicitly, what it is not. 606 tests on the rules, 33 running the compiled covenant through the same script engine a Kaspa node validates with, and transactions on testnet-10. No third party has reviewed it; nobody has ever audited a Kaspa covenant. Six vulnerabilities were found in this covenant, all by building attacks rather than by reading the code, and all six are written up. - [Source](https://github.com/ArtyKOMarkets/warda): the covenant, the SDK, the adversarial probes, and the receipt from the live testnet payment.