# 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`