Ark forfeits

Forfeits are pre-signed transactions used in refreshes and on-chain payments to grant the Ark server control over the VTXOs being spent. The server holds forfeit transactions off-chain as a safeguard against malicious exits.

Forfeits are used in combination with hash-locks or connectors to provide cryptographic assurance that the forfeit is only valid if the intended operation completes. This allows users to safely sign forfeit transactions without trusting any third party—ensuring the associated operations are atomic, self-custodial, and without counterparty risk.

Forfeits + hash-locks for refreshes.
Forfeits + connectors for on-chain payments (including offboards).

Connectors replaced by hash-locks for refreshes

As of version 0.1.0-beta.6, Bark uses hArk (Hash-lock Ark), which achieves refresh atomicity through hash-locks instead of connectors. Connectors are now used exclusively for on-chain payments and offboards.

Ark and Lightning payments don't use forfeits

Ark and Lightning payments don't involve forfeiting a VTXO.

In Ark payments, the user pre-signs a new off-chain transaction with the Ark server that extends the leaf of an existing VTXO, creating a spend VTXO.

In Lightning payments, the user relies on 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: A 2-of-2 multisig between the user and the Ark server. The user signs this path to create a forfeit transaction granting the VTXO to the server. This path has no timelock—if the exit transaction ever makes it on-chain, the server can broadcast the forfeit before the user claims the bitcoin.
Spend path 2: Controlled solely by the user for emergency exits. This path has a relative timelock of 60 blocks (approximately 10 hours), implemented using OP_CHECKSEQUENCEVERIFY (CSV).

Diagram of the spend paths in an exit output — Spending conditions in an exit output (leaf) that enable forfeits

Forfeits usually never make it on-chain

Under normal operations, neither spend path is used. The server simply sweeps the entire round transaction once its absolute timelock expires. The forfeit is held as insurance—only used if a user attempts an exit after forfeiting.

Preventing malicious exits

If a user attempts a malicious exit after forfeiting, they must broadcast their VTXO's branch transactions and then wait for the relative timelock on the leaf before claiming. The timelock (expected to be around 10 hours) gives the server ample time to detect the attempt and broadcast the pre-signed forfeit first.

How hash-locks work for rounds

For rounds involving multiple users, Bark uses hash-locks instead of connectors. The server generates a secret for each new VTXO. Users sign forfeits that are hash-locked—they require the preimage to be valid. The server reveals the preimage only after receiving the forfeit signature, which simultaneously makes the forfeit valid and grants the user access to their new VTXO.

This approach enables non-interactive round participation, which is essential for delegated refreshes on some mobile devices.

How connectors work for on-chain payments

Connectors ensure that a user's forfeit is only valid if the corresponding on-chain payment is confirmed. The server constructs the payment transaction with both the destination output and a connector output. Because the user's forfeit requires the connector output to exist, the forfeit cannot be used unless the corresponding payment transaction is confirmed first.

Diagram showing how a forfeit transaction cannot be confirmed until the payment transaction is confirmed on-chain — The connector ensures the forfeit is only valid once the payment transaction is broadcast.

This makes on-chain payments and offboards atomic: either the payment completes and the forfeit is valid, or neither happens.