Bip32

BIP32 HD Key Derivation (Multi-Chain)

The bip32 crate natively supports Secp256k1 (Ethereum/EVM). For Ed25519 (Solana), the solana-sdk provides native SLIP-10 derivation functions. From a single master 64-byte seed, you can securely derive accounts for both ecosystems based on standard BIP-44 paths.

Dependency Setup

[dependencies]
bip32 = { version = "0.5", features = ["secp256k1", "mnemonic"] }
alloy-signer-local = "2.0" # For EVM mapping
solana-sdk = "4.0"         # For Solana SLIP-10 mapping
solana-derivation-path = "3"  # For Solana derivation path parsing
rand_core = { version = "0.6", features = ["std"] }  # Required by bip32 for Mnemonic

Core Patterns at a Glance

1. Master Seed Generation

Generate a master seed from a mnemonic, or parse an existing one from environment variables.

use bip32::Mnemonic;

// Generate new 24-word mnemonic
let mnemonic = Mnemonic::random(&mut rand_core::OsRng, Default::default());
let seed = mnemonic.to_seed(""); // 64-byte seed array

2. Deriving EVM Keys (Alloy)

EVM standardizes on the path m/44'/60'/0'/0/n (where the final index n is unhardened). The bip32 crate handles this directly.

use bip32::{XPrv, DerivationPath};
use alloy_signer_local::PrivateKeySigner;
use std::str::FromStr;

pub fn derive_eth(seed: &[u8; 64], index: u32) -> PrivateKeySigner {
    // Parse the Ethereum derivation path
    let path: DerivationPath = format!("m/44'/60'/0'/0/{}", index).parse().unwrap();
    
    // Derive the child Extended Private Key (XPrv) from seed and path
    let child_xprv = XPrv::derive_from_path(seed, &path).unwrap();
    
    // Convert to Alloy PrivateKeySigner
    // child_xprv.private_key() provides the 32-byte secret scalar
    let private_key_bytes = child_xprv.private_key().to_bytes();
    PrivateKeySigner::from_slice(&private_key_bytes).unwrap()
}

3. Deriving Solana Keys (solana-sdk)

Solana uses Ed25519 with SLIP-10 hardened derivation. The standard path is m/44'/501'/n'/0'. Do not use the `bip32` crate for this—instead, use solana_sdk directly, passing the exact same 64-byte master seed.

use solana_sdk::signature::{Keypair, keypair_from_seed_and_derivation_path};

pub fn derive_sol(seed: &[u8; 64], index: u32) -> Keypair {
    // Note the single quotes indicating hardened derivation at every level
    let derivation_path = format!("m/44'/501'/{}'/0'", index);
    
    // Use from_absolute_path_str which handles the "m/" prefix
    use solana_derivation_path::DerivationPath as SolanaDerivationPath;
    let path = SolanaDerivationPath::from_absolute_path_str(&derivation_path).unwrap();
    solana_sdk::signer::keypair::keypair_from_seed_and_derivation_path(seed, Some(path)).unwrap()
}

4. Architecture Pattern for MQ Workers

In a distributed environment (like an Apalis MQ worker pool), you inject the 64-byte master seed as shared Data<<TT> and dynamically derive the key based on the database index n only when an active job executes. The database only stores n, never private keys.

use alloy_signer_local::PrivateKeySigner;
use solana_sdk::signature::Keypair;

#[derive(Clone)]
pub struct KdfConfig {
    pub seed: [u8; 64],
}

impl KdfConfig {
    pub fn get_evm_signer(&self, n: u32) -> PrivateKeySigner {
        derive_eth(&self.seed, n)
    }
    
    pub fn get_sol_signer(&self, n: u32) -> Keypair {
        derive_sol(&self.seed, n)
    }
}

Known Issues — BIP32 Skill

Issues discovered through practical compilation testing against actual crate versions (bip32 0.5.3, solana-sdk 4.0.1, alloy-signer-local 2.0.4).

1. XPrv::new(seed).derive_path(path) API — Incorrect Pattern (BREAKING)

The skill demonstrates root_xprv.derive_path(path) but derive_path is not a method on ExtendedPrivateKey<K>. The correct API is:

// WRONG (skill's code):
let root_xprv = XPrv::new(seed).unwrap();
let child_xprv = root_xprv.derive_path(path).unwrap();

// CORRECT:
let child_xprv = XPrv::derive_from_path(seed, &path).unwrap();

derive_from_path is a static method, not an instance method. See bip32 0.5.3 docs.

2. keypair_from_seed_and_derivation_path API Changed (BREAKING)

The skill uses a &String path, but the actual Solana SDK v4.x API expects Option<DerivationPath>:

// WRONG (skill's code):
keypair_from_seed_and_derivation_path(seed, &derivation_path)

// CORRECT:
use solana_sdk::signer::keypair::keypair_from_seed_and_derivation_path;
use solana_derivation_path::DerivationPath as SolanaDerivationPath;
let path = SolanaDerivationPath::try_from(derivation_path_str.as_str()).unwrap();
keypair_from_seed_and_derivation_path(seed, Some(path))

Note: The import path changed from solana_sdk::signature::* to solana_sdk::signer::keypair::*.

3. Missing Signer trait import for pubkey()

Keypair::pubkey() requires Signer trait in scope:

// WRONG:
use solana_sdk::signature::Keypair;
keypair.pubkey()  // ERROR: method not found

// CORRECT:
use solana_sdk::signature::{Keypair, Signer};
keypair.pubkey()  // Works

4. Mnemonic::random requires rand_core v0.6

The bip32 crate depends on rand_core 0.6, not 0.9. Using rand_core 0.9 causes trait resolution failures:

# Cargo.toml must use:
rand_core = { version = "0.6", features = ["std"] }

5. Seed type has no .len() method

mnemonic.to_seed("") returns a Seed type, not [u8; 64]. Use seed.as_bytes() instead:

let seed = mnemonic.to_seed("");
// WRONG: seed.len()
// CORRECT:
let seed_bytes: &[u8] = seed.as_bytes();
assert_eq!(seed_bytes.len(), 64);

6. solana-derivation-path required as separate dependency

The keypair_from_seed_and_derivation_path function needs DerivationPath type from solana-derivation-path crate (v3.x). Use from_absolute_path_str for parsing, NOT TryFrom<&str>:

// WORKS:
use solana_derivation_path::DerivationPath as SolanaDerivationPath;
let path = SolanaDerivationPath::from_absolute_path_str("m/44'/501'/0'/0'").unwrap();

// FAILS (returns InvalidDerivationPath):
let path = SolanaDerivationPath::try_from("m/44'/501'/0'/0'".as_str()).unwrap();

# Additional dependency:
solana-derivation-path = "3"

bip32-skills

A skill for generating Hierarchical Deterministic (HD) wallets for multiple blockchains using the bip32 crate.

Overview

In modern orchestration systems (like reeve), user accounts or agent spaces don't have separate keypairs. Instead, a single 64-byte master seed derives millions of isolated keys deterministically based on database row indices.

This skill teaches the LLM how to derive child private keys from a master seed for both EVM chains (using Secp256k1 via bip32) and Solana (using Ed25519 SLIP-10 derivation natively via solana-sdk).

Installation

npx skills add melonask/bip32-skills

What This Skill Covers

• Mnemonic/Seed generation: Creating a master 64-byte seed.
• EVM Derivation: Unhardened paths (m/44'/60'/0'/0/n) mapping to alloy Signers.
• Solana Derivation: Hardened paths (m/44'/501'/n'/0') mapping to solana-sdk Keypairs using SLIP-10.

File Structure

bip32/
└── SKILL.md                          # Main skill file (Key derivation patterns)

License

Provided as-is for development with LLM assistants.