ERC-7908: HD wallet In Treasury Management

Abstract

This proposal aims to provide a standardized method for on-chain treasury management of institutional assets, ensuring secure private key generation, hierarchical management, and departmental permission isolation while supporting asset security and transaction efficiency in multi-chain environments. By defining a unified derivation path and security mechanisms, this proposal offers an efficient and secure solution for treasury management.

Motivation

With the rapid development of blockchain and DeFi, secure management of on-chain assets has become critical. Traditional private key management struggles to meet the security demands of large organizations in complex scenarios, where hierarchical key management, permission controls, and multi-signature mechanisms are essential. This proposal provides a standardized solution for institutional treasury management, ensuring asset security and transaction efficiency.

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Derivation Path

For secure on-chain treasury account key management, implementations MUST use the following hierarchical deterministic (HD) path:

Path Components:

1. Master Key (m)

   • SHALL represent the root HD wallet private key.

2. BIP 44 Compliance Layer (44')

   • MUST use 44' (hardened) to indicate BIP 44 compliance.

3. Coin Type Layer ( 60' )

   • SHALL use 60' (hardened) for Ethereum and EVM-compatible chains.

4. Entity Identifier ( entity_id')

   • MUST be derived by hashing the subsidiary name into a hardened index.
   • MUST NOT reuse the same entity_id' across distinct subsidiaries.

5. Department Identifier (department_id')

   • SHALL be derived by hashing the department name into a hardened index.
   • MUST isolate keys between departments via hardened derivation.

6. Account Index (account_index)

   • MUST use non-hardened derivation to allow unified account management.

Note on BIP 44 Adaptation:

• The BIP 44 change layer SHOULD be omitted for Ethereum/EVMs due to their account model (not UTXO).

Hash Conversion

To derive entity_id and department_id:

1. Entity Index Calculation

   • SHALL compute entity_id as:

2. Department Index Calculation

   • MUST compute department_id as:

3. Output Constraints

   • Generated indices MUST be integers in [2^31, 2^32-1] to enforce hardened derivation.

Extended Path for Role-Based Access

For finer access control (e.g., roles within departments):

1. Role Identifier (role_id')

   • SHOULD use hardened derivation to isolate role-specific keys.

Compatibility Note:

• Omitting the 44' layer MAY cause incompatibility with standard wallets (e.g., MetaMask).
• Integrations with such wallets MUST implement custom plugins to handle this deviation.

Simplified Path for Smaller Entities

For entities without subsidiaries:

Compatibility Guarantee

• This structure SHOULD ensure compatibility with mainstream BIP 44 wallets.

Key Derivation Algorithm

Implementations MUST adhere to:

Cryptographic Requirements:

• SHALL use BIP 32 with secp256k1 for HD derivation.
• MUST concatenate hashes with root keys to prevent cross-layer key leakage.

Compatibility Considerations

This specification is inspired by BIP 44 (m/purpose'/coin_type'/account'/change/address_index), but:

• SHALL NOT use the change layer for Ethereum-based systems.
• MAY extend the hierarchy beyond BIP 44’s 5-layer structure for organizational needs.

Rationale

The scenarios for which the proposal applies are:

1. Company and Department Isolation: Different subsidiaries within the group, as well as different departments within each subsidiary, can create isolated on-chain accounts. Enhanced derivation is used to isolate exposure risks.
2. Group Unified Management Authority: The group administrator holds the master private key, which can derive all subsidiary private keys, granting the highest authority to view and initiate transactions across the entire group, facilitating unified management by the group administrator.
3. Shared Department Private Key: If subsidiary A's administrator, Alice, needs to share accounts under subsidiary A with a new administrator, Bob, she only needs to share the master private key of subsidiary A. Accounts from various departments can then be derived from this key.
4. Shared Audit Public Key: If the audit department needs to audit transactions under a specific department, the extended public key of the specified department can be shared with the audit department. Through this extended public key, all subordinate public keys under the department can be derived, allowing the audit department to track all transactions associated with these public key addresses.

Backwards Compatibility

This standard complies with BIP 39, BIP 32, and BIP 44.

Reference Implementation

run script:

output：

Security Considerations

For treasury managers, hierarchical deterministic wallet management is more convenient, but it requires additional consideration of protective measures for the master key, such as schemes for splitting and storing mnemonic phrases or master keys.

Copyright

Copyright and related rights waived via CC0.