2026-05-21 21:48:19 +02:00
2026-05-21 21:48:19 +02:00

CHIP 2026-paths

Title: Paths
Type: Standards
Layer: Applications
Maintainer: Tom Zander
Initial Publication Date: 2026-05-22
Latest Revision Date: 
Version: 0.1
Table of Contents

Introduction

In Bitcoin Cash wallets there is a need to manage any number of addresses in a clean and reproductive manner. The basic concepts of a seed phrase based master key with the derivation of a many addresses from this master key are already well known.

This proposal, or request for comments, suggests a wider use of this basic technology in order to allow various interesting new use cases to be unlocked and this document records the methods in order to allow better inter-wallet communication and cooperation.

This document focuses purely on standardizing derivation paths, the part behind the [base] 2 starting numbers that are defined elsewhere. Those extended derivation paths and their usage range from multi-person or multi-device setups and many others.

Deployment

Deployment is permissionless.

Technical Specification

refresher on technical details.

Every derivation path exists from a series of numbers. The numbers are either hardened or not. This is relevant only for privacy reasons. The derivation path always starts with a standard base. Always starting with m/44'/. A full path is often 5 levels, but more is possible. This document defines paths as either a full path or a partial path.

A full path example is m/44'/0'/0'/0/0. This in combination with a masterkey produces a single private key and thus address.
A partial path example m/44'/145'/0'/0/ Which has both a different base and misses the last 0. A partial path can be used to resolve millions of addresses by adding a single number at the end of the path.

We refer to the first 2 levels as the base.

A hardened level is signified with a single quote. The first level of 44 is always hardened and is written as m/44'/. Hardened is important because of the idea of XPub. A wallet can take the users seed phrase and then create a Masterkey that refers to the base. The XPub, or it's private counterpart, the XPriv, can have the derivation pre-applied and most important it can't be un-derived up the path past a hardened level.

  • Base: the first 2 levels of a path.
  • XPriv: a pre-derived masterkey. Capable of creating private keys for the rest of the path.
  • XPub: A pre-derived masterkey. Only capable of creating public keys for the rest of the path.
  • Hardened: A cryptographic back-stop. A xpub pre-derived can't go up the path past a hardened section.

Levels.

The base itself always starts with m/44/` followed with either zero of hundred fourtyfive. This is well documented elsewhere and not part of the spec. We simply just call it 'base' from here on.

The wallet-base extends the base with one more level. Most, if not all, wallet-projects today default to zero (hardened) for this, and we extend this based on the idea of family usage of company usage.

After the BASE (2 levels) we add a 3rd level we call the extension. The extension defines multiple actual physical wallets being used from the same seed and the same base.

extension:
0': main wallet
1': second wallet

This is not something today implemented, I've wanted to get to it for some time and never managed. But the idea is sound and I hope others may pick up this idea.

Usecase example is where you have a family computer at home and that one we call the main wallet. Then your phone uses the second-wallet path. They both started from the same seed phrase and as such backup is much more manageable. Additionally, the extension is always a hardened path and as such your mobile phone can store the data pre-derived and no addresses can be found even if the phone is stolen and unlocked.

The main computer can be defined to be the master, however. Which means it can simply create watch-only wallets for any known extension wallets. A father sending pocket money to the son can simply send to the next available address because the father has full view of the sons wallet.

Similarly, the master wallet can drain or top up any wallet in case of need. Maybe even automatically with pre-fused outputs so you're never going to end up with too low number of coins on your mobile phone.

Managing these series of wallets is easy with the backup CHIP by the same author as that has one seed and multiple derivation paths already natively. So just scan the NFC tag with the backup, select your wallet name and your phone can download all the rest of the data.

Receive level:
0: user-controlled addresses (lifetime set by user, typically will listen forever)
1: wallet-controlled addresses (formerly change chain)

This is simply repeating what is common practice today.

Receive level cont.:
0'..: private xpubs.

Private xpubs can be used to give away to anyone that wants to pay you repeatedly, but not every single time to the same address. So instead of giving them one of the addresses from your zero chain, you give them an entirely private hardened xpub.

The idea is this: you derive an xpub from your basic wallet BASE/EXTENSION/n' The 'n' is any number, just remember who you gave which xpub to. Notice that the n' is hardened. Making it only usable for creating addresses in the range that is private between you and your counterparty.

So if you give such an xpub to your employer they can send you money to a new sequential address every time, which is completely predictable on your side and your wallet can pick up the cash and use it.

Another exciting usage of this idea is that if you want someone to pay you a very large amount that you don't want them to pay you in one big and easy to notice transaction, you can give them a private xpub instead and they can spread their payment over a large number of transactions for privacy.

Ownership chain

In the Flowee Pay wallet we do encrypted backups of details like transaction-comments. This requires a wallet-based identity, which is a bitcoin address and we use it's related private key as basis for the encryption.

Ownership based on a public key is well documented with things like signing PDFs to the simple concept of logging in to a web service based on the primitives of public/private key cryptography.

What is important is that the bitcoin addresses used for ownership are distinct from the ones you store money on.

We defined that the partial derivation path of BASE/EXTENSION/2/ is used for its identity chain. Additionally, the full derivation path BASE/EXTENSION/2/0 is the address that identifies the wallet itself.

  • Wallet identity (index 0)
  • Login to services.
  • Ownership of BCMR, for signing transactions with op-return.

Changelog

This section summarizes the evolution of this document.

Copyright (C) 2023-2026 Tom Zander

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.

S
Description
Documenting derivation paths and neat ideas.
Readme 38 KiB