Spending conditions
Rules written into money about when and how it can be spent: what BSV supports, how to explain a lock nobody can undo, and why the setup is part of the backup.
Spending conditions are rules written into money about when and how it can be spent. Offer people two or three named arrangements, rehearse each with a small amount, and back up the arrangement with the keys.
An output does not have to say only "whoever holds this key can spend this". The locking script can say almost anything: two of three keys, not before a date, only if a secret is revealed, only to a particular recipient. These conditions turn a wallet into more than a purse. They are also the fastest way to lock people out of their own money. The rest of this page explains which conditions BSV gives you and what the interface has to carry.
Four conditions worth knowing
Several keys
n of m keys must sign. Uses include savings that one stolen phone cannot reach, business accounts that need two approvals, and inheritance. See Multi-key.
Not before a time
The output cannot be spent until a point in the future, set as a date or a block height.
A secret
Whoever reveals a value matching a hash can spend the output. This is the building block for exchanges between parties who do not trust each other: revealing the secret to claim one side makes it available to claim the other.
Combinations
A path that works today for the owner, and a different path that opens later for somebody else. The inheritance and recovery designs in this guide take this shape.
How time works on BSV
This is where scripts copied from elsewhere go wrong.
nLockTime and nSequence are the mechanism. nLockTime on a transaction says it is not valid until a block height or timestamp. nSequence on an input governs whether that lock can still be updated.
CHECKLOCKTIMEVERIFY and CHECKSEQUENCEVERIFY are not. On BSV these opcodes do not act as checks. A script that relies on them does not do what it says. The failure is silent, not an error: the script runs, and the condition is not enforced.
Commonly misunderstood: CLTV and CSV
On BTC these two opcodes are how a timelock is enforced, so published vault, escrow and inheritance scripts commonly use them. On BSV they are no-ops: the script still runs, still returns true, and locks nothing.
Nothing warns you. A vault copied from a BTC tutorial looks locked, tests green against its own happy path, and can be spent at once by whoever holds the key, which is exactly what the lock was meant to prevent.
Do
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.
The practical difference
A nLockTime transaction is a transaction that cannot be broadcast yet, not an output nobody can spend. That difference is the whole design problem:
- somebody has to keep the transaction until its time comes
- the keys that signed it have to still exist then
- if its inputs are spent in the meantime, it becomes worthless
So a pre-signed recovery transaction stays valid only until the money it spends moves. Refreshing the timer, changing the period or removing somebody means moving the funds in a payment from the wallet to itself, which needs the keys and costs a fee, then pre-signing again. Money received after signing is not covered until the next refresh.
Do
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.
The Chronicle upgrade
The Chronicle upgrade (block 943,816, 7 April 2026) restored the remaining original opcodes, so scripts that were impossible for years are available again. They run only in transactions marked with the Chronicle version.
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.
No new P2SH
New pay-to-script-hash outputs are not allowed on BSV, so a script cannot be hidden behind its hash until spend time.
The condition is therefore visible in the output from the moment it is created. Anyone can read how many keys are required, or when a lock expires.
Do
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.
Designing with them
Say what it does, not what it is
Nobody wants a wallet that mentions nLockTime. Say the consequence:
Locked until 1 March 2027.
Nobody can move this, including you.Needs 2 of your 3 keys.
This phone, your signing device, or the key you keep at home.Do
Describe a condition by its consequence: "Locked until 1 March 2027. Nobody can move this, including you."
Show the whole schedule
Where conditions change over time, show the timeline, including the parts that have not happened yet. A user should see today's rule and next year's on one screen.
Do
Show the whole schedule on one screen, including the rules that have not taken effect yet.
Make the failure visible before it happens
Every condition has a way of going wrong: a key lost before the quorum is reached, a date passing with nobody watching, a pre-signed transaction whose inputs were spent.
Do
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
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.
Letting people set their own conditions
- OK: two or three named arrangements, each rehearsed with a small amount before real money goes in.
- Grey area: named arrangements with adjustable parameters, such as the date or the number of keys, and a plain summary of the result.
- Not OK: a free-form condition builder offered to ordinary users.
The configuration is part of the backup
A custom output needs its script, its keys and its parameters to be spendable. Keys alone are not enough: a quorum of signers with no record of the arrangement cannot construct a valid spend.
Recommendation
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.
Open questions
- Who keeps a pre-signed future transaction for years, and what happens to it if that person or company is gone when its date arrives?
- Does a warning such as "one more lost key and this is unrecoverable" lead people to act, or only make them anxious?
- Is a small-value rehearsal enough to prove an unlock path that will not be used for years, when the things that fail are lost keys and forgotten devices?
- How should a wallet tell somebody that the rules guarding their savings are readable by anyone?
- Which two or three arrangements cover most people's needs? This guide has suggestions, not evidence.
Related
- Savings wallet: several keys, designed as a whole product
- Inheritance wallet: a path that opens later, designed as a whole product
- Multi-key: how several keys share control
- Backups: why the configuration needs backing up
- Transactions: versions, opcodes and what changed
- Storing data on chain: the other permanent thing a product writes
Written from: ts-stack script docs, Chronicle upgrade notes, BRC-140.
Checklist
The rules on this page, in a form you can work through.
12 rules