Skip to main content
Once the server detects a double-spend attempt, it reacts in one of two ways, depending on the transaction state:
Forfeit transactions are a critical security mechanism for Arkade operators that protect them from fraud attempts by users. When a user attempts to broadcast old pre-signed paths for a VTXO that was already spent in a previous batch swap, the operator broadcasts the corresponding forfeit transaction to claw back the funds. The attacker burns their own transaction fees attempting this fraud while gaining no economic advantage - the operator immediately publishes the forfeit transaction to reclaim the onchain funds that belong to the server. Forfeit transactions are created and managed during the batch processing lifecycle. Clients submit signed forfeit transactions via the SubmitSignedForfeitTxs RPC method as part of the batch finalization process.

​
Forfeit Transaction Structure

Forfeit transactions have a specific two-input, two-output structure (BuildForfeitTx) that requires both a VTXO input and a connector input:
  • Two inputs: One VTXO input and one connector input
  • Two outputs: Forfeit output (to operator) and anchor output
  • Timelock support: Can include CLTV locks for time-based constraints
Forfeit Transaction
The system validates this structure during forfeit transaction verification, ensuring the connector input is properly identified and paired with the corresponding VTXO input.

​
Fraud Detection and Response

The system monitors for fraud attempts (reactToFraud). When a user spends a VTXO offchain and then attempts to redeem the same VTXO onchain (fraud), the operator can broadcast (broadcastForfeitTx) the corresponding forfeit transaction to reclaim the funds:
  1. Retrieve the commitment transaction containing the VTXO
  2. Find the correct forfeit transaction and connector outpoint
  3. Broadcast the connector branch (broadcastConnectorBranch) leading to the forfeit transaction
  4. Sign and broadcast the forfeit transaction
When fraud is detected, the system must broadcast the entire connector branch leading to the specific connector needed for the forfeit transaction. This process ensures the connector UTXO is available onchain before the forfeit transaction can be broadcast.

​
Security Considerations

  1. Timing: Forfeit transactions must be submitted within the batch processing window
  2. Validation: All signatures and transaction structures are verified before acceptance
  3. Connector Management: Proper connector UTXO locking (LockConnectorUtxos) prevents double-spending
  4. Fee Bumping: Forfeit transactions support fee bumping for reliable confirmation (bumpAnchorTx)
Forfeit transactions are essential for maintaining the security guarantees of the Arkade protocol. They ensure that operators can recover funds in fraud scenarios while maintaining the efficiency of offchain transactions.