Skip to main content

Documentation Index

Fetch the complete documentation index at: https://second.tech/docs/llms.txt

Use this file to discover all available pages before exploring further.

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.
Connectors replaced by hash-locks for refreshesAs 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 forfeitsArk 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

​
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, Bark uses hash-locks instead of connectors. During a round, the server generates a secret (known as a preimage) for each new VTXO and shares its hash with participants. Both the new VTXO and the user’s forfeit transaction are constructed with a hash-lock condition—neither can be used on-chain without providing the preimage.
Diagram showing how a hash-lock makes a forfeit transaction conditional on the server revealing the preimage
The user can safely sign the forfeit without knowing the preimage, since the forfeit cannot be executed until the preimage is revealed. After signing, the server reveals the preimage, granting the user access to their new VTXO. If the server withholds the preimage, the user can still unilaterally exit their old VTXO—the hash-locked forfeit cannot be executed without it, so the server cannot prevent the exit. The only way the server could block the exit is by broadcasting the forfeit, but doing so reveals the preimage on-chain, which in turn gives the user access to their new VTXO. Either way, the user cannot lose funds. This approach also 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
This makes on-chain payments and offboards atomic: either the payment completes and the forfeit is valid, or neither happens.