What the hosted server can and cannot do
A precise account of a PolicyVault server's actual powers — coordination, never funds authority.
This page states plainly what a PolicyVault server — self-hosted or the hosted https://app.policy-vault.org deployment — can and cannot do, on the assumption that you might not fully trust it.
What it can do
- Build unsigned transactions from a request and present them for signature.
- Store and present vault state, request history, and audit records.
- Coordinate multi-party workflows: collecting approver signatures, running an optional governance ceremony for policy changes, applying a restrictive-only risk-review pipeline.
- Submit signed transactions to the Kaspa network and watch for confirmation.
- Send asynchronous notifications (webhooks, in-app notifications) about state changes it observed.
- Enforce hosted tenancy — which wallet may see or edit which hosted objects — as an entirely separate, additional layer on top of covenant authority (see Tenant isolation).
What it categorically cannot do
- Hold or access a private key. No key material exists on the server in any deployment mode. It cannot sign anything on your behalf.
- Move funds unilaterally. Every covenant transition requires a BIP-340 signature over the exact frozen transaction bytes, produced inside your own wallet, and Kaspa consensus independently enforces every covenant rule against whatever the server ultimately submits.
- Convert a login signature into a spending signature. Hosted authentication (proving which wallet a session belongs to) and transaction signing use cryptographically distinct signing domains — an authentication signature is structurally unusable as a spend authorization.
- Expand what the covenant will accept, through governance, risk controls, or any other coordination feature. These are restrictive-only by construction: they can add ceremony or refuse a hosted workflow, but there is no code path in them that can override a covenant denial.
- Make "submitted" mean "succeeded." The server never marks a request complete on the basis of having submitted a transaction — only a proven, independently re-verified chain outcome advances a vault's recorded state.
If it is lying to you
A dishonest or compromised server can still attempt to mislead you — show false state, refuse service, or try to get you to sign something other than what you asked for. See If the hosted server is compromised for exactly what a full compromise can and cannot achieve, and Local intent verification for the specific mechanism that catches a server trying to misrepresent what a transaction does before you ever sign it.
See also: Non-custodial architecture, Covenant enforcement.