Onboarding cosigners
Getting the configuration and a key to each person who will need one, and making sure they understand what they are holding.
A key on somebody's phone is not enough. For the arrangement to work years later they need four things, and a design that stops at the key delivers only the first:
- A key, which they generated themselves.
- The wallet configuration: which keys, what threshold, what period.
- The current pre-signed recovery transaction, if they are on that path.
- An understanding of what they are holding, in words they will recall under stress.
The third is particular to BSV and the one most likely to be forgotten. Without the transaction, a beneficiary with a valid key and the configuration still cannot use the succession path. See Time-based recovery.
Sending the configuration
The configuration names every participating key, so it maps the whole arrangement.
The wallet configuration is privacy-sensitive
It describes who is involved and what they can do. Send it the way you would send a house key: directly, to a person, not to a group chat or a public link.
Do
Track per person whether they have received it, imported it, and confirmed. Three states, because "sent" is not "working".
On the other person's phone
The review screen is the one that matters. It is where somebody learns what they have been given, and for most cosigners it is the only time they will read it.
Do
Say what they can do, what they cannot, and when that changes, in a sentence each: "You can't move this money on your own. You and Christina together can. If Bob doesn't use it for a year, Christina can on her own."
Do
Name who asked, and let them decline. Being added to somebody's inheritance arrangement is a real obligation.
Don't
Present it as "a wallet has been shared with you". They are not getting money, and somebody who thinks they are will be confused twice: now, and much later.
Enabling their device
Before the arrangement relies on a cosigner's key, prove it works.
Do
Have the cosigner sign something harmless as part of setup, so both sides know the key works before it is relied on. A key that has never signed is an assumption.
What they should keep
Do
Give each cosigner an export they hold themselves, containing the configuration, their key's recovery material and, where they are on the succession path, the current pre-signed transaction.
Do
Re-send the pre-signed transaction every time it is rebuilt, which is after every payment in or out and every refresh. An out-of-date copy either spends money that has already moved, and fails, or misses money the wallet received since.
Important
This is the heaviest maintenance job in the design, and it should be automated rather than left to the owner. If the wallet cannot confirm that every beneficiary has the current transaction, it should say so on the home screen.
Keeping them in the loop
Years will pass. People change phones, change email addresses, and forget this exists.
Do
Send an occasional note to each cosigner confirming the arrangement is alive and their key still works. Once or twice a year is enough, and it doubles as a check that their contact details are current.
Do
Let a cosigner see the arrangement at any time without the owner's involvement.
Open questions
- How does the owner's wallet learn that a cosigner has received and stored the latest transaction, without a server that knows the whole arrangement?
- Do cosigners read "You can't move this money on your own" correctly, or do they think they have been given money?
- What should happen on the owner's side when a cosigner declines?
Related
Written from: BRC-42, BRC-140, ts-stack script docs.
Checklist
The rules on this page, in a form you can work through.
9 rules