XKOVA Docs

Treasury

Treasury holds an institution's own operational funds in a multisig vault, a Gnosis Safe owned by a set of staff signers. Moving value out of the vault is not a single click. A transfer is drafted, a quorum of signers attests to it, and only then does the XKOVA Relayer submit the assembled transaction on chain. No one signer can move treasury funds alone.

The vault model

A treasury vault is a Gnosis Safe multisig deployed for the tenant. Each vault has a set of owners (the staff signers) and a threshold, the number of signatures required to execute a transfer. This is the N of M model: any N of the M owners must sign before a transfer can settle. The vault holds value non-custodially, the platform never holds the signer keys.

  • Create a vault. Deploying a vault deploys the Safe multisig on chain with its initial owners and threshold.
  • Manage signers. Adding or removing a signer, or changing the threshold, is gated at two levels. On a fresh workspace the change is first governance held for owner attestation (the seeded baseline in Policies and Quorum Governance); the approved change is then itself a Safe owner-management transaction that the signer quorum must approve. Pending signer changes are visible alongside active signers.
  • Register assets. A supported-asset registry tracks which tokens a vault can hold and report balances for.

How a transfer settles

Moving value out of a vault follows a draft, collect, relay, settle path. The draft reserves the Safe nonce and computes the exact typed data hash each signer will sign. Signers submit their signatures one at a time. Once the threshold is met, the assembled transaction is executed through the XKOVA Relayer, which submits the Safe execution and pays gas. The chain settles the transfer.

flowchart TD
  A[Draft transfer] --> B[Reserve Safe nonce and compute hash]
  B --> C[Collect N of M signatures]
  C --> D{Threshold met}
  D -- no --> C
  D -- yes --> E[Relay execTransaction]
  E --> F[Chain settles transfer]

The steps map to discrete operations.

StepWhoWhat happens
DraftOperator or backendReserves the Safe nonce and computes the EIP-712 hash to sign.
SignEach signerA staff signer signs the Safe hash in their own wallet. Repeats until the threshold is met.
ExecuteOperator or backendSubmits the assembled execTransaction through the XKOVA Relayer.
SettleChain and XKOVAThe transfer confirms on chain and XKOVA records the settlement.

A transfer can be cancelled off chain before it executes. After execution it is in flight and settles like any other transfer, see Transfers and Settlement.

Errors worth handling per step

The error catalog documents every code; these are the ones each step most commonly returns.

StepCodes
Drafttreasury_role_denied, not_a_treasury_signer, treasury_wallet_not_found, treasury_asset_not_registered, compliance_blocked
Signtreasury_signature_invalid (does not recover to a Safe owner), treasury_signature_already_submitted, treasury_transfer_state_invalid, not_a_treasury_signer
Executetreasury_threshold_not_met, treasury_transfer_state_invalid, treasury_transfer_nonce_blocked (an earlier drafted transfer holds the Safe nonce), authorization_denied, treasury_engine_unavailable

Signature production is browser-side

Your backend can orchestrate every step except producing a signature. Each staff signer produces their signature in their own in-app wallet through a passkey ceremony in the console. This keeps the signer keys with the signers and out of any server. The non-custodial mechanics are in the Non-custodial Model.

Treasury mutations require an elevated, recently authenticated session (a fresh MFA step). A signer cannot draft or execute a treasury move from a stale session. See Authorization and RBAC for the role and step-up model.

Beyond transfers

The treasury surface also covers reading on chain vault balances and confirmed-transfer history, a counterparty registry for naming and reusing destinations, tax exports for reportable counterparties, and NFT custody and moves for vaults that hold tokenized assets. On a fresh workspace, adding a counterparty is governance held the same way as a signer change: the call returns a pending approval, the owner attests, and the re-submitted call creates the entry. Changing which vault receives platform revenue is a separate quorum-gated re-link ceremony.

Related

For the exact treasury operations and their request and response shapes, see the operations list or try them live in the interactive reference.