Category: chain-agnostic account-identifier standard / cross-chain wallet subject format / interoperability primitive
Summary: CAIP-10 is the cross-chain account naming layer. It prepends a CAIP-2 chain identifier to an account string to produce a portable chain_id:account_address subject. That is the useful part: before a wallet can authenticate, scope permissions, or delegate authority, the system needs a stable way to say which account on which chain it means.
What it does:
Defines a case-sensitive account_id format as chain_id:account_address, where chain_id follows CAIP-2
Lets wallets and dapps express accounts across many chains in one interoperable subject format instead of proprietary per-chain structures
Allows constrained punctuation in account identifiers, including -, ., and %, with URL-encoding guidance for further escaping
Leaves namespace-specific account semantics to the chain referenced by the CAIP-2 prefix rather than imposing one universal address model
Documents backwards-compatibility changes from older suffix-based or more restrictive forms into the current chain-prefixed syntax
Key claims:
CAIP-10’s main contribution is not address validation; it is subject normalization. It gives multi-chain systems a shared way to name the principal whose permissions, signatures, sessions, or attestations are being discussed.
Because the spec composes directly on CAIP-2, practical authority still sits partly upstream in namespace governance. If chain identifiers are the base naming layer, CAIP-10 is the account layer that inherits those same namespace assumptions.
The canonicalization section is more important than it first looks. The standard explicitly declines to enforce one global normalization rule, leaving deduplication and canonicalization partly to implementers and namespace profiles. That means wallets, middleware, and registries can still accumulate subtle power over what counts as the “same” account.
The backwards-compatibility history is analytically useful because it shows the format hardening around interoperability needs. Moving from {account}@{chain} to {chain}:{account} reflects pressure to make the subject easier to parse and embed inside later protocol layers.
CAIP-10 belongs in the active corpus because it helps distinguish subject identification from authentication and authorization. EIP-4361 or CAIP-122 may prove control of an account, and CAIP-25 / CAIP-217 may scope what that account can do, but CAIP-10 standardizes how that subject is named across chains.
Whitepaper: No standalone CAIP-10 whitepaper or litepaper surfaced in this pass. The clearest primary materials were the official CAIP-10 text, the raw CAIP markdown, and the CAIP namespace guidance linked from the spec; see ../../whitepapers/caip-10-primary-sources-2026-05-10.md.