[Discussion] Key management in bread

The wallet has two keys. The hot key is a random key. Each device makes its own hot key. The cold key comes from the seed phrase.

This table shows the intended function of each key after we add spending limits:

| Action | Hot key | Cold key |
| --- | --- | --- |
| Send money | Limited, for example $5K each week | No limit |
| Rotate keys | Not permitted | Can rotate the hot key |
| Rotate the guardian | Necessary | Necessary |

This model assumes that the cold key is cold. It is not. Today the two keys are on the same device. They are in the same encrypted vault. The seed phrase is in the same vault.

A second key on the same device gives no protection against an attacker who has the device. The vault encryption does the protection today. This is the random vault key, the Secure Enclave or Keystore wrap, and the biometric check. The hot and cold split serves no additional function, if we had the same vault setup methods and a single key it would be identical security wise.

If the cold key is not on the device, we get a security property that is stronger than other wallets like Metamask.

## Solutions

### Option A: keep the seed phrase off the device

There are two ways to do this:

1. Tell the user to keep the seed phrase on paper only. This is not a good solution.
2. Keep the seed phrase in an OS keychain, for example Apple Keychain. The keychain has its own authentication. Each read of the seed phrase makes the user authenticate again. This is a second login.

This option has a problem. A wallet with more than one account needs the seed phrase to make each new account. Each "add account" action then needs a read of the seed phrase.

### Option B: a full multisig flow at the device level

Do not show hot and cold at the key level. Show them at the device level. The user adds other devices during recovery, or in a separate flow during onboarding. Each device gets a role:

- **Hot device.** It sends money each day, up to a limit set for it.
- **Cold device.** It approves a send above the limit. It changes limits. It adds and removes devices. It recovers the account.

A flow can look like this:

This is a usual multisig flow. Most people know it. A hot device does not keep the seed phrase. Only the master device, the cold device, keeps the seed phrase.

cc @Dominik1999 @WiktorStarczewski @BrianSeong99 @bobbinth

Esta é uma discussão de design sobre a arquitetura de gerenciamento de chaves. Comece lendo o código existente de manipulação de chaves na carteira, provavelmente em um diretório como `src/security/` ou `src/wallet/`. Entenda o modelo atual de duas chaves e a implementação do cofre. O objetivo é propor um novo fluxo no nível do dispositivo para multisig, então pesquise como o pareamento de dispositivos e a aprovação de transações são atualmente tratados.

Escrita pelo modelo de indexação a partir do texto da issue.