Give an agent a budget the network enforces.

Before you start

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

You need a Kaspa testnet-10 node you can reach. Everything in this SDK builds and signs transactions locally — no server sees a key — but building one means reading the UTXO set, and reading the UTXO set means talking to a node.

To try it, borrow ours. It is a laptop behind a tunnel, forwarding four methods and refusing the rest by name; /start says exactly what it is and when it is down.

To rely on it, run your own — and if you are building anything real, do:

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.

WARDA_RESOLVER is supported, and here is the honest note it needs. A Kaspa Resolver picks a public node for you, and there are sixteen public instances — named hosts under kaspa.stream, .red, .green and .blue, listed in rusty-kaspa's Resolvers.toml. This page previously said none existed; that was wrong. What is true is narrower and worse: they serve borsh, and this SDK speaks JSON. Measured on 10 September 2026 — 404 for /wrpc/json, 200 for /wrpc/borsh, on mainnet and testnet both. So the resolver path finds you nothing today, and running a node is not one option of two: it is the option. The SDK still compiles no resolver host 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.