CAIP-282
- Name: CAIP-282 (Browser Wallet Discovery Interface)
- URL: https://standards.chainagnostic.org/CAIPs/caip-282
- Category: chain-agnostic browser wallet-discovery standard / multi-wallet announcement interface / anti-lock-in coordination layer
- Summary: CAIP-282 is best understood as a chain-agnostic wallet discovery layer for browser environments rather than as a wallet product or a namespace-specific provider API. Its core move is to define common
wallet_promptandwallet_announceJSON-RPC payloads for discovering wallets across ecosystems, while standardizing wallet identity metadata through CAIP-372 and tying follow-on session creation and signing into CAIP-25 and CAIP-27. The mechanism significance is that CAIP-282 tries to move wallet discovery away from chain-specific injection conventions and toward a broader browser coordination layer, reducing some ecosystem lock-in while creating new soft power around wallet metadata, scope filtering, and the libraries that mediate wallet choice. - What it does:
- Defines a standardized browser wallet discovery interface for dapps and blockchain libraries
- Uses
wallet_promptandwallet_announceJSON-RPC messages so wallets and libraries can discover each other after initialization - Standardizes wallet identity data through the CAIP-372
WalletInfoobject, including fields like UUID, name, icon, and reverse-domain identity - Lets wallets optionally advertise authorization scopes from CAIP-217 and supported chains so dapps can filter candidates before a user connects
- Recommends per-page UUID generation and reuses that identifier as a session key only after the user approves a CAIP-25 connection flow
- Bridges discovery into later session messaging and signing flows through CAIP-25 and CAIP-27 rather than treating discovery as a standalone UX layer
- Key claims:
- The draft spec says CAIP-282 defines a standardized interface for browser wallet discovery, which is the clearest reason to treat it as discovery coordination infrastructure rather than a wallet-specific SDK
- The motivation section says dapps currently need to support many wallet APIs across ecosystems and explicitly names WalletConnect, EIP-6963, and Solana Wallet Protocol as partial but namespace-specific answers, showing that CAIP-282 is trying to generalize multi-wallet discovery beyond Ethereum alone
- The specification says both wallet providers and blockchain libraries must listen for messages published after initialization and must also publish announcement or prompt messages themselves, which makes discovery a two-sided protocol rather than a singleton global object convention
- The
wallet_promptparameters let dapps request wallets matching optional chains and auth names, whilewallet_announcecan include wallet info, targets, and authorization scopes, which means discovery doubles as an early capability-filtering layer - The draft says the
WalletInfoobject comes from CAIP-372 and can include machine-readable identity data like UUID and RDNS, which shifts part of wallet selection power into metadata schemas and wallet-selection libraries - The UUID section says wallets should generate distinct UUIDs for each page load and only reuse them as session IDs after approved CAIP-25 flows, making discovery state a precursor to later session-routing authority
- The privacy section warns that wallet discoverability can enable fingerprinting and says wallets may wait for incoming prompt messages instead of always announcing, but that this creates discoverability race conditions, showing that portability and privacy are in tension rather than automatically aligned
- Whitepaper: No standalone CAIP-282 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-282-primary-sources-2026-05-08.md. - Sources:
Internal linkages
-
Best direct comparison points: eip-6963, wallet-standard, and caip-25.
-
Keep the note on browser discovery, wallet metadata, and pre-session filtering. It is not the session object, not the injected-provider baseline, and not a general wallet-connectivity hub.
-
Last reviewed: 2026-06-02 UTC