Skip to main content
Spark wallets use a hierarchical deterministic (HD) key derivation scheme purpose-built for the Spark protocol. This follows the general principles of BIP43, using a custom purpose field derived from the SHA256 hash of “spark” to define application-specific key derivations.
This derivation scheme is our recommendation so users can easily migrate between different wallet apps. You can implement a different scheme, but it will lose the ability to migrate to/from other Spark wallets.

Derivation Scheme

Base Derivation Path

Where:
  • 8797555’: Custom purpose field (derived from last 3 bytes of SHA256(“spark”) = 0x863d73)
  • accountNumber’: Account index (hardened derivation)
  • keyType’: Specific key type (hardened derivation)

Key Types

Spark derives 5 key types from the master seed:

Identity Key

Path: m/8797555'/n'/0'Primary wallet identifier. Used for authentication, Spark Address generation, and message signing.

Signing HD Key

Path: m/8797555'/n'/1'HD key used as the base for deriving leaf-specific signing keys. Each Spark leaf gets its own derived key.

Deposit Key

Path: m/8797555'/n'/2'Used for receiving L1 Bitcoin deposits into Spark. Single key, not HD-derived.

Static Deposit HD Key

Path: m/8797555'/n'/3'HD key for generating reusable static deposit addresses. Each index produces a different deposit address.

HTLC Preimage HD Key

Path: m/8797555'/n'/4'HD key for generating HTLC preimages in Lightning payments. The htlcHMAC() method uses this key.

Account Number

Default Behavior

The accountNumber parameter controls which account’s keys are derived. The default value differs by network:
MAINNET defaults to 1 for backwards compatibility with legacy wallets created before multi-account support. If you’re integrating with the SDK and using account 0 internally, account for this off-by-one behavior on mainnet.

Using Account Numbers

Explicit Account Numbers

When building wallet software, always specify the account number explicitly to avoid confusion:

Leaf Key Derivation

When accepting transfers, Spark assigns a unique leaf ID to each UTXO. The signing key for that leaf is derived from the Signing HD Key using the leaf ID.

Derivation Formula

Full Derivation Path

Where leafIndex is calculated from the leaf ID as shown above.

Implementation

Using KeyDerivation

In the SDK, you typically don’t derive leaf keys manually. Instead, use the KeyDerivation type:

Static Deposit Key Derivation

Static deposit keys are derived from the Static Deposit HD Key at path /3':
In the SDK:

Deposit Address Flow

For L1 Bitcoin deposits, the flow is:
  1. Generate Deposit Key: Uses the Deposit Key at path m/8797555'/n'/2'
  2. Create Deposit Address: Generate Bitcoin address from the key
  3. Receive Deposit: User sends Bitcoin to the address
  4. Assign Leaf: After tree creation, funds are assigned to a leaf with its own derived key

Usage in SparkWallet

Initialize with Specific Account

Multiple Accounts from Same Mnemonic


Custom Derivation Paths

For non-standard use cases, you can provide a custom key generator:
Custom derivation paths will not be compatible with other Spark wallets. Only use this if you have specific requirements that justify breaking compatibility.

Migration Between Wallets

The standardized derivation scheme enables wallet migration:

Export

Import


Security Considerations

Hardened Derivation

All derivation paths use hardened derivation (indicated by the ' suffix). This prevents:
  • Key leakage: Child public keys cannot be used to derive parent keys
  • Chain code exposure: Compromising a child key doesn’t compromise siblings

Key Isolation

Each account number creates a completely isolated set of keys:

Mnemonic Security

  • Store mnemonic phrases securely (encrypted, offline if possible)
  • Never transmit mnemonics over the network
  • Consider using hardware wallets or secure enclaves for production

Quick Reference