CAIP-122

• Name: CAIP-122 (Sign in With X / SIWx)
• URL: https://standards.chainagnostic.org/CAIPs/caip-122
• Category: chain-agnostic wallet-authentication standard / offchain session bootstrap / self-custodied identity-provider abstraction
• Tags: ethereum-ecosystem solana-ecosystem bitcoin-ecosystem
• Summary: CAIP-122 is the chain-agnostic wallet-auth envelope, not a session standard. It standardizes the fields and consent shape for wallet sign-in, then leaves message construction and verification to chain-specific profiles. The point is simple: common login semantics across ecosystems without pretending every chain signs the same thing.
• What it does:
  • Defines a chain-agnostic abstract data model for wallet-based authentication with offchain services
  • Requires core fields such as domain, account address, URI, version, chain ID, signature, and signature type, with optional fields for statement, nonce, issuance time, expiry, not-before, request ID, and resources
  • Lets each supported namespace define its own implementation profile for turning that data model into a signing input and for verifying signatures correctly for that chain
  • Adapts the human-readable sign-in pattern popularized by EIP-4361 so wallets can present informed-consent login prompts across non-Ethereum ecosystems
  • Tries to preserve interoperability for relying parties while avoiding forced wallet changes or chain-specific bespoke auth stacks for every application
  • Serves as an input layer for richer authorization receipts such as CACAO objects under CAIP-74
• Key claims:
  • The motivation section states the main intent very clearly: EIP-4361 is treated as one chain-specific implementation of a broader chain-agnostic authentication model rather than the universal standard itself.
  • The most important design move is the split between abstract fields and namespace-specific implementation profiles. CAIP-122 does not pretend every chain signs the same bytes the same way; it standardizes the meaning of the fields while delegating serialization and verification to each ecosystem.
  • Because each namespace must define signing algorithm, type strings, message-construction procedure, and verification rules, practical control shifts toward namespace maintainers and wallet implementers rather than sitting only in the top-level CAIP text.
  • The proposed string representation preserves the human-readable consent pattern of SIWE, which matters because wallet authentication is partly a UI security problem, not just a cryptography problem.
  • The wallet-implementer guidance makes domain binding an explicit anti-phishing responsibility. That means the wallet is expected to compare the stated domain against a trusted browser source instead of passively signing whatever text is shown.
  • The spec is analytically useful because it keeps authentication distinct from authorization. Fields like resources can point to things the relying party may resolve, but the standard itself stays focused on the signed login envelope.
  • CAIP-122 belongs in the corpus because it shows how crypto identity systems often centralize power in subtle places: message-shape standardization, namespace profiles, wallet prompt design, domain-validation policy, and server-side replay protections.
• Whitepaper: No standalone CAIP-122 whitepaper or litepaper surfaced in this pass. The clearest primary materials were the official CAIP text and the Chain Agnostic standards repository context; see ../../whitepapers/caip-122-primary-sources-2026-05-10.md.
• Sources:
  • https://standards.chainagnostic.org/CAIPs/caip-122
  • https://github.com/ChainAgnostic/CAIPs
  • https://github.com/ChainAgnostic/CAIPs/blob/master/README.md

Internal linkages

• Best direct comparison points: eip-4361, erc-5573, and walletconnect-auth.

• Keep the note on the envelope itself: shared fields, namespace-specific signing rules, and wallet-side domain checking. It is not a session standard and not a generic identity hub.

• Last reviewed: 2026-06-10 UTC