CAIP-122 primary sources — 2026-05-10

What I reviewed

• Official standard and repository context:
  • https://standards.chainagnostic.org/CAIPs/caip-122
  • https://github.com/ChainAgnostic/CAIPs
  • https://github.com/ChainAgnostic/CAIPs/blob/master/README.md

Key takeaways from primary sources

• CAIP-122 generalizes Sign-In with Ethereum into a chain-agnostic authentication data model instead of forcing every wallet ecosystem into Ethereum-specific message semantics.
• The main architectural move is the split between a common abstract data model and namespace-specific implementation profiles for signing and verification.
• Required fields like domain, URI, chain ID, address, signature, and signature type define the minimum interoperable login envelope; nonce and timing fields provide replay and session controls when used.
• The spec keeps the message human-readable where possible, preserving the informed-consent pattern that made SIWE valuable at the wallet UX layer.
• Wallet implementers are expected to verify domain binding against a trusted browser source, which means phishing resistance is treated as part of wallet policy rather than only a server concern.
• The motivation section explicitly links CAIP-122 to CAIP-74, making SIWx a foundation for richer chain-agnostic capability objects rather than just a login prompt standard.

Specific source signals worth retaining

• Abstract and motivation: best concise explanation that EIP-4361 is a specific implementation of a broader cross-chain auth model.
• Namespace-specification section: most important governance/control-surface clue, because it shows that each ecosystem decides how the standardized fields actually get signed and verified.
• Example message format: useful evidence that CAIP-122 is trying to preserve readable consent text instead of reducing wallet auth to opaque bytes alone.
• Wallet-implementer guidance: key anti-phishing requirement that the domain in the message must match the real request origin.
• CAIPs repository README: useful provenance that CAIPs are cross-chain standards and that the canonical index lives under the Chain Agnostic standards process.

Why this entry belongs in the corpus

• It strengthens the wallet-auth and identity-bootstrap side of the corpus with a standards-layer entry that sits between chain-specific wallets and application sessions.
• It is a direct comparison class for EIP-4361, CAIP-275, WalletConnect, and CACAO because it isolates the authentication envelope from wallet transport and downstream authorization.
• The reusable insight is that “wallet login” power often lives in specification boundaries: who defines the fields, who maintains namespace profiles, who validates domains, and who decides what message shape a user must consent to.