CAIP-222 bundles account exposure and cryptographic authentication into one RPC request instead of forcing an app to connect first and then request separate signed proofs.
The method is explicitly built on top of CAIP-122 and CAIP-74, so its main innovation is handshake composition, not a new subject model or signature object.
The response returning one or more signed CACAOs is analytically important because the result is a verifiable receipt, not merely a wallet UI promise that certain accounts exist.
Multi-chain handling is intentionally partial: wallets can ignore unsupported chains and still return valid proofs for supported ones.
The optional signatureTypes parameter is a subtle but meaningful control surface because it constrains or reveals acceptable signing algorithms by namespace.
WalletConnect’s auth flow docs are useful implementation context because they show how auth requests can absorb ReCaps and become the bridge from proof-of-control into scoped later behavior.
Specific source signals worth retaining
Motivation and rationale: strongest evidence that the spec is trying to unify “connect” and “sign auth” into a lighter-weight one-shot handshake.
Request / response definitions: important for seeing exactly where CAIP-122 payload fields, CAIP-74 headers, and signature-type negotiation sit.
Not-supported-chains rule: key clue that partial grants are expected behavior, not an implementation accident.
Security and privacy sections: best reminder that domain binding and account exposure remain real wallet-policy surfaces even in a streamlined auth flow.
WalletConnect auth docs: useful evidence that real implementations often extend the auth flow toward capability negotiation through ReCaps.
ERC-5573 / ReCaps text: helpful comparison point for understanding how scoped authorization can be packed into auth-adjacent resources rather than left entirely for later sessions.
Why this entry belongs in the corpus
It strengthens the wallet-auth cluster with the combined authenticate-plus-account-discovery handshake layer that sits between pure sign-in standards and full wallet sessions.
It is a direct comparison class for CAIP-25 and WalletConnect because it clarifies when a wallet flow is just proving account control versus establishing a durable permissioned relationship.
The reusable insight is that simplification moves often relocate power: a one-call UX still embeds wallet policy over account selection, chain support, signature algorithms, and account disclosure.