# Onboarding to AA wallet Onboarding to a AA wallet has to be different from how we used to onboard the users on an EOA. Let’s break the problem into three sets of problems: 1. Creating a new wallet 2. Importing a wallet 3. Using hardware wallet to sign the transactions of AA. ## Creating a new wallet The easiest way for users to store private keys is through seed phrases. The hierarchical relation between a seed phrase & a private key is that a seed phrase can generate multiple private keys using Hierarchal Deterministic (HD) Wallet.[[1]](#References) The current implementation of the AA wallet in `SimpleWalletApi` allows us to create multiple AA wallets corresponding to a single private key.[[2]](#References) The above two relations lead us to one-to-many-to-many relationships. A seed phrase can have multiple private keys. Each private key can have multiple AA wallets. This brings us to the first question while creating a new wallet: > Do we allow creating multiple AA wallets for a private key in our wallet? If so, what will the UX look like? Also, we will need a deterministic way of identifying which all salts were used while importing wallets. > ### Proposed solutions Since seed phrases are easier for humans to keep a track of and keep safe, we can keep seed-phrase as the starting point. Whenever we create a new AA wallet, we derive a new private key & create a new AA wallet using that private key. By default, we will only have a one-to-one mapping between the private key & AA wallet. We can have an advanced mode in which users can add a custom salt to import/create a specific AA wallet. ## Importing a wallet Import wallet has a couple of challenges that are listed as follows: 1. When the user is importing an existing AA wallet created from our chrome extension. In such cases, importing a wallet can be done via either a seed phrase or a private key. In both cases predicting/asking for salt becomes cumbersome. If we restrict one-to-one mapping then we can default to salt & give an advanced feature to add a custom salt in case the user knows what they are doing. 2. When the user imports a wallet with no AA wallet created. There can be a couple of scenarios in that case: 1. The user has an EOA associated with this imported wallet & may have some funds in it. 2. The user has an SCW associated with this imported wallet with some other app. In both the above cases the user will have a discrepancy in their wallet address. They may expect either their old SCW address or the EOA address to show up, both of which will not happen and will lead to inconsistencies for users. ## Hardware wallets Hardware wallets have the same risks that we discussed while importing a wallet. The hardware wallet EOA may already have some funds in it. There will be a discrepancy in how the hardware wallet shows the address vs the AA address that they will see in our chrome extension. ## First Thoughts We can the following restrictions to make the onboarding experience easier for the user: 1. Have a one-to-one mapping between the private key & AA wallet by default. Whenever a user creates a new AA wallet, we derive a new private key from the seed phrase. 2. Like Argent, we allow users to import only AA wallets created by this chrome extension. In that case, users will first have to add their public wallet address & then a private key (or seed phrase?) to access the wallet. 3. Like Argent, allow recovery only via guardians. ## Wild thoughts We can go private-key less also. User comes to a platform either they recover using guardians or create a new wallet. Once a private key is lost/compromised, the user will be able to pause the account to prevent funds loss & then generate a new private key using guardians. This way a non-crypto native user can also use the blockchains. ## References: [1] [https://docs.ethers.io/v5/api/utils/hdnode/](https://docs.ethers.io/v5/api/utils/hdnode/) [2] [https://github.com/eth-infinitism/bundler/blob/main/packages/sdk/src/SimpleWalletAPI.ts#L73](https://github.com/eth-infinitism/bundler/blob/main/packages/sdk/src/SimpleWalletAPI.ts#L73) ###### tags: `eip4337` `account-abstraction` `EPF`
Last changed by  
 
Garvit Khatri
204

Read more

Transaction Analysis

TLDR; This is a call from SCW, where the SCW does two transactions. The first being approiving the USDC & then second is calling Socket's registery to bridge the token using the function outboundTransferTo. Transaction Flow: User op was forwarded using Stackup bundler Every userOp call starts with EntryPoint - 0x5ff137d4b0fdcd49dca30c7cf57e578a026d2789 Smart Contract wallet address - 0x3a1ee02cf59821e4d8264a6ddfae970a99da25d5 SCW looks like an implementation of https://ethereum-magicians.org/t/erc-6900-modular-smart-contract-accounts-and-plugins/13885/20 This is mostly popularised by zeroDev protocol - https://mirror.xyz/konradkopp.eth/7Q3TrMFgx2VbZRKa7UEaisIMjimpMABiqGYo00T9egA Codebase - https://github.com/zerodevapp/kernel/blob/main/src/Kernel.sol

5/29/2023
Final Update - EPF

Project Summary I initially aimed to develop the proposed 4337 wallet, a browser extension wallet composed of three modules: extension, auth, and recovery. The aim was to support multiple SCW implementations by exposing the API to allow users to select the SCW implementation they prefer. However, the task turned out to be monumental, and some priorities needed to be set for EthDenver. Thus, we realigned our goals and came up with the following: Deprioritize the secure module for safe execution environments for multiple wallets. Finish onboarding with a custom screen for SCW to take user input. Inject the Web3Provider. Create a primary transaction confirmation screen that developers can clone and customize. Write a README for users to clone the repo and develop. Clean up any leftover issues. Modify the 2fa extension demo.

3/23/2023
Ideas 101

This document highlight the list of ideas that are worth exploring for our startup - PROTON Writing style - challenge - poroblem statement people - target ussers outcome - measurable change in people's life Accounts for app chains

3/4/2023
Update - 8

Hey everyone, hope you're all doing well! I have an update on the wallet development. Our goal has been redefined and we're now focusing on making the wallet forkable and customizable for SCW with support for custom onboarding and transaction inputs. Our aim is to have the plugin ready by EthDenver. Here's what we have planned so far: De-prioritize the secure module for a safe execution environment for multiple wallets (Jan 29th) Finish the onboarding with a custom screen for SCW to take user input (Jan 29th) Inject the Web3Provider (Feb 4th) Create a primary transaction confirmation screen that developers can clone and customize (Feb 7th) Write a Readme for users to clone the repo and develop (Feb 14th) Clean up any leftover issues (March 1st)

2/4/2023
Read more from Garvit Khatri
Published on HackMD