Cowrie Research

caip-10-primary-sources-2026-05-10

2 min read

CAIP-10 primary sources — 2026-05-10

Classification takeaway

CAIP-10 is most usefully classified as cross-chain account identifier infrastructure: a subject-format standard that names which account on which chain is being referenced, while leaving authentication, session negotiation, and most canonicalization policy to higher or adjacent layers.

Primary sources reviewed

  1. Official CAIP-10 page — https://standards.chainagnostic.org/CAIPs/caip-10

    • Defines the chain_id:account_address account ID structure and explicitly positions the proposal as a way for wallets and dapps to communicate accounts across many blockchains.
    • Shows that the standard’s purpose is interoperability of subjects, not a single universal address-validation scheme.

  2. Raw CAIP-10 markdown — https://raw.githubusercontent.com/ChainAgnostic/CAIPs/main/CAIPs/caip-10.md

    • Includes the exact grammar, canonicalization guidance, backwards-compatibility history, and examples across EVM, Bitcoin, Cosmos, Polkadot, StarkNet, and Hedera.
    • The canonicalization section is especially important because it leaves room for namespace-specific profiles and implementer-side deduplication, which means power over “same account” decisions is not fully standardized away.

  3. CASA namespaces registry — https://namespaces.chainagnostic.org/

    • Provides the namespace-level context implied by the CAIP-10 spec’s references to CAIP-2 and namespace profiles.
    • Reinforces that account identifiers inherit upstream namespace governance and resolution assumptions rather than replacing them.

  4. Chain Agnostic CAIPs repository — https://github.com/ChainAgnostic/CAIPs

    • Places CAIP-10 inside the broader CAIP stack that later feeds wallet-auth, capability, and session-management standards.
    • Helps explain why CAIP-10 should be read as foundational subject-format infrastructure rather than as a narrow wallet implementation detail.

Why it stays in the active corpus

  • It is a useful comparison point for did:pkh, CAIP-122, EIP-4361, and CAIP-217 because all of them need a way to name the subject before they can authenticate or authorize it.
  • It surfaces an important control question: where canonicalization and deduplication power lives when one standard names accounts but declines to fully normalize them.
  • It sharpens the corpus distinction between subject naming, proof of control, and session permissions instead of flattening all three into one generic “wallet connect” layer.

Graph View