The Ark protocol

The Ark protocol is a second layer on the bitcoin network. It offers cheap on-boarding, low and predictable fees and fast transaction confirmation. The protocol works on bitcoin today and doesn't require any new op-codes or changes in consensus rules.

The protocol centers around an Ark Service Provider (ASP) that initiates and coordinates rounds. In each round a new bitcoin transaction is made that will be confirmed on-chain. However, all money received in a single round, will be confirmed in a single shared UTXO. The Ark protocol prescribes how users share UTXOs while at all times having access to their funds. A share in such a round is called a VTXO.

A client that owns a VTXO can perform a unilateral exit. This uniltateral exit is completely permissionless and can only be triggered by the client. At any point in time the client is in full control of their funds. To claim a VTXO a client pays on-chain fees and broadcasts their VTXO.

A client can also off-board by performing a cooperative exit which is co-signed by the ASP and has a much smaller on-chain footprint. Inside the Ark, they can make payments by swapping their VTXOs for new VTXOs, for example one for a recipient and another one containing the change. In this way, Ark transactions are very similar in topology to bitcoin transaction. The fee-savings are significant because swapping VTXOs has no on-chain footprint.

Ark is an optimistic protocol. We expect unilateral exits to be used by exception, as such only the round-transaction should make it on-chain. The protocol requires that VTXOs have an expiry time. This allows the ASP to claim all funds in an expired round using a single on-chain transaction.

In general, the expiry time doesn't harm clients. Clients can refresh an old VTXO which is close to the expiry-time by swapping it against a new VTXO.

UTXO-sharing using transaction trees

In this chapter we'll explain how UTXO-sharing is achieved in the Ark protocol. To keep thing simple we start with an ASP that wants to perform mass pay-out to a group of clients. A similar set-up will happen every round.

One approach is that the ASP could create single transaction which has one taproot-output for each client. This means that each output adds 43 vbytes to the transaction size or a cost of 430 sat assuming 10 sat/vbyte.

The example below shows such a mass pay-out with 8 different outputs. Each output shows the amount and the key that can be used to spent the money.

Instead of paying each user separately, the ASP builds a tree transactions that pays each user in a transaction in one of the tree leaves. This tree can be constructed in such a way that any payment is final even if only the root of the tree is confirmed on-chain. The ASP only has to pay the fee for a a single transaction with a single taproot output.

In this case, the ASP is saving fees at the expense of their clients. A client that wants to spend the bitcoin has to pay onchain fees for each transaction in their branch of the tree. I'll promise we'll solve that problem in the next section. Let's ignore that problem for now and look into how the tree is constructed.

The core idea is that all funds are secured by a N-of-N multisig that must be signed by all receivers. Having N-of-N is great, if you are one of the receivers you have an absolute veto power.

The N-of-N multisig is signed before the ASP sends any funds to the tree. Each client has a fully signed transaction and can claim the funds at any time by broadcasting their transactions and paying onchain fees. We call this a unilateral exit because there is no need to ask permission from anyone.

We apply this idea recursively. At the root of the tree is a transaction which has an output that is signed by all receivers. We have a presigned transaction that splits the funds over two outputs. Each output is locked by a multisig of all receivers for that output. We repeat this until we reach a leaf where the output is owned by a single receiver. We call the outputs at the leaf a VTXO or a virtual transaction output.

To construct such a tree the ASP can construct the transaction, request signatures from all clients. Once all transactions are signed the ASP can safely fund the transaction and publish the root of the tree.

This transaction tree is a core building block of Ark. It provides each user with a mechanism to withdraw their funds unilaterally. This is what makes Ark self-custodial.

Generally, we want to reserve the unilateral exit only for rare occasions. In the next section we'll explain how clients can avoid paying on-chain fees by swapping their VTXOs.

Swap VTXOs atomically

Swapping a VTXO doesn't have an onchain footprint and is much cheaper than a unilateral exit. The ASP provides the swaps in exchange for a small fee.

You can use a swap to make a payment. To make a payment you can swap one or more VTXOs that are owned by you against one VTXO that is owned by the recipient and a second VTXO containing the change, similar to a regular bitcoin transaction.

The same mechanism can be used to exit the ark. In this case we swap a VTXO against a normal UTXO.

The basic building blocks of an atomic swap are forfeits and connectors. The forfeit-construct allows a client to give up ownership of their VTXO(s). The connector makes the forfeit conditional and ensures the client will only give up their VTXO if something is offered in return, namely the creation of new VTXOs or a UTXO.

Forfeit transactions

If you are already familiar with the lightning network you might know how these forfeits work. We use the same mechanism as penalty transaction in the lightning network.

To support forfeits each exit transaction must follow a specific pattern which involves 2 spending-paths.

The first spending-path is fully controlled and enables unilateral exit. This spending-path a has a relative timelock of 60 blocks which is roughly 6 hours. The time-lock is implemented using the OP_CHECKSEQUENCEVERIFY (CSV) opcode in bitcoin script.

The other spending-path is a multisig between the client and the ASP. The client can use this exit-path to sign a forfeit-transaction which grants all funds to the ASP. Note that this spending-path doesn't have a timelock. If the exit-transaction ever makes it onchain the ASP can always broadcast the forfeit-transaction before the client can claim the funds.

Connectors make swap atomic

A connector ensures that if a client forfeits a VTXO they get something in return. This could either be a UTXO or VTXO in a next round.

The connector ensures that a forfeit transaction is only valid if the next round exists. By consequence, it is fully safe for the client to sign a forfeit transaction with a connector.

Stages of a round

The round has the following phases

1. ASP announces the start of the round.
2. All clients tell what VTXOs they want to swap.
3. The ASP constructs the transaction tree and forfeit transactions.
4. The clients sign the transaction tree and all forfeit transactions.
5. The ASP funds the round and ensures it is confirmed on-chain.

Pass on VTXOs instantly

Swapping VTXOs for new ones, or for an on-chain UTXO can be done atomically, but requires waiting for a round.

For faster interactions, instead of swapping VTXOs, users can also pass along a VTXO to another user. In fact, just like how bitcoin transactions work, you can pass along multiple VTXOs as inputs and create multiple VTXOs as outputs.

Since there is no need to wait for an Ark round, we call these Ark out-of-round (ArkOOR) transactions. Subsequently, also no liquidity fee has to be paid for these transactions. These transactions are incredibly fast, because the only interaction required for them is a co-signature of the ASP.

The trade-off for this convenient form of making Ark payments is that the trust model changes slightly: as long as you are holding an ArkOOR VTXO, your unilateral exit could be prevented if any of the previous holders of the VTXO colludes with the ASP. To exit this alternative trust model, a user can at any time swap an ArkOOR VTXO for a regular VTXO in an Ark round.

We believe that this more convenient way of transacting together with the fact that it is optional and can easily be converted into the regular Ark VTXO, makes for a good balance between trustlessness and user experience.

Creating ArkOOR transactions

An ArkOOR transaction is very similar to a forfeit transaction like we saw in the previous section. We spend the VTXO output by using the two-of-two clause between the VTXO owner and the ASP. However, instead of signing a transaction that sends the money to the ASP, we can send it to a new output that represents a new VTXO for the recipient. This output will be identical to the regular VTXO's output, it has a two-of-two clause between the new user and the ASP, and it has a unilateral exit clause for the user, after a timeout of 60.

After creating this transaction, the sender asks the ASP for a co-signature. The ASP guarantees that it only ever co-signs each VTXO once, so that no double spending is possible. When the sender has the ASP's signature, it can finish the transaction and send it to the recipient, who at that point has an ArkOOR VTXO.

Boarding the Ark

A client that owns a bitcoin UTXO can onboard funds into the Ark at any time. There is no need to wait for a round to occur.

The idea is pretty simple. At any point in time the client can ask the server to cosign a VTXO. Once the VTXO is created the client can fund it.

This process will result in a single on-chain transaction. Typically, the server will require 6 confirmations before it will allow the VTXO to participate in a round. This protetects the server from double-spends.

Expiry dates allow the ASP to reclaim funds

As time passes, more and more VTXOs will have been swapped an the number of VTXOs in the transaction tree owned by the ASP will grow. The ASP could broadcast the entire tree and claim the VTXOs. In this case the ASP would have to pay on-chain fees for every transaction in the tree. This is not feasible from an economics point of view.

The trick is to add an expiry time to a round. Each round, or better all VTXOs created in this round, expires after a fixed interval. By default this interval is 11520 blocks which is roughly 28 days.

If no client performed a unilateral exit, the ASP can just claim all funds in the round transaction once the round has expired.