Ark is an alternative second-layer scaling approach that allows the users of the protocol to send and receive coins without introducing; (1) liquidity constraints, (2) interactivity requirements, (3) a direct link between senders and receivers. This means a recipient can get paid without (1) having any onboarding setup (like acquiring inbound liquidity), (2) running an always-on server, and (3) leaking his identity to outside observers.
Ark consumes orders of magnitude less on-chain footprint than Lightning, as there is no concept of opening and closing channels. Like a wallet’s UTXO set, users possess a set of coins. Coins are created, live and die entirely off the chain yet can be unilaterally reverted to on-chain.
Although Ark is a completely new design, it is interoperable with the Lightning Network, which complements it. This is a comparison table as if Ark is a competing protocol:
When sending funds, users coin-select & destroy their bitcoins and create new ones for the recipient (plus change) in an off-chain mixing round. Each new coin is tweaked with a shared secret that reveals proof of payment when spent. The payment destination is a dedicated well-known public key similar to silent payments; however, the payment trace is obfuscated through plain tweaking and blinded mixing.
Two parties are involved in the Ark protocol; users and service providers. Users are non-interactive entities that hold, send, and receive coins. Service providers, on the other hand, are always-on servers that provide liquidity to the protocol.
Ark requires BIP-118 or BIP-119 covenant primitives to constrain transaction outputs of a spending transaction to make the receiving on the protocol non-interactive. BIP-118 ANYPREVOUTANYSCRIPT can constrain the spending transaction by hardcoding a 65-byte signature and a 33-byte unknown public key type in a script. Alternatively, BIP-119 CTV can directly constrain transaction outputs to a template hash. Other alternatives would be (1) TXHASH, (2) CAT + CSFS + TAGGEDHASH, or (3) XOR + CSFS + TAGGEDHASH combinations.
These covenant primitives can be emulated using n-of-n multisig by compromising on non-interactivity. Recipients must be online to sign from the n-of-n multisig to constrain the spending transaction. This interactive version doesn't require any changes to Bitcoin and, thus, something that can be deployed on Bitcoin today.
Covenants are utilized to commit a large set of transaction outputs to a single transaction output. These committed but unrevealed transaction outputs are called virtual transaction outputs or vTXOs.
On Ark, Bitcoin funds are carried by virtual transaction outputs (vTXOs). vTXOs are destroyed, and new vTXOs are created when a payment is made on the protocol, similar to how on-chain funds flow. To improve the anonymity set of the coin ownership, vTXOs values are restricted to a set of sats ranging from one sat to a million sats.
Ark uses a new locktype primitive called txlock to ensure the absolute atomicity of a transfer schedule. Txlock is a condition in which only the existence of a mutually agreed transaction identifier can unlock the condition. A txlock condition could, in theory, be satisfied by a hypothetical opcode called OP_CHECKTXIDFROMUTXOSETVERIFY. However, Ark uses an alternative approach to achieving the same outcome using connectors. Connectors are a special output type on the protocol. The primitive is that if we want the Bitcoin script to check if a particular transaction id exists, we simply attach an output from that transaction into our spending transaction and check a pre-signed signature against all prevouts of the spending transaction. The connector outpoint in the sighash preimage commits to the transaction id for which we want to satisfy the txlock condition. In the Ark context, this transaction is the pool transaction containing payout vTXOs.
ATLCs are conditional payments used on Ark, using txlocks to provide an atomic single-hub payment schedule. When a vTXO is spent, an ATLC is attached to it, similar to how HTLCs are attached to a 2-of-2 funding output on Lightning. Attached ATLC then connects to a connector to form a txlock.
This txlock formation ensures that, in order for the attached ATLC to be claimed by the service provider, the outpoint context of its connector must remain unchanged. In other words, Ark service providers should not double-spend pool transactions that they create. This provides an atomic payout construction for senders, as payout vTXOs nest under the same transaction of connectors. The link between connectors and newly created vTXOs is obfuscated through blinded mixing between those.
Pool transactions are created by Ark service providers perpetually every 5 seconds, which are effectively blinded, footprint-minimal, rapid coinjoin rounds.
ASP funds the coinjoin with their own on-chain funds in exchange for vTXOs redemptions. Therefore, the coinjoin transaction that hits on-chain has only one or a few inputs provided by the ASP.
The pool transaction has three outputs: vTXOs output, connectors output, and ASP change. Service providers place vTXOs for the intended recipients to claim (under the vTXOs output) and connectors for senders to connect (under the connectors output) in their pools.
The first output of the pool transaction, vTXOs output, contains newly created vTXOs of the coinjoin round. vTXOs are bundled and nested under this shared output and can be revealed on-chain. vTXOs output expires four weeks after its creation, and once it expires, the ASP who funded this output in the first place can solely sweep it. Nested vTXOs under the vTXOs output are expected to be redeemed by their owners in this window period. Nested vTXOs may be revealed in this four-week timeframe if the factory operator happens to be non-collaborative or non-responsive for a long period. In the optimistic big picture, however, the final result is almost always a pool transaction with few inputs and three outputs where pool content is rarely revealed on-chain. Therefore, vTXOs & connectors remain almost always off the chain.
A vTXO has a lifetime of four weeks. The recipient can solely claim a vTXO in the first two weeks of receiving it. If a vTXO remains unclaimed for the first two weeks, the vTXO reverts to the sender’s control, similar to HTLC timeouts on the Lightning network.
A vTXO has five total closures:
Collaborative Connector Closure is used for connecting an ATLC to its connector. vTXO owner and the service provider collaboratively signs atlc:connect to form a txlock from the 2-of-2 key path of ATLC. This requires collaboration with the co-signer (Ark service provider).
The first input in the vtxo:claim -> atlc:connect is the ATLC itself, and the second is its connector from the new pool template. ATLC connector carries dust value (450 sats), and it's only spendable by the Ark servie provider. The ATLC is signed using SH_ALL; meaning, the connectors' outpoint in the sighash preimage commits to the pool transaction template. To claim this ATLC in a dispute resolution case, the ASP must point to the agreed pool template by spending the corresponding connector. This provides an atomic payout construction as the recipient vTXOs nest in the same pool transaction as connectors.
If the Ark service provider happens to be non-collaborative in co-signing an ATLC from the connector closure, a vTXO owner can reveal their nested vTXOs, and then wait until after a certain relative time window encoded in the contract (24 hours) to claim funds.
Refund collaborative connector closure is the same as collaborative connector closure, except the original sender can trigger this closure instead of the intended recipient. This closure is akin to HTLC timeouts on Lightning where the sender gets a refund on their in-flight funds.
Refund uniliteral exit closure is the same as uniliteral exit closure, except the original sender can trigger this closure instead of the intended recipient.
If a revealed vTXO remains unclaimed for more than four weeks, the ASP can solely sweep this vTXO.
Ark can interoperate with Lightning by attaching HTLCs and PTLCs to a pool transaction just like attaching ATLCs and connectors. Attached HTLCs live under another shared UTXO called the HTLCs outputs, which also expires after four-weeks.
Ark service providers forward HTLCs to the broader Lightning Network the moment after HTLCs are attached to a pool transaction. This requires Ark service providers to run routing nodes on the Lightning Network with well-established outgoing channels. Ark users can also get paid from Lightning using HTLC-nested vTXOs.
Ark is an open network where anyone can run their own ASP infrastructure. This means a user can have a vTXO set associated with different ASPs. The Ark protocol design allows users to pay lightning invoices from different vTXO sources with the use of multi-part payments (MPP). Upon attaching HTLCs (or PTLCs) to multiple pools operated by various ASPs, HTLCs can be forwarded to the end destination via MPP.
Each new payout vTXO is tweaked with an epheremal shared secret that contains the payment commitment. Anchoring an ATLC reveals proof of payment when signing from the 2-of-2 connector closure. Tweaking details can be found here.