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. The Safe contract enforces the configured signature threshold.

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, not an XKOVA ledger account, holds value on chain. XKOVA never receives or exports human MPC private-key material, and the Safe verifies the configured owner quorum.

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.
Use available assets. Active supported tokens for the selected network appear automatically. Tenant-issued ERC20 tokens appear for their owning workspace when treasury-eligible.

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.

Step	Who	What happens
Draft	Operator or backend	Reserves the Safe nonce and computes the EIP-712 hash to sign.
Sign	Each signer	A staff signer signs the Safe hash in their own wallet. Repeats until the threshold is met.
Execute	Operator or backend	Submits the assembled execTransaction through the XKOVA Relayer.
Settle	Chain and XKOVA	The 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.

Failures worth handling per step

Treasury signing and execution are private institution-staff workflows. Customer applications should handle their outcomes through the Core Rails or management experience that launched the workflow, not by depending on private error identifiers.

Step	Failure conditions
Draft	The caller lacks the treasury role or signer authority, the wallet or asset is not registered, or compliance blocks the transfer.
Sign	The signature does not recover to a Safe owner, was already submitted, or the transfer is no longer signable.
Execute	The signature threshold is not met, the transfer is no longer executable, an earlier draft holds the Safe nonce, authorization is denied, or relaying is temporarily unavailable.

Signature production is browser-side

Each eligible staff signer uses the Console to authorize the frozen Safe transaction. XKOVA issues a fresh 60-second custom JWT for that exact staff identity, the browser connects a fresh memory-only Thirdweb MPC ceremony, and Thirdweb produces the EIP-712 signature. The Console submits the signature, disconnects the provider session, and clears ceremony memory. XKOVA then rechecks staff authorization and Safe-owner eligibility before persistence, quorum evaluation, and execution.

XKOVA never receives or exports the staff MPC private-key material. The custom-JWT issuer is nevertheless signing-critical because Thirdweb does not restrict the connected session to the frozen Safe transaction. XKOVA's capability, payload freeze, signer verification, authorization rechecks, and Safe quorum are separate required controls. See 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.

Transfers and Settlement: how the executed transfer confirms on chain.
Policies and Quorum Governance: approval quorums and break glass.
Roles and Permissions: who can draft, sign, and execute.

Treasury transport is private to Core Rails institution-staff workflows. The customer API operations list and interactive reference intentionally do not publish those routes.

Was this helpful?