• Your balance is a VTXO — a Virtual UTXO.
• It behaves like a real UTXO, but lives off-chain.
• Backed by pre-signed transactions you can broadcast at any time to claim your bitcoin on-chain.
• One on-chain output can hold value for thousands of users.

• Key path = MuSig2(user + server). A cooperative spend is a single Schnorr signature — cheap and indistinguishable from any normal Taproot spend.
• Every instant payment / forfeit takes this path. The server can never move funds without your half of the signature.
• Script paths only get revealed on-chain if cooperation breaks down.

Why the server fronts capital

• To mint a fresh VTXO (a refresh, a Lightning send, an off-board) the server must put up on-chain bitcoin now.
• It receives the user's forfeited old VTXO — but can only reclaim that bitcoin after it expires (~28 days).
• So capital is locked roughly for the VTXO lifetime.

The key inversion

• An LSP locks capital against each user's balance.
• An Ark server locks capital against payment volume / churn — not 1:1 against total deposits.
• Dynamic fees: cheaper to refresh a near-expiry VTXO, pricier for a fresh long-lived one. Users pay for the time-value of locked capital.

Unilateral Exit

If the server misbehaves or disappears, you broadcast your branch & leaf transactions in sequence to recover funds directly on Bitcoin. No permission needed.

VTXO Expiry

VTXOs carry a timelock (~28 days). You must refresh them in a later round before they expire — otherwise the server can reclaim that liquidity.

How it's held together

• The VTXO tree is built from pre-signed transactions, co-signed n-of-n (MuSig2) by all round participants + the server.
• Interactive: you must be online to co-sign when receiving or when your VTXO moves in a round.
• You can't (yet) send to an offline user or onboard one without their participation.

The statechain-like trust

• Transfers rely on the sender forfeiting their old VTXO and not colluding with the server before the next round settles it.
• Like a statechain: a server co-signs and helps enforce single ownership — security leans on cooperative signing + an honest operator, backstopped by unilateral exit.

What CTV changes

• OP_CHECKTEMPLATEVERIFY makes the tree deterministic & script-enforced at the root.
• Non-interactive: the server can build the tree alone — send to offline users, onboard without their input.
• Bigger trees → more users per round and better fee efficiency.

The evolutions

• hArk / Erk (Steven Roose): use CTV + CSFS to drop user interactivity entirely and allow offline refresh.
• Needs a Bitcoin soft fork (CTV / CSFS aren't activated).
• bark is built forward-compatible: upgrade to native covenants if/when they activate.

// high-level, Ivy-like syntax
contract SingleSig(pubkey user) {
  function spend(signature s) {
    require(checkSig(s, user));
  }
}

Every function auto-compiles to two variants:

• Cooperative → key-path with the operator (instant).
• Unilateral exit → script-path + timelock.

… the exact Taproot key-path / script-path split from earlier.

Primitives

• checkSig, checkMultisig, checkSigFromStack
• sha256 for HTLC preimages
• CSV / CLTV timelocks & arithmetic
• Transaction introspection — read inputs, outputs, values, scriptPubKeys (covenants)
• Asset-aware flows across VTXOs

Enough to build escrows, HTLC atomic swaps, and Spilman / Poon-Dryja payment channels.

Virtual Mempool

• Off-chain engine where VTXO spends preconfirm instantly.
• No global state machine or accounts — just local input → output transitions per VTXO.
• Independent branches run in parallel, fully deterministic.

Batch Settlement

• Operations finalize on Bitcoin via the Intent System.
• One on-chain tx anchors thousands of off-chain state changes.
• Unilateral exit still holds if the operator vanishes.