Category: chain-agnostic account-identifier standard / cross-chain wallet subject format / interoperability primitive
Summary: CAIP-10 is best understood as the cross-chain account naming layer for wallets and auth systems rather than as a generic address-format note. Its core mechanism is to prepend a CAIP-2 chain identifier to an account string, creating a portable chain_id:account_address subject that can represent accounts across incompatible ecosystems without relying on wallet-specific data structures. That makes it a useful comparison class for did:pkh, CAIP-122, EIP-4361, CAIP-217, and wallet-session standards: before an app can authenticate a wallet, scope permissions, or reason about delegated authority, it needs a canonical way to say which account on which chain is the subject.
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.