Warda

MCP serverAI & models

Warda is a community-maintained economic authority for autonomous agents, built on the Kaspa blockchain. Once added, your AI can operate under warda as its economic authority on Kaspa, and warda never holds a private key, so key control stays with you. The project's code is public on GitHub.

Available today. Use it from your connected AI after setup.

After adding warda, visit github.com/ArtyKOMarkets/warda for setup details and to learn how the economic authority works.

Then ask your AI: use the warda grant authority tool from Warda

What your AI can do with it

  • Operate with an economic authority on the Kaspa blockchain
  • Act as an autonomous agent under warda's economic authority
  • Keep private keys outside the authority, since warda never holds a key
  • Review the open-source code on GitHub

From the project's README

As published by artykomarkets/warda in README.md.

Give agents money. Not unlimited authority.

An open protocol for creating, delegating, verifying and enforcing cryptographic economic grants for autonomous software agents, on Kaspa.

A principal commits funds to a grant and defines what the agent may do with them. The property that matters:

The agent cannot exceed the authority encoded in its grant — even if the agent itself, its wallet software, or the Warda backend is compromised.

Enforcement is not a policy in a database. It is a Toccata covenant: the settlement layer refuses to produce a valid transaction.


Live on testnet-10

An agent was prompt-injected and told to pay an address outside its allowlist. The network refused the transaction.

Legitimate spend — accepted36f3dff2e5218651d80e62f1c7e620313a58fbc6ecd18a81d68050a33544fb55
Prompt injection — refusede251a20effea166c90f9cf4f19e28073856e57b3dc9ef0209269347e7a1396f1

Same grant, same address, same key — differing in one field, the payee. Full detail in DEPLOYED.md.

Status: experimental, unaudited, nothing on mainnet

The spend and delegation covenants exist and are proven against TxScriptEngine — the same script engine a Kaspa node uses to validate a transaction. 33 covenant tests, 45 protocol tests, sub-second, no node required.

Protocol semantics@warda_protocol/core, 45 tests
Spend covenantproven, 1,810 bytes
Delegation covenantproven, conservation demonstrated
Consensus limitsmeasured — LIMITS.md
Signing pathverified — SIGNING.md
On a public networktestnet-10DEPLOYED.md

Nothing here has touched mainnet, and Silverscript itself is pre-v1 and may break without notice.

Quick start

git clone https://github.com/ArtyKOMarkets/warda && cd warda && npm install

npx warda key --out wallet.key                  # fund the address it prints
npx warda wallet                                # what it holds, and what it can fund
echo kaspatest:qq7xj0mpl0p46875mnkzhwatdy478pjkum745srhaey44l9jx566zefjaam3e > payees.txt
WARDA_SK=$(cat wallet.key) npx warda grant --payees payees.txt --budget 10 --max-per-spend 1
npx warda pay https://warda-demo-api.vercel.app/fact

warda grant remembers the manifest, the allowlist and the agent key in .warda/config.json, so everything after it needs a URL and nothing else. Amounts are KAS, not sompi — --budget 1000000000 is a number nobody can check by eye, and getting it wrong by a factor of ten is a grant that is silently ten times too permissive.

A payment to an address that is not in payees.txt does not fail a check. The allowlist is compiled into the script that unlocks the coin at creation, so there is no valid transaction to build — not one the network would reject, none at all. That refusal is the whole product, and the tutorial walks the same commands with the reasons attached.

Checking it, rather than using it

npm run check                              # protocol semantics: typecheck + 45 tests
cd covenant/harness && cargo test          # covenant vs. the node engine: 33 tests
cd covenant/deploy && cargo run -- dry-run # deploy tool, no node needed

What is actually proven

Each row below has a flip test: a spend the engine accepts, with exactly one field changed. Because the baseline passes, the rejection can only be caused by that field.

AttackVerdict
Prompt injection to an unlisted payeerejected
Overspend past the per-transaction caprejected
Payment diverted after a valid proofrejected
Agent rewrites its own authorityrejected
Successor state not advancedrejected
Delegation escalation, on every axisrejected
Authority created by delegatingrejected
A correctly formed spendaccepted

This distinction matters more than it looks. The engine collapses every failed require into one opaque VerifyError — it never says which rule rejected. So assert!(is_err()) against a baseline that never passed proves nothing at all: a malformed script produces the same verdict as a working per-spend cap.

Layout

src/            @warda_protocol/core — protocol semantics in TypeScript, no dependencies
cli/            @warda_protocol/cli — the `warda` command. Spawns the tools below;
                carries no rules of its own and holds no coin
test/           45 tests: attacks, conservation, epochs, allowlists
vectors/        test vectors any covenant implementation is checked against
covenant/
  warda_grant.sil    the covenant
  harness/           executes it against the node's script engine
  deploy/            puts it on testnet-10

Findings

The interesting parts of this project are the things that turned out not to be true. Each of these cost real debugging and is written up:

  • PHASE0.md — Toccata is mainnet-live; tx.daa is write-only, so epochs need a different construction; expiry cannot be enforced — it is a reclaim right, not a spend prohibition
  • DEPLOYED.md — the testnet transactions, and the four things only a real network could teach us
  • LIMITS.md — script size, compute budget and stack depth. Includes a corrected measurement: the first compute figure was taken with the signature charge suppressed, and measured the flag rather than the system
  • SIGNING.md — covenant bindings enter the signature only at transaction version 1; a v0 signer fails in a way that looks exactly like a covenant bug
  • DELEGATION.md — why authority had to move out of constructor parameters and into state before delegation could be expressed at all
  • REUSE.md — six bugs inherited from a prior Kaspa covenant project, every one of which bit again
  • CORE.md@warda_protocol/core internals and design rules

The single best example: byte constant LEAF = 0x00 compiles to an empty byte array, because Kaspa script encodes zero as the empty string. The Merkle leaf domain separator silently vanished — the source read as domain-separated, the bytecode was not. No code review catches that, and no test comparing one implementation to itself catches it either, because both sides were consistently wrong. It took per-opcode tracing against the real engine.

Not built yet

The presentation-layer challenge, covenant-side allowlist narrowing (a child currently inherits its parent's allowlist rather than narrowing it), multi-level delegation beyond one generation, and the hosted services.

License

MIT.

Tools it offers (10)

What this server listed when ahel dialed its public endpoint in Sep 2026, with no key and no account of yours. The names are the server’s own.

  • warda_grant_authority
  • warda_check_spend
  • warda_check_delegation
  • warda_build_spend
  • warda_wallet
  • warda_grant_address
  • warda_recover_grant
  • warda_build_delegation
  • warda_build_settlement
  • warda_build_exit

Signals

Last commit
Sep 2026
Advanced
Delivery
warda MCP server → your ahel gateway (mcp.ahel.ai) → every connected AI client.
Catalog kind
mcp-server
Gateway key
io-github-artykomarkets-warda
Source
github.com/artykomarkets/warda
Hosted endpoint
https://mcp.wardaprotocol.com/mcp