Glossary

The words that recur across these docs have precise meanings on XKOVA. This page collects them in one place, grouped by area and cross-linked to the guide that covers each in depth. If a term reads ambiguously elsewhere, this is the definition it means. For how the pieces fit together, start with the Platform Overview.

Actors and Scopes

These terms describe who acts on XKOVA and the boundaries their access runs inside. The two isolation scopes, tenant and workspace, are covered in Tenants and Workspaces.

Term	Definition
Tenant	An institution using XKOVA, for example a bank, a credit union, or a fintech. The tenant scope owns what belongs to the institution as a whole: member identity, billing, staff, branding, and compliance policy. Each tenant is provisioned with a sandbox sibling automatically.
Workspace	The operational scope inside a tenant where day to day operations live. Payments, escrows, treasury, wallets, fees, and member sessions are scoped to a workspace, and a workspace is pinned to one chain at onboarding.
Member	An end user of a tenant, also called an account holder, who holds balances and signs their own value transfers in their own wallet. See Account Holders.
Operator	Staff who run a tenant from the console. An operator signs in with a session scoped to their tenant and acts under a role from the permission registry. See Authorization and RBAC.
Integrator	A backend system that calls the XKOVA API with a tenant API key. The key is pinned to a workspace, so an integrator's calls operate inside that one workspace. See Authentication.

Money Movement

These terms describe how value moves on the rails, XKOVA SPS. Every transfer is signed by its owner and submitted by the relayer, never by the platform holding a key.

Term	Definition
Treasury / vault	An institution's own operational funds held in a multisig vault, a Gnosis Safe owned by a set of staff signers. Value leaves the vault only when an N of M signer quorum has each attested to the transfer. See Treasury.
Revenue treasury	A treasury vault designated to receive a workspace's earned fees, the institution, external, and issuer fees the tenant collects into its own pockets. A fee schedule carrying an earned fee rule cannot commit unless the workspace has an active revenue treasury, and re-linking to a different vault is a quorum-gated attestation ceremony. See Fee Schedules.
Escrow	Held value that a sender commits before the recipient is ready to receive it. Use escrow when the recipient has no wallet yet, is known by email or phone rather than by address, or should choose the destination later. See Escrow and Claims.
Claim	The recipient side of an escrow. The recipient lands on a claim flow from a claim link that carries a token, verifies a one-time code to prove they control the channel, then resolves where the held value goes.
Relayer	The XKOVA Relayer, the sole executor of transfers. It takes a signed instruction, submits it on chain, and pays the gas. The owner signs and the relayer submits, so the application never holds a private key. See Transfers and Settlement.
Meta-transaction	A transfer authorized by an off-chain signature that someone else submits. The owner signs EIP-712 typed data, the XKOVA Relayer wraps it in the contract's meta-transaction entrypoint, and the contract recovers and verifies the signer on chain before it moves value. This is the non-custodial seam. See the Non-custodial Model.

Digital Assets

These terms describe the tokenized asset side of the platform, XKOVA TAMS.

Term	Definition
Tokenization	Issuing and managing programmable tokens on the rails: deploying ERC-20, ERC-721, and ERC-1155 token contracts, minting and burning, and setting on-token policies. See Tokenization Overview.
RWA	A real-world asset, an off-chain asset represented by a token, together with the metadata plane that describes it: published schemas, committed fields, provenance, and its cap table. See Real-World Assets.

Controls and Governance

These terms describe the controls that stand in front of a high impact action. Authorization decides who may attempt an action; governance decides whether it proceeds. See Policies and Quorum Governance.

Term	Definition
Policy firewall	The screen every transfer passes through before the XKOVA Relayer submits it. It 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.
Break-glass	The only sanctioned bypass of the normal approval quorum, for genuine emergencies. It is armed two of two (the owner plus one other principal), time boxed and auto expiring, and every action taken while it is armed is tagged and recorded as a high severity audit event. See Break-glass Access.
Fee schedule	The set of fee rules a workspace applies to its payments. Fees are recomputed at write time rather than trusted from an earlier quote, and a schedule carrying an earned fee rule requires an active revenue treasury before it can commit. See Fee Schedules.

API Mechanics

These terms describe how a request behaves at the API surface, independent of what it does.

Term	Definition
Gateway	The integration gateway, a deployable service that sits between XKOVA and an institution's core banking system. It speaks one stable contract to XKOVA and a core specific adapter to the bank, and it backs the hold, capture, and credit steps that funding and off-ramp depend on. See Core Banking.
Idempotency key	The Idempotency-Key header required on every mutating request. It lets you retry a write safely: the first request does the work, and every retry with the same key returns the original result. See Idempotency.
Cursor	An opaque token that marks a position in a list. List operations return one page at a time and hand you a cursor for the next page, so pagination stays correct while the underlying data changes. See Pagination.
Correlation id	A per-request identifier echoed on the X-Correlation-Id response header of every response, including pre-auth errors, and carried in the error envelope. Include it when you report an issue so a request can be traced end to end. See Support.

Related

• Platform Overview: how the two product pillars, the orchestration layer, and the actors fit together.
• Tenants and Workspaces: the two isolation scopes in depth.
• Non-custodial Model: the sign, relay, confirm mechanics behind every transfer.
• Payments: the money movement flow these terms describe end to end.