Summary: CAIP-211 is best understood as an authority-negotiation extension for wallet sessions rather than as just another RPC schema note. Its core mechanism is to let wallet and app sessions negotiate not only method names, but ordered RPC documents and ordered RPC endpoints inside authorization scopes. That makes it a useful comparison class for CAIP-25, CAIP-217, WalletConnect, and chain registry systems: the important question is who gets to define the authoritative RPC surface, which endpoint set is trusted or preferred, and whether custom network capabilities override namespace defaults or remain sandboxed beneath them.
What it does:
Defines rpcDocuments and rpcEndpoints as ordered URI arrays inside CAIP-217 authorization scopes
Lets a session negotiate which RPC specification documents describe the methods and notifications that are actually in scope
Lets a session negotiate preferred routing endpoints for those requests instead of assuming one implicit node set
Distinguishes between assumed values, implicit namespace-profile defaults, and explicit negotiated values for RPC documents and endpoints
Uses array ordering as an authority and priority signal when multiple documents or endpoints are present
Gives wallets a way to reject, counter-propose, or progressively authorize unfamiliar RPC authorities rather than silently inheriting every caller-supplied network extension
Key claims:
The abstract makes the main move explicit: CAIP-211 is for negotiating exact RPC versions and routing preferences, not just generic support for a method family. That is why it belongs in the corpus as a control-plane spec rather than a transport detail.
The most analytically useful distinction is the spec’s ladder from assumed values to implicit values to explicit values. It shows how wallet authority can shift from hardcoded defaults toward negotiated, potentially higher-risk custom RPC surfaces.
The ordered-array rule matters because it turns list position into a trust and precedence signal. For rpcDocuments, later documents may extend but must not redefine earlier ones; for rpcEndpoints, ordering expresses namespace-specific preference or fallback. This is where policy and priority become serialized.
The CAIP-25 example is especially useful because it shows several distinct security postures: prioritize namespace defaults, prioritize requested extensions, force defaults only, or explicitly reject requested values. The point is not merely that negotiation exists, but that wallets can operationalize different trust modes while preserving a uniform handshake shape.
The security section is unusually revealing about real wallet power. A wallet can validate unfamiliar endpoints, validate unfamiliar documents, drop the request, or counter-propose known values. That means the practical control surface sits with wallet policy engines, trusted registries, and namespace profiles, not only with the requesting dapp.
The privacy guidance is also important: wallets should avoid verbose rejection patterns that let dapps fingerprint supported custom RPCs. So CAIP-211 is partly a privacy-preserving negotiation spec, not just a capability-discovery spec.
The recommendation to use checksummed or commit-pinned URI types when immutability matters highlights another subtle governance surface: whichever publication system or URI convention a namespace standardizes can become part of the trust infrastructure for wallet interoperability.
CAIP-211 strengthens the corpus because it explains how session authorization can quietly become endpoint routing, version selection, and trust-list policy. That is the missing layer between plain login/auth specs and full wallet-session control.
Whitepaper: No standalone CAIP-211 whitepaper or litepaper surfaced in this pass. The clearest primary materials were the official CAIP-211 and CAIP-217 texts plus CAIP-25 context; see ../../whitepapers/caip-211-primary-sources-2026-05-10.md.