HD Wallet Support

Key management is the foundation of digital asset security. Every blockchain transaction, every authentication event, and every policy enforcement ultimately depends on how cryptographic keys are generated, stored, and used. For years, onchain finance has relied on Hierarchical Deterministic (HD) Wallets, a model introduced through Bitcoin Improvement Proposals BIP-32 and BIP-44, that allows a tree of wallet addresses to be deterministically derived from a single “root key.”

Today, Dfns adds HD wallet support to its platform. This new feature enables full key import and export compatibility with legacy systems. However, while HD wallets are a functional necessity for interoperability, Dfns continues to view them as an outdated and insecure model. Their popularity originated from early hardware limitations and not from sound cryptographic design. This post explains (1) what key derivation means and how it became a de facto industry standard, (2) how Dfns implemented HD wallets, and why we are adding them only now, and (3) why Dfns believes HD wallets are technically flawed and should not be part of future designs.

What key derivation really means

In cryptography, key derivation refers to generating multiple cryptographic key pairs from a unique public-private key pair, also known as a “root key,” deterministically. Each derived key corresponds to a different wallet address or account, determined by a mathematical path. 

In Bitcoin’s HD wallet standard (BIP-32), a wallet path is a list of integers, like:

m / 0' / 1 / 2

Each level defines a branch of the hierarchy. For example:

• m/44'/60'/0'/0/3 might represent the fourth Ethereum account in a user’s wallet.
• The ' symbol denotes “hardened” derivation, a type of path that prevents public key leakage attacks.

All keys in this hierarchy can be regenerated from the master key, as long as the derivation paths are known. This allows unlimited address creation from a single key.

Enabling import, export, and portability

The motivation for supporting HD wallets has little to do with scalability and everything to do with key migration, regulatory compliance, and architectural modularity.

The institutional custody ecosystem is dominated by HD-based architectures. Vendors such as Fireblocks, BitGo, Ledger Enterprise, Ripple Custody, and Taurus all derive wallets from master keys using proprietary derivation schemes. Their APIs, recovery mechanisms, and audit workflows are built around that deterministic structure.

For customers, this creates a portability problem. Once their key hierarchies are tied to a specific vendor’s infrastructure, they cannot easily migrate without regenerating every address, invalidating historical references, and potentially disrupting regulated operations. Supporting HD wallets ensures that financial institutions can de-risk vendor dependencies while remaining fully operational.

By adding HD wallet support, Dfns eliminates this vendor lock-in. Customers can now:

• Import existing master extended keys from other providers and rehydrate their entire wallet tree within Dfns’ secure environment.
• Export root keys and derivation metadata for business continuity, ensuring they can migrate back or to another provider if required by contract, regulation, or internal governance.
• Reconstruct existing derivation paths to maintain historical address continuity, critical for accounting, regulatory audits, and blockchain analytics.

Supporting regulatory compliance and audit continuity

Regulated institutions are often required to prove continuity of control over cryptographic assets across infrastructure changes. Dfns’ HD support allows customers to demonstrate that the same key hierarchy, and therefore the same legal control of assets, persists after migration.

The feature also simplifies audit reconciliation: imported wallets retain their original derivation paths, allowing auditors to cross-reference on-chain histories with previous custody systems.

Promoting wallet stack modularity

The modern wallet stack is increasingly modular: exchanges, stablecoin issuers, and payment providers want to mix vendors, swap out key managers, and layer governance and policy tools from different providers. HD wallet compatibility enables this modularity. By supporting industry-standard derivation formats, Dfns integrates cleanly into heterogeneous infrastructures without forcing customers into a vertically integrated or closed ecosystem.

How Dfns implemented HD wallets

Dfns’ HD wallet support introduces a new cryptographic primitive inside its key management layer: the Derivation Master Key (DMK). Unlike regular wallets, a DMK cannot be used to sign transactions or broadcast messages. Its only role is to generate derived keys using deterministic offsets based on derivation paths. Under the hood, this system combines MPC-based security of the master key with deterministic key derivation at the edge.

Dfns’ system was deliberately designed without HD wallets. Every key pair in Dfns is generated through either MPC or HSM, with each signer contributing independent randomness. This ensures no single entity, including Dfns, ever possesses the full private key. Every wallet has its own entropy, its own lifecycle, and its own audit log. 

So why introduce HD wallets at all? The reason is interoperability, i.e., enabling clients to migrate from legacy custody systems while retaining the same keys, addresses, and compliance records.

Architecture overview

Each key management service (KMS) used inside Dfns (e.g., MPC, HSM, etc.) can now generate and maintain one or more master extended keys. These are stored and managed under the same threshold cryptography used for ordinary Dfns wallets or any FIPS certified device that clients bring on their own. From there:

1. A master extended key (DMK) is created using:

POST /keys
{
  "scheme": "ECDSA",
  "curve": "secp256k1",
  "masterKey": true
}

2. This key acts as the root of derivation. It is marked non-signable.
3. To create a child derived key:

POST /keys
{
  "deriveFrom": {
    "keyId": "key-xxxx",
    "derivationPath": "m/1147563635/0/5"
  }
}

4. Dfns’ infrastructure computes a deterministic offset based on the master key and the derivation path using secure hash-based transformations (read more about our Rust-based HD derivation library, open-sourced at the Linux Foundation under the Lockness project) as specified by BIP32, applied at the signer level without reconstructing the master key. The resulting child key behaves as an independent key object inside the API.
5. Each derived key can now be used to create wallets:

POST /wallets
{
  "network": "Ethereum",
  "signingKey": {
    "deriveFrom": {
      "keyId": "key-xxxx",
      "derivationPath": "m/1147563635/0/5"
    }
  }
}

6. All derivation paths are automatically indexed, logged, and recoverable. If a derived wallet is archived or deleted, it does not affect the master key or its other children.

Internal derivation scheme

Each master key can deterministically generate 2³¹ derived wallets, giving massive scaling potential while remaining lightweight in storage and computation.

The derived keys are stored as metadata objects, not full MPC shares, meaning new wallet creation becomes a metadata insertion rather than a full distributed key generation (DKG) protocol execution. This optimization reduces wallet creation time from seconds to microseconds and costs by several orders of magnitude.

Security controls

Even though HD derivation introduces correlation between keys, Dfns mitigates traditional risks through architectural constraints:

• Root key isolation: the DMK never leaves the MPC/HSM enclave and is never exposed, even as an extended public key.
• Path control and persistence: derivation paths are recorded and versioned; users cannot lose them.
• Delegation consistency: if a DMK is delegated, all derived wallets inherit the same resource ownership and access policies.
• Audit immutability: every derivation operation, path assignment, and derived wallet creation is logged in the Dfns cryptographic audit ledger.
• Cross-key separation: derived keys cannot be exported or delegated independently, preventing unauthorized exposure of the key hierarchy.

These features make Dfns’ HD model safe for high-volume applications without undermining the MPC security boundary.

Why adding HD wallets only now

When BIP-32 introduced HD wallets in 2012, the goal was simple: allow users to restore entire wallet hierarchies from one backup seed. Instead of managing thousands of independent keys and backups, users could safely store a single seed phrase and deterministically regenerate every derived key when needed. But the deeper reason behind this invention was not convenience, it was hardware limitation.

In the early 2010s, most wallets were physical devices with minimal memory and processing capacity. Hardware wallets like Trezor and Ledger could not store or manage large sets of independent keys. Memory was measured in kilobytes, and regenerating thousands of cryptographically secure key pairs would have been infeasible.

HD derivation solved this. By storing just one root key and a mathematical derivation function, hardware devices could generate new addresses on demand without consuming extra memory. It was an ingenious workaround that fit the constraints of the time.

Fast-forward to today: custody, staking, trading and other forms of wallet infrastructure run in cloud-native environments. Storage and computation are no longer scarce resources. Yet the HD wallet model, designed to economize on hardware memory, still dominates the institutional space. HD wallets were born from hardware limitations, but they survive because of ecosystem inertia.

However, there’s a trade-off. Because every derived key is a mathematical function of the same root key, all children share the entropy of the parent. If the parent key is compromised, all derived wallets are compromised too. Entropy independence—a critical property of strong key management—is lost.

Why Dfns remains skeptical of HD wallets

Dfns generates unique public–private key pairs by default. One wallet = one key pair.

HD wallets will remain an opt-in feature that clients can enable manually, as we don’t believe the less secure option should be the default. What began as a convenience has become a structural flaw. Instead of creating independent, high-entropy keys, most providers still rely on deterministic key trees derived from a single entropy source. 

This approach introduces a single point of failure and a single source of trust, both unacceptable in enterprise or institutional settings, and precisely the problems MPC was designed to solve.

• Shared entropy and correlated risk: All derived keys share the same entropy. BIP-32’s chain code improves key diversification but doesn’t restore independence. Compromise of the root key compromises every wallet beneath it. In contrast, Dfns’ segregated model ensures each wallet is created with fresh, distributed randomness, i.e., a compromise of one key yields no information about others.
• Path fragility and recovery dependency: HD wallets depend on derivation paths for recovery. Lose the path and you lose the key. Dfns mitigates this by maintaining a durable path registry, but it remains an architectural fragility absent in segregated wallets.
• Extended key exposure: If a child private key and the master extended public key are both known, the entire subtree can be reconstructed. This is why Dfns deliberately withholds chain codes and extended public keys from exposure through its APIs. They remain internal-only artifacts.
• Complexities in threshold cryptography: HD derivation was designed for single-key environments, not threshold-based MPC systems. In multi-party setups, the derivation offset must be computed collaboratively without reconstructing the secret.‍
• Limited suitability for secure operations: HD wallets simplify operational flows but violate defense-in-depth principles that institutions demand. For instance, independent key rotation, key provenance tracking, and cryptographic compartmentalization are harder to enforce under a deterministic hierarchy.

Dfns’ new HD wallet support is not an endorsement of the HD paradigm, but a reconciliation with market reality. We’ve implemented it in a way that preserves the spirit of distributed custody: root keys remain protected under threshold cryptography, derivations are logged and controlled, and the attack surface is minimized by design.

Start building onchain today: app.dfns.io/get-started