Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ARC-44 - Wallet contextual derivations (& ecosystem alignment) #224

Open
wants to merge 8 commits into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
92 changes: 92 additions & 0 deletions ARCs/arc-0044.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,92 @@
---
arc: 44
title: Algorand BIP44 HD Wallet derivations
description: Specification to support BIP44
author: Bruno Martins (@ehanoc)
discussions-to: https://github.com/algorandfoundation/ARCs/issues/224
status: Draft
type: Standards Track
category: Interface
created: 2023-06-30
---

# Algorand BIP44 HD Wallet derivations

## **Abstract**

Proposal for standardization of Algorand's HD wallets and <a href="https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki">BIP44</a>. derivation path. By establishing a consistent approach to wallet generation and key derivation, this ARC aims to enhance interoperability and compatibility across different wallets, applications, and services.

## **Motivation**
Currently, the Algorand ecosystem lacks a standardized methodology for HD wallet generation and key derivation paths. This absence of a consistent approach results in fragmentation and challenges for wallet developers, users, and the broader Algorand community.

## **Specification**
The key words "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**", "**SHALL NOT**", "**SHOULD**", "**SHOULD NOT**", "**RECOMMENDED**", "**MAY**", and "**OPTIONAL**" in this document are to be interpreted as described in <a href="https://www.ietf.org/rfc/rfc2119.txt">RFC-2119</a>.

### **BIP44 Derivation Path**

The BIP44 path structure follows the format: `m/purpose'/coin_type'/account'/change/address_index`.

`m`: The root key of the HD wallet.

`purpose`': The purpose field indicating the usage of this path.

`coin_type`': The coin type field indicating the specific cryptocurrency.

`account`': The account index.

`change`: The change index.

`address_index`: The index of a specific address generated by the wallet.

#### **Specification For Algorand**

The following table outlines the derivation path for Algorand wallets. The table introduces the ability for wallets to generate keys for a specific (optional) Context.

| Purpose | Coin Type | Account | Change | Address Index | Context |
| :-----: | :-------: | :-----: | :----: | :-----------: | :-----------------: |
| 44' | 283' | x' | x | x | Algorand Addresses |
| 44' | 0' | x' | x | x | Identity Keys |

Please note the \' symbol after each field. This symbol indicates that the field is hardened. See <a href="https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#extended-keys">BIP32 Extended Keys</a>.

##### **Contexts**

- **Algorand Addresses**: The context for deriving Algorand addresses. This context is used to derive the public keys for Algorand addresses.

- **Identity Keys**: The context for deriving identity keys. These can be used for Decentralized Identifiers (DIDs) and other identity-related use cases. Path `m/44'/0'/x'/x/x` is the one suggested in the <a href="https://w3c-ccg.github.io/universal-wallet-interop-spec/#hd-wallets">W3C Universal Wallet Interoperability Spec</a>.

- Others can / should be added in the future.

### **HD Wallet Generation**
The standardization will also cover HD wallet generation, ensuring compatibility across different wallet implementations. Wallets adhering to this standard must use the <a href="https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki">BIP39</a> standard for mnemonic phrases and BIP32 for key derivation. The following steps outline the HD wallet generation process:

Generate a random mnemonic phrase of 12 or 24 / 25 words using BIP39.
Derive a seed from the mnemonic phrase using BIP39.
Derive the master key from the seed using BIP32.
Derive the account-level keys from the master key using the BIP44 derivation path with the appropriate purpose, coin type, account index, change index, and address index.
Derive change and address-level keys from the account-level keys using the BIP44 derivation path.

### **Wallet Compatibility**
Wallets adhering to this standard will be compatible with each other and with applications and services built on the Algorand blockchain. Wallet users will be able to import their account into any compatible wallet by using their mnemonic phrase or extended public key (xpub). The compatibility will ensure a seamless user experience and facilitate the adoption of Algorand across various platforms.

## Rationale
Standardization will improve the user experience, promote interoperability, and foster the development of a robust and secure ecosystem.

### **Known Derivation Implementations**
- `Ledger`: Supporting already the derivation path `m/44'/283'/0'/0/0` for Algorand.
- `Trezor` : N/A
- `kmd` : No BIP32/44 derivations, but HMAC-based Extract-and-Expand Key Derivation Function (HKDF) as defined in <a href="https://www.ietf.org/rfc/rfc5869.txt">RFC-5869</a>.

### **Contextual Derivations**
We might need to derive keys for many different purposes and want to avoid re-using the same keys. Some possible contextual derivations can be for the purpose of generating keys for algorand addresses, identity such as DIDs, authentication, messaging, etc.

## Security Considerations
The security of a HD wallet is dependent on the security of the mnemonic phrase. Although different actors may have different security requirements, the following guidelines are recommended:

- Is the responsibility of the **USER** to keep the mnemonic phrase safe and secure.
- Is the responsibility of the **WALLET** to provide a secure storage for the mnemonic phrase.
- Is the responsibility of the **WALLET** to not populate the application's runtime memory with the mnemonic phrase or unnecessary key material.
- It's recommended, if possible, that the **key management service (KMS)** used by the wallet does **NOT** share runtime memory space with the wallet application

## Copyright
Copyright and related rights waived via <a href="https://creativecommons.org/publicdomain/zero/1.0/">CCO</a>.