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.
| Installation | Sandbox mode | Production mode |
|---|---|---|
| Local or local VM | Testnets | Mainnets |
| Staging | Testnets | Mainnets |
| Production | Testnets | Mainnets |
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_refis 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_testnetidentifies the chain tier already selected by workspace mode.native_symbolis 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.
Related
See Tenants and Workspaces for automatic asset availability, and Wallets and Balances for the assets a member holds on it.