Making changes
Replacing a lost device, changing who is involved, and moving the funds. The routine work that decides whether the arrangement is still real in ten years.
An inheritance arrangement is set up once and lives for a decade. In that time there are likely to be three or four phone replacements, somebody will move away, somebody will be added, and the owner will spend from it occasionally.
None of that is an edit. Every one of them is a transaction. Every one also invalidates the succession path, and so does any payment received, so the path has to be rebuilt after each.
A pre-signed succession transaction stays valid until the money it spends moves. So refreshing the timer, changing the period or removing somebody means moving the money in a payment from the wallet to itself, which needs the keys and costs a fee, and then signing a new succession transaction. Money received after signing is not covered until the next refresh.
Important
A wallet that lets the arrangement change without rebuilding the pre-signed transaction has quietly broken the inheritance. The change succeeds, the wallet looks right, and the succession path no longer works. This must be automatic, and visible when it fails.
Replacing a key
The change this wallet will see most: a new phone, a lost signing device, a cosigner who switched to a different handset.
With a multi-key script the keys are written into every output, so replacing one means moving the money to outputs that carry the new key. Plan it as a migration, like changing the arrangement below.
Do
Distinguish a planned replacement, where the old key still exists, from a lost one. They need different confirmations and the second is a security event.
Do
Require the remaining quorum to authorise the replacement. One person should not be able to swap another out.
Do
End the flow by confirming three things happened: the new configuration reached everybody, the succession transaction was rebuilt, and the recovery document was regenerated. Each is a separate failure if it is skipped.
Important security note
If a key was lost rather than retired, treat the move as urgent: whoever has the old device holds a working key until the money moves.
Moving the funds
A multi-key spend, which means collecting signatures from people who are not in the same room.
Do
Show progress as named people rather than a count: "Signed by Bob. Waiting for Alice or Christina."
Do
Let the second signer see what they are approving, including the recipient and the amount, on their own device. That screen is the only independent check in the flow.
Do
Let a pending payment be abandoned cleanly, and say so if it leaves outputs reserved.
Important
A spend consumes the outputs the succession transaction was built against, so that transaction no longer works. Rebuild it and redistribute it as part of completing the payment, not as a separate chore the owner might skip.
Changing the arrangement
Adding a person, removing one, or changing the threshold means a different spending condition, which means moving the money to outputs that carry it.
Do
Present it as a migration: a new arrangement is created and the balance moves to it, in a payment the current quorum approves.
Do
Keep the old wallet's history after the move. The arrangement changed; the record of what was spent did not.
Don't
Imply somebody can be removed without the funds moving. They keep their key, and a key that still works on the old outputs is a key that still works.
Changing the period
The same as the others: the money moves to new outputs, and a new pre-signed transaction is signed against them. Without the move, the old copy still works on its old date.
Do
Make sure every beneficiary gets the new transaction, and tell them the old one stopped working when the money moved. Two valid-looking copies with different dates is the worst state for somebody using this in an emergency.
Archiving
Do
Let an emptied arrangement be archived rather than deleted, keeping its history and its recovery document.
Don't
Allow an arrangement with a balance to be deleted. Offer to move the funds first and say where they would go.
Open questions
- Does the owner understand that pushing the date back is a payment, with a fee and an entry in activity?
- When a key is lost, how quickly do owners move the money, and what would make them act sooner?
Related
Written from: BRC-42, BRC-140, ts-stack script docs.
Checklist
The rules on this page, in a form you can work through.
12 rules