Treasury

Treasury is where an operator manages institution held funds. Funds sit in a multisig vault, and every transfer out needs a quorum of signers to approve it before the XKOVA Relayer submits it. The console is the surface for creating vaults, managing signers, and approving transfers.

What a vault is

A treasury vault is a multisig Safe (for example a Gnosis Safe) that holds the institution's funds. Unlike a member wallet, a vault is moved by a quorum, not a single signer. A transfer needs N of M signers to each sign the Safe transaction before it can be submitted. The concepts behind this are in Treasury in the XKOVA SPS section.

Set up signing first

Each operator who acts as a treasury signer needs an in-app signing wallet provisioned before they can sign. The treasury overview surfaces your own setup status, so you see the gate before you hit it. Complete your signer setup from the overview if it is not yet done.

Create a vault

From the treasury overview, start a new vault. The form asks for a name, the staff signers, and the threshold. The network is implicit; it was pinned when your workspace was set up, so there is no network field.

Signers. Pick from the active staff in your tenant. The default is the current operator alone, which is the common case for a first vault.
Threshold. The N in N of M. A vault survives a lost key only when it has more signers than its threshold; raising the threshold protects against a stolen key but makes key loss harder to survive. Any vault that could not survive two key losses (fewer than threshold + 2 signers) asks you to acknowledge the reduced redundancy, with a single-signer vault being the extreme case where no key loss is survivable.

Choose the threshold deliberately. A higher threshold protects against a stolen or compromised key but needs more signers present to move funds, and it makes a lost key harder to survive. A one signer vault is convenient but has no redundancy.

Move funds

A transfer out of a vault follows the quorum pattern. The flow is created, then each required signer signs the Safe transaction in their own wallet, and once the threshold is met the transfer becomes ready to execute; an operator then runs Execute, after which the XKOVA Relayer submits it on chain.

An operator creates a transfer from a vault, naming the asset, amount, and destination.
Each required signer reviews and signs the Safe transaction in their wallet.
When the signature count reaches the threshold the transfer becomes ready to execute; an operator then clicks Execute, after which the XKOVA Relayer submits the transfer on chain and pays gas.
XKOVA confirms settlement on chain and the transfer reaches a terminal state.

A mined transaction is not automatically a success. XKOVA verifies the on chain success flag before marking a treasury transfer confirmed, so a reverted transfer is never recorded as settled.

Beyond transfers

The treasury area also covers counterparties (named, reusable destinations), per signer dashboards, and a tax export. A revenue treasury is a designated vault that receives the tenant's earned fees (its institution, external, and issuer fees); relinking it to a different vault goes through a quorum approved ceremony rather than a single edit.

On a fresh workspace, signer changes and counterparty additions are governance held: the console shows a held notice with the pending approval, the owner attests it under Governance, Approvals, and re-submitting the same form completes the change. This is the seeded secure default described in Policies and Quorum Governance.

For the underlying model, see Treasury and the Non-custodial Model. For approval quorums and governance, see Policies and Quorum Governance. For the exact operations, see the operations list or the interactive reference.

Was this helpful?