Forfeits and connectors

Forfeits are pre-signed transactions, used for refreshes and offboards, that grant the Ark server control over a user's VTXOs. The server holds these forfeit transactions off-chain as a safeguard against malicious exits. Although a forfeit grants control over the original VTXO to the server, the server can't access the bitcoin immediately—it must still wait for the VTXO to expire.

Connectors provide cryptographic assurance that forfeit transactions are only valid if the intended transactions are completed:

• A new VTXO included in the round transaction and confirmed on-chain
• An offboard output is included in the on-chain round transaction

Consequently, a user can safely sign a forfeit transaction without needing to trust any third-party—ensuring these processes are atomic, self-custodial, and without counterparty risk.

The connector ensures that Alice's refresh forfeit is not valid until the new VTXO's round transaction is confirmed on-chain.

Spends don't use forfeits

Ark spends do not involve an atomic operation where the user forfeits a VTXO to make a payment. Instead, the user pre-signs a new off-chain transaction with the Ark server that extends the leaf of one of their existing VTXOs. For Lightning spends, Ark uses custom HTLC-based spending policies to ensure atomic execution.

How forfeits work

If you are familiar with penalty transactions in the Lightning Network, you should already have a good idea of how forfeits on Ark work.

To support forfeits, each VTXO's exit transaction (leaf) has two spend paths:

• Spend path 1: This path is a 2-of-2 multisig between the user and the Ark server. The user signs this path to make a forfeit transaction which grants the bitcoin associated with the VTXO to the Ark server. Crucially this spend path doesn't have a timelock. If the exit transaction ever makes it on-chain, the Ark server can always broadcast the forfeit transaction before the user can claim the bitcoin.
• Spend path 2: This path is controlled solely by the user and enables them to exit unilaterally, assuming a signed forfeit doesn't exist. The path has a relative timelock of 60 blocks (approximately 10 hours). The timelock is implemented using the OP_CHECKSEQUENCEVERIFY (CSV) opcode in Bitcoin Script.

How spending conditions in an exit output (leaf) enable forfeits

Forfeits usually never make it on-chain

Under normal operations, neither of these spend paths should ever be used, even for forfeited VTXOs. Instead, Ark servers will simply sweep the entire round transaction in one on-chain transaction once the round transaction's absolute timelock has expired.

The forfeit transaction signed by the user is only held as "insurance" should the user attempt an exit after they have forfeited.

How forfeits are used to prevent malicious exits

If a user does attempt a malicious exit, they will broadcast all their VTXO's branch transactions, but once they get to the leaf, they must wait for the relative timelock to expire before they can send the balance to an on-chain address only they control.

At Second, we're expecting to set the exit timelock at around 10 hours. That will give ample time for an Ark server to detect the exit attempt and broadcast the forfeit transaction that was pre-signed by the user before the user can claim their bitcoin.

While forfeits provide an Ark server with security, they're not ideal: the server must make extra on-chain transactions beyond the normal round sweep post-expiry (to claim the rest of the round's bitcoin). However, the on-chain fees to broadcast multiple transactions (branch to leaf) should be a sufficient deterrent from users attempting this too often!

How connectors work

Now that we understand forfeits, let's examine how connectors ensure they work atomically by looking at refreshes (offboarding works essentially the same way).

Forfeits are atomically dependent on the linked round transaction being confirmed. As long as the round transaction is unconfirmed (for example, sitting in the mempool), the forfeit transaction is invalid and would be rejected if broadcast to prevent the user's unilateral exit. Of course, without the round transaction confirmed, the new VTXO is not valid either!

If the round is not confirmed on-chain, the forfeit and new VTXO cannot be confirmed.

But as soon as the round transaction is confirmed on-chain, it will both activate the forfeit and grant the new VTXO.

Once the round is confirmed on-chain, the forfeit and new VTXO can now be confirmed.

Optimizing blockspace footprint

To save chain space, we want all connectors to be grouped in a single output. But we need to do it efficiently. Ark rounds are expected to involve hundreds and perhaps thousands of users and poorly structured connectors could lead to huge (and very expensive!) round transactions.

Below is an illustration of a bad design for grouping connectors in a single output that could quickly balloon in size:

Instead, the Ark protocol uses connector chains—a chain of transactions and each has a connector output. Below is an illustration of a good design for grouping connectors—it results in a smaller round transaction while still embedding all the data required to link the forfeits.

The trade-off is more interactivity: A user that forfeits a VTXO must sign a forfeit for each connector output in the chain.

Below you can see an illustration of how an Ark server must respond to a user attempting a malicious exit of one of their forfeited VTXOs. For example, it must broadcast C1 and F1 on-chain.

Forfeits and connectors are only a contingency

In normal circumstances only the round transaction ever goes on-chain. Transactions from the connector chain only go on-chain when a user attempts to maliciously spend a forfeited VTXO.