Policies and Quorum Governance

Authorization decides who may attempt an action. Governance decides whether a high impact action proceeds. A policy firewall screens every transfer before it relays, a quorum gates the highest blast actions, separation of duties keeps one person from approving their own request, and break glass is the only audited bypass.

The policy firewall

Every transfer passes through a policy firewall before the XKOVA Relayer submits it. The firewall applies the tenant's compliance and risk policy, including transaction screening and sanctions checks, so a transfer that fails a check is denied rather than relayed. Because the firewall sits in front of the relayer, a denied action never reaches the chain. The member's EIP-712 signature plus this firewall are the real controls on send initiation, which is why creating a payment is open by default. For the screening providers behind it, see Screening.

A tenant may opt in to restricting who can initiate a send, but the default posture is open send initiation plus the firewall and the signature requirement.

Approval quorums

High blast actions are gated by an approval quorum rather than a single principal. The action is staged as a request, a defined number of authorized approvers must attest, and only then does the action execute. Treasury movement is the canonical example: a transfer out of a Safe needs N of M signers to each sign the Safe transaction before the relayer submits it.

The request is created and the creator is stamped on it.
Authorized approvers attest until the clause's threshold is met.
The action executes only once quorum is reached.

See Treasury for the N of M signer model and Cap Tables and Distributions for quorum approved distributions.

Fresh workspace governance baseline

A fresh workspace does not start ungoverned. Provisioning seeds an owner-approval requirement on six high impact actions, so the secure posture is the default rather than something you must remember to configure:

Changing a governance requirement itself (the meta gate; this one cannot be removed).
Transferring workspace ownership.
Committing the value-movement authorization policy (the firewall that screens transfers).
Creating an API key.
Adding or removing a treasury signer, or changing a Safe threshold.
Adding a treasury counterparty.

The first call to a seeded action does not execute. It returns a held response carrying status: pending_approval and a pending_approval_request_id. The owner attests the request (in the console under Governance, Approvals, or through the attestation operations), and then the same call is re-submitted and executes from the approved snapshot. The owner can loosen, tighten, or remove any of these requirements through governance, except the meta gate on governance changes, which stays in place so the matrix can never be rewritten silently.

flowchart TD
  A[Call a governed action] --> B{Approval requirement?}
  B -- none --> E[Executes immediately]
  B -- quorum required --> C[Held: pending_approval with a request id]
  C --> D[Approvers attest by signing in their own wallet]
  D --> F{Quorum met?}
  F -- not yet --> D
  F -- yes --> G[Request ready]
  G --> H[Re-submit the same call]
  H --> I[Executes from the approved snapshot]

Separation of duties

The request creator cannot approve their own request when the clause is satisfiable without them. If the threshold can be met by other authorized approvers, a self attestation by the creator is rejected. The check is conditional, not absolute: a solo or owner clause that can only be satisfied by that one principal still resolves (for example an owner attesting a one of one clause). Separation of duties is never silently bypassed.

Break glass: the only bypass

Break glass is the single sanctioned way to act without the normal quorum, for genuine emergencies.

Armed two of two. Arming requires the owner plus one other principal. No single person can arm it.
Time boxed. It is bounded in time and auto expires, so it cannot stay open.
Tagged and audited. Every action taken while armed is tagged as a break glass action and recorded as a high severity audit event with an alert.
Only bypass. It bypasses the approval requirement only while armed, and there is no other bypass path.

Break glass leaves the loudest possible trail. Use it only for emergencies; every action under it is high severity audited and alerted. See the Audit Log.

Who may do what

The roles that can initiate, approve, and execute these actions, and the permissions each role carries, are defined in the permission registry. See Roles and Permissions for the role model and the catalog, and Authorization and RBAC for how a request is authorized.

For how the controls in this page are recorded, see the Audit Log. For the overall posture, see the Security Model. For the exact governance and treasury operations, see the interactive reference.

Was this helpful?