Summary: CAIP-74 is the signed receipt format for wallet auth. It packages a CAIP-122-style authentication payload, signature metadata, and minimal headers into a reusable CACAO object that other systems can verify, store, and forward. That matters because auth is often more useful as a portable capability receipt than as a one-off prompt result.
What it does:
Defines a CACAO container with header, payload, and signature sections for chain-agnostic signed capability objects
Reuses the CAIP-122 sign-in payload model so fields like domain, audience URI, nonce, timing bounds, statement, request ID, and resources stay portable across ecosystems
Uses did:pkh as the issuer format so the subject includes both account and chain context rather than only a bare address
Encodes the result as an IPLD object that can be deterministically serialized, identified, and transported as a CAR file
Supports multiple signature verification styles by carrying an explicit signature type such as eip191 or eip1271
Frames wallet authentication as the starting point for richer capability chains instead of the endpoint of login
Key claims:
The abstract makes the main analytical move explicit: CAIP-74 records the result of a CAIP-122 signing operation as a composable and replayable authorization receipt. That is a different job than defining the auth message itself.
The most important design choice is the split between payload semantics and container semantics. CAIP-122 standardizes the sign-in fields; CAIP-74 standardizes how that signed result becomes a reusable object.
The use of IPLD and CAR serialization matters because it turns wallet auth into portable capability data rather than app-local session state. Whoever controls the object grammar, serialization, and verification rules controls what later systems can treat as a valid delegated receipt.
did:pkh as issuer is a key control-surface clue. It ties subject identity to a chain-qualified account string, which makes cross-chain subject formatting and DID-method maintenance part of the trust stack.
The backwards-compatibility note is revealing: newer implementations must handle both eip4361 and caip122 header types. That shows how Ethereum-first sign-in conventions still shadow supposedly chain-agnostic standards.
CAIP-74 belongs in the corpus because it clarifies the missing middle layer between login prompts and capability systems: the signed receipt format that downstream wallets, apps, and resource services can verify and compose.
Whitepaper: No standalone CAIP-74 whitepaper or litepaper surfaced in this pass. The clearest primary materials were the official CAIP text plus repository context; see ../../whitepapers/caip-74-primary-sources-2026-05-10.md.