Protocol Berg v2: Pedro Gomes - Two flavors of Smart Sessions: Session Keys vs SubAccounts

Hey everyone. There we go. WalletConnect – I hope everyone in the room has seen it. As was already presented, my name is Pedro Gomes, founder and director of the WalletConnect Foundation. We've been building wallet infrastructure for what feels like forever. Wallets are changing very rapidly. Once scaling happened and we had other problems to solve, wallets became the next challenge. I'm here to talk about different flavors of smart sessions. First, what is a smart session? You may have heard of smart wallets – like a smartphone. But what about a smart session? When you connect a wallet through WalletConnect, you're establishing a session: an agreement between the app and the wallet for exposing accounts, signing, and transacting. WalletConnect is built around this simple session protocol. How can we make it smarter? Smart sessions eliminate the constant pop-up signing requirement. Instead of signing every transaction, the session itself becomes intelligent with temporary limited permissions. This generates a separate key, not the private key. It reduces clicks and friction. Permissions can be time-based (hour, day, week), spending limits, specific contracts or tokens. This requires smart accounts. Initially, ERC-4337 pioneered smart accounts, but it's complex. Now EIP-7702 brings smart contract functionality directly to EOA, a wallet-specific core change. Both enable smart sessions. There are three implementations: session keys, session accounts, and sub accounts. Session keys: wallet creates a signing key with delegated permissions. But it requires wallet module coordination, which is slow. Session accounts: wallet controls permissions, app manages keys via a delegation manager (ERC-7710). More flexible, no module coordination needed. Sub accounts: wallet creates child accounts that handle keys, permissions, and even balances. It's like embedded wallets but owned by the main wallet. This introduces multiple addresses under one hierarchy, changing EVM thinking. ERC-7715 negotiates which flavor is used. ERC-5792 provides wallet_getCapabilities to ask what the wallet supports. Through these standards, wallet UX is becoming commoditized, reducing vendor lock-in. WalletConnect is driving this to improve user experience, aiming for zero clicks and no pop-ups. Thank you.

Yeah. So, that's why there was an asterisk because a sub account isn't really a module. It's more like a pattern. You as a wallet don't necessarily need a smart account to have a sub account module. What you actually need is the ability to map out your hierarchy, and that could be through generating deterministic addresses as well. This is something being worked on: the ability to determine which addresses for each sub account will be based on some salt and init code, so you know exactly for this specific session which sub account will be used, and also the ability for indexers to understand for each sub account which main account it maps to, and for each main account which sub accounts it has. So it's not necessarily a module per se, it's more like a framework. This framework touches on apps, wallets, and blockchain explorers. It's quite a substantial change, but seeing how much adoption it has gained, it feels quite worth putting the resources and attention into it.