XKOVA Docs

Supported Networks

A workspace receives every active chain applicable to its mode. Networks are not pinned at onboarding. Each chain-bound resource still identifies the exact network used for that operation.

Mode mapping across every installation

Workspace mode alone determines whether the automatic catalog contains testnets or mainnets. Installation selects where the service and credentials run, never the network tier.

InstallationSandbox modeProduction mode
Local or local VMTestnetsMainnets
StagingTestnetsMainnets
ProductionTestnetsMainnets

Active Avalanche Fuji and Base Sepolia deployments can appear in every sandbox catalog. Active Avalanche and Base deployments can appear in every production-mode catalog. A deployed contract or ready registry entry does not appear until the chain is active. Mainnet catalog availability does not bypass production access, billing, compliance, authorization, or runtime certification. For sandbox behavior, see the Quickstart and the operations under All Operations.

Discovering chains

GET /v1/chains is the global ready and active registry. An authenticated client uses GET /v1/chains/available for the active chains actually applicable to its workspace mode. Each row carries a stable chain_ref, an is_testnet flag, and the native gas symbol.

  • chain_ref is the stable, environment portable identifier you key on. The internal chain UUID is per environment and not portable, so it is never the public identity.
  • is_testnet identifies the chain tier already selected by workspace mode.
  • native_symbol is the native gas token, for example AVAX or ETH.

The chain descriptor

Every chain bound resource carries an embedded chain descriptor, so a consumer always knows which chain a resource settled on, and whether it was testnet or mainnet, without a second call. A resource always carries exactly one chain, resolved from the wallet, token, or explicit operation-level selection.

"chain": {
  "ref": "43113",
  "kind": "evm",
  "name": "Avalanche Fuji",
  "is_testnet": true,
  "native_symbol": "AVAX"
}

Operation-level selection

Some requests accept chain_ref or chain_id because the operation must choose one available network. Tokenization deploys are one example. Payment and escrow requests must also agree with the referenced wallet and token deployment. A conflict or an inapplicable chain returns chain_not_allowed. Onboarding accepts no chain selection.

Adding and activating another supported chain makes it appear automatically. Integrations should read the available catalog and chain descriptors instead of hardcoding Avalanche or Base.

Related

See Tenants and Workspaces for automatic asset availability, and Wallets and Balances for the assets a member holds on it.