Bisq Halted Trading After a Protocol Flaw Put User Funds at Risk

Bisq developers used the exchange network’s emergency alert key on April 7, 2020 to disable trading after discovering that an attacker had exploited a flaw in its trade protocol. The intervention was extraordinary for a project designed to avoid centralized custody and control: Bisq subsequently said it was the first time in four years of mainnet operation that the key had been used to place nodes in a safe mode.

The action did not switch off a conventional exchange server. Bisq was distributed peer-to-peer software, so users could override the alert and continue operating their nodes. Developers strongly discouraged that option while they investigated the vulnerability. The incident demonstrated that removing a central custodian did not remove software risk—or the need for an emergency response mechanism.

The flaw was in trade settlement

Bisq attributed the vulnerability to the trade protocol introduced with version 1.2 in October 2019. That design removed arbitrators holding a third key in the multisignature escrow for bitcoin trading funds. Mediators and arbitrators without escrow keys replaced them, reducing the authority of trusted third parties.

The replacement design needed another way to resolve trades that remained locked after a specified period. Participants therefore signed a time-locked transaction that would eventually move the bitcoin to a donation address selected through the Bisq DAO. The donation address served as a destination from which a prolonged dispute could be resolved.

According to Bisq’s April 8 disclosure, the software failed to verify that the address embedded in the delayed payout transaction was the donation address approved by DAO stakeholders. An attacker could substitute another address before a counterparty signed the transaction, allowing the attacker to receive the locked bitcoin after the time limit expired.

Bisq emphasized that the vulnerability concerned the execution of individual trades, not centralized storage of customer balances. That distinction was technically important because Bisq did not maintain a pooled customer wallet comparable to a custodial exchange. It did not, however, reduce the losses suffered by counterparties whose trades were manipulated.

The initial scope remained uncertain

No complete loss accounting was publicly available on April 7. In its April 8 statement, Bisq said it was then aware of approximately 3 BTC and 4,000 XMR stolen from seven victims. The project said only the XMR/BTC market was affected and that the relevant trades occurred during the preceding 12 days. Those were preliminary project claims, not independently audited figures or a final incident report.

Contemporaneous reporting confirmed that trading had been halted on April 7 and that users were told not to send funds to counterparties while the fix was prepared. Bisq released version 1.3.0 on April 8 as a hotfix for the critical trade-protocol vulnerability. Its signed GitHub release linked the relevant code changes, providing direct evidence that the response involved a software correction rather than only an operational warning.

Why the halt mattered

The incident exposed a difficult governance trade-off for decentralized market infrastructure. Bisq’s alert key enabled developers to protect users quickly, but nodes retained the ability to ignore it. The network was therefore neither centrally stoppable nor incapable of coordinated intervention. Its safety depended on developers identifying the problem, distributing an authenticated warning and persuading users to follow it.

The April 7 halt also showed how decentralizing dispute resolution can relocate risk. Removing an arbitrator’s escrow key reduced one form of trusted control, while the replacement delayed-payout mechanism introduced an address-validation failure. That is an interpretation of the documented design, not evidence that peer-to-peer exchanges are inherently less secure than custodial platforms.

Later clarification

A Bisq DAO proposal opened on April 14, 2020 revised the loss record to 34.86 BTC taken from six traders attempting to buy bitcoin with monero, with affected trades dated March 28 and April 7. The proposal put the loss at $235,831 and sought repayment from future trading fees. Because that accounting was unavailable on April 7 and differs from the initial seven-victim estimate, it should be treated as later clarification rather than event-day knowledge.