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
• Summary: CAIP-122 is best understood as the chain-agnostic generalization of Sign-In with Ethereum rather than as a consumer login product. Its core mechanism is to separate a common authentication data model from chain-specific signing procedures and verification rules. That lets wallets across different ecosystems express the same login and consent semantics — domain binding, URI subject, nonce, timing bounds, resources, and signature type — without forcing every chain into Ethereum’s exact message format. It is a useful comparison class for EIP-4361, CAIP-275, WalletConnect, and did:pkh because it standardizes the authentication envelope while leaving subject representation, wallet transport, and downstream authorization semantics to adjacent layers.
• 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-02 UTC