This is disappointing: Some Bisq developers are highly proficient with AI tools. However, we had not systematically used them as part of an actual security audit process. One developer attempted to get Bisq into an external security audit program, but the application was rejected. In hindsight, this was a serious failure on our side. The mistake was not only the missing validation check. It was also failing to react early enough to the changing security landscape and the increasing practical relevance of AI-assisted vulnerability discovery.
Based on preliminary estimates from data analysis and reports from affected users, the total amount stolen appears to be approximately 11 BTC. So far only Altcoin trades have been reported. This remains a preliminary estimate.
In short, the exploit was caused by a missing validation that should have rejected negative input values provided by the taker. The maker and taker must use the same miner fee. That fee value is provided by the taker.
The attacker supplied a negative miner fee. When the maker calculated the multisig output — including the payout transaction fee — the negative value reduced the multisig amount to 0.001 BTC, while the remaining funds were redirected to the taker’s change output.
Some Bisq developers are highly proficient with AI tools. However, we had not systematically used them as part of an actual security audit process. One developer attempted to get Bisq into an external security audit program, but the application was rejected.
In hindsight, this was a serious failure on our side. The mistake was not only the missing validation check. It was also failing to react early enough to the changing security landscape and the increasing practical relevance of AI-assisted vulnerability discovery.
We must assume that there will be further attempts. Over the coming weeks we will invest significant effort into hardening the codebase and using AI tools to search for failure modes. We will particularly focus on vulnerabilities that could directly affect the wallet.
Until additional review and hardening are completed, we recommend that Bisq users do not keep more BTC in their Bisq wallet than is necessary for active trading.
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.
This is disappointing:
Some Bisq developers are highly proficient with AI tools. However, we had not systematically used them as part of an actual security audit process. One developer attempted to get Bisq into an external security audit program, but the application was rejected. In hindsight, this was a serious failure on our side. The mistake was not only the missing validation check. It was also failing to react early enough to the changing security landscape and the increasing practical relevance of AI-assisted vulnerability discovery.Bisq also published an X thread about this:
https://twiiit.com/bisq_network/status/2050917431699460231
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.