By Saravanan Mani
Source: https://medium.com/@saravananmani_/ark-101-0d64cfe9378f
What is "Ark"?
“Ark” is a Bitcoin Layer 2 protocol that enables instant and cheap Bitcoin payments.
Most of its operations occur off-chain, meaning that payments based on the Ark protocol occur outside the Bitcoin blockchain. Ark is a protocol that supports self-custody, allowing users to withdraw funds on-chain when needed, although this differs from self-custody solutions based on exclusive outputs (which I will discuss later).
Unlike the Lightning Network, the Ark Protocol does not rely on concepts such as invoices, payment channels, HTLCs (Hash Time Lock Contracts), and routing. Instead, it uses a provider-client model, where all users interact with their own provider rather than through a peer-to-peer network (with other users).
Ark follows an optimistic design, meaning users assume that the service provider will coordinate transactions correctly. If the service provider becomes indifferent, censors transactions, or otherwise behaves inappropriately, the user can retaliate with a unilateral exit. Under normal circumstances, exits are handled off-chain, coordinated between the service provider and the user, meaning unilateral exits are only used in exceptional circumstances.
Ark payments are similar to on-chain payment models: they are pre-signed Bitcoin transactions processed off-chain, the recipient does not need to be online to receive the payment, and users do not need to lock up liquidity in advance.
Ark is Bitcoin-only. It excludes Altcoin, tokens, sidechains, and new blockchains. It works with the current Bitcoin consensus rules. However, "covenants" (a type of Bitcoin consensus rule upgrade) could significantly strengthen the protocol.
Like all Layer 2 protocols, Ark has its own trade-offs, which make it more suitable for some scenarios and less suitable for others.
Admission and payment
There are two ways to join an Ark:
Use a regular Bitcoin transaction to move your Bitcoins within the blockchain to an Ark
Receiving Ark-to-Ark payments also gives you instant access to an Ark. This happens off-chain, with no blockchain confirmation fees or pre-requisites.
(Translator's note: This form of payment is generally called "Arkoor (Ark out-of-round)" payment.)
All Ark-to-Ark payments are instant, low-fee, and occur entirely off-chain.
How to access an Ark through on-chain deposit?
In this example, Alice uses her own on-chain UTXO (represented as "Alice input utxo" in the diagram) to create a funding transaction. This transaction can be spent by Alice and the target Ark's service provider (AS) at any time, or by the AS alone after 30 days. Before signing and broadcasting the funding transaction, Alice and the AS jointly sign a non-broadcast "exit virtual transaction." This exit transaction spends the funding transaction's output ("output UTXO"); its output can be spent by both parties at any time, or by Alice alone one day after the exit transaction is confirmed in a block. This mechanism gives Alice the option to unilaterally exit the Ark within 30 days of joining.
These unbroadcasted transactions all contain an additional anchor output, which allows for additional transaction fees to be added via the CPFP (Child Pays Parent) method. For simplicity, this anchor output is omitted in the diagram above.
But why can AS independently withdraw funds from a funding transaction after a 30-day absolute delay, while Alibe must wait for a 1-day relative delay before unilaterally withdrawing funds from an exit transaction? Why is CPFP the only fee payment mechanism for these transactions? We will explain this later.
In the Ark protocol, unbroadcasted transactions and UTXOs are called “virtual transactions” and “VTXO (virtual UTXO)” respectively.
(Translator's note: As you can see, different authors have slightly different definitions of "VTXO", but the core meaning is the same.)
The Ark protocol uses Schnorr-based Taproot scripts to enforce these spending conditions. The Alice+AS multi-signature mechanism follows the N-of-N MuSig2 multi-party computation protocol, ultimately producing a single aggregate public key and a single aggregate signature.
How do I access an Ark through Ark Payment?
In this scenario, Alice pays Bob 100k satoshis (see the yellow "bob vtxo") by spending her own VTXO ("alice vtxo"). She signs with the AS, unlocking the "Alice+AS" spending conditions. She receives 900k satoshis as change ("alice change vtxo"). The spending conditions in Bob's VTXO are identical to those in Alice's (the only difference is that they use Bob's public key instead of Alice's). Alice's change VTXO ("alice change vtxo") maintains the same spending conditions as her original VTXO.
Now, Bob can use his VTXO to initiate an Ark payment, just as Alice did. However, Bob's VTXO carries the risk of double-spending: because the payment occurs off-chain, these transactions are not confirmed by the blockchain and lack the double-spend protection provided by the blockchain. The AS and Alice could collude and re-spend Alice's original VTXO elsewhere, thus voiding Bob's VTXO without his knowledge. However, Alice's change VTXO does not carry this risk, as she has no incentive to defraud herself.
If Alice and AS behave honestly (not signing or broadcasting transactions that conflict with this payment), Bob can unilaterally exit the Ark by broadcasting his "payment virtual transaction" and the exit virtual transaction. He must pay the block confirmation fee for these two transactions using CPFP.
VTXOs with double-spending risk are colored yellow, while VTXOs without such risk are colored green.
A closer look at Ark Payments
As you can see, just like Alice can pay Bob, Ark users can pay each other. However, any new VTXO created from a VTXO with double-spend risk carries the same risk. In fact, this risk increases as any predecessor in the chain of this VTXO could collude with the AS to harm the holder of the latest VTXO. Change VTXOs (or self-payment VTXOs) are originally derived from an exit VTXO (such as Alice's exit VTXO) and can be considered free of this risk because the same user controls both the input and the output, so there is no incentive to create a conflicting transaction (participate in collusion).
Furthermore, VTXOs created from a long chain of payment transactions face higher blockchain confirmation fees when unilaterally exiting. This is because the user must pay the fee for every transaction in the chain (starting from the initial exit transaction).
We will discuss how to mitigate the risk of double spending and the high unilateral exit costs of long-chain VTXOs in subsequent chapters.
Because Ark payments are completely off-chain transactions signed only by the sender and the AS, they are instant and there are no block confirmation fees.
How does the Ark Protocol scale for onboarding and payments?
Any user can join an Ark using their own on-chain funds, just like Alice. In the diagram above, Wendy also joins an Ark in a similar way. For simplicity, only spendable VTXOs are shown.
The throughput of on-chain transactions is limited by Bitcoin's block space. In contrast, Ark payments occur entirely off-chain and are not subject to block space constraints. Its throughput depends entirely on the ability of Ark service providers to process and coordinate these transactions.
Collaborative Exit
What is a “cooperative exit”?
In a cooperative exit, a user indicates to their AS that they wish to exchange a VTXO for an on-chain UTXO. The user transfers their VTXO balance to an address controlled by the AS, and the AS simultaneously transfers an equal amount of on-chain funds to an address controlled by the user. This exchange is atomic, ensuring fairness.
As shown in the diagram above, Bob and Wendy both wish to collaboratively exit the Ark. The AS constructs a transaction, called a "batch transaction," to transfer the AS's on-chain funds to these two users. Simultaneously, each user prepares a "forfeit transaction" to transfer their VTXO balances to an address controlled by the AS.
At this stage, none of these three transactions are signed. This is because neither the AS nor the user wants to transfer their balance to the other party first, as this would introduce counterparty risk: the other party might refuse to sign the corresponding transaction. To ensure fair exit, we need a mechanism to atomically sign these transactions and ensure fair exchange of VTXO and UTXO.
The idea here is that if the aborted transaction can only be spent after the batched transaction becomes spendable, then the exchange is atomic.
As shown in the diagram above, when we use an output from a batched transaction (called a "connector") as an input to a relinquishment transaction, the relinquishment transaction can only be spent after the batched transaction is signed and confirmed. The value of the connector output is not important; as long as it exceeds the dust amount, the relinquishment transaction can only be confirmed after the batched transaction is confirmed.
Now, the importance of signature order comes in. Users must sign their own waiver transactions first — this step is absolutely safe for them because the waiver transaction will not take effect unless the AS signs the batched transaction.
After receiving the waiver transaction from the user, the AS completes the process of signing and broadcasting the batch of processed transactions to get block confirmation.
Why add the clause “users can withdraw funds only after 1 day” to VTXO?
If Wendy attempts to deceive the Ark service provider, that is, after having signed a waiver transaction and received funds from a batched transaction, she initiates a unilateral exit and attempts to claim the value of her (already waived) VTXO, the AS can broadcast the waiver transaction and block Wendy.
This is the purpose of adding a one-day relative timelock to the VTXO. This delay gives the AS ample time to broadcast and confirm the relinquishment transaction; this transaction, already signed by Wendy, unlocks the Wendy+AS condition and is therefore not subject to the timelock. The timelock allows the AS to withdraw the funds from the VTXO before Wendy does.
The length of this relative time lock can be configured by the service provider.
The connector output can become quite large, is there a way to optimize it?
In the above diagram, the number of connector outputs in a batched transaction is equal to the number of VTXOs using it for cooperative exits. Because batched transactions require block confirmation, as the number of connector outputs increases, their size also increases, and the block confirmation fee also increases.
Here, we add a buffer transaction called a "connector tx," which allows batched transactions to prepare only one connector output (to generate enough connectors) to service all aborted transactions. This eliminates the need to prepare a connector output for each aborted transaction (in a batched transaction), replacing the linear increase in the number of connector outputs with a single output, significantly reducing the size and confirmation costs of batched transactions.
Ideally, dummy transactions for VTXOs, as well as abandonment and connector transactions, are not broadcast to the blockchain. They are a fallback, deployed only in the event of a user attempting fraud (in which case the user broadcasts the entire dummy transaction and the abandoned VTXOs, while the AS broadcasts the connector and abandonment transactions).
But what prevents users from launching a DoS (Denial of Service) attack against the AS by broadcasting a relinquished VTXO? The answer is that because all virtual transactions rely on CPFP to pay for fees (and carry no fees themselves), the user attempting fraud must pay fees for the entire transaction chain. Even if the user accepts this, the AS can still preemptively withdraw the funds from the relinquished VTXO using a pre-signed relinquishment transaction. This makes such attacks expensive and pointless, effectively deterring users from attempting fraud.
Then why add the condition of "AS can withdraw money after an absolute delay of 30 days" to the output UTXO?
In real life, any group of users of an Ark Service Provider (AS) may request a cooperative exit at any time.
VTXOs created from a funding transaction output are directly or indirectly derived from that output, forming a multi-layered, interconnected transaction structure. This means that multiple users effectively share the same on-chain UTXO from the funding transaction.
However, the AS cannot force all other users who share the same ancestor transaction to exit when one user requests a cooperative exit. Doing so would create a poor user experience and is impractical because some users may be offline or unresponsive during the cooperative exit process.
In order to process the exit requests of some users without disturbing other users, AS temporarily uses its own on-chain funds to assist users who wish to exit cooperatively in batches.
However, after the AS itself injects funds into the batched transactions (to serve users), how can it recover funds from the VTXOs abandoned by users? One option is to broadcast the abandonment transaction. However, this would force the withdrawal of many unrelated VTXOs that share the same ancestor transaction. Furthermore, this approach would introduce unnecessary transaction confirmation costs and delays, essentially deviating from the original intention of Ark's off-chain design.
At the same time, AS cannot permanently lock up the liquidity it provides until every user who participated in a funding transaction cooperatively exits. This would be too costly. Doing so would impose an unbearable burden on AS and make such a system unscalable.
A more pragmatic approach would be to impose a deadline on all users who share a funding transaction, before which they must initiate a cooperative exit. But how would this be achieved?
This is where the "AS withdrawal after 30 days absolute delay" policy comes into play. After the 30-day absolute delay, the AS can spend the UTXO independently. During this window, users can request a cooperative exit at any time. However, if a user fails to exit during this period, their VTXO will be taken by the AS—regardless of whether they have explicitly signed a withdrawal transaction.
This mechanism allows AS to recycle liquidity within a predictable timeframe and continue to operate efficiently. The length of this expiration period can also be configured by the service provider.
The disadvantage is that users who fail to act before the deadline will lose their VTXO balance (taken away by the AS).
Three embarrassing questions
We have identified three awkward issues that could make the Ark protocol impractical or unattractive:
- Double-spending risk associated with VTXOs created from Ark payments
- Risk of losing VTXO balance due to not withdrawing before the 30-day deadline
- The difficulty and high cost of unilateral exit, especially for users whose VTXO is at the end of a long virtual transaction chain
How can the Ark protocol solve these problems?
Fortunately, all three problems can be solved with one solution: AS reclaims the affected VTXOs and issues refreshed exit virtual transaction VTXOs to the relevant users.
We can address these issues using transaction batching, similar to the cooperative exit process. However, instead of coordinating an on-chain UTXO for each user, the AS simply issues each user a new VTXO from a new exit virtual transaction. This new VTXO is more secure because it has no double-spend risk, isn't at the end of a long virtual transaction chain, and has its expiration reset to 30 days from now.
In the example above, Dave atomically swapped his old VTXO (which carried double-spend risk) for a new, risk-free VTXO. Rather than using batched transactions to perform a cooperative exit (acquiring an on-chain UTXO), he securely obtained a new VTXO from a virtual exit transaction.
If you look more closely, you'll notice that the spending conditions for the first output of the batched transaction above are identical to those for the aforementioned funding transaction. Dave's exit virtual transaction also involves multiple transactions. The key difference lies in the source of funds: while the funding for the funding transaction mentioned above comes from the user's own UTXO, the funding for the batched transaction here comes from the AS's own UTXO. Why? The reason is the same as for the AS's funding for a cooperative exit—it temporarily injects its own funds to help the user exchange their old VTXO for a new one. Once the old VTXO expires, the AS can recover the funds all at once, just as in a cooperative exit.
When the expiration date of this new VTXO approaches, the user must perform another swap following the same process. This prevents the AS from seizing expired VTXOs. If the AS sweeps expired VTXOs (without explicitly relinquishing them), the user effectively hands over their funds to the AS. The Ark protocol does not guarantee that the value of swept VTXOs will be returned to the user. However, in reality, the AS may issue a new VTXO of the same value to the user as a courtesy when they return to the internet.
Naturally, these periodic swaps will incur a fee, as batching transactions requires block confirmation. However, this fee is generally low, as each user only has to pay a portion of the block confirmation fee.
How does the Ark protocol scale up the throughput of VTXO swaps?
A key advantage of this design is scalability. In the example above, Carol and Dave each exchange their VTXOs, which are at risk of double-spending, for new VTXOs from an exit dummy transaction. A single batch transaction can support thousands of users simply by adding the user's public key to the multi-signature spending conditions of the output and generating more exit dummy transactions and VTXOs. The primary bottleneck lies in the interactive signature process between the AS and all participating users.
Details on batching trades and exiting virtual trades
The frequency with which AS creates batched transactions
Generally, the AS creates a new batch of transactions at regular intervals, such as once an hour. Users wishing to cooperatively exit or exchange existing VTXOs for new, risk-free VTXOs can register their intention with the AS, which then coordinates the transaction with their wallet software. This interval is determined by the AS itself. During periods of high demand, the AS can initiate additional batches as needed.
There are some problems with exiting virtual trading
In a basic exit virtual transaction structure, once one user unilaterally exits, all other users in the same batch are also forced to exit. This breaks the continuity of the off-chain processing facilities, causes unexpected fees and delays, and requires everyone to re-enter the market.
Furthermore, the block confirmation fee for a unilateral exit increases linearly with the number of VTXOs in the same batch. For example, if a batch contains 1,000 VTXOs, then the user exiting the batch must pay the block confirmation fee for all 1,000 outputs, making a unilateral exit extremely expensive.
How to solve this problem?
Instead of having a single exit virtual transaction carry all VTXOs, we can use a binary tree-like exit virtual transaction construction. In this construction, as shown in the diagram above, if Carol (before other participants in the same batch) wishes to unilaterally exit, she needs to broadcast a series of virtual transactions in sequence: first, the "root virtual transaction" that anchors the entire batch; then, the "branch virtual transaction" on the left that leads to where her VTXOs are located; and finally, her own personal "exit virtual transaction."
As a result, if Dave also wants to unilaterally exit, since he and Carol happen to be on the same branch of the tree, he only needs to broadcast his own exit virtual transaction, because the ancestor transactions of this transaction in the tree - the root virtual transaction and the branch virtual transaction - have already been confirmed by the block during Carol's unilateral exit.
The tree-structured virtual transaction exit design offers several advantages over the basic design. In the basic design, a unilateral exit by one user forces all other users in the same batch to exit as well. In the tree-structured design, users who don't initiate a unilateral exit are not affected by the exits of others, thus avoiding forced exits while maintaining the user experience of off-chain payments.
The block confirmation fee burden of a unilateral exit is thus significantly reduced. In the tree structure design, block confirmation fees no longer scale linearly with the number of VTXOs, but rather increase logarithmically with the number of VTXOs (increasing linearly with the depth of the tree), making unilateral exits more economical. Users who initiate the operation later further benefit, as they only need to broadcast their own sub-branch and leaf transactions, minimizing their personal block confirmation fees.
The tree structure also improves scalability, allowing a single batch to accommodate more VTXOs. However, it also brings more complexity: the number of interactive signatures increases with the depth of the tree, and more coordination between participants is required.
When a user chooses to unilaterally exit, they must broadcast every connection (every transaction) along the entire path from the root to their leaf, making this process extremely time-consuming and labor-intensive. However, root and branch transactions (outputs) use the same scripting rules and expiration conditions as batched transactions. The key difference is that these transactions are not immediately broadcast to the blockchain network after being signed, but only when needed.
Finally, if a user unilaterally exits, then when AS needs to clear the value of the remaining VTXO in the future, it must also broadcast and confirm the corresponding branch transaction (instead of just spending batch processing transactions to complete the clearing).
- - -
To learn more, see these resources:
- Ark Protocol — Second Documentation ( Chinese Translation )
- Ark: A UTXO-based Transaction Batching Protocol — Litepaper by Ark Labs
Special thanks to tiero for reviewing this article.
(over)
