Category: wallet-connection bootstrap URI standard / QR-link transport envelope / WalletConnect pairing-invitation format
Summary: ERC-1328 is best understood as the transport bootstrap envelope for WalletConnect-style wallet sessions rather than as a generic wallet-auth standard or a synonym for WalletConnect itself. Its core mechanism is a compact wc: URI that packages the minimum metadata needed to start a wallet-app handshake through a QR code or deep link: a topic, a protocol version, and version-dependent relay plus encryption parameters. That makes ERC-1328 analytically useful because it isolates the invitation layer beneath later WalletConnect pairing, session, and auth flows. The important question is not just how a wallet eventually connects, but which relay path, versioned handshake rules, and bootstrap payload shape control the very first app-to-wallet contact.
What it does:
Defines a wc: URI syntax for initiating wallet connections from applications via QR codes or links
Encodes a topic and protocol version plus version-dependent connection parameters in one transport string
For WalletConnect v1, carries a bridge server URL and symmetric key for the pairing bootstrap
For WalletConnect v2, carries a symmetric key plus relay protocol, optional relay data, supported methods, and optional expiry timestamp
Replaces earlier JSON-in-QR patterns with a lighter URI form intended to be easier for wallet parsers and mobile deep-link systems
Serves as the bootstrap artifact that hands an app’s connection request into the wallet before later pairing and session protocols take over
Key claims:
The ERC abstract says the standard exists to define how application-to-wallet connection data is encoded in a URI, which is the clearest reason to catalog ERC-1328 as invitation and transport infrastructure rather than as a full auth or session protocol.
The syntax section makes the top-level control surface explicit: wc:topic@version?params. That means the invitation layer itself standardizes topic identity, protocol versioning, and transport-specific parameter carriage before any higher-level approval happens.
The semantics section shows that required parameters differ materially by WalletConnect version. In v1 the URI centers on a bridge URL and key, while in v2 it centers on relay settings, symKey, supported methods, and expiry. That makes ERC-1328 a versioned handshake envelope, not a single frozen QR format.
The rationale says the proposal moved away from JSON because JSON was inefficient to parse for QR intents and because a URI can leverage systems like Android intents more cleanly. That is a useful design clue: ERC-1328 is optimizing for transport ergonomics and parser simplicity at the wallet edge.
WalletConnect’s v2 pairing-URI spec says pairing and session are decoupled, with the URI shared first to construct a pairing proposal and only later settling a session. That sharpens the analytical split between bootstrap transport and subsequent durable session authority.
ERC-1328 is therefore most useful in the corpus as a lower-layer comparison point for WalletConnect Auth, WalletConnect sessions, ERC-7946/UWULink, and wallet-routing standards: it standardizes how a connection offer is carried, while leaving later authentication, capability delegation, and session power to other layers.
Whitepaper: No standalone ERC-1328 whitepaper or litepaper surfaced in this pass. The clearest primary materials were the ERC page, the raw ERC markdown in the Ethereum ERCs repository, and the WalletConnect v2 pairing-URI spec; see ../../whitepapers/erc-1328-primary-sources-2026-05-14.md.