Warda protocol

Give agents money. Not unlimited authority.
Cryptographic spending limits, delegation & agent payments.
Built on Kaspa.

[Warda protocol @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

[Warda protocol @Warda_protocol]

@moxypixy15683 Hey, in which step step?

[Warda protocol @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

[Warda protocol @Warda_protocol]

@moxypixy15683 Hey, what exactly you were trying to do and in which step you got error?

[Warda protocol @Warda_protocol]

The key distinction is permission vs enforcement.

An agent can be given a budget in software, but the spending boundary shouldn’t depend on the agent continuing to obey the software.

Warda makes the budget, per-payment cap and recipient rules enforceable at the transaction layer.

[Warda protocol @Warda_protocol]

@Gustafssonkotte @mywcard Exactly. Agents need money, not unlimited authority.

Spend limits + revocable permissions should be enforced at the money layer, not trusted to the agent itself.

That’s the problem Warda is solving.

[Warda protocol @Warda_protocol]

@JinnoPolar Yes, this is exactly it. The agent can request the payment, but it doesn’t get to decide whether it’s allowed. The grant defines the limits, and Kaspa enforces them at the transaction level.

[Warda protocol @Warda_protocol]

@21Mproject @Cointelegraph That’s the direction. Agents should be able to pay autonomously, but with authority that is bounded by rules—not by handing them the keys to everything.

[Warda protocol @Warda_protocol]

@audiee_ai @CHASER712002 Exactly. Agent payments make the machine economy real, but guardrails are what make it usable. Bounded authority, spending limits, and clear rules need to work quietly in the background.

[Warda protocol @Warda_protocol]

@moxypixy15683 You already can, we are in testnet already: https://t.co/w5wqLCIAPQ

[Warda protocol @Warda_protocol]

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.

https://t.co/IkGh6MRvJL

[Warda protocol @Warda_protocol]

@clawddevs @Muse @x402 @Pumpfun x402 solves how agents pay.
Warda solves what agents are allowed to spend.

Different layers, same machine-native economy. 🤝

[Warda protocol @Warda_protocol]

@moneyinmotion26 Exactly. And that’s the distinction we’re trying to make explicit:

a mandate describes authority; enforcement makes it real.

The interesting question isn’t only what an agent is permitted to do, but what happens when it tries to do something outside that authority.

[Warda protocol @Warda_protocol]

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:
https://t.co/EmYDqRQyO1

[Warda protocol @Warda_protocol]

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.

https://t.co/9VlV5LTm0K

[Warda protocol @Warda_protocol]

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: https://t.co/hR7XQllmNs

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.

[Warda protocol @Warda_protocol]

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: https://t.co/hR7XQllmNs

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.

[vertex @KaspaScopio]

Imagine an AI hiring a few other agents for a job, then having to work out who does what and when each one gets paid.

That’s the example in Sutton’s reply to BlackRock. He’s arguing for agents to create rules for each job that the network can enforce, with everyone joining the agreement in one atomic step.

What I’d like to see next is a small working example on Kaspa. A few agents, one task, an agreed payment. Something we can follow from start to finish.

#Kaspa #AI

[Warda protocol @Warda_protocol]

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.

https://t.co/zjpqPJ9jzi

[Warda protocol @Warda_protocol]

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.

https://t.co/bhh2rSa9TB

[Warda protocol @Warda_protocol]

Agent #005 buys from https://t.co/JaQKIHwIe5 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.

https://t.co/47m2MGvcWC

[Warda protocol @Warda_protocol]

Interesting direction. Inspection answers “what is this request asking me to do?”

The next layer for autonomous agents is “what is this agent actually authorized to do?”

x402 can carry the payment request, but programmable spending authority can enforce the limits before settlement — budget, payment cap, recipient, expiry, rate limits.

Inspection + authorization + settlement feels like an important stack for agent-native payments.