
Overview
The people, the keys and the rules: how an inheritance arrangement is shaped, and what each participant can and cannot do.
Who holds which key, what each person can do alone or together, and how the arrangement behaves over ten years. Read this before the flow pages.
The people
A worked example, used across these pages:
- Bob, who owns the money and sets this up.
- Alice, his partner, who should be able to reach it with him today and without him later.
- Christina, his adult daughter, who inherits.
- Optionally a fourth person holding one more key: a sibling, a lawyer or a service. In these pages that is David, Bob's brother.
The example matters because the design question is never "how many keys" but "who holds what, and what can each of them do alone".
The keys
A workable arrangement is two of four, held like this:
| Key | Held by | Where |
|---|---|---|
| 1 | Bob | His phone |
| 2 | Bob | A signing device at home, or a second phone |
| 3 | Alice | Her phone |
| 4 | Christina | Her phone |
Today, Bob spends with his two keys. Alice and Bob together can spend. Alice and Christina together can spend, which is deliberate: if Bob is unavailable, the two people closest to him can act without waiting.
Adding David adds a key, so the question below has to be asked again with him in it.
Do
Choose the threshold by asking which pairs of people should be able to act together, not by picking a number. "Any two of these four" is a sentence the owner can check against their own family.
Don't
Build an arrangement where the owner alone cannot spend. It turns everyday access into a committee and the wallet stops being used, which is how it ends up abandoned and unmaintained.
What the succession path adds
Two of four covers "Bob is unavailable but Alice and Christina are around". It does not cover "Bob is gone and only Christina is left".
The succession path does: a transaction signed in advance that becomes valid after a period of inactivity and moves the funds to a smaller group, or one person.
On BSV that is an nLockTime transaction rather than a script condition, which has consequences the owner must understand:
- somebody has to hold it until it is needed
- it is invalidated by any spend, and does not cover money received after it was signed, so it is rebuilt after every payment in or out
- pushing its date back means moving the money, because an older copy stays valid until the money it spends moves
- the keys that signed it are not needed later, which is the point
See Time-based recovery.
What each person can do
The table worth putting in the product, because it is the thing nobody can keep straight:
| Today | After the period, with no activity | |
|---|---|---|
| Bob alone | Spend | Spend, which also cancels the succession route until it is rebuilt |
| Alice alone | Nothing | Nothing |
| Christina alone | Nothing | Send the succession transaction, which moves the funds it covers to her |
| Alice + Christina | Spend | Spend |
Do
Show this table in the app, filled in with the real names, and let anybody holding a key see it. A participant who does not know what they hold cannot act when it matters.
The life of the arrangement
Over ten years this wallet is likely to see something like three phone replacements, one person moving house, one person changing their mind, several periods of nobody thinking about it at all, and eventually the event it was built for.
That is the design brief. Everything in Making changes exists because of it.
Recommendation
Judge every setup decision by what it costs to maintain. A four-key arrangement with a six-month period is more secure on paper and will be dead in two years, because nobody keeps up with it.
Open questions
- Why should the route after the period go to Christina and not Alice? Test whether owners expect their partner on it.
- If Bob and Christina are both gone, Alice alone can do nothing. Is that acceptable to owners once the table shows it to them?
- Is two of four the arrangement owners pick when offered named options, or do they choose something simpler?
Related
Written from: BRC-42, BRC-140, ts-stack script docs.
Checklist
The rules on this page, in a form you can work through.
4 rules
