Every time Purple Flea creates a wallet for an AI agent, it returns a BIP-39 mnemonic — a sequence of 12 or 24 English words that encodes the agent's entire financial identity. From those words, every private key, every address, and every signature the agent will ever produce can be deterministically derived. There are no databases to sync, no backups to manage, and no coordination required across instances.

This is not a coincidence. BIP-39 was designed for exactly the problem that agent developers face: how do you give a software process a persistent, recoverable, multi-chain financial identity with a single stored secret?

What BIP-39 Actually Is

Bitcoin Improvement Proposal 39, published in 2013, defines a standard for encoding random entropy as a sequence of common English words. The wordlist contains exactly 2048 words. A 12-word mnemonic encodes 128 bits of entropy (plus 4 checksum bits). A 24-word mnemonic encodes 256 bits (plus 8 checksum bits).

The encoding works like this:

  1. Generate cryptographically random bytes (128 or 256 bits)
  2. Hash the bytes with SHA-256 and append the first 4 or 8 bits as a checksum
  3. Split the resulting bit string into 11-bit groups
  4. Map each 11-bit group to one of the 2048 words in the BIP-39 wordlist

The result is a human-readable string that is also machine-parseable. For an agent, "human-readable" is less important than the other property: the mnemonic is the complete, self-contained representation of the entropy. Store those words, and you can reconstruct the entire wallet tree — every chain, every account, every address — at any time.

From Mnemonic to Seed: PBKDF2

The mnemonic is not used directly as a key. It is first stretched into a 512-bit seed using PBKDF2-HMAC-SHA512 with 2048 iterations. The input is the mnemonic phrase concatenated with an optional passphrase (prefixed with "mnemonic"). The output is the root seed from which all HD wallet keys derive.

For agents, the passphrase is a useful second factor: even if the 12-word mnemonic leaks, an attacker without the passphrase cannot derive the correct addresses. Some agent architectures store the mnemonic in one secrets system and the passphrase in a separate one, requiring both to be compromised for funds to be lost.

BIP-32: The HD Wallet Tree

BIP-39 generates the seed. BIP-32 defines how to derive a tree of key pairs from that seed. The root key acts as the trunk; every branch and leaf is derived deterministically using HMAC-SHA512 with the parent key and a child index.

A child key at index i is computed as:

bip32_derivation.py
import hmac, hashlib def derive_child_key(parent_key: bytes, parent_chain_code: bytes, index: int): # Hardened derivation: index >= 2^31 (0x80000000) # Normal derivation: index < 2^31 if index >= 0x80000000: # hardened data = bytes([0x00]) + parent_key + index.to_bytes(4, 'big') else: # normal data = pubkey_from_privkey(parent_key) + index.to_bytes(4, 'big') I = hmac.new(parent_chain_code, data, hashlib.sha512).digest() child_key = I[:32] # left 32 bytes = child private key material child_chain_code = I[32:] # right 32 bytes = child chain code return child_key, child_chain_code # The apostrophe in path notation (m/44'/60') means hardened derivation # Hardened children cannot be derived from the parent public key alone

The key insight is that derivation is one-way: given a child key, you cannot compute the parent. Given a parent public key, you cannot compute hardened children. This property is crucial for agent architectures where a master key might be stored in a high-security system while derived operational keys live closer to the agent.

BIP-44: Derivation Paths by Coin Type

BIP-44 standardizes the HD tree structure across blockchains using a five-level path:

Purpose m / 44' BIP-44 standard
Coin type / coin_type' 0'=BTC, 60'=ETH, 195'=TRX, 128'=XMR
Account / account' 0' = first account (isolates funds)
Change / change 0 = external, 1 = internal/change
Index / address_index 0, 1, 2 ... sequential addresses

For an agent managing funds across multiple blockchains, the derivation paths look like this: m/44'/60'/0'/0/0 for its first Ethereum address, m/44'/0'/0'/0/0 for its first Bitcoin address, and m/44'/195'/0'/0/0 for its first Tron address — all from a single 12-word mnemonic.

Why Deterministic Wallets Are Ideal for Agents

Human users benefit from HD wallets primarily because they can recover everything from a backup phrase. For agents, the advantages are different and arguably more important:

Creating a Wallet with Purple Flea

The Purple Flea Wallet API handles BIP-39 generation, seed derivation, and address computation server-side. Your agent receives a structured wallet object with addresses already derived for each supported chain. Store the mnemonic immediately in your secrets manager; it is returned only once at creation time.

create_wallet.py
import requests import os # Create a new BIP-39 wallet for this agent instance resp = requests.post("https://wallet.purpleflea.com/api/wallet/create", json={ "agent_id": "my-trading-agent-v2", "strength": 128 # 128 bits = 12 words, 256 = 24 words }) wallet = resp.json() # The mnemonic is returned ONCE - store it immediately mnemonic = wallet["mnemonic"] store_in_secrets_manager(mnemonic) # your secrets backend # Pre-derived addresses for each chain print(wallet["addresses"]["XMR"]) # m/44'/128'/0'/0/0 print(wallet["addresses"]["ETH"]) # m/44'/60'/0'/0/0 print(wallet["addresses"]["BTC"]) # m/44'/0'/0'/0/0 # wallet_id is your reference for all future API calls wallet_id = wallet["wallet_id"] # Check balance — uses wallet_id, never needs the mnemonic again balance = requests.get( f"https://wallet.purpleflea.com/api/wallet/{wallet_id}/balance" ).json() print(f"XMR balance: {balance['XMR']['total']}")

12 Words vs 24 Words: Which Should Agents Use?

A 12-word mnemonic provides 128 bits of entropy. To brute-force it, an attacker would need to try 2128 combinations — computationally infeasible with any technology that exists or is projected to exist for decades. A 24-word mnemonic provides 256 bits, which is also computationally infeasible but provides a larger margin against future advances in computing.

For agents managing small amounts in development, 12 words is fine. For production agents handling significant value, use 24 words — the operational cost is identical and the security margin is meaningfully larger. Purple Flea defaults to 128-bit (12-word) wallets but supports 256-bit on request.

Agent tip: Use a unique BIP-39 mnemonic per agent identity, not per task. Create task-specific wallets by deriving fresh addresses using incrementing indices (address_index = 0, 1, 2...) from the agent's master key. This way one backup covers all of the agent's financial history.

Security Considerations for Agents

Three properties of BIP-39 that matter specifically for agents:

First, the mnemonic encodes raw entropy — it is not itself a key. The words are a representation of randomness. This means the security of the wallet is only as good as the randomness used to generate it. Always use a cryptographically secure random number generator, never a predictable seed. Purple Flea uses OS-level entropy (/dev/urandom equivalent) for all wallet generation.

Second, the optional passphrase creates a "hidden wallet." An agent could use its environment-supplied passphrase with a public-ish mnemonic as a two-factor scheme — though most agent deployments opt for simpler full-secret storage instead.

Third, derived keys are permanent. Once funds are sent to address m/44'/128'/0'/0/7, they stay associated with that derivation path. If you ever need to prove ownership, you can re-derive that specific key from the mnemonic. This is actually useful for agents building audit trails: every address is reproducible from the mnemonic, so disputes about ownership can be resolved cryptographically.

Conclusion

BIP-39 is the right foundation for agent wallets because it collapses all of an agent's key management complexity into a single secret. One mnemonic, one backup, unlimited derived addresses across all chains. Combined with the Purple Flea Wallet API, agents can have full multi-chain financial capability without ever implementing BIP-32 derivation themselves — the API handles it, returns the mnemonic for backup, and accepts the wallet ID for all subsequent operations.