Summary: CAIP-311 is best understood as the push-based change-notification primitive in the CAIP-25 wallet-session stack rather than as just another wallet event. Its core move is to standardize how a wallet tells a caller that session authorizations changed on the wallet side after the original handshake, which matters whenever the wallet remains the live authority over permissions. That makes it a useful comparison class for CAIP-285, CAIP-312, and CAIP-316: those cover revocation, pull-based state retrieval, and lifecycle guidance, while CAIP-311 defines the event path for wallet-initiated authorization changes.
What it does:
Defines a wallet_sessionChanged JSON-RPC notification for active CAIP-25 sessions
Lets wallets push updated authorization scopes to callers when users change permissions directly in the wallet
Sends the full updated sessionScopes payload rather than relying on wallet-specific event semantics
Optionally includes a sessionId so the notification can identify which session changed when multiple sessions exist
Explicitly tells callers to use wallet_getSession if connectivity is interrupted and missed events are possible
Extends CAIP-25 so session lifecycle management is not limited to the initial wallet_createSession handshake
Key claims:
The most important design move is treating wallet authorization as a live relationship instead of a one-time connect flow. CAIP-311 makes mid-session permission changes first-class rather than wallet-specific edge cases.
The event matters because it shifts practical authority toward the wallet and user action layer after connection establishment. A dapp cannot safely assume its locally cached permissions remain canonical once the wallet can push updated scopes.
The requirement to send the full updated sessionScopes object is analytically important. It makes the event a state-replacement surface, not just a sparse diff stream, which reduces ambiguity for downstream clients.
CAIP-311 is strongest when read together with CAIP-312. One defines the push path for wallet-side changes; the other defines the pull path for rehydrating current state after reconnects or missed notifications.
The security guidance is also part of the mechanism, not boilerplate. The recommendation for domain-bound or other 1:1 transports, plus optional sessionId binding, shows that wallet-session notifications are also an authentication and hijacking surface.
In corpus terms, CAIP-311 helps unbundle “connect wallet” into separate lifecycle verbs: create a session, receive wallet-originated updates, query current state, and revoke the relationship.
The best comparison frame is not generic event subscription; it is “the wallet-driven session-authority update channel inside the broader CAIP-25 lifecycle stack.”
Whitepaper: No standalone CAIP-311 whitepaper or litepaper surfaced in this pass. The strongest primary materials were the official draft text, the raw CAIP markdown, the lifecycle-method proposal diff, and adjacent CAIP-25 / CAIP-312 / CAIP-316 texts; see ../../whitepapers/caip-311-primary-sources-2026-05-10.md.
Keep it on the push-based authorization-update path from wallet to caller. It is not the query method, not the revoke method, and not a broad wallet-connectivity explainer.