Covenant enforcement

How Kaspa L1 consensus itself enforces vault policy, and what that guarantee is proven against.

A covenant here means a constrained spending condition, compiled in SilverScript, that Kaspa consensus evaluates directly against a proposed transaction — not a PolicyVault-side check, not a database rule, and not anything an application server decides. This is the actual mechanism behind every claim in this documentation labeled "covenant-enforced."

What the covenant fixes at each vault's creation

Immutable policy — the owner's key, the delegate/agent structure, caps, budgets, period length, and recipient commitments — is compiled directly into the covenant. Mutable accounting (current protected balance, current period's spending so far, paused/unpaused, fee reserve) lives in the covenant's tracked state and is updated only through covenant-defined transitions.

Consensus-time budget tracking, not client clocks

Periodic budgets roll over based on Kaspa's own DAA (difficulty adjustment algorithm) score — a real consensus time-lock condition, never a wall-clock date supplied by a client. An agent cannot fake an early period reset; the covenant simply will not accept a transaction claiming a period has elapsed before the network's actual DAA score says so. See Periodic budget.

Recipient and multi-agent commitments

Recipient allowlists and (in covenant versions supporting multiple agents) each agent's complete policy are committed as Merkle trees. A spending transaction must supply a valid membership proof; the covenant verifies that proof as part of accepting the transaction, so an allowlist or an agent's specific limits cannot be bypassed by constructing a transaction differently.

Fee-reserve conservation

Where a covenant-controlled fee reserve is configured, the covenant computes the actual network fee directly from the transaction's own real inputs and outputs, and bounds fee-reserve consumption to the smaller of a configured cap and that actual fee — so the reserve can only ever become network fee, never a redirected payment or spendable principal. See Fee reserve.

The production-byte discipline

Any component that can shape the exact bytes a signature covers — the transaction encoder, the state compiler, serializers, finalizers — is required to have an integration test that runs its exact real output through the actual Kaspa virtual machine (or a live node), never only a test harness that rebuilds the same bytes in isolation. This discipline exists because of a real, historical defect class: an earlier covenant version's encoder passed 100% of its in-process tests while failing every live transaction, because the test harness and the production code built bytes independently rather than the test driving the real production path. Every subsequent covenant version is held to the stricter standard.

What is proven, and how

Version discipline

Every layer — the covenant itself, its call encoder, the SDK's compiler and builders, request/response schemas — dispatches explicitly on a version tag. An unrecognized version fails closed everywhere, with no default handler and no cross-version fallback.

See also: Non-custodial architecture, Vault, Fee reserve.