Inheritance wallet
Long-term savings with a plan for passing them on: what the arrangement is, who it is for, and the five flows it needs.
Self-custody has an ending problem. Money nobody else can reach stays out of reach when you are gone. The usual answer, an envelope of recovery words in a safe, is both a single point of theft and a single point of loss.
This reference design is a savings wallet with succession built in: several keys, held by the owner and by the people who will inherit, arranged so that nobody can act alone today and the right people can act together later.
What makes it different from a savings wallet
A savings wallet protects against theft and the loss of one key. An inheritance wallet adds three things:
- Other people hold keys from the start, not just at the end.
- A recovery path opens after inactivity, so the people you chose can reach the money without your keys or your devices.
- The arrangement has to survive years of the owner changing phones, people moving house, and nobody thinking about it.
The third is the hard one. Most of this design is maintenance.
Who it is for
Somebody holding an amount they would want passed on, who would rather arrange it themselves than rely on an envelope or a lawyer. Usually they have a partner, adult children or a trusted friend who can hold a key. The owner type is close to Hugo, the long-term saver.
Don't
Offer this to somebody setting up their first wallet. It is the most complex arrangement in this guide and the least forgiving of an abandoned setup. See Upgradeable wallet.
A note on BSV
Two protocol facts shape every page in this section.
This design uses a multi-key script rather than one key split into shares, because Alice and Christina need to sign on their own phones, in any order, without anybody's key being rebuilt in one place. See Multi-key for the alternative.
Timelocks are pre-signed transactions, not output conditions. CHECKLOCKTIMEVERIFY and CHECKSEQUENCEVERIFY no longer act as checks on BSV, so the succession route is a transaction signed in advance with an nLockTime, held by the people who will need it. It stays valid until the money it spends moves, and money received after it was signed is not in it. So it must be rebuilt after every payment in or out, and pushing its date back means moving the money. See Time-based recovery.
The arrangement is public. New pay-to-script-hash outputs are not allowed, so the keys and threshold are visible in the output. Anybody watching can see how many keys it has and how many must sign. Design accordingly, and never rely on the shape being secret.
The five flows
Start with the Overview: the people, the keys, and what each of them can do.
Wallet creation
Setting it up: the keys, the threshold, the succession period, and getting through it without the owner abandoning it halfway.
Onboarding cosigners
Getting the configuration and a key to each person who will need one, and making sure they understand what they are holding.
Backup
What has to be kept, by whom, and the document that makes it recoverable by somebody who has never used the app.
Making changes
Replacing a lost device, adding or removing a person, and extending the period. The routine work that keeps the arrangement real.
Succession
What the beneficiaries do, in the worst circumstances anybody uses this product in.
Recommendation
Read Succession before designing any of the others. Every decision in setup should be judged by whether it makes that flow survivable for somebody grieving, unfamiliar with the app, and possibly using it for the first time.
Open questions
- Do owners understand that keeping the arrangement alive is ongoing work, or do they expect to set it up once?
- Who do owners want on the route after the period: their partner, their children, or both?
Related
Written from: BRC-42, BRC-140, ts-stack script docs, Chronicle upgrade notes.
Checklist
The rules on this page, in a form you can work through.
2 rules