Owner/agent/approver authority boundaries
On-chain authority is determined solely by the covenant. Application-level roles and metadata never grant or modify it.
On-chain authority is determined solely by the vault's covenant. A member labeled "Administrator" or "Treasurer" in PolicyVault's organization layer gains nothing on-chain; a real owner, agent, or approver loses nothing by having no organization record at all.
The three covenant-recognized roles, and only these
- Owner — the key compiled into the covenant at creation; the only party who can change policy, pause, unpause, or perform terminal recovery.
- Agent / delegate — a key the owner authorized, bounded strictly by the policy the owner set.
- External approver — a key that may co-sign a qualifying request; cannot spend and cannot act as the owner.
Every meaningful authority check PolicyVault performs — for the request- mutation pipeline (build, sign, submit, reject) and for the covenant itself — resolves against these three roles and only these three. There is no fourth, application-defined role that grants any of them.
What application metadata is, and is not
PolicyVault's organization layer (members, role labels, vault groupings) is local, off-chain bookkeeping for humans reading a dashboard — payroll, vendors, "who to ask" — and nothing more. It is explicitly documented, in the product itself, as never granting or modifying Kaspa covenant authority: the wallet-request pipeline authorizes signers against the covenant's owner/agent/approver identities only, and never consults organization metadata to decide who may build, sign, or submit a transaction.
The dashboard reinforces this deliberately: an organization panel shows "Organization role" and "On-chain authority" as separate columns, and carries an explicit disclaimer that assignment is local metadata and does not change on-chain ownership or permissions.
Why this separation is a hard design invariant
If application-level roles could ever substitute for covenant authorization, a hosted-server compromise or a metadata bug would become a funds-authority bug. Keeping them structurally separate means the worst a metadata failure can do is degrade to an "Unassigned" or unlabeled presentation state — never grant, widen, or fake covenant authority, and never make funds unreachable. See Tenant isolation for how this separation is enforced in a hosted multi-tenant deployment specifically.
A concrete example: approver-only access
An external approver's hosted-application access should be narrow by design: read access to the specific request awaiting its signature, plus the ability to submit its approval. This is enforced independently at the API layer (a request-mutation guard pins sensitive actions to the actual signer/owner/agent/delegate principals), not by trusting any role label — so an approver's application-level access can never accidentally widen into owner- or agent-level capability.
See also: Owner, Agent/Delegate, External approver, Tenant isolation.