Vault

One on-chain covenant instance holding funds under a specific, exact spending policy.

A vault is one on-chain covenant instance: a specific balance of KAS locked under a specific, exact policy, with its own live-state identity on the Kaspa blockchain. Every meaningful fact about a vault's policy and current state — who the owner and agents are, the caps and budgets, the allowlist, whether it is paused — lives in the covenant itself, not in a PolicyVault database row.

Identity

A vault has a stable identifier (its vault id) and, at any point in time, an exact live state — the specific unspent transaction output (UTXO) that currently represents it on-chain, along with the covenant id bound to that state. Every operation on a vault (a spend, a top-up, a policy change) consumes the current live state and produces an exact, well-defined successor state; PolicyVault never treats "the transaction was submitted" as proof that this happened — only observing the expected successor on-chain counts.

What lives in a vault's policy

Vault lifecycle

A vault moves through a small set of well-defined statuses over its lifetime — active, paused, recovered, or (in rare failure cases) a state PolicyVault cannot currently verify and honestly reports as such rather than guessing. See Vault states for the exact list and what each one means for what you can and cannot do.

Multiple vaults, and organizations

An owner can create and manage any number of vaults. PolicyVault's optional organization layer lets you group vaults and label members for your own bookkeeping (payroll, vendors, and so on) — this is purely local application metadata for humans reading a dashboard. It never merges vaults into a single account and never grants on-chain authority; see Owner/agent/approver authority boundaries.

See also: Spending authority, Fee reserve, Vault states.