# Key derivation

Executive summary
**For almost all new deployments, Ripple Custody uses hierarchical deterministic (HD) key derivation to generate unlimited blockchain addresses from a single master seed.**

- One master seed backup recovers all accounts across all blockchains.
- Derivation paths provide cryptographic separation between addresses.
- **VaultHard is the only strategy available by default** for new vaults—the most secure option.
- VaultSoft and Random strategies require explicit enablement by your CPE (Customer Partner Engineer).


Why this matters
Key derivation strategy affects your security posture, backup and disaster recovery procedures, and blockchain compatibility. Hardened derivation provides stronger key isolation but requires KMS support. Your choice of strategy determines which blockchains you can support and how key material is protected.

**For architects and operators**: Choose your derivation strategy carefully during initial deployment — changing it later requires key migration. Verify that your KMS platform supports your chosen strategy before committing. Document your derivation paths for disaster recovery procedures.

Prerequisites
Before reading this page, you should understand:

- [Key management](/products/custody/v1.34/concepts/key-management) - How Ripple Custody protects cryptographic keys
- [Accounts](/products/custody/v1.34/concepts/accounts) - The relationship between accounts and blockchain addresses


## What is key derivation?

Key derivation is the cryptographic process of creating new private keys by deriving them from an existing key, called the *master seed*. Rather than generating and storing thousands of independent private keys (one for each blockchain address), Ripple Custody derives all keys mathematically from a single master seed.

The derivation process works as follows:

1. **Master seed creation**: When you initialize your key management system (HSM or MPC), a *master seed* is generated and securely stored. This seed is a random 256-bit or 512-bit value that serves as the root of all derived keys.
2. **Derivation path specification**: The method to use to derive each child private key is specified by a unique *derivation path* — a sequence of numbers that acts as an address within the key hierarchy. For example, `m/44'/144'/0'/0/0` specifies a path to derive an XRP Ledger key.
3. **Child key calculation**: The KMS applies a cryptographic hash function (HMAC-SHA512) to combine the parent key with the derivation path index. This produces a new 512-bit output: the first 256 bits become the child private key, and the remaining 256 bits become the chain code for further derivation.
4. **Public key derivation**: From each derived private key, the corresponding public key is calculated using elliptic curve multiplication. The public key is then used to generate the blockchain address.


This process is *deterministic* — given the same master seed and derivation path, the KMS will always produce the same private key. This property enables disaster recovery — if you have backed up your master seed, you can regenerate all derived keys without needing to store each individual private key.

### Key derivation and accounts, domains, and vaults

The following diagram shows how key derivation fits within the Ripple Custody organizational structure:


```mermaid
flowchart TD
    subgraph Vault["Vault"]
        MS[Master Seed]
    end

    subgraph D1["Domain 1 (d=1)"]
        A1["Account 1<br/>Path: m/1'/1'"]
        A2["Account 2<br/>Path: m/1'/2'"]
    end

    subgraph D2["Domain 2 (d=2)"]
        A3["Account 1<br/>Path: m/2'/1'"]
    end

    MS -->|"Derives"| A1
    MS -->|"Derives"| A2
    MS -->|"Derives"| A3

    A1 -->|"secp256k1"| ETH1["Ethereum Address"]
    A1 -->|"secp256k1"| BTC1["Bitcoin Address"]
    A1 -->|"Ed25519"| SOL1["Solana Address"]

    A2 -->|"secp256k1"| ETH2["Ethereum Address"]
```

- **Vault**: Contains the master seed from which all keys are derived
- **Domain**: An organizational unit that groups accounts; each domain has its own unique derivation index (e.g., `d=1`, `d=2`)
- **Account**: A logical entity with a unique derivation path; one account can have addresses on multiple blockchains
- **Address**: A blockchain-specific address derived from the account's key using the appropriate elliptic curve


**Same key, different addresses:** When an account derives addresses for blockchains that use the same elliptic curve (e.g., Bitcoin and Ethereum both use secp256k1), the underlying key pair is the same. However, each blockchain uses a different address encoding scheme, so the resulting addresses are different. For example, Ethereum addresses use Keccak-256 hashing, while Bitcoin addresses use SHA-256 followed by RIPEMD-160.

For more information about accounts, see [Accounts](/products/custody/v1.34/concepts/accounts). For more information about domains, see [Create domains (UI)](/products/custody/v1.34/ui/environment/domain/create) or [Create domains (API)](/products/custody/v1.34/api/environment/domain/create).

## BIP32 and BIP44

Hierarchical Deterministic (HD) wallets derive child keys from parent keys following [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) and [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) standards:


```
m / purpose' / coin_type' / account' / change / address_index
```

Examples:

- Bitcoin: `m/44'/0'/0'/0/0`
- Ethereum: `m/44'/60'/0'/0/0`
- XRP: `m/44'/144'/0'/0/0`


The apostrophe (') indicates **hardened derivation**.

## SLIP10

[SLIP10](https://github.com/satoshilabs/slips/blob/master/slip-0010.md) extends BIP32 to support elliptic curves that BIP32 does not natively support, specifically Ed25519. While BIP32 was designed for secp256k1 (the curve used by Bitcoin and Ethereum), many newer blockchains use Ed25519 for its performance and security characteristics:

- **Ed25519 blockchains**: Solana, Cardano, Polkadot, Stellar, Algorand, Tezos
- **secp256k1 blockchains**: Bitcoin, Ethereum, Tron, XRP Ledger, Litecoin


Ripple Custody implements SLIP10 to provide consistent key derivation across all supported blockchains, regardless of the underlying elliptic curve.

### How Ripple Custody uses SLIP10

When you create a new Ripple Custody account, Ripple Custody assigns the account a derivation path `p`, which is a unique sequence of numbers representing the domain `d` and account number `a`. For hard derivations, this results in derivation path `m/d'/a'`, where `'` represents hard derivation and `m` is the master seed.

This derivation path `p`, together with the wrapped seed and the ledger-dependent curve (secp256k1 or Ed25519) are transmitted to the KMS, which performs key derivation according to SLIP10. The KMS returns to Ripple Custody the derived extended public key, which is then stored in the database.

When Ripple Custody attempts to generate a transaction from the account, the vault requests the KMS to sign the transaction payload using the wrapped seed and the derivation path. Based on these parameters, the KMS deterministically derives the secret key, signs the provided data, and returns the signature to the vault.

For UTXO-based ledgers, such as Bitcoin, the KMS derives each UTXO account `u` based on the parent domain `d` and account `a`, resulting in derivation path: `m/d'/a'/u`.

## Hardened vs non-hardened derivation

Deterministic key derivation can be either hardened or non-hardened (also called "soft"):

| Aspect | Hardened Derivation | Non-Hardened Derivation |
|  --- | --- | --- |
| **Notation** | Index with apostrophe: `0'`, `1'` | Index without apostrophe: `0`, `1` |
| **Requires** | Access to the master seed or parent private key | Only the parent public key |
| **Security** | If a child private key is compromised, the parent key remains safe | If a child private key is compromised AND the parent public key is known, the parent private key can be derived |
| **Use case** | Account-level derivation (higher security) | Address-level derivation (allows watch-only wallets) |


In Ripple Custody, the first three levels of the derivation path (`purpose'`, `coin_type'`, `account'`) always use hardened derivation to ensure that compromise of any individual address key cannot expose the master seed.

Key Takeaway
**Hardened derivation is more secure** because it prevents an attacker who compromises a child key from deriving the parent key. Ripple Custody uses hardened derivation at the domain and account levels.

## Key derivation strategies

Ripple Custody supports three key derivation strategies that determine how keys are generated for new accounts. **VaultHard is the only strategy enabled by default** for new vaults. The other strategies (VaultSoft and Random) require explicit enablement by your CPE due to their additional configuration and backup implications.

The following diagram illustrates the VaultHard derivation strategy. Reading from top to bottom:

- **Master seed**: The root secret stored in the HSM or distributed across MPC nodes.
- **Domain level**: Each domain gets a unique index derived with hardened derivation (d').
- **Account level**: Each account within a domain gets a unique index, also hardened (a').
- **Address level** (UTXO only): For Bitcoin-type ledgers, individual UTXO addresses are derived using soft derivation, enabling address generation without vault access.


Key Strategy Hard
### VaultHard (recommended)

With VaultHard, the domain and account indices use hardened derivation, meaning access to the master seed (via the vault) is required to create new accounts. This is the most secure strategy because:

- Compromise of any child key cannot expose the parent key
- All account creation is auditable through the vault
- Keys can be fully recovered from the master seed backup


VaultHard is the only strategy available by default for new vaults.

### VaultSoft (requires CPE enablement)

With VaultSoft, all derivations from the master seed downwards use non-hardened (soft) derivation. This allows account creation using only the extended public key, without direct vault access. VaultSoft is only supported for ledger protocols based on ECDSA (secp256k1), including Bitcoin, Ethereum, Tron, and XRP Ledger.

VaultSoft has weaker security properties: if both a child private key and the parent extended public key are compromised, an attacker can derive the parent private key. **This strategy requires explicit enablement by your CPE.**

### Random (requires CPE enablement)

For KMS platforms that do not support deterministic derivation, you can use *random key generation*. With the Random strategy, rather than deriving keys from the master key, keys are generated randomly with no derivation relationship to the master seed. Addresses within UTXO accounts may still use *soft* derivation if the KMS supports it.

With a random key strategy, accounts cannot be recovered from the master seed. You must back up your database to prevent permanent loss of keys. **This strategy requires explicit enablement by your CPE.**

Enabling Alternative Strategies
**VaultHard is the only key derivation strategy available by default.** If you have a specific requirement for `VaultSoft` or `Random`, contact your Ripple liaison to request enablement by your CPE (Customer Partner Engineer). These strategies have additional configuration and backup implications that must be addressed before use.

## Choosing a derivation strategy

For most deployments, **VaultHard is the only strategy you need**. The following comparison is provided for customers who have specific requirements that necessitate an alternative strategy.

| Factor | VaultHard (Default) | VaultSoft (CPE Required) | Random (CPE Required) |
|  --- | --- | --- | --- |
| **Availability** | Enabled by default | Requires CPE enablement | Requires CPE enablement |
| **Security level** | Highest | Medium | Lowest (no recovery) |
| **Disaster recovery** | Full recovery from seed | Full recovery from seed | Requires database backup |
| **Account creation** | Requires vault access | Public key only | Requires vault access |
| **Cold vault compatible** | Yes (for UTXO addresses) | Yes | No |
| **Supported curves** | secp256k1, Ed25519 | secp256k1 only | All |
| **Recommended for** | All production deployments | Specific high-volume UTXO requirements | Legacy KMS that lacks derivation support |


Recommendation
**Use VaultHard for all deployments.** This is the default strategy and provides the highest security with full disaster recovery. Only request VaultSoft or Random enablement if you have a documented requirement that cannot be met with VaultHard.

## Derivation strategies by ledger

The following table lists the key derivation strategies available for each ledger. These strategies apply to all supported KMS platforms.

Important
The key derivation strategy available by default for new vaults is `VaultHard` as the other strategies have additional configuration and backup implications. If you have a specific requirement for `VaultSoft` or `Random`, contact your Ripple liaison for additional work from CPEs.

| Ledger | VaultHard | VaultSoft | Random |
|  --- | --- | --- | --- |
| Bitcoin | ✅ | ✅ | ✅ |
| Ethereum | ✅ | ✅ | ✅ |
| Tron | ✅ | ✅ | ✅ |
| XRPL | ✅ | ✅ | ✅ |
| Tezos | ✅ |  | ✅ |
| Substrate | ✅ |  | ✅ |
| Cardano | ✅ |  | ✅ |
| Stellar | ✅ |  | ✅ |
| Solana | ✅ |  | ✅ |
| Algorand | ✅ |  | ✅ |
| Hedera | ✅ |  | ✅ |


## Elliptic curve derivation

Different blockchain networks use different cryptographic algorithms to secure transactions. Just as different locks require different keys, each blockchain requires keys generated using a specific mathematical curve. Ripple Custody handles this complexity automatically—when you create an account for a specific blockchain, the system selects the correct curve and derivation path.

**Why this matters:**

- **Compatibility**: Your keys will work with the target blockchain
- **Security**: Each curve is chosen for its security properties on that network
- **Simplicity**: You don't need to manually configure curves—the system maps them automatically


For the ledgers listed above, Ripple Custody supports derivation of several elliptic curves, where derivation of keys for a specific ledger requires the usage of a specific curve. For each identifier, the following derivation paths are available (where `d` is domain, `a` is account, and `'` is hard derivation):

| Curve | secp256k1 | secp256k1 | Ed25519 | Ed25519 | Ed25519 |
|  --- | --- | --- | --- | --- | --- |
| Identifier | `secp256k1_CUSTODY_1` | `secp256k1_CUSTODY_1` | `Ed25519_CUSTODY_1` | `Ed25519_CUSTODY_2` | `Ed25519_STAKING_1` |
| Purpose | Custody - hard derivation | Custody - soft derivation | Custody - hard derivation | Custody - hard derivation | Staking - hard derivation |
| Bitcoin | `d'/a'` | `d/a` |  |  |  |
| Ethereum | `d'/a'` | `d/a` |  |  |  |
| Tron | `d'/a'` | `d/a` |  |  |  |
| XRPL | `d'/a'` | `d/a` |  |  |  |
| Tezos |  |  | `d'/a'` |  |  |
| Substrate |  |  | `d'/a'` |  |  |
| Cardano |  |  |  | `d'/a'/0'` | `d'/a'/1'` |
| Stellar |  |  | `d'/a'` |  |  |
| Solana |  |  | `d'/a'` |  |  |
| Algorand |  |  | `d'/a'` |  |  |
| Hedera |  |  | `d'/a'` |  |  |


The two potential derivation based keys for identifier `secp256k1_CUSTODY_1` refer to the key derivation strategy selected during creation of the account, that is, `VaultHard` or `VaultSoft`. For `Random` strategies, one different random key is generated per identifier.

We recommend a hard derivation strategy wherever possible.

For KMS configuration details, see the platform-specific guides in [Integrate KMS](/products/custody/v1.34/how-to/integrate-kms/overview).

## Glossary

| Term | Definition |
|  --- | --- |
| **BIP32** | Bitcoin Improvement Proposal 32, the standard that defines hierarchical deterministic wallet structure and key derivation for secp256k1 keys. |
| **BIP44** | Bitcoin Improvement Proposal 44, which defines a standard derivation path structure: `m / purpose' / coin_type' / account' / change / address_index`. |
| **Chain code** | A 256-bit value derived alongside each key that enables further child key derivation. The chain code prevents derivation of sibling keys from a single child key. |
| **derivation path** | A sequence of indices (e.g., `m/44'/144'/0'/0/0`) that uniquely identifies a key within the hierarchical structure. Each number represents a level in the tree. |
| **ECDSA** | Elliptic Curve Digital Signature Algorithm, a cryptographic signature scheme used by Bitcoin, Ethereum, and XRP Ledger (secp256k1 curve). |
| **Ed25519** | An elliptic curve used for digital signatures, known for its speed and security. Used by Solana, Cardano, Polkadot, Stellar, Algorand, and Tezos. |
| **extended public key** | A public key combined with its chain code, enabling derivation of child public keys without access to the private key (for non-hardened derivation only). |
| **hardened derivation** | Key derivation that requires access to the parent private key. Indicated by an apostrophe (e.g., `0'`). Prevents child key compromise from affecting parent keys. |
| **HMAC-SHA512** | A cryptographic hash function used in BIP32/SLIP10 to derive child keys from parent keys and the derivation index. |
| **master seed** | The root secret (a 256- or 512-bit value) from which all keys are derived. Typically generated from a mnemonic phrase and stored securely in the KMS. |
| **non-hardened (soft) derivation** | Key derivation that can be performed using only the parent extended public key. Indicated by no apostrophe (e.g., `0`). |
| **secp256k1** | The elliptic curve used by Bitcoin, Ethereum, and XRP Ledger for digital signatures and key generation. |
| **SLIP10** | SatoshiLabs Improvement Proposal 10, which extends BIP32 to support Ed25519 and other curves that BIP32 does not natively support. |
| **UTXO** | Unspent Transaction Output, the accounting model used by Bitcoin-type blockchains where each transaction consumes previous outputs and creates new ones. |
| **wrapped seed** | The master seed encrypted with a key-encrypting-key (KEK) for secure storage and transmission. The KMS unwraps it during derivation operations. |