# 4337 Compatible wallet app

## Abstract

We are moving closer towards the finalisation of [EIP-4337](https://eips.ethereum.org/EIPS/eip-4337). A lot of effort by the core team has been put into designing the contracts, mempool, DOS protections etc. But the team haven't had time to properly support UserOps through one of the browser extension wallets.

In this cohort, I intend to work on making a user-facing wallet which can then pave the way forward for the wallets in the Ethereum ecosystem. The larger goal is to test the eip enough and make it ready for everyday use. Once we get AAs into everyday use we can then easily work towards the depreciation of EOAs from the ecosystem.

## Objectives

With this wallet I intend to achieve the following objectives:

- Ability to create a SCW
- Recover a SCW
- Support for sending transactions
- Expose API for Dapps to attach custom paymaster
- Ability to add user specified paymaster
- API to batch multiple transactions together
- Social recovery
- Ability to pause an account
- Define Spending limits

Areas to research

- How to support multiple SCW implementations

Work for future

- Explore other recovery methods - zk

## Contents

1. [Onboarding a User](#Onboarding-a-user)
a. [Create a SCW](#Create-a-SCW)
b. [Recover a SCW](#Recover-a-SCW)
3. [Guardians](#Guardians)
a. [Adding a gaurdian](#Adding-a-gaurdian)
b. [Removing a gaurdian](#Removing-a-gaurdian)
4. [RPC exposed](#RPC-exposed)
4. [Technical terms](#Technical-terms)

## Onboarding a user

The user when they launch the extension for the first time, they will be presented with the below options:

1. [Create a Smart contract wallet (SCW)](#Create-a-SCW)
2. [Recover a SCW](#Recover-a-SCW)

### Create a SCW

The user will be given a couple of options while creating a new wallet

1. Create a new wallet
2. Create a new wallet from hardware key

The above two options will decide if we are creating a new local private key or are we using the priate key provided by the hardware wallet. Once the selection is complete, the following process is followed for every wallet that is created:

1. We [create a private key](#Create-a-private-key) or use hardware private key.
2. User is asked to enter a password. The password will be used to unlock the chrome extension wallet for a [session](#Sessions).
3. The private key is [stored in the local storage](#Storing-private-key-locally) & will be used as the owner to generate the [counter-factual address](#Counter-factual-address) of the SCW. The salt (index) used to generate the default counter-factual address will be `0`.
4. The user will then be asked to add guardians (These will be used to recover the address later on). If the user choose not to add the guardians right now, then there will be a constant warning on the extension warning the user that they will not be able to recover the wallet. [Read here](#Add-a-gaurdian) to know more about how to add guardians.

Whenever a user creates adds a new wallet we repeat the flow above. That means for every new wallet created, we will be creating a new private key or requesting a new private key from the hardware wallet. This is mostly to make things consistent with the current user flow.

### Recover a SCW

There are going to be few ways to recover a SCW.

1. Recover using hardware wallet
2. Recover using guardians
3. Recover using other device

#### Recover using hardware wallet

This will be a simpler workflow, where the user would enter the address of their SCW that they want to recover. Upon adding the SCW address, they would connect their SCW & choose a key to use to recover (in case there are multiple keys)

We will be creating a new private key & setting it as additional owner once the hardware key has been used to recover the wallet. This is so that user doesn't have to connect hardware wallets for every transaction from SCW.

Read the role of multiple owners & defining spending limits [here](#spending-limits).

#### Recover using guardians

User would be asked to enter the SCW addess that they want to recover. Upon entering the SCW, we will create a private key internally & generate a message with the corresponding public key. This message will then be signed by the guardians and then sent to the wallet for the creation of the new owner.

To make the whole process smoother, we can add support to connect the guardians with wallet connect. We can the call the `personal_sign` RPC method for the signing. This though assumes that the gaurdian is online & available right now.

It would be good to have a way to send email to gaurdian & they could sign the message using their wallet with a click & send it back. There needs to be more work in this area.

`TODO:// Define the exact recovery user flow`

#### Recover using device

Since every device that can access the SCW has it's own private key. These can also be used as guardians and used to recover the wallet on a new device. It will behave similar to recovery using guardians.

`TODO:// How many devices will be required to gain access?`

## Guardians

Garudians are the addresses that can help in the recovery of a wallet. A wallet with no guardians can never be recovered unless the user has access to the private key of the owner of the SCW. Hence a user MUST add guardians. Gaurdian could be a hardware wallet, a friend, another device.

### Adding a gaurdian

A gaurdian can be any of the following:

- Hardware wallet
- Another device with the same SCW
- A friend

Minimum number of guardians that will be required to recover a wallet would be 2.

### Removing a gaurdian

We need to check this because is the stolen key is used to remove a gaurdian it can have disasterous outcomnes,

`TODO:// What is the most efficient way to remove a gaurdian`

## RPC exposed

`TODO:// List down the RPC that will be exposed for the Dapps to interact with wallet.`

## Technical terms

Below are the technical delails of the terms mentioned above in the user flow.

#### Create a private key

The process of creating a private key will be describing here. The first though is to use `ethers.Wallet.createRandom`.
there would be an advanced setting to change it if the user wants.

#### Storing private key locally
`TODO:// Add how we will store the private key locally in a secure way`

#### Counter factual address
A counter factual deployer will be deployed on all the chains. The deployer will deploy a proxy to our wallet in using `Create2`. Proxy is used to manage future upgradability of the SCW.

#### Sessions
A session is defined as an active state of the wallet. Once a session is active the user doens't need to enter the password to access the chrome extension. The length of a session is defined as 20 minutes. The start time of the session is reset with the last active time. This means that the password will only be asked after 20 minutes of inactivity of wallet. In-activity is defined as a blur state of the chrome-extension's popup window.