**Bisq Protocol Exploit Update**
This is a brief update on what we have learned so far, the current state of reimbursement planning for affected users, and some broader observations about the growing role of AI-assisted attacks.
**Estimated impact**
Based on preliminary estimates from data analysis and reports from affected users, the total amount stolen appears to be approximately **11 BTC**.
The attacker used a **0.001 BTC** multisig output together with an unusually high **10,000 sat** miner fee in the reported transactions. That combination created a recognizable transaction fingerprint, which helped identify suspicious transactions within the time window in which the attack occurred.
So far only Altcoin trades have been reported.
This remains a preliminary estimate. The final amount may change as additional reports are reviewed.
**How are victims getting reimbursed?**
We are currently discussing several reimbursement options. Our goal is to enable **fast and complete reimbursement with minimal friction for victims**.
There are, however, practical constraints:
• **Protocol constraints**: victims must open arbitration cases. Arbitration can only be opened after a time lock of **10 days for altcoin trades** and **20 days for fiat trades**.
• **DAO constraints**: the DAO has limits on how much can be issued per DAO cycle.
• **DAO governance**: the proposal for the reimbursement has to be confirmed by the DAO via voting. The current DAO cycle will end around 25th of May.
The current intention is to allow victims to choose between reimbursement in **Bitcoin** or **BSQ**.
At this stage we cannot make a final commitment on the exact mechanism, but we wanted to share our intentions.
For Bisq users — whether affected directly or not — discussion is ongoing in the **Matrix channel**: (
You're invited to talk on Matrix
You're invited to talk on Matrix
And on **GitHub**: (
GitHub
Reimbursement options for victims of the May 1 exploit · bisq-network/bisq · Discussion #7628
We are currently evaluating several reimbursement options. Our goal is to provide fast, full reimbursement with as little friction as possible for ...
The final reimbursement model will be submitted as a **DAO proposal for voting**.
The exploit caused a significant challenge for both Bisq and the DAO, but we are confident it is manageable. It was serious, but it was not a fatal blow.
**How did the exploit happen?**
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 amount — which includes the miner fee for the payout transaction — the negative value reduced the multisig amount to **0.001 BTC**, while the remaining funds were redirected to the taker’s change output.
Unfortunately, the taker change output was a leftover from older protocol versions. It had already been identified as something that should be removed, but that cleanup had unfortunately not happened.
**Was it an AI-assisted attack?**
We cannot answer that with certainty. However, based on our own experience during the investigation, we think it is likely.
After the issue was discovered, one group of developers started manual code inspection to understand how the exploit could have happened.
A second group used AI-assisted analysis.
The AI-assisted group was faster and identified the exploit path in a relatively short time.
The first AI-generated attempt turned out to be a false positive, but a second attempt by another developer successfully reproduced the exploit. It also produced both an attack patch and a corresponding fix.
AI tools include safeguards, so simply asking them to identify an exploit will usually not work.
However, with enough context, careful prompting, and a degree of social engineering of the model, those safeguards can be bypassed.
Based on our experience, it is reasonable to assume that the attacker may have followed a similar path.
**A warning shot**
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 actively using AI tools ourselves to search for failure modes.
We are particularly focused 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**.
We also hope this serves as a useful warning to other projects in the space.
If our experience helps others identify similar risks earlier and strengthen their defenses, something positive may still come out of it.
**Release plans**
We have already fixed the immediate vulnerability and are currently working on additional hardening for a hotfix release.
We expect to publish that release in the coming days.
After that, we will continue with a follow-up release focused on further hardening, broader review, and additional security auditing.
This release mainly addresses concerns about the overly restrictive trade amount limits introduced in the previous release and fixes a bug affecting BSQ swap trades.
## Release notes
### Trading
- Maximum trade limits were increased to 0.250 BTC.
- The risk-based reduction factors for the 4 risk classes were changed from `1, 2, 4, 8` to `1, 2, 3, 4`. This results in trade limits of up to 0.250 BTC for Altcoins and up to 0.0625 BTC for higher-risk fiat payment methods such as SEPA or Zelle.
- Fixed a bug in BSQ swap fee validation and added additional validation checks.
- Trade statistics validation was adjusted for the reduced trade limits introduced in the previous release.
### UX And Settings
- Updated the user agreement.
- Trade rules are now shown when users create or take an offer for the first time.
- Trade rules and the user agreement are now available from Settings → About.
- The cold-storage reminder threshold is now configurable in preferences.
### Release Process
- Debian package dependency generation now relaxes `t64` dependencies while preserving the original constraint or qualifier on the non-`t64` alternative.
See full release notes at: 
Running a full P2P app over Tor on mobile is challenging. Android supports Java, iOS does not, so we built two approaches:
• **Bisq Easy Mobile (Android)**: full node with complete P2P stack.
Same privacy and security as desktop, no extra infrastructure.
Trade-offs: Android only, higher resource usage, background connectivity issues, no desktop sync, backups required.
Want to help shape Bisq’s future?
Join us in Matrix at: