Wallet Session and Relay Rails

This note narrows wallet-connectivity to external-wallet sessions, relay infrastructure, and post-connect authority.

Questions worth asking:

Where does session authority live after the first approval?
Which relay, namespace grammar, verification system, or capability format shapes durable wallet authority?
How much leverage sits with routing, notification, or relay operators before any onchain execution happens?

Canonical comparison set

Rail and relay substrate: walletconnect and walletconnect-network
App-facing operator shell above the same rail: reown
Verification and payment descendants on the same branch: walletconnect-verify and walletconnect-pay
Bitcoin and Nostr session analogue: nostr-wallet-connect
Request surface and capability grammar beneath many sessions: eip-1193 and caip-25

Relay / transport surface keeps messages flowing between app and wallet.
App wrapper and onboarding kit can sit above the same rail without being the rail itself; reown belongs here.
Verification and payment descendants can sit on top of the same rail without being the rail itself.
Safety overlays may classify the same requests or destinations, but that is a different control point from the relay.
Execution venue sits downstream of the session layer and should not be collapsed into it.

Is a product improving wallet UX, or quietly becoming the durable authority rail between apps and wallets?
Does the session survive because the user chose it, or because the relay or operator made it sticky?
Which layer is really deciding trust: the relay, the verification registry, the safety overlay, or the downstream account system?
What breaks, and who regains leverage, when the relay or verification layer changes?

wallet-connectivity
control-surfaces
Keep this note on durable session authority. Do not let it dissolve into a generic wallet-connectivity index.