---
tags: client-libs
---
# Account creation
### Method 1: Asking a friend to create a coin balance

- User `A` creates a key-pair and shares the public key with user `B` who already has a wallet(s) on the network
- `B` creates a wallet at the given public key's address with some safecoin.
- `A` can now fetch the balance, transfer coins and even create other coin balances. For these operations, the src Elders is the PublicId of A's Wallet.
- Now if A has enough safecoin and wants to create an account, the following is done:

1. `A` provides a locator, secret and the SecretKey of his existing wallet.
2. The two passwords are used to create a seed with which a BLS key-pair is deterministically generated.
3. A random account is generated. This includes a keypair at which a wallet will be created. This is the default wallet for the account.
4. The PublicId of the account holds the public key from the keypair created above. All client requests (after the account is created) will go via the source elders of this PublicId.
5. The account is serialized, encrypted and signed. This is sent to the network to be stored at a location `X` generated using the secret and password.
6. This request goes via the src elders of A's already existing wallet. The wallet is debited and the vaults store this account blob along with the signature. A new wallet (at the account's PublicId) is created, optionally preloading it with some coin.

#### Potential drawback:

If `A` loses the keypair then `B` is at a loss as the coins will now remain unused on the network.

#### Point to be noted:

What if `A` creates the account and sends the account's public key to `B` asking him to create a wallet?
When `A` later calls create account, it will attempt to create the wallet and it will error. Should we allow this and handle the error?

### Method 2: Asking a friend to create an account

To overcome the drawback mentioned above, account creation can also happen as follows.

1. User `A` uses the locator and secret and creates a seed which is used to create a keypair.
2. `A` creates a random account that is serialized, encrypted and signed using the keys generated in step 1.
3. `A` sends the account data to `B` along with the _account's_ public key - to create the account's default wallet.
4. The account data is stored at location `X` which is determined using the passwords along with the signature.
5. The default wallet is created optionally loading it with some safecoin.
6. This create_acc request goes via `B`s wallet's PublicId.

# Fetching an Account

1. The client provides his locator and secret. The deterministic BLS key is generated.
2. A GetAccount request is sent to the src elders of this public ID. The request is then forwarded to fetch the account data from location `X` - which is generated from the passwords.
3. This request is signed and verified in the vaults as usual.
4. The vaults return the account blob and the signature.
5. The **client** then verifies the signature against the data to see if it's still valid.
6. The data is then decrypted and the account's data is obtained.
7. A new connection is established using the account's PublicId via which all following _client_ requests are sent.