Wallet Connectivity
Wallet connectivity is the layer that turns one visible connect or sign prompt into a durable wallet-app relationship.
Questions worth asking:
- Where does authority live after the first approval?
- Which relay, discovery rule, or session grammar decides what the wallet keeps trusting?
- How much power sits with warning layers versus the underlying session rail?
- What survives disconnects, device changes, or wallet replacement?
Curated comparison set
- Session and relay baseline: walletconnect and reown
- Verification overlay on the same approval surface: walletconnect-verify and blockaid
- Browser discovery substrate: eip-1193 and eip-6963
- App-owned signer contrast: privy and turnkey
- Execution handoff after connection: safe, erc-4337, and eip-7702
- Off-EVM analogue: nostr-wallet-connect
Keep the layers separate
- Discovery decides which wallet is even visible.
- Session and relay infrastructure keep the relationship alive after discovery.
- Verification layers classify origin and approval risk, but do not hold custody.
- Hosted signer stacks move more wallet policy inside the app or operator.
- Execution standards decide what the connected account can actually do once control is handed off.
Focused traversal notes
Useful comparison question
Is a product merely smoothing wallet UX, or becoming the durable authority rail between apps, wallets, relays, and execution?