Tenants and Workspaces

XKOVA isolates each institution at two levels. A tenant is the institution itself, and a workspace is an operational scope inside it. Every customer request is restricted to its authorized tenant and workspace.

Tenant: the institution

A tenant is the institution using XKOVA, for example a bank, a credit union, or a fintech. The tenant scope owns the institution's verified member bindings and directory, billing, staff, branding, and compliance policy. The institution or its authenticated channel remains the identity authority. Each tenant receives a strict sandbox and production workspace pair, so every institution can keep test and live operations isolated. See Supported Networks for how those environments map to chains.

Workspace: the operational scope

A workspace is the scope inside a tenant where day to day operations live. Operational data such as payments, escrows, treasury, wallets, fees, and member sessions is scoped to a workspace. A workspace is not a network or token configuration boundary. Its available networks and assets are derived automatically from the installation and workspace mode. A fresh workspace is also provisioned with a seeded governance baseline: owner approval is required on its highest impact actions until the owner tunes those requirements. See Policies and Quorum Governance.

Scope	What lives here
Tenant	Verified member bindings, billing, staff, branding, compliance policy.
Workspace	Payments, escrows, treasury, wallets, fees, member sessions.

Automatic network and asset catalogs

A tenant does not enable networks or tokens. XKOVA derives the workspace catalog from mode, the active chain registry, and the active asset registry. It also includes the workspace's own active TokenFactory ERC-20, ERC-721, and ERC-1155 deployments. Adding a supported chain or registered asset makes it available automatically wherever its tier applies.

Call	Returns
`GET /v1/chains/available`	Every active chain applicable to this installation and workspace mode.
`GET /v1/workspace-tokens`	Active external assets on those chains plus this workspace's active TokenFactory assets.

Each asset row identifies its chain_ref, source, asset_standard, permit_strategy, rails_eligible, and certification state. Catalog availability is not permission to use every payment rail. Select an asset whose exact flow is eligible and runtime certified for the operation. NFT assets appear in the catalog for holdings and asset operations even when rails_eligible is false.

Both catalog endpoints are read only. There are no network or token enable and disable calls, onboarding choices, or settings toggles.

Tenant and workspace isolation

Every customer request runs under its authorized tenant and workspace, and access outside that scope is rejected. A workspace-scoped key always gets strict workspace isolation, and the tenant boundary always holds on top of that, so one customer cannot use its credential to read or change another customer's data. XKOVA management and partner-management principals use separate private surfaces that are not published by the customer SDK.

Tenant and workspace scope is an authorization invariant, not a caller-supplied filter.

How keys map to scope

An integrator authenticates with a tenant API key scoped to a workspace, so its calls operate inside one workspace without being pinned to a network. Customer applications do not receive a cross-tenant management credential. XKOVA management users sign in to the private Console, and private partner-management functionality remains outside @xkova/sdk.

Authentication: API keys, bearer sessions, and federated or bring your own identity.
Authorization and RBAC: customer roles and permissions.

For where these scopes come from when you first set up, see Customer Onboarding. For the actors that operate within a tenant, see the Platform Overview.

Was this helpful?