Transaction batching is the foundation of Arkade’s efficiency. Rather than each user having their own onchain UTXO, Arkade consolidates multiple users’ ownership claims into a single output called a batch output which gets anchored onchain through a commitment transaction.

​
Commitment Transactions

Commitment Transactions are the single onchain footprint that underpin the Arkade protocol. A commitment transaction is created and cosigned by the Arkade Operator alongside the VTXO owners included in the respective batch. A commitment transaction contains two outputs:
  • Batch Output: Encapsulates multiple users’ ownership claims in a tree of presigned virtual transactions
  • Connector Output: A connector output is a dust-amount output that ensures atomicity during batch swaps and VTXO exits by providing virtual anchors for forfeit transactions.
commitment-tx-new.png

​
Batch Output

A batch output encapsulates multiple users’ ownership claims (VTXOs) through a tree of presigned virtual transactions while still allowing - in the worst case - every VTXO holder to exit unilaterally.
The leaves of the virtual transaction tree (A, B, C, D) created by the batch output are the VTXOs, ie. the offchain ownership claims of users:
  • Larger trees: Require more interactive signing sessions during batch creation, as each branch of the tree needs to be signed by its participants
  • Smaller trees: Reduce interactivity but could result in larger transactions or fewer independent paths
commitment-tx-sigs.png Technically, a batch output is a transaction output which is locked by a taproot script with an n-of-n Musig2 internal key, and all VTXO owners as cosigners. A batch output consists of an unspendable key path and exactly two script paths:
  1. A sweep path that allows the operator to spend the entire output after a timeout, the so-called batch expiry, and
  2. An unroll path that enables to split the single batch output into separate VTXO branches of the virtual transaction tree
The virtual transaction tree balances transaction sizes with tree depth and signing interactivity
Each VTXO’s parent in the virtual transaction tree is cosigned by each VTXO owner of that respective branch and the Arkade Signer, while all are having the same batch expiry as timelock. batch-output-sigs.png

​
Connector Output

Connector outputs are dust-amount outputs created in commitment transactions specifically to serve as inputs for forfeit transactions. They ensure atomicity of the swap procedure. For each VTXO swap in a commitment transaction, the operator creates a connector output. The connector output holds a similar tree structure to the batch output, mapping one dust output to each VTXO that requires forfeit protection. It is constructed and owned solely by the Arkade operator. The connector output is meant to be spent in a forfeit transaction to ensure that a swap is conditional on the commitment transaction itself being confirmed onchain. commitment-tx-virtual-connector.png
A connector output is not exclusively for the purpose of a batch swap: it is also used to allow VTXOs to be swapped for an onchain UTXO during an exit.

​
Batch Expiry

To ensure efficient liquidity recovery for the server, each batch output includes an expiry timestamp that applies to all VTXOs derived from it. It enables the server to sweep all funds of a batch output at once instead of having to broadcast all presigned transactions onchain to recover its provided liquidity. However, this timestamp creates a liveness requirement for users as they need to take action during the specified timebound window: VTXO owners can simply participate in a new batch swap to renew their funds or withdraw them onchain. If no action is taken, users lose the unilateral exit right of their VTXO(s). The operator might issue a redeemable Arkade Note for expired funds.
VTXO renewal can be delegated to a third party without relinquishing fund sovereignty, meaning: while keeping unilateral exit rights, in the process
Each batch has an associated expiry time, after which the operator can unilaterally spend it without collaboration from the batch’s cosigners. This lets the operator sweep all funds of the batch output in one go, recovering economically its fronted liquidity.