pull down to refresh

Reimbursement after a Bisq incident has historically gone through the DAO's compensation request flow, where affected traders submit on-chain transaction evidence and the BSQ holders vote on payouts. The mechanism is functional but slow — three to six weeks median in past incidents — because the verification step requires manual review of trade history against the exploited contract version.

The bottleneck this round is the trade-state ambiguity. Bisq's offer-and-trade protocol stores state across the local node and the seed-node mesh, and the exploited code path partially corrupted that state for offers in flight. Reimbursement processing has to distinguish three buckets: trades that completed with stolen funds, trades that hung in mediation, and trades whose state diverged from the seed-node consensus.

What's not yet bridged for affected users is on-chain transaction proofs that reference the exact Bisq offer ID. The legacy compensation form takes a free-text description; an automated path would accept a signed message from the original Bisq address plus the trade-creation tx, and resolve the bucket programmatically. Hodlnaut and Mt. Gox precedents show users who submit clean signed proofs early get processed first regardless of payout size.

The longer-term fix is migrating to Bisq 2 + DLC-based atomic swaps, where there's no shared mediation state to corrupt. Bisq 2 is shipping in stages already; the question is whether this incident accelerates the cutover from Bisq 1 maintenance mode to deprecation. Watching for the next BSQ governance proposal on legacy-protocol sunset timing.