python-hdwallet: one Python library for 200+ HD wallet chains and standards

The pitch is one key derivation library instead of one per chain

python-hdwallet is described in the repository description as a Python based library implementing a Hierarchical Deterministic wallet generator for 200+ cryptocurrencies. The README positions it as a flexible and scalable solution for developers integrating multi-currency wallet functionality, and it says the library adheres to standard protocols for compatibility with other wallets and services, with features like secure seed generation, careful key management, and straightforward account control. The problem it solves is real and unglamorous. A product that accepts a deposit in six currencies needs six address formats, and the natural approach of a library per coin means six codebases, six security reviews, and six places to get a derivation path wrong. Here the derivation standards are implemented once and the chain is a parameter.

The feature table is organised by layer, not by coin

The table in the README is the most useful page in the project, because it shows the library as a stack rather than a list of coins. The cryptocurrencies row links to a supported list, and the rows below it are the layers. Entropies are `Algorand`, `BIP39`, `Electrum-V1`, `Electrum-V2`, and `Monero`, and mnemonics cover the same set. Seeds add `Cardano` and `BIP39`. The elliptic curve cryptography layer lists `Kholaw-Ed25519`, `SLIP10-Ed25519`, `SLIP10-Ed25519-Blake2b`, `SLIP10-Ed25519-Monero`, `SLIP10-Nist256p1`, and `SLIP10-Secp256k1`. The hierarchical deterministic row covers `Algorand`, `BIP32`, `BIP44`, `BIP49`, `BIP84`, `BIP86`, `BIP141`, `Cardano`, `Electrum-V1`, `Electrum-V2`, and `Monero`, derivations list `BIP44`, `BIP49`, `BIP84`, `BIP86`, `CIP1852`, `Custom`, `Electrum`, `Monero`, and `HDW` described as the library's own custom derivation.

Addresses are the layer where chain differences actually live

The addresses row is the longest in the table, and it is a useful catalogue of the format differences you would otherwise have to discover one at a time. It covers `Algorand`, `Aptos`, `Avalanche`, `Cardano`, `Cosmos`, `EOS`, `Ergo`, `Ethereum`, `Filecoin`, `Harmony`, `Icon`, `Injective`, `Monero`, `MultiversX`, `Nano`, `Near`, `Neo`, `OKT-Chain`, the Bitcoin output script types `P2PKH`, `P2SH`, `P2TR`, `P2WPKH`, `P2WPKH-In-P2SH`, `P2WSH`, and `P2WSH-In-P2SH`, plus `Ripple`, `Solana`, `Stellar`, `Sui`, `Tezos`, `Tron`, `XinFin`, and `Zilliqa`. The last row, Others, holds `BIP38`, `Wallet Import Format`, and `Serialization`. A team picking a library for a multi chain product reads this list and knows immediately which chains are covered and in what format.

Installing is pip, with an extra for the command line

The easiest way to install hdwallet is via pip:

pip install hdwallet

If you want the command line interface installed globally, for Linux `sudo` may be required:

pip install hdwallet[cli]

To run the latest version of the code you can install from git:

pip install git+ssh://github.com/hdwallet-io/python-hdwallet.git

The setup metadata confirms the structure. The package requires Python 3.9 or newer and below 4, and the `extras_require` dictionary defines `cli`, `docs`, and `tests` extras, each loading its own requirements file from a `requirements/` directory. A console script entry point named `hdwallet` is registered against `hdwallet.cli.__main__:cli_main`, so the CLI is part of the same distribution rather than a separate tool. The licence is MIT, and the documentation is published at hdwallet.readthedocs.io.

The API composes a wallet from explicit layer choices

The quick usage example is a Bitcoin HD wallet generator, and the imports show the layering directly:

from hdwallet import HDWallet
from hdwallet.entropies import (
    BIP39Entropy, BIP39_ENTROPY_STRENGTHS
)
from hdwallet.mnemonics import BIP39_MNEMONIC_LANGUAGES
from hdwallet.cryptocurrencies import Bitcoin as Cryptocurrency
from hdwallet.hds import BIP32HD
from hdwallet.derivations import CustomDerivation
from hdwallet.consts import PUBLIC_KEY_TYPES

The wallet object is then constructed by naming each layer:

hdwallet: HDWallet = HDWallet(
    cryptocurrency=Cryptocurrency,
    hd=BIP32HD,
    network=Cryptocurrency.NETWORKS.MAINNET,
    language=BIP39_MNEMONIC_LANGUAGES.KOREAN,
    public_key_type=PUBLIC_KEY_TYPES.COMPRESSED,
    passphrase="talonlab"
).from_entropy(
    entropy=BIP39Entro

Everything is a keyword argument and every value is an enum member, which makes a mismatched combination easy to spot when you read the code. The example also shows the mnemonic language choice, which is a small thing that matters when a user reads their recovery phrase aloud, and a passphrase parameter, which in BIP39 is an optional string mixed into the seed.

The cryptographic dependencies are the security surface

The requirements file is short and tells you what the library actually leans on: `ecdsa>=0.18.0,<1`, `crcmod>=1.7,<2`, `pycryptodome>=3.20,<4`, `ed25519-blake2b>=1.4.1,<2`, `coincurve>=20.0.0,<21`, `pynacl>=1.6.2,<2`, `base58>=2.1.1,<3`, and `cbor2>=5.6.1,<6`. That is a small, deliberate dependency set, with `coincurve` handling secp256k1 operations, `ed25519-blake2b` and `pynacl` covering the Ed25519 variants, `pycryptodome` for the symmetric and hashing work, and `cbor2` for binary encoding. Every one of them is pinned to a narrow version range, which for a library that derives private keys is the part of the manifest you should read rather than skim.

Where python-hdwallet is the wrong tool

Two boundaries are worth naming. The first is scope. This is a key derivation and address library. It produces mnemonics, seeds, extended keys, and addresses, and the README says nothing about signing transactions, broadcasting them, querying a chain, storing keys, or talking to a hardware wallet, so if your requirement is a wallet rather than a key derivation library, this is a component rather than a solution. The second is chain coverage in practice. The table lists a lot of addresses, but the same row also shows that the Hierarchical Deterministic support is concentrated in the Bitcoin family plus Cardano, Monero, Electrum, and Algorand, so a chain with a bespoke derivation outside that list falls back to the Custom or HDW derivation paths and the wallet behaviour becomes your responsibility. There is also a TypeScript port mentioned in the README, hdwallet.js, with a live playground at hdwallet.online, which is worth knowing if your team is not Python.

Editorial conclusion

python-hdwallet fits a Python team that needs to derive keys and addresses across many chains from one implementation rather than maintaining a separate library per coin, and that has to interoperate with other wallets, which is why every layer is tied to a published standard. It is the wrong tool if you need a full wallet with signing, transaction building, and key storage, because this is a key derivation and address library and says nothing about custody. It is also the wrong tool if you need hardware wallet integration or on-chain queries, none of which the README mentions. Before you adopt it, confirm the specific derivation and address type your chain uses appears in the feature table, and read the security notes, because a library whose job is to hold seed material deserves a careful look at how it handles it.

Frequently asked questions

Official sources

1. hdwallet-io/python-hdwallet on GitHub
2. License: MIT
3. Project website
4. README
5. Releases