Account Coordinator: A Proposal for the Future of Wallets

This is meant to be a place to discuss the blog post: Account Coordinator: A Proposal for the Future of Wallets.

One thing I didn’t quite capture with the final diagram illustrating the coordinator is that it’s intended to abstract over multiple key managers, which is one of the largest UX pain points right now. While Metamask lets you handle multiple keys, if you want to use Metamask + a mobile wallet for different applications you end up with a proliferating number of wallets and it gets very hard to keep track of which keys are where, associated with which dApp, and in which context. The Account Coordinator solves precisely this problem.

Something I started thinking through with @pedrouid and @ethanfrey was the details of the user experience after each data transport step took place. So you start on the application, it uses walletconnect to attach to the account coordinator. This is essentially what we see today. The account coordinator receives the transaction from the application, shows it to the user and suggests which key manager to use. At this point there will need to be another walletconnect data transport to the key manager. On a ledger, you’d expect to see the transaction info one more time to confirm before signing. At this point the user would be viewing the tx data twice which feels redundant. I’d wanted to know if there was a hash, uid, or emoji style message that could be used in place so that a user just needs to confirm it’s the same message on both sides rather than review the entire transaction. Pedro pointed out that doing so would mean the security assumption of the key manager must now include the account coordinator. One goal of separating the two is that the account coordinator can be compromised without compromising the keys. If the key manager just relied on a hash, uid or emoji message…

Excerpt (1198 of 2111 characters). Read the whole post on the forum ↗

Another topic I’d like to think through further is with regard to MetaMask’s snap system and if and how exactly it might improve the relationship between the account coordinator and the key manager. In that scenario, the account coordinator would ask for specific permissions to access different keys from the key manager. Does that mean that if the account coordinator is compromised the permissions it has on the various keys also become compromised?

If so maybe you actually wouldn’t want that kind of access from the AC?

reviving this post for https://twitter.com/mikedotexe/status/1605958458200641536