Skip to main content
Preconfirmed virtual outputs are instant, but they rely on the operator. A virtual output reaches Bitcoin finality when it settles in a batch: a commitment transaction that confirms on Bitcoin holds it. You choose when to settle each output.

​
The Commitment Transaction

The operator gathers many users into one onchain transaction, the commitment transaction, and every participant signs it. It swaps outputs atomically in three flows:
  • Boarding (onchain to virtual): onchain outputs enter Arkade as virtual outputs.
  • Renewal (virtual to virtual): existing virtual outputs are swapped for fresh, settled ones. This is a batch swap.
  • Offboarding (virtual to onchain): virtual outputs leave Arkade as onchain outputs, with the operator cosigning.

​
Batch Swaps

A batch swap moves preconfirmed virtual outputs to Bitcoin finality. Settle for three reasons:
  1. Trust. Preconfirmed outputs rely on the operator. Settled outputs do not.
  2. Exit cost. Long transaction chains make unilateral exit more expensive. Settlement resets the chain.
  3. Expiry. Virtual outputs must be renewed before their batch expires. Settlement gives them a new expiry.
The swap is atomic, and users keep custody throughout.

​
How Batch Swaps Work

1

Register

Each user submits a batch registration request. It lists the virtual outputs to swap, the scripts and amounts of the new virtual outputs, and the user’s cosigner keys for the new batch’s transaction tree.
2

Build the commitment transaction

The operator builds the commitment transaction. It has a batch output for all participants’ new virtual outputs, and a connector output that makes the swap atomic.
3

Sign the virtual transaction tree

The operator builds the tree of virtual transactions that splits the batch output into each participant’s virtual output. The participants and the operator check it and sign it together with MuSig2.
4

Sign forfeit transactions

Each user signs a forfeit transaction for each old virtual output. It spends the old virtual output and a connector output, so the operator can claim the old output only if the new commitment transaction confirms.
5

Broadcast

The operator signs and broadcasts the commitment transaction. On confirmation, the new virtual outputs are settled, and the forfeit transactions protect the operator from claims on the old ones.

​
Batch Anatomy

A commitment transaction can have these outputs:
  • Batch output. Holds all participants’ new virtual outputs in a virtual transaction tree. Thousands of virtual outputs share this one onchain output.
  • Connector output. A dust-amount output of the operator, present when users give up virtual outputs. It splits into a tree with one leaf for each virtual output that needs a forfeit transaction.
  • Onchain outputs for offboarding, and the operator’s change.
Offboarding uses connector outputs too: the user forfeits virtual outputs and receives an onchain output of the same commitment transaction. Atomicity comes from forfeit transactions. Each user signs a forfeit transaction that gives the old virtual output to the operator. The forfeit transaction spends both the old virtual output and a connector output, so the operator cannot claim the old output unless the new batch exists on Bitcoin. Users can give up old virtual outputs safely, because they get the new ones only together. The operator is protected if a user tries to spend a forfeited output onchain.

​
Batch Registration Requests

Users join a batch by submitting a batch registration request to the operator. Boarding, renewal, and offboarding all use this request. It lists the inputs the user gives up and the exact outputs the user expects to receive. The request proves ownership of each input with a BIP322 signature. Inputs can be virtual outputs, onchain outputs, or expired virtual outputs. Users keep their keys, and the operator coordinates the batch.

Previous: Transactions & Execution

Transaction structure, chaining, and the virtual mempool.

Next: Expiry & Renewal

Expiration, renewal, and delegation.