# 0xSocialWallet: self-custodial social accounts

## Abstract
To onboard the next billion users to Web3, we will need to radically simplify the user journey and do away with extensions and seed phrases. How can we convince anyone that Web3 is better if it's significantly harder to use?

We need a signup flow similar or better than Web2.

One way to achieve this is to use account abstraction, or in other words programmable accounts, to allow newcommers to start with social login, but then gradually transition to true self-custody.

In this proposal, we explore what's wrong with existing solutions, and how we solve these problems via true account abstraction.

We also present a [prototype](https://0x-social-wallet.vercel.app/) of our solution.

## Why now?

Account abstraction and ERC-4337 enable a new type of programmable accounts. While smart contract wallets have exited for a while, they've never been so ready for the prime time, with advances like ERC-4337, ERC-1271 and ERC-6492.

## Objective

Create a simple wallet PoC that allows people to:
- sign up with their Twitter account
- send funds to Twitter handles who don't have Web3 accounts yet, essentially "inviting" them to create an account: we call this **counterfactual social wallets**

Later, this PoC can be adapted to be part of an existing wallet, for example through a Metamask Snap or a Safe App.

We believe that this will be the first fully open-source and self-custodial social wallet project, with no proprietary dependencies.

## Outcomes

We believe that the main reason most people start their Web3 journey with centralized exchanges is that custodial wallets are too hard to use. Unfortunately we could not find data to back this claim up, but we believe most of us in the community have had anecdotal experiences to back this up - how many times have you heard about your friend signing up to Binance and tried to convince them to get a real wallet?

We believe that the benefit of 0xSocialWallet is immense: imagine if you can get an Ethereum wallet using your Twitter account, and later on move to a hardware wallet in order to get full self-custody.

**This is a hybrid approach that can finally get most newcommers off of exchanges.**

## Prior art and background

We examined the following existing solutions:

* [n00b wallets](https://launch.mirror.xyz/wDFf0PylbkZ70LKbxe_fmTeikvgbzsEfthcH7pCjlng), later rebranded to Patch
* [Lit Protocol](https://litprotocol.com/): used by Patch Wallet
* [ZeroDev SDK](https://zerodev.app/): uses Web3Auth under the hood
* [Web3Auth](https://web3auth.io/)
* [Ambire Wallet](https://www.ambire.com): implements email login

We'll examine all of those in detail, but overall, all of them make some sort of a compromise.

### The ugly truth about social login
The fundamental problem of social login, that nobody can solve is that oAuth verification cannot be performed on-chain in a secure manner. This is why most of those solutions try to "distribute" the verification via MPC, but it doesn't change the fact that it's 1) a black box off-chain procedure that you just have to trust and 2) social networks themselves cannot be categorized as self-custodial in any way (except efforts like Lens).

**Furthermore, with most MPC solutions, losing a single key share leads to losing access to the account.** This means that any legal/regulatory action can "wipe out" your social wallet, which can hardly be classified as self-custody.

### Web3Auth
For the purposes of 0xSocialWallet, we examined how [Web3Auth.io](http://web3auth.io/) handles social authentication and wallet creation.

[Web3Auth.io](http://web3auth.io/) enables users to register via various OAuth providers, including Google, Twitter, GitHub, and others of their choice. Using this service, users manage their keys in a manner similar to that of a multi-factor account, using their OAuth login, devices, and other factors to handle their key pairs. The complete cryptographic private keys of users are not stored anywhere.

In essence, self-custody is achieved by splitting up key shares among different entities, such as the user's device, a recovery share, and a social login share. This is making it impossible the user's private key to be retrieved independently. In other words, MPC is utilized to secure the private key.

To retrieve or reconstruct the private key, the user must demonstrate ownership of at least two out of three (2/3) shares.

**Here are some crucial points that we have tested and verified:**

1. Whenever a social profile is linked to the same email, it is always associated with the same wallet address. This is accomplished via their Auth service.
2. When logging in, their Auth service doesn't expose any keys (we traced the network requests). One of the shares is always kept locally on the user device. Their SDK manages the private key reconstruction process on the user's device to execute blockchain transactions. The critical aspect here is that their service does not keep or expose the entire private key.
3. In the event that you wish to log in on another device, you can create a new backup on your current device. When you perform a social login on the new device, you will be prompted for the backup. After you are connected (and a new device share is established), your private key can be reconstructed on that device, allowing you to operate on both devices.

**After conducting our research, we have discovered the following:**
1. To create a wallet, a centralized service (Auth service) that manages the oAuth flow is necessary, as the oAuth providers' APIs do not have a signature-like mechanism that can be used for on-chain verification.
2. While [Web3Auth.io](http://web3auth.io/) uses MPC for self-custody, we can simplify the key reconstruction process and achieve the same level of security by implementing a multisig wallet instead of MPC.
3. Even if we were able to utilize [Web3Auth.io](http://web3auth.io/)'s SDK for the social login aspect of 0xSocialWallet, our flow would still be distinct. This is due to the fact that the initial sender of the tokens cannot initiate the oAuth process on behalf of the receiver (more on that later).

**Furthermore, pure MPC approaches to key distribution suffer from the following issues:**
1. They require at least 2 communication rounds between signing parties; this isn't a problem because in this case both signers are online at the same time, but it does make the system more cumbersome
2. Key rotation for setups with more than 2 parties is next to impossible without a centralized coordinator
3. Losing a key share normally leads to losing access to the whole account

### Patch Wallet and Lit Protocol
We have carefully examined the existing solutions. PatchWallet is one of them, a social wallet, claiming to be non-custodial, meaning that the user retains full control over their private keys and assets.

#### Intro

PatchWallets are created automatically for users, tied to their social media accounts, and do not require any additional action on the part of the user. When a user receives tokens or NFTs to their PatchWallet, the smart contract associated with the wallet is deployed on the blockchain, but the user retains full control over the private key associated with the wallet.

When the user wants to utilize the assets they have accumulated in their PatchWallet, they would need to interact with the smart contract on the blockchain using their private key to sign transactions. The Lit Protocol is used to sign these transactions, but the user's private key remains under their control and is not held by a centralized custodian.

#### How it works

The key point to their non-custodial claim is the Lit protocol.

The Lit protocol is a decentralized key management network that allows users to create and manage distributed cryptographic key-pairs for condition-based encryption and programmatic signing. The Lit Protocol is designed to be an alternative to centralized key custodians and other key management solutions, allowing users to retain control over their private keys while still being able to use them for a variety of purposes.

Overall, the Lit Protocol is an interesting approach to decentralized key management that has the potential to offer users greater control over their private keys and more flexibility in how they use them.

There is a concept in Lit called Programmable Key Pairs (PKPs). This is an ECDSA key-pair that is held in distributed custody by the Lit network. PKPs can be programmed to automatically sign based on application logic, which is specified in a JavaScript program called a Lit Action.

PKPs can be programmed to automatically sign based on application logic, which is specified in a JavaScript program called a Lit Action. This allows for more flexibility in key management, as PKPs can be programmed to perform specific actions in response to certain conditions or triggers.

PKPs are held in distributed custody by the Lit network, which means that they are not held by any centralized custodian and cannot be accessed or controlled by any single entity. Instead, the keys are distributed across the network, which helps to improve security and resilience.

Overall, PKPs in Lit offer a unique approach to key management, allowing for more flexibility and programmability in the use of cryptographic keys.

However, as with any key management solution, it is important to carefully consider the security implications and risks associated with using PKPs.

#### What we found

The key point to their non-custodial claim is the Lit protocol. We challenge this claim and we identified two primary issues that need to be addressed to enhance its security and non-custodial features:

**The Lit Protocol is designed to use multi-party computation (MPC) to securely custodian and distribute private keys. This sounds interesting in theory, but in practice it's a black box and we found no way of knowing or guaranteeing that the signatures really do come from MPC. Furthermore, fundamentally there's no way to know that the co-signers will not collude.**

PatchWallet uses the PKP concept in Lit.

PKP is used as an asset "vault", sending a mix of crypto and NFTs to it, and then selling them as a bundle by selling the NFT that controls the PKP on OpenSea. The buyer of that NFT would then have full permission to sign and decrypt data with the PKP, since they are now the owner of the controlling NFT. This means that the buyer could also withdraw the crypto and NFTs stored within, if desired.

So the sender is whoever wants to send crypto to a Twitter handle (let's say). And the buyer of this PKP NTF is the person owning the Twitter account.

This functionality is essentially securely trading a private key (a PKP). Each PKP is a valid ECDSA wallet, custodied collectively by the Lit nodes (an MPC wallet)

The LIT Protocol implementation does have a "centralized" component in the form of the validator nodes. While the nodes themselves are decentralized and operated by different individuals or organizations, the validation process is controlled by an unknown number of nodes.

Our solution is not depending on the Lit infrastructure, which could not be as non-custodial as it claims to be. Also, our validation process is not dependent on the participation of validator nodes (which could be a small group of nodes in the Lit case), but on the sender and the receiver (more on that later), which we consider to be truly non-custodial.

Even if the oAuth-derived social key doesn't add any centralization risk, it's still not enough by itself to guarantee a secure system (as the social network itself is centralized).

**Finally and most importantly,** solely relying on MPC infrastructure without any on-chain recovery mechanisms is problematic, because any legal/regulatory action against such infrastructure can lead to lost key shares, which could lead to losing access to the whole wallet account.

## Our approach

### Terminology
* backend key/social key/social key share = all of those refer to the key or key share which is responsible for signing messages/transactions on behalf of a Twitter (or another social media) user, when authenticated through its oAuth endpoint
* sender = the user who is sending funds to a Twitter handle directly before the holder of this Twitter handle has set their wallet up

### The best possible compromise
The approach used in Ambire for their email/password accounts uses an on-chain 2/2 multisig, coupled with single-key timelocked recovery, which we believe is the best possible compromise for social wallets too, here's why:

- if the social key is compromised, it won't impact the account
- if the user key (which is kept on the users device) is compromised, it won't impact the account
- if any of the keys is lost, the account can be recovered after the timelock period - this includes cases where the user lost their own key, or cases where the backend is permanently or temporarily down

Therefore this scheme is **censorship-resistant**, unlike pure MPC schemes where losing a key share would be fatal.

### Counterfactual social wallets
Our solution has the capability to create a wallet on behalf of any Twitter user simply from their handle. This also utilizes the 2/2 multisig in a novel way: **when a wallet is created on behalf of a user, one of the signers is the sender, and the other is the social key.**

This is distinct from competitors, since they rely solely on the oAuth powered key (which is effectively centralized) before the newly onboarded user sets up their wallet - meaning that if someone sent funds to your Twitter handle, before you take ownership of your wallet, the funds can be taken back by whoever controls the social key share.

Once the user "claims" their wallet, the original sender will have to also co-sign the first transaction, which will replace the sender key with the user's locally generated key.

### Upgradable security, gradual onboarding
One of the best traits of account abstraction wallets is that you can rotate keys, or better put: change the authentication rules of the wallet account on the go.

This makes the counterfactual social wallets possible, but it also allows users to migrate to true, pure self-custody in the form of hardware wallets or even traditional hot wallets.

#### Illustration:
| stage | key 1 | key 2 |
| ----- | ------| ------|
| sender sends funds to a twitter handle | sender | recipient's social key |
| recipient claims ownership | recipient's local key | recipient's social key
| recipient upgrades their security | recipient's local key | hardware wallet

### Current progress
We've built a simple prototype here https://0x-social-wallet.vercel.app/ that can be used to counterfactually create wallets for Twitter handles and lookup existing wallet addresses, as well as claim ownership of wallets created on your behalf via your Twitter handle.

It's all open-source: https://github.com/0xGoodMorning/0x-social-wallet

### Team
We're Goodmorning, a boutique Web3 development studio based in Eastern Europe. We have worked with LimeChain on Hedera, as well on the Ambire Wallet mobile app. We've also built hobby projects on Ethereum: for example, we built an AA wallet that lets your loved ones recover your funds in case you're no longer alive.

#### Kaloyan Kosev
Meet Kaloyan Kosev, the front-end engineering maestro with an insatiable appetite for blockchain, Web3, and all things digital.

Onboarded into the team several months after Coinbase was founded, Kaloyan has been a core part of the Goodmorning dream team ever since. He’s currently making the internet a better place one React, React Native, and NodeJS project at a time.

A proud member of the elite 10k+ StackOverflow reputation club, Kaloyan is the startup scene’s secret sauce. When he’s not crushing code or exploring the cryptoverse, he’s busy co-creating hobby projects like EasierEnglish.BG, P2P Handbook, Dora for Teams, and CryptoTab.

Kaloyan likes to see himself as a nano-influencer spreading the gospel of technology and crypto by organizing workshops, delivering talks, and mentoring teammates. With a flair for distilling complex concepts into bite-sized wisdom, he’s on a mission to take the tech world by storm!

#### Simeon Petkov
Simeon Petkov is a skilled software developer with 6 years of experience in coding and programming. He started his programming career in Goodmorning, a company based in Bulgaria, where he gained valuable experience and knowledge. He continued his education at the Technical University of Varna for a total of four years, where he honed his skills in software development and frontend development.

Simeon’s expertise lies in frontend development, with a particular focus on browser extension development with React and mobile development using React Native. Along with his programming experience, Simeon is also a passionate Web3 enthusiast, constantly exploring and learning about the world of cryptocurrency and blockchain. He has spent the last two years gaining experience in the crypto space, with a special emphasis on smart contracts and the EVM ecosystem.

#### Jordan Enev
Jordan Enev is a full-stack JS developer who has been dedicated to Web3 development for the past year. He began his coding journey over a decade ago and has since been a valuable contributor to various challenging greenfield projects within the financial, insurance, and e-commerce sectors. Jordan possesses extensive experience in developing both backend and frontend applications. Throughout his career, he has predominantly utilized JS to create stunning UIs in React, while also demonstrating proficiency in PHP/MySQL and Python.

#### Ivo Paunov
Ivo has an education in telecommunications and finance but switched to software development nine years ago. Has some experience with corporate closed-source software but finds out this is not his passion. Joins the Stremio team in 2016 with CEO Ivo Georgiev and have continued to work with him on blockchain projects since 2017 - the decentralized ad network AdEx and most recently, Ambire Wallet.

Ivo is a jack of all trades, with deep experience with React, but also proficient in Node.js and quite experienced with DevOps.

#### Lyubomir Nanev
Lyubomir Nanev is a Front-end developer with 7 years of experience and he is a part of Goodmorning team since September of 2021. From his start in the company he is working on self-custody wallet project called Ambire Wallet. In the period from 2016 to 2021 he has been working in company “A-sharp” where he has developed a mobile and web applications.

## Milestones

* Turn the current prototype into a usable dApp where you could connect an existing wallet (extension or WalletConnect) in order to send funds to a Twitter handle
* Develop a notification system (Twitter bot) that lets people know when they've received funds on their Twitter handle
* ProductHunt launch
* ERC-4337 support and gas abstraction via paymasters (we currently use a private relayer)
* Plugin for an existing wallet, for example Safe App or MetaMask Snap to import your social wallet

We aim to achieve these milestones by the end of Q2.

It's difficult to nail down an exact timeline of the features, because we think that a product-driven approach where we prioritize based on community demand is more valuable.

While we think that 0xSocialWallet should be launched and iterated like a startup, we envision it becoming an open-source community-owned project.

## Budget
We request a budget of $25k that will be used in the following way:
* $20k will be be used to cover the team's salaries during the time we are working on 0xSocialWallet
* $5k set aside for infrastructure costs (Vercel, Digitalocean/AWS) - this should be sufficient for one year of operation

We consider the current team to be diverse enough not to require any external contributors, as we have in-depth experience with all aspects of the project's development, including Solidity, product management, back-end, front-end and infrastructure/DevOps.