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

• Base relay and network surface: walletconnect and walletconnect-network
• Product and operator layer above the same rail: reown
• Descendants that thicken the same rail into a broader control plane: 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

Keep these layers separate

• Relay / transport surface keeps messages flowing between app and wallet.
• 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.

Useful traversal questions

• 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?

Adjacent lenses

• wallet-connectivity
• payment-auth
• control-surfaces