Many thanks to Matt for great discussion on that topic and for developing this tool to parse every contract and put them into a sparse Merkle tree which simplifies prototyping by not having to do zk proves over the patricia tree. Also, thanks to Vitalik for great input. Managing multiple accounts can be challenging for several reasons, including issues with social recovery, privacy, L2s and overall user experience. Using stealth addresses complicates it further, as each interaction needs a new account. Vitalik suggested using zk-SNARKs to separate the account for transaction logic from the one holding assets. This allows for improved privacy, user experience and one-click social recovery. For the following, it is recommended to first have a look at Vitalik's The Three Transitions post for some background. In short, what we try to achieve is the following: One-stop social recovery without compromising privacy. Naive Approach

TL;DR - Users buy "tickets" from "coordinators" that, when redeemed, fund an unfunded EOA. This, while maintaining privacy, so that not even the coordinator knows who has bought the redeemed ticket. Thanks to Matt (lightclient), Guillaume, Matt Solomon, Barnabé, Chris Hager and Vitalik for review and feedback! Find a PoC implemented in Python (CLI) and Go (Coordinator) in this repo. Today's landscape One of the challenges of today's Ethereum landscape is privacy. <br/> Users fund their accounts, get doxxed, set up new accounts, repeat.