**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**: (
And on **GitHub**: (
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.
You're invited to talk on Matrix
You're invited to talk on Matrix
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 ...
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: 
This update brings critical improvements for more reliable message delivery and bugfixes in the trade process. Please upgrade ASAP to benefit from enhanced resilience and stability.
✨ New features
- A splitpane to calibrate sizes between offerbook chat and offer list has been added.
- Official Bisq mediators and moderators can now be identified by the badge next to their nickname.
🔧 Improvements
- The Bisq Easy protocol has been enhanced to protect against triangular scams. Now, when the buyer does the Fiat transfer, trade ID must be set as "Reason for payment".
- Splash screen now shows the loading progress for each required step: Starting Tor, publishing onion service, connection to P2P network and, finally, data inventory request.
📬 Message delivery improvements
- Send message as mailbox message in case no connection to the peer is yet established, which speeds up message delivery and provides better resilience.
- Send mailbox message in case the node associated with the user profile has not yet published it's onion service. This case could happen specially with multiple user profiles and if Tor is slow/unstable.
🔄 Trade process improvements
- Allow multiple takers to take the same offer of a maker who is offline. Before only the first take offer message was successfully processed and the remaining led to a failure when the maker went online.
- Add new version for trade ID creation, including the take offer date. This allows that an offer can be taken by the same taker multiple times. This will get activated with June 1st.
⚖️ Mediation improvements
- Add support for message delivery status with multiple peers in case of mediation.
- Add new version for mediator selection which includes the offer ID. Now the same pair of traders would always get the same mediator selected. This will get activated with June 1st.
- Add mediation case details popup (for mediators)
- Add "remove mediation case" button (for mediators)
🐛 Bug Fixes
- Fixed bug with trade messages arriving out or order, which led to failed or stuck trades.
- Fixed several issues related to mediation and the mediation request process.
- Fixed bug preventing from taking new offers.
✅ Download from inside your current Bisq 2 app or from Github:
👉 
⚠️ Security update
- To enhance security for buyers, sellers must have sufficient reputation to secure a trade for the specified amount. The required reputation score is determined using the following formula:
Reputation score = max. selling amount * 200
For a minimum trade amount of 6 USD, the required reputation score would be 1200, which can be achieved through any of the following methods:
• Burn 12 BSQ (approximately 25 USD).
• Lock 120 BSQ as a bond for approximately one year.
• Have a Bisq v1 signed account for at least 120 days.
• Have a Bisq v1 account age of at least 280 days.
BSQ can be purchased with Bisq 1.
For more details, visit the Bisq reputation system Wiki:
- To improve on privacy, sensitive trade data will be automatically deleted after a certain period of time. This can be adjusted in Settings > Offer and trade.
- See trade details in the trade process window by clicking on the "Show details" button.
🔧 Improvements
- The create offer wizard has been consolidated into three steps to improve quickness and ease of use. You can choose the amount and price in the same screen and see the BTC conversion display.
🐛 Bug Fixes
- Fixed reputation display at start up.
- Resolved issues during the trade process with peer messages not being processed correctly, and other bugs.
See all changes in this release:
Trades up to 25 USD no longer require sellers to have reputation, with higher amounts becoming available as sellers establish and increase their reputation scores.
This change makes it easier for new sellers to get started and should increase small trade liquidity.
The multiple, topic-specific chat rooms found in previous versions have now been consolidated into Chat and Support sections, with both public discussions and private chats being brought together under a single screen.
