Ark is a novel off-chain transaction batching mechanism originally proposed by Burak, a young Turkish developer. There are currently two implementations being built, one by Ark Labs, and the other by Second, neither of which Burak is involved with.
The original proposal for Ark was much more complicated, and involved some design goals more focused around privacy than the implementations currently being built. It was also originally envisioned to require CHECKTEMPLATEVERIFY (CTV) in order to be built.
The protocol depends on a central coordinating server in order to function properly, but despite that is able to provide the same functionality and security guarantees that the Lightning Network does. As long as a user stays online during the required time period, at all times (unless they choose to trust the operator for short periods of time) every user is capable at any time of unilaterally exiting the Ark system at any time and taking back full unilateral control of their funds onchain.
Unlike Lightning, Ark does not require users to have pre-allocated liquidity assigned to them in order to receive funds. An Ark user can simply onboard to a wallet and receive funds immediately with no liquidity pre-allocation at all.
Let’s walk through the different constituent pieces of Ark.
The Ark Tree
Coins held on Ark are called Virtual UTXOs (vUTXOs). These are simply pre-signed transactions that guarantee the creation of a real UTXO under the unilateral control of a user once submitted onchain, but are otherwise held offchain.
Every user’s vUTXOs are nested inside a tree of pre-signed transactions, or a “batch.” Ark works by having the coordinator server, or Ark Service Provider (ASP), facilitate the coordination between users necessary to create a batch. Whenever users are receiving funds, onboarding to Ark, or offboarding, it is necessary to construct a transaction and the associated transaction tree to create a new batch.
The tree is constructed to take the single root UTXO confirmed onchain, locked with an n-of-n multisig including all users holding vUTXOs in the tree as well as the ASP, and slowly split into more and more UTXOs until eventually reaching the leaves, which are each users vUTXO. Each vUTXO is guaranteed using a script that has to be signed by a 2-of-2 multisig, one key held by the user, and the other by the ASP, or just the user after a timelock.
Each time the tree splits, vUTXOs are created onchain, but so are more internal UTXOs that have yet to actually split into vUTXOs. Each of these internal UTXOs is locked with an n-of-n multisig composed of the ASP, and all users who have a vUTXO further down the tree. During the batch creation process, users start at their respective vUTXOs, and go through a signing process all the way back down the root of the tree. This guarantees that the root will never be signed before each user’s claim to a vUTXO is, ensuring they always have unilateral access in a worst case scenario to their funds.
Each batch also has an expiry time (which will make sense in the next section). This expiry spend path, which exists as an alternate spending condition for the root UTXO onchain as well as every internal UTXO, allows the ASP to unilaterally spend all funds by itself.
Transactions, Preconfirmation, and Connector Inputs
When it comes to transacting on Ark, there are two possible mechanisms that are possible, both with their own costs and implications in terms of security model. There are out-of-round transfers, or preconfirmed transactions, and there are in-round transfers, or actually confirmed transactions.
To conduct an out-of-round transfer is a very simple process. If one user (Alice) wants to pay another (Bob), they simply contact the ASP and have them co-sign a transaction spending the vUTXO to Bob. Bob is then given that pre-signed transaction, as well as all the other ones preceding it back to the batch root onchain. Bob is now capable of unilaterally exiting the Ark with this transaction, but, he must trust the ASP not to collude with Alice to doublespend it. These out-of-round transactions can even be chained multiple times before finally confirming them.
To finalize an Ark transaction, users have to engage in a “batch swap.” Users cannot actually trustlessly confirm a transfer within a single batch, they have to atomically swap a vUTXO in an existing batch with a fresh vUTXO created in a new batch. This is done using the ASP as a facilitator of the swap, and with the aid of what is called a “connector input.”
When a user goes to finalize an Ark transaction with a batch swap, they relinquish control of the vUTXO to the ASP. This could be problematic, what is to stop the ASP from simply keeping it and not giving them a confirmed vUTXO in a new batch? The connector input.
When a new batch is created, a second output is created in the transaction that is confirmed on chain instantiating a new tree composed of connector UTXOs. When Bob goes to sign over a forfeit transaction to the ASP to conduct the batch swap, the transaction includes as an input one of the connector UTXOs from the new batch.
This creates an atomic guarantee. Bob’s confirmed vUTXO is included in a batch in the same transaction the connector input is created in that is necessary for his forfeit transaction to be valid. If that batch is never created onchain, i.e. Bob never actually receives the new confirmed vUTXO, then the forfeit transaction he signed for the ASP will never be valid and confirmable onchain.
Liquidity Dynamics and Blockspace
All of the liquidity necessary to create new batches in order to facilitate transfers between users is provided by the ASP. They are required to have enough liquidity to create new batches for users until old ones have expired and the ASP can unilaterally sweep them to reclaim old liquidity previously locked up to create vUTXOs for users.
This is the core of the liquidity dynamic at the center of the Ark protocol. While in one sense this is a massive efficiency win, not requiring liquidity providers to assess users and essentially guess which ones will actually receive large volumes of payments before they can receive any funds, in another it is an efficiency loss as the ASP must have enough liquidity to continue creating new batches for users for however long they configure the expiry time to be and they can start reclaiming allocated liquidity.
This can be mitigated to a decent degree by how often an ASP offers to create new batches to finalize pending transactions. In the event of an ASP attempting to create new batches in real time as transactions are coming in, the liquidity requirements would be exorbitantly high. However, an ASP can lower the frequency at which they create new batches and drastically lower their liquidity requirements.
This dynamic also has implications for blockspace use. Unlike Lightning, which can provide strong confirmation guarantees entirely offchain, in order for an Ark transaction to have an equivalent trustless degree of finality a new batch has to be created onchain. This means that unlike Lightning, where transaction volume does not reflect itself onchain, the velocity of Ark transactions inherently requires a proportional amount of blockspace use, albeit in a very compressed and efficient manner. This creates a theoretical upper limit of how many Ark batches can be created during any given time interval (although Ark trees can be smaller or larger depending on this dynamic).
Wrapping Up
Ark presents in many ways an almost opposite set of tradeoffs to the Lightning Network. It is a massive blockspace efficiency improvement for offchain transactions, and does away with the problem of liquidity allocation on the Lightning Network, but it does have a much closer tied throughput limit that is correlated with the blockchains throughput limit.
This dynamic of almost opposite tradeoffs makes it a very complementary system to the Lightning Network. It can also interoperate with it, i.e. vUTXOs can be swapped atomically in transactions entering or exiting the Lightning Network.
Ultimately how it fits into the broader Bitcoin ecosystem is yet to be seen, but it is an undoubtedly valuable protocol stack that will find some functional niche, even if it is different than originally intended.
