Category: chain-agnostic wallet-session revocation standard / CAIP-25 lifecycle primitive / authorization-exit control
Summary: CAIP-285 is best understood as the session-exit primitive in the CAIP-25 wallet-session stack rather than as a minor cleanup method. Its core move is to standardize how a caller or wallet counterpart can explicitly revoke an active authorization set, including flows where no sessionId maps cleanly onto a browser-extension connection. That makes it a useful comparison class for CAIP-25, CAIP-312, and CAIP-316: those define session creation, retrieval, and lifecycle guidance, while CAIP-285 makes revocation itself legible instead of leaving session termination to wallet-specific disconnect behavior.
What it does:
Defines a wallet_revokeSession JSON-RPC method for revoking an active CAIP-25 session
Supports both explicit sessionId-based revocation and no-sessionId flows where a wallet tracks the active session internally
Requires the wallet to remove authorizations and session properties associated with the revoked session on success
Specifies generic-failure behavior for unknown or untrusted contexts to reduce wallet fingerprinting and analytics leakage
Adds more specific trusted error codes for recognized counterparties that need to distinguish missing sessions from ambiguous no-sessionId cases
Fits into the broader CAIP-25 lifecycle family alongside wallet_getSession and wallet_sessionChanged
Key claims:
The main mechanism significance is that CAIP-285 turns revocation into an explicit protocol surface. Without something like this, wallet-session standards risk being strong on authorization creation but vague on how delegated power cleanly ends.
The draft is especially useful because it handles the messy case where extension-style wallet connections do not map neatly onto persisted sessionIds. That means the standard is solving an implementation reality, not just polishing an abstract API.
Its trusted-versus-generic failure design matters. The spec recommends vague errors for unknown counterparties while allowing sharper error codes in trusted contexts, which shows revocation doubles as a privacy surface and not only a lifecycle convenience.
CAIP-285 is analytically valuable in this corpus because it clarifies who owns session teardown authority. A wallet is not merely a signer responding to prompts; it is a stateful authorization manager that can invalidate previously granted scope.
Together with CAIP-312 and CAIP-316, the spec helps separate four layers that wallet UX often flattens together: session creation, current-state retrieval, wallet-initiated updates, and explicit revocation.
The document is a good example of how small companion standards can meaningfully shift the control surface: once revoke semantics are standardized, middleware and wallet libraries can no longer hide important authorization-exit behavior behind proprietary disconnect flows.
Whitepaper: No standalone CAIP-285 whitepaper or litepaper surfaced in this pass. The clearest primary materials were the official draft text, the raw markdown in the CAIPs repository, and the linked lifecycle-method proposal thread; see ../../whitepapers/caip-285-primary-sources-2026-05-10.md.