Supported Networks

A workspace settles on exactly one chain, pinned at onboarding. Sandbox workspaces run on Avalanche Fuji testnet, and production workspaces run on Avalanche mainnet. The public API shape is locked for multichain, so every chain bound response already carries a stable chain descriptor.

Sandbox and production

The chain a workspace settles on follows its environment. Sandbox is backed by Fuji testnet USDC and never moves real money. Production settles on Avalanche mainnet against Circle USDC. The two are isolated by construction, and keys do not cross between them.

For the full sandbox model, including programmable failure scenarios and the testnet faucet path, see the Quickstart and the operations under All Operations.

Discovering chains

A client does not hardcode a chain. It reads the chain registry to find the chains its workspace mode can pin. Each registry row carries a stable chain_ref, an is_testnet flag, and the native gas symbol, so a sandbox client filters to testnet chains and a production client filters to mainnet chains without guessing.

• 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 tells a client whether the chain is sandbox pinnable or production pinnable.
• native_symbol is the native gas token, for example AVAX.

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 server side from the workspace pin.

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

Multichain posture

The public API shape is locked for multichain. Every chain bound response carries the chain descriptor above, and payment, escrow, and onboarding requests accept an optional chain_ref override. For onboarding it must be a chain selectable by the workspace mode (sandbox to testnet); for payment and escrow it must equal the chain the request resolves to (the from_wallet's or token deployment's chain). A mismatch returns chain_not_allowed. Because the shape is already in place, lighting up a second chain is a backend and configuration rollout with no request, response, or SDK shape change.

Related

See Tenants and Workspaces for how a workspace pins its chain, and Wallets and Balances for the assets a member holds on it.