PolicyVault in 5 Minutes

The complete mental model — owner, vault, agent, policy, request, verification, signature, and covenant enforcement — in one page.

This page gives you the whole picture in one pass: the objects PolicyVault works with, the path a spend takes from an agent's request to a confirmed Kaspa transaction, and exactly where trust does and does not live at each step. If you read nothing else, read this.

#The objects

• OWNER — a Kaspa wallet (a keypair). The owner creates a vault, sets its policy, and is the only party who can change that policy, pause the vault, or perform terminal recovery. See Owner.
• VAULT — one on-chain covenant instance: a specific amount of KAS locked under a specific, exact policy. A vault has its own address-like identity on chain. See Vault.
• AGENT (or delegate) — a second keypair the owner authorizes to spend from the vault, but only within limits the owner set: a per-transaction cap, a periodic budget, an allowlist of destinations, and (optionally) a requirement for other approvals above some threshold. An agent can be a person, a script, a service, or an AI agent — the covenant does not care which. See Agent/Delegate.
• POLICY — the actual rules: per-transaction limit, periodic budget, destination allowlist, approval threshold, and (in the current covenant) a fee reserve so the agent doesn't need a separate wallet just to pay network fees. See Spending authority.
• EXTERNAL APPROVER — an optional additional wallet that can approve a spend that exceeds an agent's approval threshold. An approver cannot spend the vault's funds and cannot act as the owner — approval authority is strictly narrower than owner or agent authority. See External approver.

#The path a spend takes

OWNER  →  VAULT  →  AGENT  →  POLICY  →  REQUEST
   →  DETERMINISTIC VERIFICATION  →  WALLET SIGNATURE
   →  KASPA COVENANT ENFORCEMENT

Walking through it:

1. OWNER → VAULT. The owner creates a vault with an initial policy — the agent's key, the per-transaction cap, the periodic budget, the allowed recipients, and so on — and funds it with KAS. This policy is compiled directly into the covenant; it is not a database row anywhere.

1. VAULT → AGENT. The owner grants an agent key spending authority over that vault, bounded by the policy above. The agent never receives the owner's key and can never expand its own authority.

1. AGENT → POLICY → REQUEST. When the agent wants to spend — pay an invoice, top up a service, complete an autonomous task — it (or a human using the dashboard on the agent's behalf) submits a request: "pay X KAS to recipient Y." PolicyVault's deterministic core checks this request against the vault's actual live state before building anything: is the amount within the per-transaction cap? Does it fit inside the remaining periodic budget? Is the recipient on the allowlist? Does it need additional approvals? This is the "POLICYVAULT DETERMINISTICALLY DECIDES" step — no AI judgment, no server operator judgment, just a fixed set of rules evaluated against the vault's exact state. A request can be simulated (dry-run) before anything real happens, so an agent (or its operator) can see in advance whether a request would be refused, and why.

1. DETERMINISTIC VERIFICATION. Before any signature is requested, PolicyVault builds the exact unsigned transaction and derives an intent manifest — a structured, machine-checkable description of exactly what that transaction does (amounts, recipients, fee, state changes). In the browser, this manifest is independently re-derived from the raw bytes about to be signed and cross-checked against what was actually requested. If anything doesn't match — a manipulated amount, a substituted recipient, a hidden policy change — signing is refused and nothing is presented to the wallet. This step exists specifically so you do not have to trust the server telling you what a transaction does. See Local intent verification.

1. WALLET SIGNATURE. Only after verification passes is a signing request ever handed to your own wallet (KasWare). The wallet — not PolicyVault — holds the private key and produces the signature. The wallet UI shows what is actually being signed; PolicyVault never has access to your key material at any point in this pipeline. See What KasWare signs.

1. KASPA COVENANT ENFORCEMENT. The signed transaction is submitted to the Kaspa network. Kaspa consensus — not PolicyVault — evaluates the covenant script against the transaction. If the transaction violates the vault's policy in any way (exceeds the cap, exceeds the remaining budget, pays a non-allowlisted recipient, is missing a required approval, misrepresents the fee reserve, and so on), consensus rejects it outright, unconditionally, regardless of what any PolicyVault server said or did. This is true even if an attacker has the agent's private key and skips the PolicyVault app entirely. This is where the actual security guarantee lives.

Only after the network confirms the transaction, and PolicyVault has independently verified the exact expected successor state on-chain, does the vault's recorded state advance. A transaction being "submitted" is never treated as success — only a proven, verified chain outcome is.

#What to take away

• Every step before the wallet signature is advisory and convenience. It exists to make a correct spend easy and an incorrect one hard to attempt, and to catch a lying or compromised server before you ever sign anything.
• The only step with actual financial authority is the last one: Kaspa consensus evaluating the covenant.
• Nothing about "AI" changes this model. An AI agent is just another kind of agent key with the same covenant-enforced limits as a human delegate — it can request, but it cannot decide, verify, sign, or enforce on its own behalf.

Next: Connect KasWare, then Create your first vault.