Protecting a live path
A live path is one specific small Bitcoin output, and an ordinary payment that spends it ends the path for good. Here is how to make sure that never happens.
Your place in a world is not stored in an account. It sits in one specific small Bitcoin output, and whoever spends that output decides what happens next. Four habits keep it safe, and they take about a minute to set up.
Your path lives in one output#
When you take a forward, the step you sign creates a new output worth 1,000 satoshis. That output is your position in the world. Spending it with a valid ChainBloom action moves the path one step on. Spending it any other way ends the path.
There is nothing else holding your place. No password, no record on a server, no way to restore it. If that output is spent by an ordinary payment, the path stops there and nothing can bring it back: not the world's creator, not an indexer, not us.
How it happens by accident#
No released wallet knows what a ChainBloom output is. To your wallet, a live path looks like an ordinary 1,000-satoshi with no label. Wallets are built to be helpful with coins like that, which is exactly the problem.
The three usual ways people lose one:
- Sweeping. "Send max" empties an address, and a 1,000-satoshi output goes with everything else.
- Consolidating. Combining small coins into one to save on future fees is good practice, and it will eat your path without asking.
- Automatic coin selection. A wallet picking inputs for an unrelated payment may reach for the smallest coin it has. Yours is very small.
In every case the transaction is a valid Bitcoin payment. Nothing warns you, because nothing knows.
Four habits that keep it safe#
Keep path outputs where you do not spend from#
Use a separate account, wallet, or at minimum a dedicated address for paths you hold. If the only coins in that place are , no ordinary payment can reach them by accident. This single habit removes most of the risk.
Write down the outpoint#
The moment a step confirms, record the , the txid:vout pair of the new output. Not just the transaction id; the output index matters. Keep it with the world id and the path id, which reads <worldId>:<laneNumber> and is numbered from 0.
You need this to return to the path later, to verify a signing screen is spending the right thing, and to look the path up in any tool that reads confirmed state.
Check before you sweep or consolidate#
Before any transaction that empties or tidies a wallet, ask one question: does this spend an output I am holding for a path? Compare the input list against your written outpoints. Use coin control and deselect anything you cannot account for.
Label it where you will actually look#
Most wallets let you freeze or label a coin. Label it with the world title and the path number, not "do not spend". Six months later you will want to know which path it was.
What the protocol does if it happens#
The protocol is honest about this rather than clever. When a confirmed transaction spends a live carrier and is not a valid ChainBloom event, every path it spent becomes with the terminal reason INVALID_CONFIRMED_SPEND, and the offending spend is recorded in the state's list of invalid carrier spends, with its transaction id, block height, and the issue codes that made it invalid.
Nothing is invented to replace the path. No successor is conjured, no substitute output is nominated, and the path does not quietly continue somewhere else. Every independent reader replaying the chain reaches the same conclusion: this path ended here, this way.
The events the path already contributed remain part of the world's history exactly as they were. What ends is the ability to add more.
The other ways a path ends#
Not every ending is a mistake. Knowing the full list makes the accidental one easier to recognise:
| Status | How it happens | Reason recorded |
|---|---|---|
CLOSED | You sign a CLOSE action deliberately | CLOSE_<reason> |
EXPIRED | The world reaches the end of its lifetime | WORLD_DURATION_ELAPSED |
ABANDONED | A confirmed spend was not a valid ChainBloom action | INVALID_CONFIRMED_SPEND |
A world's end height is fixed when it is created: the creation height plus its duration in blocks, between 144 and 52,560 blocks, roughly 1 day to 365 days. At that height the world becomes and every path still live expires with it. Separately, once a path has taken its maximum number of steps, up to 512, further steps are refused with MAX_STEPS_REACHED, though you may still complete it deliberately.
So write down the end height along with your outpoint. A path you meant to complete, left until after the world expired, ends as expired instead. The 1,000 satoshis stay in an output you can still spend, but the ending is no longer yours to write.
Nobody ever needs your recovery phrase#
If something has already gone wrong, troubleshooting explains how to tell an abandoned path from one that is merely waiting for a block, and the security model sets out exactly what the protocol does and does not protect.