CAIP-2

  • Name: CAIP-2 (Blockchain ID Specification)
  • URL: https://standards.chainagnostic.org/CAIPs/caip-2
  • Category: chain-agnostic chain-identifier standard / namespace control plane / multi-chain interoperability primitive
  • Summary: CAIP-2 is best understood as the base naming layer for chain-agnostic crypto infrastructure rather than as just a formatting convention. Its core mechanism is to standardize a compact namespace:reference string for blockchains across ecosystems, then delegate the meaning of each namespace to separate namespace-specific resolution methods. That makes it a useful comparison class for CAIP-10, CAIP-19, WalletConnect, CAIP-25, and cross-chain wallet-auth standards: before any wallet can authenticate, authorize, route RPC, or reference assets across chains, someone has to decide what counts as the canonical chain identifier and who governs the namespaces that resolve those identifiers.
  • What it does:
    • Defines a case-sensitive chain_id format as namespace:reference
    • Lets a short namespace identify a family of chains or a resolution standard such as eip155, bip122, or cosmos
    • Keeps the base syntax small enough for onchain storage, hardware-wallet display, filenames on case-sensitive systems, and URL paths
    • Delegates the detailed semantics of each namespace and reference format to separate namespace specifications
    • Gives multi-chain apps, wallets, and standards a common way to refer to chains outside a single ecosystem-specific ID system
  • Key claims:
    • The important move is not merely cross-chain naming; it is governance by namespace. CAIP-2 says a global identifier exists only because each namespace points to some further resolution method, which means namespace maintainers quietly become part of the control surface for chain-agnostic interoperability.
    • The rationale section makes the design tradeoff clear: the format is intentionally constrained for portability across URLs, hardware-wallet screens, and onchain or transaction-adjacent contexts. So CAIP-2 is infrastructure for machine-readable trust boundaries, not just developer ergonomics.
    • The test cases are analytically useful because they span Ethereum, Bitcoin, Cosmos, StarkNet, and Lisk. That breadth shows CAIP-2’s role as a lowest-common-denominator coordination layer across ecosystems that otherwise use incompatible native identifiers.
    • Because later standards like CAIP-10 and CAIP-25 embed CAIP-2 identifiers, control over chain naming propagates upward into account identification, wallet-session scopes, and capability negotiation. A lot of later wallet-auth standardization inherits this foundation instead of replacing it.
    • The spec belongs in the active corpus because it helps separate three layers that often get flattened together: chain naming, subject naming, and session authorization. CAIP-2 only solves the first layer, but later standards depend on it.
  • Whitepaper: No standalone CAIP-2 whitepaper or litepaper surfaced in this pass. The clearest primary materials were the official CAIP-2 text, the raw CAIP markdown, and the Chain Agnostic CAIPs repository; see ../../whitepapers/caip-2-primary-sources-2026-05-10.md.
  • Sources:

Internal linkages

  • Immediate descendants: caip-10 and caip-25.
  • Deployed wallet middleware where the naming layer turns into actual session policy: walletconnect.
  • Reusable question: who controls the namespace definition once everyone upstream starts treating the identifier as canonical?
  • Last reviewed: 2026-06-03 UTC