# Complete Version: Reason why we can't support multiple XLM addresses

There are two facts that cause this issue:
(1) The famous **key derivation protocol - [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki)**, and **HD Wallet Derivation Protocol** [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) and
(2) The current workflow of our App

## The BIPs

### BIP32

BIP32 defined two kinds of key derivation function (generate a child key from a parent key): **hardened derivation** and **non-hardened derivation**.

If you want to derive a child public key(which is the address), with **Hardened derivation**, you must use a parent private key to derive a child private key, and then convert the child private key to child public key.

With **non-harden derivation**, you can just use a parent **public key** to derive a child public key. **Note here: in BIP32, it only defined how non-harden derivation works for ECDSA**(Elliptic Curve Digital Signature Algorithm).

### BIP44

BIP44 defines a hierarchical key derivation schema about how to use BIP32 , (This is also the reason why we can use a single mnemonic sentence to recover our addresses on different wallet APPs.):

MASTER / purpose'  / coin_type' / account' / change / address_index

This is called the `path` of a key, the ` ' ` above means harden-derivation. A note here is that the harden-derivation is only use until **Account Layer**.

### Example

An Example about how to follow this protocol to derive a bunch of bitcoin addresses:

Since we are following BIP44, we should use `purpose=44` in the derivation. and BTC has a coinType of `00` (you can check the coinType list [here](https://github.com/satoshilabs/slips/blob/master/slip-0044.md)), and we also have to define we're using **Account 0**, change 0, and address 0.

Now it's time to derive the keys:
1. Master Private Key -- (harden) -> **Purpose Private Keys No.44**
2. **Purpose Private Keys No.44** -- (harden) -> **CoinType Private Key No.0**
3. **CoinType Private Key No.0** -- (harden) -> **Account Private Key No.0**

And then what people usually do is

4. **Account Private Key No.0** --> Convert to -> **Account Public Key No.0**

This is because start from this layer, BIP44 defines that we start using **non-harden derivation**, which is more convenient. Now we can just use Public keys to derive public keys, in CoolWalletS, this is when SE return the **Account Public Key No.0** to the App, so the App can freely derive any amount of **public keys** it wants with only the access of a public key. So the last two steps would be:

5. **Account Public Key No.0** -> (non-harden derive) -> **Change Public Key No.0**
6. **Change Public Key No.0** -> (non-harden derive) -> **Address Public Key No.0**.

### What's different with Stellar

Stellar is that it's using EdDSA instead of ECDSA (just a different key pair generation algorithm), just like Cardano(ADA). And there's no standard about how **non-harden key derivation work with EdDSA**. Most Stellar wallets out there simply generate a private key - public key pair for a user each time the user wants to add an address. That means, most Stellar wallet is not using BIP32 to have multiple addresses with one master key.

But XLM also registered an BIP44 coinType in the registered list we mentioned before, this means if any BIP44-compatible wallet wants to add XLM, they can use this coinType and maybe implement their own non-harden derivation, or just use the **Account Layer** as address layer keypair, like Ledger.

We decided to follow Ledger, using Account Layer public keys to be presented as address, and use the private keys to sign the transactions. **In terms of SE, we can still support multiple addresses and optimize the derivation process in signing like other coins**, we just have to store the the private key of coinType layer, (the parent layer of account layer).

## What make us unable to support multiple address NOW

The main reason is that in the current workflow, we have two features that conflict with this key schema: Add New Address and Asset Search during recovery.

### New Address

Originally Adding a new address will not need the user to connect to your CoolWalletS, but this is impossible for Stellar.

Like we mentions in the key derivation [Example](#Example), our app will have a replica of **Account Layer PublicKey** for every ECDSA coins, so adding an address is easily a derivation on the App side.

But since EDDSA doesn't have non-harden key derivation, we cannot store a **parent public key** at App side and just use it to derive a child public key. **Every time we need a new child public key, we need it from the parent private key.** Of course, all the private keys should be store in CoolWalletS, So we need to connect our App with CoolWalletS anytime we need a new address.

### Asset Search

The reason is similar to the one above. Right now, in the setup phase, our app automatically search for all used address for every currency. This is already very time consuming. If we have to support Asset Search for Stellar, It will take ~10 sec more for every address search since we will have to connect and derive again for every address. This is not feasible unless we change the rule of asset search in the future.

To avoid confusion for our user in these two features, we wont not supporting multiple addresses in the wallet right now. We CAN support it if that's really the market wants, but some old rules or features may need to be updated as well.