# Lock BSV behind keys, time or a secret: every rule
Every do and don't the guide states on the pages behind this skill. The costly ones come first; the full list follows, grouped by page. Quote them; do not paraphrase them.
50 rules: 18 that can cost money, 3 that can cost trust, 29 standard.
## Start here
- **DO** _(Costs money)_ Build time conditions with nLockTime and nSequence, and test that an early spend fails. A test that only proves the late spend succeeds proves nothing.
- **DO** _(Costs money)_ State where a pre-signed future transaction lives, who holds it, and what happens if the inputs are spent before its date. That is a backup requirement, not an implementation detail.
- **DO** _(Costs money)_ Warn before a condition becomes unmeetable, not after. "One more lost key and this is unrecoverable" is useful; the same message afterwards is not.
- **DON'T** _(Costs money)_ Let a user create a condition they have not demonstrably tested. Require a small-value rehearsal of the unlock path before real money goes in.
- **DO** _(Costs money)_ Back up the wallet configuration alongside the key material, and include it in the recovery drill. A condition nobody can reconstruct is money nobody can move. See Backups.
- **DO** _(Costs money)_ Back up the wallet configuration with the same care as a key. It names every key in the arrangement.
- **DON'T** _(Costs money)_ Offer a period shorter than a few months. A path that opens while somebody is on a long trip is a theft risk dressed as a feature.
- **DO** _(Costs money)_ Make sure they keep the pre-signed transaction, since without it the path is theoretical. The wallet should hold it and the backup should include it.
- **DON'T** _(Costs money)_ Add somebody to a recovery path without telling them. The arrangement only works if they still have their key when it matters.
- **DO** _(Costs money)_ Send the new recovery transaction to the recovery people as part of every refresh, and show on the home screen anyone who has not received it.
- **DO** _(Costs money)_ Treat it as a change with consequences: move the money to new outputs first, so the removed person's copy stops working, then say who was removed and send the new transaction to the people who remain.
- **DON'T** _(Costs money)_ Let somebody be removed from a recovery path without the wallet confirming the replacement transaction actually reached everybody who needs it.
- **DO** _(Costs money)_ The pre-signed transaction is the part other backup designs have no slot for, and the part that makes this arrangement real. Back it up with the configuration, re-export it every time it is rebuilt, and include it in the recovery drill. See Backups.
- **DON'T** _(Costs money)_ Finish setup without the user having restored from it once, with a small amount. An untested multi-key wallet has more ways to fail than a single-key one.
- **DON'T** _(Costs money)_ Let the limit be raised with a single key. Raising the threshold for spending is itself a high-value action and needs the quorum.
- **DON'T** _(Costs money)_ Let the everyday wallet pull from savings on its own. A compromised app would drain both, which defeats the whole arrangement. See Multiple wallets.
- **DO** _(Costs money)_ Move the funds to a new arrangement when a key is lost, and say why: the old key still works on every output it is part of until the money moves.
- **DO** _(Costs money)_ Back up the wallet configuration alongside the keys, and include it in the recovery drill. A quorum of signers with no record of the arrangement cannot spend. See Backups.
- **DO** _(Costs trust)_ Treat the condition as public when you design it. A recovery path that only works because nobody knows it exists is not a security property.
- **DO** _(Costs trust)_ Let a partly signed payment be abandoned cleanly, without leaving funds stuck.
- **DON'T** _(Costs trust)_ Build savings features into the everyday wallet. A wallet that is both ends up too slow for a coffee and too exposed for savings.
## Every rule, by page
### Spending conditions
https://www.bitcoinsv.design/guide/patterns/spending-conditions/
- **DO** _(Costs money)_ Build time conditions with nLockTime and nSequence, and test that an early spend fails. A test that only proves the late spend succeeds proves nothing.
- **DO** _(Costs money)_ State where a pre-signed future transaction lives, who holds it, and what happens if the inputs are spent before its date. That is a backup requirement, not an implementation detail.
- **DO** State the minimum transaction version any script you document requires. A script that works in one version and silently fails in another is the worst kind of documentation error.
- **DON'T** Assume every wallet or service in the chain of custody emits the version your script needs. Check before you depend on it.
- **DO** _(Costs trust)_ Treat the condition as public when you design it. A recovery path that only works because nobody knows it exists is not a security property.
- **DO** Describe a condition by its consequence: "Locked until 1 March 2027. Nobody can move this, including you."
- **DO** Show the whole schedule on one screen, including the rules that have not taken effect yet.
- **DO** _(Costs money)_ Warn before a condition becomes unmeetable, not after. "One more lost key and this is unrecoverable" is useful; the same message afterwards is not.
- **DO** Let an unfinished setup be saved and resumed. These arrangements need several devices or several people and rarely come together in one sitting.
- **DON'T** _(Costs money)_ Let a user create a condition they have not demonstrably tested. Require a small-value rehearsal of the unlock path before real money goes in.
- **DON'T** Offer a condition builder to ordinary users. Offer two or three worked arrangements with names and plain descriptions, and let the complexity live in the templates rather than in the user's head.
- **DO** _(Costs money)_ Back up the wallet configuration alongside the key material, and include it in the recovery drill. A condition nobody can reconstruct is money nobody can move. See Backups.
### Multi-key
https://www.bitcoinsv.design/guide/how-it-works/private-key-management/multi-key/
- **DO** Show whose signature is still outstanding, and give a way to nudge them. Most of the time a shared payment is waiting on a person, not on the network.
- **DO** Walk the setup one key at a time, and say for each one where it is going and what losing it would mean.
- **DO** Let an unfinished setup be saved and resumed. Gathering three devices or three people rarely happens in one sitting.
- **DON'T** Finish setup without the user having restored from it once. An untested multi-key wallet is a wallet with more ways to fail than a single-key one.
- **DO** _(Costs money)_ Back up the wallet configuration with the same care as a key. It names every key in the arrangement.
- **DO** Show what is being signed in plain terms on every device that signs, and how many signatures are collected.
- **DO** _(Costs trust)_ Let a partly signed payment be abandoned cleanly, without leaving funds stuck.
- **DON'T** Say "2-of-3 multisig". Say "Two of your three keys are needed to spend", and name the keys the way the user named them.
- **DO** Pick on the trust question, not the privacy one. If the parties need to be sure no one of them can ever reconstruct the whole key, that is bare multisig. If the goal is one person's key surviving a fire, shares are simpler and cheaper.
### Time-based recovery
https://www.bitcoinsv.design/guide/savings-wallet/time-based-recovery/
- **DO** Explain the arrangement before any key is created, in terms of what happens rather than what it is made of: "You can always spend this. If you don't use it for a year, the people you choose can."
- **DO** Name each key by where it is, not by its number. "This phone", "Signing device", "Anna's phone" is what the owner will need to recognise in two years.
- **DO** Turn reminders on by default and say why: the path opening is the failure case, and a reminder is what prevents it.
- **DON'T** _(Costs money)_ Offer a period shorter than a few months. A path that opens while somebody is on a long trip is a theft risk dressed as a feature.
- **DO** Tell them what they have been given, in a message they can understand without the app: "Maya has named you on her savings wallet. You can't spend anything. If she doesn't use it for a year, you and one other person can move it on her behalf."
- **DO** _(Costs money)_ Make sure they keep the pre-signed transaction, since without it the path is theoretical. The wallet should hold it and the backup should include it.
- **DON'T** _(Costs money)_ Add somebody to a recovery path without telling them. The arrangement only works if they still have their key when it matters.
- **DO** Show the date plainly on the home screen, as a date rather than a countdown. "Recovery opens 14 March 2027" is checkable; "in 237 days" is anxiety.
- **DO** Remind well in advance, more than once, and through a channel that is not the app. Somebody who has stopped opening the app is exactly the person who needs reminding.
- **DO** Notify the recovery people when the path is refreshed, so they know the arrangement is alive.
- **DO** _(Costs money)_ Send the new recovery transaction to the recovery people as part of every refresh, and show on the home screen anyone who has not received it.
- **DO** _(Costs money)_ Treat it as a change with consequences: move the money to new outputs first, so the removed person's copy stops working, then say who was removed and send the new transaction to the people who remain.
- **DON'T** _(Costs money)_ Let somebody be removed from a recovery path without the wallet confirming the replacement transaction actually reached everybody who needs it.
- **DO** Fold the path rebuild into device replacement automatically, and show it as a step so the owner knows it happened.
- **DO** _(Costs money)_ The pre-signed transaction is the part other backup designs have no slot for, and the part that makes this arrangement real. Back it up with the configuration, re-export it every time it is rebuilt, and include it in the recovery drill. See Backups.
### Savings wallet
https://www.bitcoinsv.design/guide/savings-wallet/
- **DO** Size it by what the everyday wallet should not hold. "How much would you be uncomfortable keeping on your phone?" is the question that produces a sensible split.
- **DON'T** _(Costs trust)_ Build savings features into the everyday wallet. A wallet that is both ends up too slow for a coffee and too exposed for savings.
- **DO** Walk setup one key at a time, saying for each where it is going and what losing it would mean.
- **DO** Let setup be saved and resumed. Gathering devices rarely happens in one sitting, and a setup that cannot be resumed tends to be abandoned.
- **DON'T** _(Costs money)_ Finish setup without the user having restored from it once, with a small amount. An untested multi-key wallet has more ways to fail than a single-key one.
- **DO** Design on the assumption that the rule is readable. A recovery path that works only because nobody knows it exists is not a security property. See Multi-key.
- **DO** Say which path a payment is taking before the user starts, not after. "This is above your limit, so it needs your signing device too."
- **DO** Show progress through a multi-key signature as collected and outstanding, naming the device still needed.
- **DON'T** _(Costs money)_ Let the limit be raised with a single key. Raising the threshold for spending is itself a high-value action and needs the quorum.
- **DO** Make the transfer a named action with the destination prefilled, so it is two taps from the savings home screen.
- **DON'T** _(Costs money)_ Let the everyday wallet pull from savings on its own. A compromised app would drain both, which defeats the whole arrangement. See Multiple wallets.
- **DO** _(Costs money)_ Move the funds to a new arrangement when a key is lost, and say why: the old key still works on every output it is part of until the money moves.
- **DO** _(Costs money)_ Back up the wallet configuration alongside the keys, and include it in the recovery drill. A quorum of signers with no record of the arrangement cannot spend. See Backups.
- **DO** Prompt an occasional recovery check. A wallet opened twice a year is one whose backup has had a long time to go stale.