Category: chain-agnostic wallet-routing standard / browser-extension connection target spec / CAIP-294 companion transport primitive
Summary: CAIP-341 is best understood as a wallet-routing primitive inside the broader browser wallet discovery stack rather than as a discovery standard on its own. Its core move is to define caip341 as a target type that can be included in CAIP-294 wallet_announce payloads, letting a dapp learn not just that a wallet exists but which browser-extension endpoint it should connect to through externally_connectable. The mechanism significance is that CAIP-341 turns extension connection details into standardized wallet metadata, shifting practical control toward the routing hints, target arrays, and browser APIs that determine which communication channel wins after wallet discovery.
What it does:
Defines caip341 as a valid wallet target type for CAIP-294 browser-extension wallet announcements
Lets wallets publish an extension ID inside the optional target array of the WalletData object
Tells dapps that when a caip341 target is present they must establish communication through the browser externally_connectable API rather than guess the transport
Standardizes how routing metadata can sit alongside wallet identity fields like UUID, name, icon, and reverse-domain identifier
Connects extension discovery to later wallet-session flows such as wallet_createSession, making the target field a precursor to authorization and session state rather than just UX metadata
Explicitly positions itself as a chain-agnostic extension of the same anti-fragmentation goal pursued by EIP-6963 and Solana Wallet Standard
Key claims:
The draft says CAIP-341 defines the Extension ID type as a valid target type for establishing connections with browser extension wallets via CAIP-294 wallet_announce, which is the clearest reason to catalog it as routing infrastructure rather than as another wallet-discovery proposal
The motivation section explicitly frames the problem as fragmentation across wallet discovery mechanisms such as EIP-6963 and Wallet Standard, so CAIP-341 is trying to standardize the transport handoff layer that those discovery systems leave ecosystem-specific
The most important design move is that the wallet can advertise not only identity metadata but also the connection method that should be used. That means power sits partly in the target array and the libraries that interpret it, not only in discovery events or injected provider objects
The spec says that when target.type is caip341, the dapp MUST use the extension ID to connect through runtime.connect() / runtime.sendMessage() over externally_connectable, so the proposal is standardizing which browser channel should be canonical after discovery
Because the target field is optional and extensible, CAIP-341 is also analytically useful as a comparison point for later CAIP target definitions: once routing becomes structured metadata, the transport layer itself becomes governable and composable
The proposal matters in this corpus because it helps separate discovery, routing, and authorization into distinct layers: CAIP-282/294 find wallets, CAIP-341 tells the dapp which extension channel to use, and CAIP-25 / related session methods govern what the established session can do
Whitepaper: No standalone CAIP-341 whitepaper or litepaper surfaced in this pass. The clearest primary materials were the official draft page, the raw markdown in the CAIPs repository, and the linked GitHub proposal history; see ../../whitepapers/caip-341-primary-sources-2026-05-10.md.