Category: chain-agnostic wallet-auth capability-receipt standard / signed authorization container / IPLD capability object
Summary: CAIP-74 is best understood as the receipt layer that turns wallet-auth messages into reusable capability objects rather than as just another sign-in format. Its core mechanism is to package a CAIP-122-style authentication payload, a typed signature, and minimal header metadata into a deterministic IPLD object that can be serialized, transported, and chained. That makes it a useful comparison class for CAIP-122, CAIP-222, ERC-5573/ReCaps, and WalletConnect Auth: the important shift is from “did this wallet sign in?” to “what signed capability object can another system verify, store, forward, and compose?”
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.