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 }}

“Liquidity” means three different things — where {{ protocolName }} carries each bucket
{{ bk.label }}
{{ bk.title }}

{{ bk.body }}

bucket 1 is never operator liquidity, however large it gets · the “operator liquidity” callout below tracks bucket 2 · “third parties in practice” tracks bucket 3

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
{{ 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, recover later.

S is not a custodian on the normal path — every user keeps a unilateral exit before expiry. But S does run a balance sheet: it funds new coins now, receives forfeits, and sweeps expired or forfeited branches later. The problem is not custody; it is timing — new money goes out today, old money comes back at maturity, and that gap is the liquidity requirement. 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 principal exposure doesn't move. But her unfurl fragments the old tree: at day 30, S will sweep exposed branches separately instead of one clean root. Same capital, higher on-chain cost.
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 — a worst-case, sketch-only estimate

In this sketch, every cooperative payment is a server-funded swap, so: required treasury ≈ liquidity-consuming volume per period × lockup period. Ruben's back-of-envelope:

1 BTC of server-funded swaps every 10 min × 30-day recovery = 6 × 24 × 30 ≈ 4,320 BTC locked

Three assumptions make it brutal: every 10 minutes mints 1 BTC of new server-funded claims, nothing recovers before day 30, and no capital is reused. It is a stress-case intuition for this sketch, not a protocol constant — real designs attack all three assumptions, and price what remains:

liquidity cost ≈ amount × (days until recovery / 365) × BTC opportunity rate + on-chain fees + margin
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.

Important — this is the original sketch, not every modern Ark design

Here, every cooperative payment is shown as a server-funded swap into a new shared coin — that is what makes this sketch liquidity-heavy. Modern Bark-style systems split the world differently: internal Ark payments happen out-of-round and need no fresh server liquidity; refreshes, offboards, and Lightning are the operations that consume it. Arkade's version of the same split: preconfirmations are free, batch settlements front capital, and expiry exists precisely so that capital recycles. Each protocol tab's “Operator liquidity” callout states its own version.

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