Payment Processor
Concepts

Escrow Wallets

How HD wallet derivation and the wallet pool work.

Overview

Payment Processor uses a pool of escrow wallets derived from a BIP-44 HD mnemonic. Each wallet address is deterministically derived at path m/44'/60'/0'/0/{index} using the standard Ethereum coin type. Because all EVM chains share the same address space, a single derived address works on every chain simultaneously — no per-chain wallet needed.

Wallet pool

At startup, the database is pre-seeded with escrow.numWallets addresses (configurable). When a new charge is created the API selects one unassigned wallet and marks it as assigned for the lifetime of that payment.

Pool: [wallet-0, wallet-1, wallet-2, ...]
         ↑ assigned               ↑ free

When payment completes (or expires) the wallet is released back to the pool and can be reused for the next charge.

If all wallets are in use, POST /v1/charges returns a NO_AVAILABLE_WALLETS error. Increase escrow.numWallets in your config to raise the pool size.

Key derivation

mnemonic (24 words)
    └─ m/44'/60'/0'/0/0  →  wallet address 0
    └─ m/44'/60'/0'/0/1  →  wallet address 1
    └─ m/44'/60'/0'/0/N  →  wallet address N

The mnemonic is read from the ESCROW_MNEMONIC environment variable (takes precedence over the config file value). The server derives addresses at startup and writes them to the database. Private keys are never stored — they can always be re-derived from the mnemonic if needed.

Security considerations

  • Store the mnemonic in a secrets manager (Vault, AWS Secrets Manager, etc.) and inject it via environment variable.
  • The mnemonic controls all funds. Anyone who obtains it can sweep every wallet.
  • Use a dedicated mnemonic for this service — not a personal wallet.
  • Consider rotating the mnemonic periodically by expanding the pool with new wallets.

On this page