Category: chain-agnostic browser-extension wallet messaging standard / extension transport layer / cross-ecosystem wallet session plumbing
Summary: CAIP-294 is browser-extension wallet transport plumbing. It standardizes how extension wallets announce themselves and open communication channels, then hands off to the broader CAIP session stack. The useful question is which discovery and routing conventions become default once libraries start treating them as normal.
What it does:
Defines a standardized browser-event transport for extension-wallet discovery and session bootstrapping
Uses caip294:wallet_prompt and caip294:wallet_announce custom events over window.dispatchEvent and window.addEventListener
Standardizes a walletData object with UUID, name, icon, and reverse-domain identity, plus optional targets and authorization scopes
Extends CAIP-282 by letting wallets advertise extension-specific targets such as CAIP-341 identifiers for browser externally_connectable messaging
Tells dapps to keep using the selected wallet UUID as the routing handle for later CAIP-25 handshake and CAIP-27 signing flows
Distinguishes between wallets that want communication through traditional injected-provider patterns and wallets that want a separate extension-messaging channel
Key claims:
The draft spec says CAIP-294 defines a standardized messaging transport for browser extension wallets, which is the clearest reason to treat it as transport infrastructure rather than another wallet SDK
The motivation section says developers currently support different messaging standards for different namespaces and that those patterns are not chain-agnostic, showing that CAIP-294 is trying to unify extension-wallet transport across ecosystems rather than only improve Ethereum UX
The specification defines caip294:wallet_prompt and caip294:wallet_announce custom events and says both wallets and blockchain libraries must listen and publish on initialization, which makes extension discovery an explicit event protocol instead of a load-order race
The walletData object is defined as a superset of the CAIP-282 announcement payload and can include optional targets and scopes, which means the transport layer also becomes a capability- and routing-disclosure surface
The targets section says that when a CAIP-341 target is present, the dapp should connect through the browser externally_connectable API and should not keep using the injected provider for communication, which is important because the draft is not just standardizing discovery metadata; it is trying to standardize which communication channel wins
The draft explicitly ties wallet selection to later CAIP-25 session establishment and CAIP-27 signing, so the standard is best viewed as transport plumbing for a broader wallet-session stack rather than as an isolated browser UX improvement
The spec again emphasizes per-page UUID generation and session reuse only after user-approved connection flows, which reinforces that routing identifiers and session plumbing are central control surfaces in the design
Whitepaper: No standalone CAIP-294 whitepaper or litepaper surfaced in this pass. The clearest current sources were the draft CAIP text and its official GitHub discussion trail collected in ../../whitepapers/caip-294-primary-sources-2026-05-08.md.