USDX Public Surface

Domain Policy
for supply accounting

USDX uses protocol-defined domain IDs to reconcile supply across 11 EVM networks. This policy explains what a domain is, why it is not the same thing as a native chain ID, and how the public API resolves domain aliases.

Canonical unit: domain_id
Phase 1 scope: 11 EVM chains
Updated: 2026-04-27

01 Overview

A domain is a protocol-defined integer identifier used by USDX to represent one supply-bearing network in the global accounting model. Domain IDs are assigned at system design time and remain stable for the life of the deployment.

Policy Rule
domain_id ≠ block.chainid
Native EVM chain IDs still matter on their home networks, but global USDX supply reconciliation relies exclusively on canonical domain IDs. The USDXGlobalSupplyController tracks remote domain supply keyed by domain ID, not by chain ID.

Phase 1 covers 11 EVM-compatible networks. All domains use the same USDXToken contract interface, the same 6-decimal denomination, and the same governance and compliance architecture.

02 Phase 1 Domain Registry

The following table defines the canonical domain ID assignments for all 11 Phase 1 networks. These values are fixed in the manifest files and in the public registry.

Domain ID Network Network Family EVM Chain ID
1EthereumEVM1
2Arbitrum OneEVM42161
3Polygon PoSEVM137
4BNB Smart ChainEVM56
5BaseEVM8453
6OptimismEVM10
7CeloEVM42220
8Avalanche C-ChainEVM43114
9ScrollEVM534352
10LineaEVM59144
11UnichainEVM130
ℹ️

Each network also has a distinct set of operator addresses: a governance multisig, an emergency multisig, a treasury operator, a compliance operator, a reserve reporter, and a supply reporter. These are defined per-chain in the deployment manifests and are independent of the domain ID assignment.

03 Alias Resolution

The public API resolves multiple aliases for GET /supply/{identifier}. An identifier may be a numeric domain ID, a network label, or a common short alias. All aliases resolve to the canonical domain object.

  • Ethereum: 1, ethereum, eth, ethereum-mainnet
  • Arbitrum: 2, arbitrum, arb, arbitrum-mainnet
  • Polygon: 3, polygon, poly, polygon-mainnet
  • BNB Chain: 4, bnb, bsc, bnb-mainnet
  • Base: 5, base, base-mainnet
  • Optimism: 6, optimism, op, optimism-mainnet
  • Celo: 7, celo, celo-mainnet
  • Avalanche: 8, avalanche, avax, avalanche-cchain-mainnet
  • Scroll: 9, scroll, scroll-mainnet
  • Linea: 10, linea, linea-mainnet
  • Unichain: 11, unichain, unichain-mainnet
⚠️

Aliases that are ambiguous (e.g., a short name that could match multiple networks) should not be added. The canonical rule is: one alias maps to exactly one domain. Unknown aliases return 404.

04 Adding Domains

New domains may be added in future phases when they meet the deployment criteria. All new domains must be EVM-compatible in Phase 1+. Non-EVM support requires separate aggregation infrastructure and a separate policy amendment.

  1. Assign a unique canonical domain_id sequentially from 12 onward.
  2. Create and populate a deployment manifest with operator addresses and configuration.
  3. Deploy the full six-contract stack and verify via the RPC smoke matrix.
  4. Register the domain in the public registry with real contract addresses.
  5. Update the USDX_REMOTE_DOMAIN_IDS parameter on all existing domains via the governance timelock (48-hour delay applies).
  6. Update this policy document, the transparency API reference, and the public registry rules.
Read Registry Rules Read API Reference Open the Live Hub