WalletConnect Auth is not just a SIWE login prompt. The spec requires a pre-existing WalletConnect pairing, then adds an auth-specific request/response flow with an app-generated response topic and wallet-returned signed authentication object.
The app creates a fresh keypair and response topic for each auth attempt after expiry, while reusing the known pairing topic. That means auth renewal is a distinct control plane layered on top of the long-lived wallet-app communication channel.
The signed result is a CACAO-style authentication object, not just an optimistic session flag. That makes the output portable and verifiable instead of leaving the app with only a transient wallet approval signal.
ReCaps in the resources array are analytically important because they turn WalletConnect Auth from pure ownership proof into an auth-plus-authorization handshake. The implementation text explicitly says this follows ERC-5573 closely.
Multi-chain behavior is intentionally partial. Wallets can support only a subset of requested chains, rewrite the ReCap to the supported set, and still return a valid authenticated result.
The wallet docs say not every approval must create a full WalletConnect session. That helps separate one-shot authentication from persistent session establishment instead of flattening them into one generic connect wallet flow.
The docs also note that one signed auth object can establish a multi-chain session even though authentication is only guaranteed for the signed chain, which is a subtle but important trust-model wrinkle.
Specific source signals worth retaining
User-flow and request-protocol sections: strongest evidence that WalletConnect Auth is its own handshake built on top of pairing rather than just a SIWE helper.
Response-topic derivation from the app-generated keypair: useful clue about how authority and liveness are split between the old pairing channel and a fresh auth-response path.
ReCap examples and chain-subset scenarios: important for seeing where capability negotiation and wallet-supported chains actually get compressed into the auth artifact.
One-click Auth wallet SDK docs: strong implementation evidence that the protocol has real event names, approval methods, and partial auth-versus-session behavior, not only aspirational spec prose.
Why this entry belongs in the corpus
It strengthens the wallet-auth cluster with the auth-renewal and authenticated-session layer between pure signed-login standards and full persistent wallet-session standards.
It is a direct comparison class for EIP-4361, CAIP-122, CAIP-222, CAIP-25, CAIP-74, and ERC-5573 because it bundles ownership proof, pairing reuse, capability requests, and possible session creation into one protocol surface.
The reusable insight is that wallet auth is not one thing: WalletConnect Auth shows how login, transport continuity, capability delegation, chain selection, and session creation can be coupled but still remain distinct control surfaces.