CAIP-222

• Name: CAIP-222 (Wallet Authenticate JSON-RPC Method)
• URL: https://standards.chainagnostic.org/CAIPs/caip-222
• Category: chain-agnostic wallet-authenticate RPC standard / combined connect-and-sign flow / multi-chain authentication handshake
• Summary: CAIP-222 is best understood as a one-shot wallet authentication handshake rather than as a general wallet session standard. Its core mechanism is to bundle account exposure and signed authentication into a single wallet_authenticate JSON-RPC call that returns one or more signed CACAOs, without requiring the app to know accounts in advance. That makes it a useful comparison class for CAIP-122, CAIP-25, WalletConnect Auth, and ERC-5573/ReCaps: the important question is when wallet UX should stop at proof of account control, when it should establish a persistent session, and when auth should already carry scoped capabilities.
• What it does:
  • Defines a wallet_authenticate JSON-RPC method for requesting wallet authentication across one or more CAIP-2 chains
  • Lets callers submit CAIP-122-style auth fields plus a CAIP-74 header type and optional namespace-specific signature-type preferences
  • Returns zero, one, or more signed CACAOs so the relying party receives verifiable account-control proofs rather than only optimistic account exposure
  • Allows wallets to ignore unsupported chains instead of failing the whole request when at least some requested chains can be signed
  • Uses explicit user approval and domain binding requirements to reduce phishing and silent-account-leak patterns
  • Positions wallet authentication as a lighter-weight alternative to opening a full persistent wallet session for apps that only need proof of control
• Key claims:
  • The core analytical move is to collapse two familiar steps — connect wallet, then sign auth message — into one method. That is UX simplification, but it also changes where trust is concentrated in wallet policy and prompt design.
  • CAIP-222 depends on CAIP-122 and CAIP-74, which means it is not a freestanding auth invention. It operationalizes existing auth-message and capability-object standards inside a single RPC request.
  • The optional signatureTypes field is more important than it first appears because it turns algorithm negotiation into part of the request surface. That shifts some control toward callers, namespace maintainers, and wallet support matrices instead of leaving signature choice entirely implicit.
  • The spec’s guidance to ignore unsupported chains rather than reject outright is analytically useful because it makes partial authorization a first-class behavior. Multi-chain authentication can degrade into a wallet-selected subset, not an all-or-nothing contract.
  • The privacy section matters because successful auth necessarily exposes the chosen account to the relying party. CAIP-222 is not just a signing optimization; it is an account-disclosure policy surface.
  • The most useful comparison is against CAIP-25: CAIP-222 proves account control and can hint at later capabilities, but it does not itself define the long-lived session object that CAIP-25 negotiates.
  • CAIP-222 strengthens the corpus because it helps separate three often-blurred layers: account discovery, signed authentication, and persistent wallet authorization.
• Whitepaper: No standalone CAIP-222 whitepaper or litepaper surfaced in this pass. The clearest primary materials were the official CAIP-222 text plus WalletConnect Auth implementation context and the adjacent CAIP-74 / CAIP-122 standards; see ../../whitepapers/caip-222-primary-sources-2026-05-10.md.
• Sources:
  • https://standards.chainagnostic.org/CAIPs/caip-222
  • https://raw.githubusercontent.com/ChainAgnostic/CAIPs/main/CAIPs/caip-222.md
  • https://standards.chainagnostic.org/CAIPs/caip-74
  • https://standards.chainagnostic.org/CAIPs/caip-122
  • https://raw.githubusercontent.com/WalletConnect/walletconnect-specs/main/docs/specs/clients/sign/wallet-authentication.md

Internal linkages

• Authentication-envelope substrate that CAIP-222 operationalizes in one RPC call: caip-122
• Persistent-session contrast once the app needs durable authority instead of a one-shot proof: caip-25
• Closest deployed wallet-auth analogue: walletconnect-auth

Control surface

• CAIP-222 lives in wallet RPC, prompt policy, domain-bound message construction, and account-disclosure defaults. It is upstream of settlement and smart-account execution.

• The leverage is in partial-chain acceptance, signature-type negotiation, and wallet policy about whether a successful proof stays a one-shot login or turns into a larger session or product graph.

• Treat it as a compressed connect + sign in handshake, not as a general session rail.

• Last reviewed: 2026-06-05 UTC