Non-custodial architecture

PolicyVault's funds-control guarantees are enforced by Kaspa L1 consensus, not by any PolicyVault-operated infrastructure.

PolicyVault's funds-control guarantees are enforced by Kaspa L1 consensus, via a SilverScript covenant. The backend, frontend, SDKs, REST API, MCP server, Python client, and payment-protocol adapters are convenience layers and are explicitly not the security boundary.

#The exact claim

Any rule PolicyVault advertises as covenant-enforced holds even against an actor who:

• holds the legitimate delegate's (agent's) private key;
• bypasses the PolicyVault frontend, backend, SDKs, and API entirely;
• hand-constructs a transaction and submits it directly to a Kaspa node.

This is the bar every security claim in this documentation is held to. A control that only holds when the attacker cooperates with the PolicyVault application is not described here as covenant-enforced.

#No master keys, no admin bypass, no custodial recovery

There is no PolicyVault-side key that can move funds out of a vault. Nobody operating a PolicyVault deployment — hosted or self-hosted, including its own developers — has a bypass around the covenant's owner/agent/approver signature requirements. Recovering a vault's funds requires the vault owner's own signature; see Owner recovery.

#Claim discipline

Every security statement PolicyVault makes follows CLAIM → ENFORCEMENT → TEST → EVIDENCE, and carries one of three labels:

• PROVEN — enforced in code/consensus AND exercised by automated tests (and, where stated, by real-network transactions).
• PARTIALLY PROVEN — enforced and tested at some layers; the exact missing layer is stated.
• DESIGN TARGET — designed and documented, not yet fully verified.

This documentation follows the same discipline: it never upgrades a DESIGN TARGET to PROVEN, and never claims an external audit that has not happened.

#What is PROVEN (representative highlights)

• Covenant policy enforcement against a key-holding delegate — real Kaspa virtual-machine execution suites, plus authorized testnet negative-validation transactions constructed independently of the PolicyVault application, verifying that consensus rejects policy-invalid transactions even when correctly signed by the designated delegate. The current covenant has additionally executed a complete real-mainnet lifecycle (create → delegated reserve-funded spend → pause → governed unpause → top-up → terminal recover), operated by its owner.
• Deterministic byte-identity — the covenant source regenerates byte-identically from its generator; identical intents build identical transactions across the REST/MCP/Python/x402/AP2 paths; the browser's verification bundle is pinned against drift.
• Pre-sign independent verification — the browser re-derives the intent manifest from the exact bytes about to be signed and refuses on any mismatch, including a large hostile-input test matrix. See Local intent verification.
• Numeric safety — integer sompi everywhere; canonical parsers reject numbers/arrays/leading zeros/unsafe integers at every API boundary.
• Fail-closed lifecycle — unknown versions, states, and fields refuse rather than falling back to a default; manifest records are content-addressed with integrity re-hashing.

See also: Covenant enforcement, What the hosted server can and cannot do, External audit status.