ERC-7908 HD Wallet Path Standard for Treasury Management (HD wallet In Treasury Management)
Final · Accounts & wallets · created 2025-03-07
Defines an HD wallet path that lets a company derive isolated Ethereum accounts for each subsidiary and department from a single master key using fixed rules. It enables unified group management and permission separation between departments at the same time.
Why it is needed
As blockchain and DeFi grow quickly, it has become important for companies to manage onchain assets directly. However, the traditional approach of creating and storing a separate private key for each account struggles to meet the complex needs of large organizations. A group with many subsidiaries and departments needs hierarchical key management, permission control and multi-signature mechanisms, but without a common rule each organization manages keys in its own way and permission boundaries between departments become blurred. Auditing is also hard, because there is no systematic way to trace which key belongs to which department. This standard defines how to derive subsidiary and department accounts from a single master key along a unified path, together with security requirements, and offers a solution that secures both assets and transaction efficiency in multi-chain environments.
In depth
Derivation Path Structure
Implementations must use the path m/44'/60'/entity_id'/department_id'/account_index. m is the root HD wallet private key, 44' is the hardened level indicating BIP 44 compliance, and 60' is the coin type for Ethereum and EVM-compatible chains. entity_id' is a hardened index made by hashing the subsidiary name, and different subsidiaries must not reuse the same value. department_id' is likewise a hardened index made by hashing the department name, and hardened derivation must isolate keys between departments. Only the last level, account_index, uses non-hardened derivation, which allows unified account management. Because Ethereum uses an account model rather than UTXOs, it is better to omit the BIP 44 change level.
Hash Conversion from Names to Indexes
entity_id is computed by hashing the string "ENTITY:{entity}" with SHA-256, reading the first 4 bytes as a big-endian integer, and applying a bitwise OR with 0x80000000. department_id is computed by hashing "DEPT:{entity_hash}:{department}" in the same way. Because the subsidiary hash is part of the department hash input, the same department name yields a different index under a different subsidiary. The generated index must be an integer from 2^31 to 2^32-1 inclusive, and this range enforces hardened derivation.
Extended Path for Role-Based Access
When finer access control by role is needed within a department, the path m/60'/entity_id'/department_id'/role_id'/account_index can be used. It is better for role_id' to use hardened derivation so that keys are isolated per role. However, this path omits the 44' level, so it may not be compatible with standard wallets such as MetaMask, and integrating with such wallets requires implementing a custom plugin that handles this difference.
Simplified Path for Small Organizations
An organization with no subsidiaries can use a simplified path of the form m/44'/60'/department_id'/0/account_index. The source states that this structure should ensure compatibility with mainstream BIP 44 wallets. Overall, this standard draws on the BIP 44 five-level structure (m/purpose'/coin_type'/account'/change/address_index), but for Ethereum-based systems the change level must not be used, and it allows extending beyond five levels according to an organization's needs.
Key Derivation Algorithm Requirements
Key derivation must use the official BIP 32 derivation function on the secp256k1 curve. The source's pseudocode models an organization as a map of subsidiaries and departments, builds a root key from the path, and for each organization concatenates the root key with the hierarchical hash index and uses the SHA-256 hash of that as the key. Concatenating the hash with the root key is meant to prevent key leakage between levels, and this is a mandatory requirement. This standard complies with BIP 39, BIP 32 and BIP 44.
Four Usage Scenarios
The original text lists four application scenarios. First, create an isolated on-chain account for each subsidiary and department in a group, and block exposure risk with hardened derivation. Second, the group administrator holds the master private key and derives all subsidiary private keys, giving the group top-level authority over viewing and transacting across the whole group. Third, Alice, the administrator of subsidiary A, shares only subsidiary A's master private key with a new administrator, Bob, and Bob can then derive every department account. Fourth, if the extended public key of a specific department is shared with the audit department, the auditors can derive all child public keys and track the transactions of those addresses. The reference implementation demonstrates account creation, lookup of the extended public key for auditing, department isolation, and extended private key sharing in Python.
Things to watch out for
- Master key protection measures are needed: A hierarchical deterministic wallet is convenient for fund managers, but a single master key holds all authority. Additional protections must be put in place, such as splitting the mnemonic or master key and storing the parts separately.