Give an agent a budget the network enforces.

Before you start

One prerequisite, and there is now a way round it.

You need to read the UTXO set. You do not need to run a node. Everything in this SDK builds and signs transactions locally — no server sees a key — but building one means reading live chain state, and that has to come from somewhere.

This page used to say the resolver path found you nothing, and that running a node was not one option of two but the option. Here is what was actually going on, since it is the more useful fact.

There are sixteen public resolvers — named hosts under kaspa.stream, .red, .green and .blue, listed in rusty-kaspa's Resolvers.toml. They serve borsh. Measured 10 September 2026: 404 for /wrpc/json, 200 for /wrpc/borsh, mainnet and testnet both. The nodes were never missing; we were asking in a language they do not answer in.

And reading over borsh was not enough to spend. Borsh is positional: no field names on the wire, so a struct the encoder does not know about is not an unknown field but an absent one, and absence shifts everything after it. The published WASM SDK predates covenants, so a grant spend through it would have been well-formed, correctly signed, and bound to nothing. rusty-kaspa's own bindings have carried covenants since Toccata and builds from those revisions are published — so the barrier turned out to be packaging, not protocol.

Nor does that mean trusting a stranger's binary. The covenant binding is part of the sighash, so any difference between what was signed and what the encoder produced changes the transaction id. Every submit computes it both ways and refuses to broadcast unless they match byte for byte. borsh/tools/agree.ts runs the same check against whatever build you installed, before you fund anything.

To rely on it rather than try it, run your own — a node you do not run is a node you are trusting:

kaspad --testnet --netsuffix=10 --utxoindex \
      --rpclisten-json=127.0.0.1:18210

Both flags matter. Without --utxoindex a node reports every grant as spent. The JSON wRPC port is separate from the Borsh one (18210 versus 17210) and only listens when that flag is given — note the =, which the flag requires. The SDK compiles no resolver host in and no node URL in, because naming one is a decision about who you trust to answer "which node", and that belongs to you.

There is also a floor under how small a payment can be. Kaspa charges storage mass for the small outputs a transaction creates, and a payment of 0.01 KAS is refused by consensus — massing 1,000,000 against a ceiling of 500,000 — with the grant, the budget and the fee all perfectly fine. In practice nothing under about 0.02 KAS can be broadcast, so per-request micropayments below that are not a thing this chain does.

tools/check-node.ts interrogates whichever node you point at before you build anything against it. Each thing it checks fails by returning a plausible wrong answer that reads as a problem with your grant rather than with the node.

Install

Five packages. Nothing to compile.

Compiled JavaScript with TypeScript declarations. Node 20+, no build step, no Rust toolchain and no Silverscript compiler — address derivation splices values into a compiled covenant template that ships inside the package.

Create a grant

import { buildGenesis, attachGenesisSignature, signDigest, RecipientSet } from "@warda_protocol/kaspa";
import template from "@warda_protocol/kaspa/covenant-template.json" with { type: "json" };

// Who this agent may pay, committed as a Merkle root.
const payees = new RecipientSet([vendorA, vendorB]);

const grant = {
  authority: { principalKey, revocationKey },
  state: {
    agentKey,
    budgetTotal:  1_000_00000000n,  // 1000 KAS, ever
    maxPerSpend:    200_00000000n,  // 200 KAS per payment
    epochLimit:     500_00000000n,  // 500 KAS ...
    epochLength:            1000n,  // ... per 1000 blocks
    recipientsRoot: payees.rootHex,
    notBefore, expiresAt,
    delegationDepth: 2n,
    /* accounting starts at zero */
  },
};

const unsigned = buildGenesis({ template, grant, funding, changeScriptPublicKey, fee });
const tx = attachGenesisSignature(unsigned, signDigest(unsigned.sighash, principalSecret));

Paying a metered API

import { WardaPayer, wardaFetch } from "@warda_protocol/x402";

const payer = new WardaPayer({
  grant: { template, authority, state, recipients },
  node, sign: agentSecret,             // or a remote signer function
});

// A paid endpoint, called like a free one. The 402, the covenant
// spend and the X-PAYMENT proof are handled underneath.
const res = await wardaFetch("https://vendor.example/compute", {
  method: "POST",
  body: JSON.stringify({ prompt: "explain GHOSTDAG" }),
}, { payer });

It never pays twice. A second 402 means the payment is still settling, so the same proof is re-presented rather than a new one bought — and if the server never settles, it says the money is spent instead of paying again.

The agent spends, unattended

import { signSpend } from "@warda_protocol/kaspa";

const { tx } = signSpend({
  template, authority, state,
  utxo,                             // the grant's current coin
  amount:   50_00000000n,
  recipient: vendorA,
  proof:     payees.proof(vendorA), // proves the payee is allowed
  claimedDaa, fee, computeBudget: 16,
}, agentSecret);                    // the principal is not involved

The distinction it all rests on

Where does the limit actually live?

Anatomy

Six constraints, three keys.

A grant is state encoded into an address. Change any field and it is a different address — which is why a grant is never edited, only spent forward.

Lifecycle

Six operations, each with its own signer.

Every one is an entrypoint in the covenant. The address changes at each step, because the address is the state.

Proof of work, in the literal sense

One agent, one paid API call, on testnet-10.

A real x402 endpoint priced at 0.2 KAS, paid by a covenant spend, with the vendor verifying against the UTXO set before serving. Reproduce it with x402/demo/testnet-demo.ts.

The settling retry is the part worth watching. The vendor answered 402 a second time because the coin was not yet in the UTXO set, and the client re-presented the same proof rather than buying a second call — the one failure mode in this design capable of draining a budget through nobody's fault.

Checking it yourself

The receipt was written by the process that made the payment, which is precisely the party not to take it from. So every claim in it is re-derived from the UTXO set:

node --experimental-strip-types x402/demo/verify-receipt.ts

  ok   the vendor was paid 20000000 sompi by 267e1bac1270fde3…
  ok   the address the grant spent FROM is now empty
  ok   the successor address holds exactly one coin
  ok   the coin balances: 300000000 in, 20000000 paid, 2000000 fee, 278000000 left
  ok   spentTotal advanced by exactly the amount paid (20000000)
  ok   the payment was within the per-spend cap (50000000)

the chain agrees with this receipt.

Evidence

Fourteen attacks, run against the real script engine.

Golden vectors prove two implementations agree about a transaction meant to work. They cannot catch a covenant that permits too much. These do the other half — and every attack sits beside its nearest legitimate twin, because a covenant that refuses everything would pass a suite made only of refusals.

Eight of fourteen shown. Six vulnerabilities have been found in this covenant; none was found by reading the code, and each is now pinned by a probe that fails if it returns.

Integrations

A grant is a funding source with rules attached.

Which makes it a drop-in wherever an agent currently needs a private key.

Limits

What the chain does not enforce.

Published as prominently as the guarantees, because a limit you discover in production is a bug and a limit you read first is a design constraint.