Succession
What the beneficiaries do, designed for the worst circumstances anybody uses this product in.
The flow this product exists for, and the only one that will be used by somebody who did not choose to be here.
Assume the person is grieving, has never opened this app, is not technical, and is doing it on a borrowed laptop at a kitchen table. Everything else in this reference design should be judged by whether it makes this survivable.
Recommendation
Design this flow first and work backwards. A setup flow that produces an elegant arrangement nobody can execute has failed at the only thing it was for.
The two routes in
Together, at any time. Two beneficiaries holding keys can spend exactly as they could while the owner was alive. No special mode. We suggest leading with this route: it covers the whole balance and needs no waiting.
Alone, after the period. One beneficiary uses the pre-signed transaction, which became valid once the inactivity period elapsed. No other signature is needed, because the signatures were collected when the arrangement was last refreshed. It moves only the money that was in the wallet at that moment.
Do
Say which route is available, and when the other becomes available, on the first screen a beneficiary sees. "You and Alice can do this together now. On your own, from 14 March 2027."
Loading the wallet
The configuration comes from their own copy, or from the recovery document. This is where the document earns its place: it is the route for somebody whose phone is new, whose app is gone, and who has only a sheet of paper.
Do
Accept the configuration from a printed code as readily as from a file. Paper is the medium most likely to survive a decade and an estate.
Do
Show the balance and what can be done with it immediately after import, before asking for anything else. The first question is "is it still there".
Moving the money
The destination is almost always the beneficiary's own wallet, so the flow should assume that and let it be changed.
Do
Offer "move everything to my own wallet" as the default action, not a generic send screen. It is what more or less everybody is here to do.
Do
Let it be done in parts. Somebody may want to move a little first to be sure it works, and that instinct should be supported rather than treated as an error.
Signing together
In these screens Christina signs with David, Bob's brother, who holds the extra key described in the Overview.
Do
Make sharing the part-signed transaction work over whatever people already use: a message, email, a code on a screen. Do not require both parties to be in the same place, or to install anything beyond the wallet that holds their key.
Do
Name the people, not the keys. "Waiting for David" is something a grieving person can act on.
Using the pre-signed route
The route particular to BSV, and the one with a failure mode worth designing against.
The transaction was signed when the arrangement was last refreshed. It needs no further signature. It only needs to be broadcast, and only after its lock time.
Do
Show the lock date plainly and whether it has passed. "This becomes valid on 14 March 2027" and, after that, "This can be sent now."
Do
Check the inputs are still unspent before offering it, and say clearly if they are not: "This route is out of date because the wallet was used after it was prepared. Use the two-signature route instead." That is the single most likely failure and it must not present as a cryptic error.
Don't
Let a beneficiary broadcast a transaction whose inputs are gone and watch it fail. Check first and explain.
Important
A pre-signed transaction sends a fixed amount to a fixed destination, decided when it was made. Money received after that is not included, and needs the two-signature route. Say what it will actually move, in figures, and what it will leave behind, before it is sent.
Things nobody plans for
Worth building for, because they happen:
- A beneficiary who has lost their key. If the threshold can still be met without them, say so. If not, say that too, plainly and early.
- Two beneficiaries who disagree. The arrangement enforces a threshold, not an agreement. The product should not pretend to mediate.
- A beneficiary who does not know what BSV is. The flow should work for somebody who has never held any, and end with the money somewhere they understand.
- An executor or solicitor helping. They will not have a key, and should still be able to see what exists and what is required.
After
Do
Offer to archive the arrangement once it is empty, keeping its history and its document. There may be an estate to account to.
Do
Tell the other participants it was used, and when. Somebody holding a key should learn that the arrangement has been executed from the app rather than from a relative.
Open questions
- Can a beneficiary who has never used the app complete either route from the recovery document alone?
- What should an executor without a key be able to see, and does showing it to them leak more than the estate needs?
- How should the flow end for a beneficiary who wants local currency rather than BSV, without the guide recommending an exchange?
Related
- Backup: the recovery document this flow depends on
- Making changes
- Time-based recovery
Written from: BRC-29, BRC-42, BRC-140, ts-stack script docs.
Checklist
The rules on this page, in a form you can work through.
13 rules