The commitment has a price attached
An operator accepting a batch posts bond sized to that batch. Accepting more work means risking more of their own capital, so the window they quote is one they have a reason to hit.
Advancing
LoadingAdvancing
LoadingOrecart
Ore rides a cart back up the level it came down. Redemption works the same way: seams have to be unwound before principal returns one for one, and that takes real time. Every venue knows this. The difference is whether the number is on the page.
A figure published without its limits gets read as a guarantee. Each readout below carries both halves.
What it is
How much principal sits ahead of a new request. Counting positions instead would be meaningless: the tickets in front of you differ in size by orders of magnitude, so being tenth in line tells you nothing on its own.
What it is not
It is not a promise that everything ahead of you will clear. If a seam ahead cannot be unwound at size, that ticket stays in front and the depth does not move.
The vault program is not deployed, so no principal is in seams and nothing is queued. The policy and wait ladder below describe what a redemption will cost once it is.
| Redemption size | Estimated wait | Worst case |
|---|---|---|
| 0.1 BTC | 2.5 days | 6.3 days |
| 1 BTC | 2.6 days | 6.5 days |
| 5 BTC | 2.9 days | 7.3 days |
| 25 BTC | 4.6 days | 11.5 days |
Redemption returns principal one for one in the BTC representation that was deposited, less the redemption fee. It is a claim on the vault's open positions, not a promise: an extended venue outage, a thin book at unwind time or an issuer halting redemption of the underlying representation will delay it, and a venue failure can impair it.
Five steps, all of them on chain. The order is decided by the record rather than by whoever is watching the queue.
01
A redemption request is written on chain with its size and its timestamp. Position is decided by that record, not by who is watching.
02
An operator accepts a batch and posts bond against it. The bond is sized to the batch, so accepting more means risking more.
03
Liquidity positions are closed against the published unwind order, worst-priced seam last, so an exit does not quietly dump the cost on whoever is still inside.
04
Principal is returned one for one in the representation it came in as. Any return already realised settles with it.
05
If the batch misses its window the bond is slashed and the tickets stay at the front of the line. The delay is written to the log that this site reads.
Every entry below is a choice somebody made. The right hand column is the choice made here instead.
| What usually happens | What happens here |
|---|---|
| Deposits confirm in a block, withdrawals take an unstated number of days | The line depth and the observed wait are published on the same screen as the deposit control |
| A queue that can be paused at the operator's discretion | No discretionary pause. A keeper that stops working loses bond and the line keeps its order |
| Priority granted quietly to whoever asked first offline | Priority is a fee with a published split, visible to everyone in the line |
| Delays disappear from the interface once they are resolved | Every missed window stays in the log with the seam that caused it |
An operator accepting a batch posts bond sized to that batch. Accepting more work means risking more of their own capital, so the window they quote is one they have a reason to hit.
A missed window slashes the bond and leaves the affected tickets at the front of the line. The holder does not lose position for somebody else's failure.
There is no discretionary halt. If every operator walks away, the queue keeps its order and the positions stay redeemable through the unwind path written on chain.
None of this makes an exit instant, and nothing here should be read as one. It makes the wait a figure somebody has posted collateral against, which is a different thing from a number in a paragraph.
See how a chamber changes the unwind