Data points
We have now received all reports from affected users. The total amount of funds lost is 11.59104 BTC. A total of 10 users were affected. Only altcoin trades were impacted. Fiat trades are protected by the account age witness signing system, which likely acted as a deterrent to the attacker. Three traders accounted for almost 90% of the total loss, while three traders suffered only very small losses.
What is the current status of reimbursement?
No final proposal has been completed yet. Our goal remains to submit a proposal for DAO voting, and the current proposal period ends in about one week. The intent remains the same as initially communicated: we plan to fully reimburse all victims and provide the option to receive reimbursement in Bitcoin or BSQ. What remains unresolved is how to fund the reimbursement in a way that minimizes the impact on the DAO, BSQ stakeholders, and Bisq contributors.
When will a new version be released?
Our initial plan was to deploy a hotfix based on the latest release, with only minimal changes to address the vulnerability used in the exploit. However, this approach proved too risky. We must assume that the same attacker — and potentially others — will actively probe for additional vulnerabilities across all parts of the application.
This includes the wallet, the P2P network, the DAO, and infrastructure components such as external market price providers.
Given the breadth of this attack surface, a full review could not be completed in a short timeframe. We therefore focused on hardening the trade protocol and addressing other short-term risks that could realistically be mitigated.
In addition, we decided to merge the hotfix branch into the main branch, which already contained the work for the upcoming 1.9.23 release and was close to completion. This introduced a substantial number of additional changes and naturally requires more extensive testing — which is why this option was not initially considered. However, as the hotfix itself grew significantly in scope, the original argument no longer applied and merging became the more reasonable path. As a result, our release schedule has been delayed. We are now in the final stages and hope to begin testing and release within the next few days. We understand that this delay is frustrating for users. However, security requires discipline, and we cannot take shortcuts that could create the risk of a follow-up incident.
What did we find during the security analysis?
The main findings that could affect user funds are limited to the trade protocol. No new exploit path has been identified. That said, we discovered and addressed a number of potential issues. Based on our current understanding, none of them could have been used to directly steal funds. Some, however, could have caused transactions to become invalid, potentially leading to secondary damage and operational risk.
Wallet security
No wallet-related vulnerability has been identified. We are currently evaluating additional measures to further reduce wallet-related risk, but these would require significantly more time to implement.
While no wallet vulnerability has been found, we cannot completely exclude the possibility that undiscovered issues may exist. Because a hot wallet integrated into a P2P application inherently carries more risk than a traditional wallet, we strongly recommend that users do not keep more funds in the Bisq wallet than are necessary for active trading. This should already be standard security practice: keep savings in a hardware wallet, not in the Bisq wallet.
Other areas
Our analysis of the DAO, P2P network, and node infrastructure did not uncover any critical vulnerabilities. However, we did address several existing issues and will continue working to reduce attack surface and strengthen protective safeguards.
Some learnings
One important lesson from this work is that structural friction and layer boundaries can act as valuable security safeguards.
In Bisq 1, the maker fee transaction allocates the UTXO required by the maker for the trade. This transaction is created only through direct user action, not by network messages, and it exists outside the trade protocol itself. That separation created an important boundary and limited the maximum possible damage the exploit could cause. In the Bisq 2 MuSig protocol, we removed that extra transaction as an optimization. At the time, we viewed that as clear progress. With the learnings from this incident, we need to reconsider that assumption — or at minimum recognize that the protective boundary created by that separate layer no longer exists in the new protocol.
Security often works against intuition. Friction can be beneficial. Layer boundaries create risk boundaries.