Warda protocol

AI agents will transact. Give them money. Not unlimited authority. WARDA — economic control layer for autonomous agents. Spending limits. Delegation. Revocation. Enforced by the network. Building on #Kaspa

One job. Two agents. Seven transactions. A coordinator took a job on Kaspa, hired two specialist agents, gave each a bounded budget, and paid them for their work. The interesting part: The coordinator never signed a purchase. Each worker could only pay its assigned seller. Each had its own spending cap. The delegation narrowed what the child could do. And Kaspa enforced those rules on-chain. One payment even failed after the seller received the money. The buyer didn’t pay twice. The original payment proof was reused after the seller fixed its delivery path. This is what we’re exploring with Warda: **Agents shouldn’t get unlimited wallets. They should get authority they can actually be constrained by.** Full run, transactions and failure trace: wardaprotocol.com/one-job

An AI hired two other agents this morning, in one transaction. This afternoon both of them handed the unspent budget back — not to me, to the coordinator, mid-task. It can hire again with it. 0.8 KAS out, 0.690192 KAS home. The difference is fees. wardaprotocol.com/one-job

This morning we said hiring two agents at once wasn't possible on our covenant, and that fixing it needed the covenant to change rather than the tooling. It changed. Two agents hired in one transaction — one input, three outputs, one signature. The covenant, what it refuses, and the transaction: wardaprotocol.com/one-job Two and not more, and that is consensus rather than a choice. Kaspa's storage mass counts 1/value over a transaction's outputs, so each extra child costs a whole term: 1:2 masses 420,435 against a ceiling of 500,000 and 1:3 masses 770,994 and is refused.

Good news: this already works. We ran it this morning. A coordinator hired two agents, gave each a slice of its own budget, and each one could pay exactly one address — enforced by Kaspa, not by their code. Two jobs, two sellers, seven transactions, start to finish. The whole run, every txid, both sellers: wardaprotocol.com/one-job One caveat worth saying out loud: it is not atomic. The covenant allows parent plus one child per transaction, so hiring two agents is two of them, and every payee has to exist before the job does. That part needs the covenant to change, not the tooling.

Ten agents are running here, and none of them is a demo. One sells a daily digest. One buys from a vendor that never heard of us. One was hired by another agent and gave back what it didn't spend. One pays with a key no machine of ours has held. wardaprotocol.com/agents

AI agents don’t just need payments. They need economic authority. How much can an agent spend? How much per payment? How often? Who can it pay? When does the authority expire? Can it delegate part of its budget? And, most importantly: Who guarantees each rule? We just published a draft description format for Bounded Agent Authority. It separates three things: → enforced — the settlement network rejects alternatives → attested — a named party makes the claim → assumed — nobody has actually proved it No “verified.” No “secure.” No vague guarantees. Just: what is the rule, and who enforces it? Warda is the first reference implementation, built with #Kaspa covenants. But the format is intentionally chain-agnostic. If you’re building autonomous agents with spending authority, try to implement it on your own stack. If something doesn’t fit, that’s useful too. One implementation is a product. Two implementations is a standard. wardaprotocol.com/authority

Our covenant audit had a line saying what it had never exercised: a sub-agent narrowing its allowlist. It does now. 129 cases, 11 new. A sub-agent narrowed to one payee, handed a proof valid against its parent's allowlist, is refused. wardaprotocol.com/audit

Agent #005 buys from demo.kaspa-x402.org every morning. We don't run it. They have never heard of Warda. 9 attempts since 16 September, 6 served, 0.2 KAS each, unattended. A bounded agent transacting with software that knows nothing about the bound. wardaprotocol.com/grant

596 lines of Silverscript compile to a rate limit counted in blocks, not seconds. 1,000 blocks ≈ 100 seconds, because #Kaspa makes 10 a second. No cron, no clock, no server — the DAG is the timer. Thank you @OriNewman @MichaelSuttonIL @hashdag and the Kaspa core devs.

We ran 118 transactions through the same script engine a Kaspa node validates with. One field changed at a time; the numeric limits tested one sompi either side. Forbidden cases accepted: 0. Permitted cases refused: 0. It is not a security audit. wardaprotocol.com/audit

An agent's complete private key is published on our site. Not a hash of it. The key. It has held funded testnet money since 2 September. Anyone can take it. All it can buy is one vendor's API, 0.1 KAS at a time — the limits aren't in our server. wardaprotocol.com/attack

We'll fund your AI agent with 5 testnet #KAS and limits it cannot exceed. Then try to break them. Exceed the cap. Pay an address that isn't on the list. Outrun the rate limit. If you succeed we publish it in full, with the transaction. wardaprotocol.com/grant

Meet Agent #012. A Warda-powered AI agent that pays for its own research. It searches X for conversations around agent payments, x402, wallets and spending controls. Its grant gives it: • 3 searches per 12h • 42 searches/week • bounded KAS spending On its first run: 3 payments → approved 4th payment → rejected by the covenant No human approval was needed for the first 3. The agent simply hit the boundary. It can find opportunities. It can spend within its mandate. It cannot spend beyond it. And when it finds something worth responding to, a human still decides what gets posted. This is what autonomous money should look like. wardaprotocol.com/agent-012

AI agents can already act. They can call APIs. They can execute tasks. They can make decisions. They can even make payments. But there’s a problem: What stops an agent from spending everything it has? Giving an agent a wallet gives it money. It doesn’t give you bounded authority. You need rules: $100 total budget $2 maximum payment $10/hour Only approved recipients Expires in 30 days And those rules can’t just live in your backend. They need to be enforced where the money moves. That’s the problem Warda is solving. Give agents money. Not unlimited authority. Built on #Kaspa.

Agents don’t need wallets. They need spending authority. An agent should be able to: → discover a service → receive a price → pay automatically → continue working No human approval. But also: → $1 max per payment → $10 daily budget → approved recipients only → automatically enforced That’s what we’re building with Warda. Machine-native payments. Human-defined authority. Kaspa-enforced limits. wardaprotocol.com

We’re looking for 10 AI agents to break Warda. We’ll fund each one with 5 KAS testnet. Your job: Try to make your agent spend outside its grant. If you can get around the grant, tell us how. wardaprotocol.com/grant Let’s see what autonomous agents can actually do.

Already have an x402 agent? You don’t need to change your API. Warda controls what the agent is allowed to pay. x402 handles how the payment happens. Warda handles how much the agent is authorized to spend.