Protocol / implementation-specific explainer

{{ title }}

{{ dek }}

What this protocol is, and what it is not.

The original mixed explainer made the motions visible, but it let protocol and implementation names bleed together. This fork gives each page its own object model, payment path, maintenance path, liquidity burden, and failure mode.

{{ r.label }}
{{ r.title }}

{{ r.body }}

Five-person example flow.

Step through the timeline one slot at a time or jump directly to a highlighted event. Amounts, fees, and timings are illustrative examples, not protocol constants.

Scenario
What happens in this scenario — one line per step (click to jump)
{{ timelineUnit }}
{{ blockLabel }}
{{ readoutTail }}
{{ m.label }}
L1 confirmed (deposit / round / offboard / exit) offchain only (arkoor / preconf / ownership transfer) operator / server / edge failure idle ▼ current
Each event is badged by provenance: native primitive the protocol itself   implementation-specific one implementation's documented behavior   illustrative service flow a third-party service pattern, shown as a toy   conceptual / historical baseline model or not-yet-built design
L1 · Bitcoin layer
{{ badgeLabel }} {{ eventTimeKindDot }}
  • {{ bi.text }}
Transaction trees · what hangs under each root at this phase
{{ tr.label }}{{ tr.sub }}
  • {{ tr.root.kind }}{{ tr.root.pub }}
    {{ tr.root.id }}{{ tr.root.amt }}
    {{ tr.root.note }}
    {{ tr.root.script }}
    • {{ n1.kind }}{{ n1.pub }}
      {{ n1.id }}{{ n1.amt }}
      {{ n1.note }}
      {{ n1.script }}
      • {{ n2.kind }}{{ n2.pub }}
        {{ n2.id }}{{ n2.amt }}
        {{ n2.note }}
        {{ n2.script }}
        • {{ n3.kind }}{{ n3.pub }}
          {{ n3.id }}{{ n3.amt }}
          {{ n3.note }}
          {{ n3.script }}
          • {{ n4.kind }}{{ n4.pub }}
            {{ n4.id }}{{ n4.amt }}
            {{ n4.note }}
            {{ n4.script }}
UTXO set · VTXOs / branches under each, this phase
{{ u.label }} {{ u.amount }}
{{ u.toneLabel }}
{{ lf.id }} {{ lf.who }} {{ lf.amt }}
L2 · wallet state — what each user holds now
{{ protocolName }}
{{ wal.name }}
Σ {{ wal.total }}
no protocol object here
{{ ob.id }}
{{ ob.tag }}
{{ ob.amount }}
{{ ob.meta }}
{{ offlineText }}

The original sketch: four people, one coin, thirty days.

Every protocol on this page descends from one short drawing: Ruben Somsen's “Simplest Ark explanation”. His cases — holding, sending, the swap, the four outcomes, the shared tree, the lonely exit, the server's locked pile — are replayed here with four people, real amounts, and a calendar. Fees are ignored, “day 30” stands in for any timelock, and the scripts are Ruben's simplified pseudoscript, not literal Bitcoin script. On the other protocol tabs, this section becomes the delta: what each design keeps from this sketch, and what it throws away.

“Alice gives a coin to the Server, provided the Server gives a coin to Bob. There is no trust involved.”the whole protocol in one sentence · everything below is enforcement detail
Alice
0.40 BTC in the pool
pays Dave on day 3 — her arm of the tree gets forfeited
Bob
0.25 BTC in the pool
pays Carol on day 3 — same swap, same new coin
Carol
0.20 BTC in the pool
trusts nobody — walks out alone on day 12
Dave
0.15 BTC in the pool
gets paid off-chain, then exits cooperatively
Server (S)
deep pockets, no custody
fronts every new coin; waits 30 days to be repaid by the timelocks
Day 0Ruben's cases: holding coins · on-chain efficiency

One on-chain coin, four owners, a tree of escape hatches.

Alice, Bob, Carol, and Dave pool 1.00 BTC into a single on-chain output, UTXO_1. Bitcoin sees exactly one coin. Underneath it, everyone pre-signs a tree of transactions that nobody intends to publish: two branch outputs splitting the coin, four leaves — one per person — and, hanging off each leaf, that person's REDEEM_TX. The redeem is the escape hatch: publish your path through the tree, left to right, and it pays you out with nobody's permission. Every box in the diagram except UTXO_1 lives in wallets, not on the chain.

UTXO_1 · 1.00 BTC · confirmed day 0every connector = one presigned transaction
solid = confirmed on Bitcoin  ·  dashed = presigned, held in a wallet, published only if something goes wrong  ·  depth = how many transactions must confirm before this box exists on-chain

Two catches, both from the gist. Building this tree needs everyone — A+B+C+D+S — to pre-sign together, which is the interactivity a covenant opcode like OP_CTV would remove. But after day 0, nobody ever needs the other three again: to spend, you talk only to S. That single change is what separates Ark from the older payment-pool designs, where every spend meant herding the whole pool.

Day 3Ruben's cases: preparing to send · the swap · confirmation times

Two payments, nobody paid on-chain — and one brand-new coin.

Alice owes Dave 0.10; Bob owes Carol 0.05. Neither payment touches UTXO_1. Instead, S batches both into a new coin it funds from its own pocket: UTXO_2, 0.65 BTC, with fresh leaves for Alice's change (0.30), Bob's change (0.20), Carol (0.05), and Dave (0.10) — each with its own dashed REDEEM_TX, exactly like day 0. In exchange, Alice and Bob each sign a FORFEIT_TX: “S may take my old redeem output — but only in a world where UTXO_2 actually exists.” The moment UTXO_2 confirms, the swap is atomic: the old claims belong to S, the new claims to their owners. Until it confirms, nothing has moved — treat the payment as instant only if you trust S not to rework pending transactions.

Alice's arm of UTXO_1 — now five deep
Bob's arm now looks exactly the same, ending in FORFEIT_B. Carol's and Dave's day-0 arms are untouched.
UTXO_2 · 0.65 BTC · S's money, everyone's new claims · confirmed day 3
Each leaf again carries its own dashed REDEEM_TX, omitted here. Ruben's sketch sends Alice's whole claim; giving her change as a second output in the new coin is the same mechanics.

Carol and Dave now hold claims under two different roots at once — their untouched day-0 leaves in UTXO_1, plus their new leaves in UTXO_2, each root with its own clock. And note who had to be online: everyone with a leaf in UTXO_2 pre-signs its tree before it goes on-chain. That is the recipient interactivity the gist flags, and the thing later designs (and CTV) work to remove.

Day 3, four waysRuben's case: possible outcomes

The same swap, four endings.

Everything above is machinery for exactly one guarantee: whatever anyone does after the swap is agreed, they cannot come out ahead by misbehaving. Run Alice-pays-Dave through all four worlds:

expected Everyone behaves.

UTXO_2 confirms; Carol and Dave are paid. Every redeem transaction stays in its drawer. On day 30 the “S after day 30” clause matures and S sweeps UTXO_1 with one transaction. Total chain footprint: two coins, no matter how many payments rode inside.

handled Alice tries to keep her old coin.

After UTXO_2 confirms, she publishes REDEEM_A anyway. S answers with FORFEIT_A — valid precisely because UTXO_2 exists — and takes the 0.40 long before Alice's 30-day wait matures. She bought fee bills and nothing else.

handled S never delivers.

UTXO_2 never appears, so FORFEIT_A can never be valid — its anchor input doesn't exist. Alice publishes REDEEM_A, waits out her 30 days, and takes her 0.40 back. Dave wasn't paid, but nobody was robbed. That is what “atomic” buys.

the real duty Alice sleeps through day 30.

She neither swaps nor publishes her redeem before UTXO_1's clock runs out. The “S after day 30” clause matures and S can claim her arm. The one non-negotiable obligation in this design: come back online before expiry.

Day 12Ruben's cases: worst-case redemption · cooperative exit

Carol walks out alone — and the tree unfolds behind her.

Carol never spent her day-0 leaf, and she has decided not to ask S for anything. So she publishes her path down the tree, transaction by transaction, paying a fee for each hop:

tx 1 · day 12Carol pays fee
UTXO_1 → BRANCH_AB 0.65 + BRANCH_CD 0.35 — both now on-chain
tx 2 · day 12Carol pays fee
BRANCH_CD → LEAF_C 0.20 + LEAF_D 0.15 — Dave's leaf surfaces too
tx 3 · day 12Carol pays fee
REDEEM_C: LEAF_C → “C+S or C after a 30-day wait”
day 42free
30 quiet days pass. Carol never signed a forfeit, so S has no counter. The 0.20 is plain Carol money.
S's clean sweep is gone
log(n) cost
UTXO_1 was going to be one spend on day 30. Now S must claim the exposed BRANCH_AB output instead — the gist's point that one user's exit leaves S spending log(n) outputs instead of 1.
Dave's leaf is on-chain now
deadline unmoved
LEAF_D sits exposed with its day-30 clause still ticking. Dave takes the polite version of Carol's move: a cooperative exit. He forfeits the leaf to S in exchange for a plain, timelock-free 0.15 on-chain output — one clean transaction.
Three fees for 0.20 BTC
economic floor
The deeper the tree and the smaller the coin, the worse the unilateral path gets. This is what puts a floor under the smallest denomination worth holding in an Ark.
Nobody could stop her
the point
No permission, no cooperation, no trust. The cheap cooperative paths are safe to use precisely because this expensive lonely path always exists.
Day 30 and afterRuben's cases: payment-pool comparison · liquidity · the anchor trick

The server's books: front now, sweep later.

S never held anyone's money — every user could always exit unilaterally. What S did do is front fresh coins and wait for timelocks to pay it back. The whole month, from S's side of the desk:

Day 0 · UTXO_1 created
0.00 fronted
The four users fund the pool themselves. S only co-signs.
Day 3 · UTXO_2 created
0.65 fronted
S pays for the new coin out of pocket. Its repayment — Alice's and Bob's forfeited 0.65 under UTXO_1 — is locked until day 30.
Day 12 · Carol's solo exit
still 0.65
Her money, her fees. S's balance sheet doesn't move.
Day 14 · Dave's cooperative exit
0.80 fronted
S pays Dave a clean 0.15 on-chain output now, and gains the claim on LEAF_D at day 30.
Day 30 · timelocks mature
0.00 — made whole
S sweeps BRANCH_AB (0.65, forfeited by Alice and Bob) and LEAF_D (0.15, forfeited by Dave). Everything it fronted comes back.
Day 33 · UTXO_2's own clock
cycle repeats
Before it runs out, the four claims inside UTXO_2 must be refreshed into a UTXO_3, exited, or lost to the sweep clause. An Ark is a rolling sequence of these coins, not a single pool.
Why S needs deep pockets

Every payment makes S front money that only comes back after the timelock. Ruben's back-of-envelope for a busy Ark:

30-day timelock × 1 BTC moving every 10 min = 6 × 24 × 30 ≈ 4,320 BTC locked at all times

The faster money moves, the more of S's capital sits frozen. That lockup — not custody risk — is the price of everyone else's cheap instant payments, and it is the tradeoff every protocol on this page is negotiating.

The anchor trick — “if UTXO_2 exists” without a soft fork

Bitcoin script cannot say “spendable only if some other UTXO exists.” So the transaction that creates UTXO_2 also carries a tiny ANCHOR output only S can spend, and Alice's FORFEIT_TX takes that anchor as a second input.

FORFEIT_A inputs: [ REDEEM_A output ] + [ UTXO_2's anchor ]

Now the forfeit literally cannot confirm unless UTXO_2 confirmed first. An impossible script condition becomes an ordinary transaction dependency.

Same picture, this page's words
LEAF + its REDEEM_TX
a VTXO (section 02's A1, B1…)
the batch that creates UTXO_2
a round
old claim swapped for a fresh leaf
a refresh
“S after day 30”
expiry
publishing your branch, hop by hop
unilateral exit

{{ vsArkTitle }}

{{ vsArkLead }}

{{ vr.from }}
{{ vr.to }}
Operator liquidity  {{ vsArkLiqChip }}

{{ vsArkLiq }}

Third parties you'll meet in practice

{{ vsArkTp }}

left: Ruben's sketch (the Original Ark tab) · right: this protocol