Category: chain-agnostic domain-wallet authentication standard / name-to-auth-flow registry / wallet-selection and login coordination layer
Summary: CAIP-275 is best understood as a domain-to-wallet-authentication registry standard rather than as another wallet SDK or naming protocol. Its core move is to let a crypto domain publish an authenticator record that resolves to structured authentication-flow metadata: wallet address, optional chain, and an ordered list of platform- and transport-specific login methods such as browser extension, WalletConnect, or mobile wallet protocol. The mechanism significance is that CAIP-275 tries to move wallet-selection power away from raw provider injection and remembered addresses toward domain metadata, authenticator hosts, and the login libraries that decide which advertised flow to try first.
What it does:
Defines an authenticator text record that a crypto domain can expose to point at a URL or inline JSON describing how that domain should authenticate
Lets relying apps resolve a domain name into a wallet address plus an ordered authFlows list with platform, connection method, and optional URI hints
Supports browser-extension, WalletConnect-style, and mobile-wallet-protocol login paths rather than assuming one wallet transport
Recommends using EIP-6963 reverse-domain identifiers when a browser flow wants a specific injected wallet extension
Allows applications to skip unsupported flows and continue until one can complete or requires explicit user action
Bridges name-based login into later session and signing flows such as CAIP-25 rather than treating domain lookup as the whole authentication stack
Key claims:
The draft spec says Domain Wallet Authentication links a crypto domain with authentication methods or providers through an authenticator JSON/URL field, which is the clearest reason to treat it as a registry-and-routing layer for login rather than as a naming system by itself
The motivation section says existing authentication depends on users remembering both wallet provider and wallet address, and frames crypto domains as the usability abstraction that can sit above growing wallet and chain fragmentation
The storage-format section says compatible domain systems should expose an authenticator text record that dereferences to authentication-flow configuration, which means control can shift toward whoever controls the name record and authenticator endpoint
The schema requires an address and an authFlows array, with optional chain, platform, connection, and URI fields, so the standard is not merely naming an account; it is publishing routing hints for how the relying app should reach that account
The standard browser-extension flow says that when a specific wallet is requested, applications must check EIP-6963 wallets and match the requested reverse-domain identifier instead of silently swapping in some other injected provider, which makes wallet identity metadata a security boundary rather than just a UX nicety
The injected-default example warns that using a generic injected wallet can create race conditions and false positives when multiple wallets are present, which highlights that CAIP-275 is partly an attempt to reduce ambiguous provider selection
The WalletConnect fallback says the generic wc flow should never be skipped when supported because it allows user choice across platforms, showing that the standard intentionally mixes deterministic wallet routing with human-in-the-loop fallback
The connection-properties section explicitly points to CAIP-25 session management and direct signer SDK integrations, so CAIP-275 is best viewed as the domain-auth bootstrap layer beneath later session and signing control surfaces
Whitepaper: No standalone CAIP-275 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-275-primary-sources-2026-05-08.md.
Keep the note on the narrow thing it actually does: a domain-controlled bootstrap record that steers wallet choice before the real auth or session flow starts. Do not turn it into a generic wallet-connectivity directory.