Ethereum hierarchy for deterministic wallets

Abstract

This EIP defines a logical hierarchy for deterministic wallets based on BIP32, the purpose scheme defined in BIP43 and eip-draft-ethereum-purpose.

This EIP is a particular application of eip-draft-ethereum-purpose.

Motivation

At present, different Ethereum clients and wallets use different derivation paths; a summary of them can be found here. Some of these paths violate BIP44, the standard defining derivation paths starting with m/44'/. This creates confusion and incompatibility between wallet implementations, in some cases making funds from one wallet inaccessible on another, and in others requiring prompting users manually for a derivation path, which hinders usability.

Further, BIP44 was designed with UTXO-based blockchains in mind, and is a poor fit for Ethereum, which uses an accounts abstraction instead.

As an alternative, we propose a deterministic wallet hierarchy better tailored to Ethereum's unique requiremnts.

Specification

We define the following 4 levels in BIP32 path:

m / purpose' / subpurpose' / EIP' / wallet'

Apostrophe in the path indicates that BIP32 hardened derivation is used.

Each level has a special meaning, described in the chapters below.

Purpose

Purpose is a constant set to 43, indicating the key derivation is for a non-bitcoin cryptocurrency.

Hardened derivation is used at this level.

Subpurpose

Subpurpose is set to 60, the SLIP-44 code for Ethereum.

Hardened derivation is used at this level.

EIP

EIP is set to the EIP number specifying the remainder of the BIP32 derivation path. For paths following this EIP specification, the number assigned to this EIP is used.

Hardened derivation is used at this level.

Wallet

This component of the path splits the wallet into different user identities, allowing a single wallet to have multiple public identities.

Accounts are numbered from index 0 in sequentially increasing manner. This number is used as child index in BIP32 derivation.

Hardened derivation is used at this level.

Software should prevent a creation of an account if a previous account does not have a transaction history (meaning its address has not been used before).

Software needs to discover all used accounts after importing the seed from an external source.

Rationale

The existing convention is to use the 'Ethereum' coin type, leading to paths starting with m/44'/60'/*. Because this still assumes a UTXO-based coin, we contend that this is a poor fit, resulting in standardisation, usability, and security compromises. As a result, we are making the above proposal to define an entirely new hierarchy for Ethereum-based chains.

Backwards Compatibility

The introduction of another derivation path requires existing software to add support for this scheme in addition to any existing schemes. Given the already confused nature of wallet derivation paths in Ethereum, we anticipate this will cause relatively little additional disruption, and has the potential to improve matters significantly in the long run.

For applications that utilise mnemonics, the authors expect to submit another EIP draft that describes a method for avoiding backwards compatibility concerns when transitioning to this new derivation path.

Test Cases

TBD

Implementation

None yet.

References

This discussion on derivation paths

Copyright

Copyright and related rights waived via CC0.