Architecture as Defense: Why the RetoSwap Exploit Can't Happen on BasicSwap
On May 20, 2026, at 2:31 UTC, Haveno lead developer, Woodser, disclosed on Matrix that the protocol was being actively exploited. Two minutes later, at 2:33 UTC, RetoSwap, the most prominent active deployment of the Haveno trade protocol, halted trading by raising the minimum client version to 2.0.0 through the network's filter feature, and blacklisted the attacker's onion address. Reported losses are approximately 7,000 XMR (~$2.7M USD), confined to large crypto-to-crypto trades; fiat trades were unaffected.
The disclosed root cause, as relayed in the RetoSwap statement quoting Haveno lead developer Woodser:
When the attacker took a trade, they sent a fake, out-of-order ACK message impersonating the arbitrator, causing the software to update the arbitrator's node address to their own, allowing them to create a compromised multisig wallet before funds were deposited.
That class of attack is not possible against BasicSwap. The reason is architectural, not incidental. This post walks through why, and what it says about how DEXs should be built.
Two trust models, side by side
A trade on Haveno and a trade on BasicSwap are not the same kind of thing. They lock funds differently, authenticate messages differently, and depend on different parties for safety.
The Haveno / RetoSwap model
Each trade creates a fresh 2-of-3 multisig, with one key each held by the maker, the taker, and a trade arbitrator. From the official Haveno trade protocol documentation:
the 3 keys are distributed one each to the two traders and one to the arbitrator.
In the happy path the two traders cooperate and the arbitrator never signs. If a dispute arises, the arbitrator signs with one of the traders. The arbitrator is therefore a privileged role inside the protocol: their identity and node address are part of the in-flight trade state that the client must track and trust.
Separately, network-wide policy (which offers are visible, which payment methods are allowed, which onion addresses are blacklisted, what the minimum client version is) is controlled by signed messages from keypairs with developer privileges. From the Haveno mainnet deployment guide:
Keypairs with developer privileges are able to set the network's filter object, which can filter out offers, onions, currencies, payment methods, etc.
Correctness of a Haveno trade depends on five things: the counterparty behaving honestly, the arbitrator behaving honestly if disputes arise, the protocol correctly authenticating which messages do or do not come from the arbitrator, the seed nodes serving accurate network state, and the holders of developer signing keys exercising them responsibly. The May 20 exploit landed on the third one.
The BasicSwap model
There is no arbitrator role. There is no third key.
Funds lock directly between maker and taker. On scripted chains (BTC, LTC, DASH, DCR, FIRO, NMC, PIVX) the lock is a Hashed Time-Locked Contract; on chains without a useful scripting layer (XMR, WOW, PART_ANON, plus DOGE, BCH, FIRO when paired with one of those) the swap is enforced by adaptor signatures, with the scriptless coin held in a split-key output. Refund branches are pre-signed and timelock-enforced before any funds move. The blockchains validate and finalize the swap.
Generate secret s
compute h = SHA256(s)
Lock 1 BTC in HTLC
HTLC(h, Alice, Bob) · longer timelock
Audit Alice's BTC HTLC
verifies h, amount, pubkeys, timelock
Lock 80 LTC in HTLC
HTLC(h, Bob, Alice) · shorter timelock
Audit Bob's LTC HTLC
verifies same h, amount, pubkeys, timelock
Redeem LTC, reveal s
secret is now publicly visible on the Litecoin chain
Extract s from LTC chain
reads Alice's redeem transaction
Redeem BTC using s
before Alice's longer timelock expires
Unhappy path
If either party stops responding, the unspent funds refund themselves after the script timelocks expire. Bob's LTC refunds first (shorter timelock), then Alice's BTC. No third party intervenes.
Correctness of a BasicSwap trade depends on the soundness of the cryptography and the user's own key custody. Nothing else.
Why arbitrators exist in the first place
The arbitrator role in Haveno is not a careless addition. It exists for a specific reason rooted in Haveno's parent project, Bisq.
Bisq has been operating since 2014 as an open-source peer-to-peer exchange whose primary purpose is fiat-to-crypto trading: bank transfers, cash deposits, SEPA, Wise, Revolut, dozens of national payment methods. Fiat settlement is, by definition, off-chain. A SEPA transfer that lands in a German bank account is not visible to the Bitcoin blockchain. If the BTC seller sends their coins to a multisig and the buyer claims they sent the EUR, the protocol cannot independently verify that the EUR ever arrived. Without some entity able to step in, either side can grief the other indefinitely.
That is what the arbitrator is for. The 2-of-3 multisig with an arbitrator key exists so that, in the case of a dispute over an off-chain fiat payment, the arbitrator can sign with one of the two traders to release funds, judging by chat logs, screenshots, and bank statements submitted as evidence. The arbitrator never has custody in the happy path; they hold one key out of three. But their existence is structurally required for the protocol to support fiat at all.
Haveno forked Bisq to focus on Monero pairs and carried that architecture forward unchanged. Even pure crypto-to-crypto trades on Haveno still flow through the same 2-of-3 multisig with the same arbitrator role, because the protocol is one protocol. There is no separate code path for crypto-crypto that bypasses the arbitrator.
BasicSwap took a different starting point. It does not support fiat. It is, by design, a crypto-to-crypto rendezvous protocol. And crypto-to-crypto trades have a property fiat trades do not: every step is verifiable on a public blockchain. A swap that requires Alice to send BTC and Bob to send LTC can be settled with an atomic swap, where the cryptography itself guarantees that either both transfers complete or both refund within a bounded time. No arbitrator needs to exist, because there is no off-chain step for them to adjudicate. Atomic-swap atomicity is the dispute mechanism.
That is the structural difference. The exploit on RetoSwap was, at root, an exploit of the role that exists to handle fiat disputes, a role BasicSwap removed by removing fiat from scope.
How the fake-ACK exploit works on Haveno
Start with what a normal Haveno trade does under the hood. When a taker takes an offer, the maker, the taker, and an arbitrator selected from the registered set begin a multi-message protocol whose end goal is a funded 2-of-3 multisig with one key per participant. Along the way, each side sends acknowledgement messages (ACKs) to confirm receipt of each step. ACKs drive the state machine forward: when the right ACK arrives, the client knows the previous step was received by the right party and can move on.
The vulnerability lay in how a particular ACK was authenticated. Based on the public disclosure, the attack ran roughly like this:
- The attacker takes a trade. They control the taker side legitimately.
- Before the legitimate arbitrator-selection handshake completes, the attacker sends an ACK message that arrives out of the expected order and claims to originate from the trade's arbitrator.
- The client accepts the message without strictly verifying that it was signed by the actual arbitrator's onion identity at the actual step the protocol was on. It updates the arbitrator's stored node address to a value the attacker controls.
- The remainder of the multisig setup proceeds against that substituted address. When the public keys for the 3-of-3 keyset are gathered, the "arbitrator" key in the multisig is the attacker's, not the legitimate arbitrator's. The 2-of-3 multisig that receives the trade funds is
(maker, taker_attacker, arbitrator_attacker). - The attacker now holds two of the three keys: their taker key and the substituted arbitrator key. Two of three is exactly the threshold the multisig requires. They sign with both keys, broadcast the spend, and the trade is drained.
The vector is tight because it requires no collusion. The attacker does not need to compromise a legitimate arbitrator, social-engineer a developer, or persuade a counterparty to cooperate. They only need to act as taker on their own trade and forge one message at one moment in the setup sequence. The protocol does the rest.
The root cause is straightforward: the protocol granted state-altering authority to a message whose origin it could not strictly verify against the expected protocol state. That is the entire class of failure. It is not a Haveno-specific bug. It is a vulnerability inherent to any architecture where a privileged third party's identity is part of the in-flight trade state, and where any message can flip a bit that determines whose key ends up in the lock.
Why this class of attack cannot land on BasicSwap
Five concrete reasons, each grounded in the code or the protocol papers.
1. There is no arbitrator to impersonate
The BasicSwap state machine has no arbitrator role, no mediator role, no escrow role. There is no node address in trade state that a forged message could rewrite, because no such address exists in trade state to begin with.
2. No message rewrites whose key goes into the lock
The BasicSwap protocol carries a small number of message types over SMSG: offer, bid, accept, lock-signature, secret reveal, refund. Each is a complete cryptographic artifact: a signature, a transaction, a key reveal. None of them is a control signal whose effect depends on which named role the sender claims to occupy.
A swap step either produces valid cryptographic input that the underlying blockchain accepts, or it does not. There is no equivalent of an "I am the arbitrator, please update my address" message, because there is no arbitrator role and no per-trade address to update.
3. Every SMSG message is end-to-end encrypted and authenticated
The Secure Messaging network (SMSG) underneath BasicSwap was designed to make message forgery infeasible. Each message uses ECDH over secp256k1 to establish a shared secret with the intended recipient. Payloads are encrypted with AES-256-CBC, and a HMAC-SHA256 tag authenticates the ciphertext. Authenticated messages carry the sender's address and an ECDSA signature in the payload header; even decrypted, a message has no validity unless that signature matches the claimed sender's public key.
SMSG is not delivered through a central relay either. It is a gossip mesh: every BasicSwap node automatically participates, every message propagates peer-to-peer across the network, and messages are stored in 1-hour time buckets. Free messages default to a 2-day retention and can be requested for up to 14 days; paid messages, which carry an on-chain funding transaction, can be stored for up to 31 days. There is no SMSG server to compromise and no central inbox to phish. Bootstrap seed nodes exist for peer discovery (as they do in Bitcoin), but once a node has peers, message delivery is mesh-wide and does not flow through them. Anti-spam comes from proof-of-work and on-chain fees, not from rate-limiting at a central point. The network's resilience is the same kind the underlying blockchains have.
A spoofed message therefore has two layers to defeat. It must either decrypt successfully under the attacker's chosen key (infeasible without knowing the recipient's private key) or carry a valid signature over forged content (infeasible without knowing the claimed sender's private key). BasicSwap never holds, sees, or transmits user private keys, so neither layer is available to any third party.
4. The lock script names only the two traders' keys
On scripted chains, the lock that holds the funds during an HTLC swap is a script with two spending paths: one that releases the coins to the taker if they supply the secret, and one that returns them to the maker after a timelock. Two public keys appear in it, the maker's and the taker's. There is no third slot for anyone else.
For chains without a usable scripting layer, BasicSwap uses an adaptor-signature scheme instead. The two coins are locked differently: the scripted coin in a 2-of-2 multisig requiring both traders' signatures, the scriptless coin in a split-key output whose spend key is the sum of their two key-halves. Atomicity is enforced by the cryptography of the signatures themselves rather than by an on-chain contract. Again, no third key.
Both flows are easier to follow with a concrete example. Suppose Alice wants 1 BTC for 80 LTC and Bob wants the other side. They agree on rate and amounts via offer and bid messages on SMSG.
HTLC flow (BTC ↔ LTC). Alice generates a random secret and computes its hash. She publishes a Bitcoin transaction locking 1 BTC into the HTLC script above, using that hash, her own public key, and Bob's. Bob waits for Alice's lock to confirm, verifies the script matches what they agreed, and publishes a mirror-image Litecoin transaction with the same hash and the roles swapped: Bob's key in the maker slot, Alice's in the taker slot. Alice spends Bob's Litecoin lock by revealing the secret on the Litecoin chain. Bob reads the secret off the Litecoin chain and uses it to spend Alice's Bitcoin lock. At every step, only the two traders' public keys appear in either lock. If Alice never reveals the secret, Bob's refund branch reclaims his LTC after the timelock, and Alice's longer timelock reclaims her BTC afterward. Either both spends complete, or both refunds do.
Adaptor-signature flow (BTC ↔ XMR). Monero has no useful script layer, so the HTLC approach does not apply. Instead, the swap relies on adaptor signatures, with pre-signed refund transactions exchanged before any money moves. The pre-signed refunds are the cryptographic equivalent of signing the divorce papers before the wedding: necessary now in case either party walks away later, useless until they do.
Alice and Bob each generate two private keys, one for each chain, and exchange the corresponding public keys. Alice publishes a Bitcoin transaction locking 1 BTC into a 2-of-2 multisig requiring both her signature and Bob's. Bob publishes a Monero transaction to a split-key output whose spend key is the sum of their two Monero key-halves.
Now the clever part. Alice signs the spend of her Bitcoin lock, then hands Bob that signature in encrypted form: an adaptor signature (BasicSwap uses the ECDSA variant, a one-time verifiably encrypted signature) locked to Bob's Monero key-half. Bob decrypts it with his Monero key-half, adds his own signature, and broadcasts the Bitcoin spend to claim the BTC. The plaintext signature is now on the Bitcoin chain. Alice reads it off the chain, recovers Bob's Monero key-half from it, combines it with her own, and spends the Monero lock to claim the XMR.
Only Alice's and Bob's keys ever appear in the Bitcoin lock. Only Alice's and Bob's keys ever appear in the Monero lock. There is no third party at any step. Atomicity comes from the cryptographic link between the adaptor and Bob's Monero key-half: the moment Bob's spend signature lands on Bitcoin, Alice's path to spend Monero exists as a matter of math, not of trust. Refunds, if anyone walks away, are exactly the pre-signed transactions both parties already hold.
For a more thorough treatment of both flows, see our earlier post HTLC vs Adaptor Signature Swaps in BasicSwap. The point that matters here is simpler: at no step in either flow does a third key, third role, or third party have authority over the funds. The lock cannot be drained from outside, because the outside has nothing to drain with.
Setup · off-chain
Alice and Bob exchange public keys (with DLEAG proofs that one key works across both curves) and pre-sign mutual refund transactions
Lock 1 BTC in 2-of-2
multisig over (Alice, Bob) Bitcoin keys
Audit Alice's BTC lock
verifies amount, pubkeys, lock script
Lock 1 XMR to a split-key output
spend key = sum of Alice's and Bob's Monero key-halves
Audit Bob's XMR lock
verifies amount and combined-key construction
Send encrypted signature (OtVES)
her Bitcoin-spend signature, encrypted under Bob's Monero key-half
Decrypt the signature, publish the Bitcoin spend
Bob receives 1 BTC; the plaintext signature is now on the Bitcoin chain
Recover key-half, spend the Monero lock
reads the on-chain signature, recovers Bob's Monero key-half, combines both, receives 1 XMR
Unhappy path
If Bob never publishes the Bitcoin spend, or either party walks away, the refund transactions pre-signed during setup return the funds to their original owners after the lock timelocks expire. No third party intervenes.
5. BasicSwap itself signs nothing
Signing happens locally, against the user's own core wallet, against the user's own keys. The BasicSwap process has no signing authority of its own, no custodial address, no escrow account, no recovery key. From the BasicSwap terms, §02:
BasicSwap is a decentralized messaging protocol. It facilitates atomic swaps. It does not perform them. ... BasicSwap does not hold funds, generate wallets, or store private keys. Core wallets do.
No third party can drain a trade because no third party has anything to drain with. BasicSwap puts two people in touch and helps them exchange instructions; the underlying blockchains do the rest.
Atomic swaps beat every form of intermediary
The RetoSwap exploit is one data point. Across cross-chain designs more broadly, the protocols that get drained are the ones that hold funds or hold authority over funds. The protocols that survive every cycle are the ones that do neither.
Centralized exchanges
Full custody, full counterparty risk, full censorship surface. The historical worst case: FTX collapsed in November 2022 with roughly $8B in customer funds inaccessible. Celsius filed for bankruptcy in July 2022 owing customers around $4.7B. Mt. Gox lost approximately 850,000 BTC in 2014. None of those failures were cryptographic. All of them were custodial.
Pooled-vault cross-chain protocols (Thorchain and similar)
Often called "DEXs," but architecturally these protocols take custody of user funds during a swap. Thorchain routes deposits into Asgard vaults controlled by a threshold-signature scheme (GG20 TSS) shared across bonded validator nodes. No single validator holds the key, but the protocol holds the funds. That custody surface has been exploited more than once:
| Date | Loss | Root cause | Source |
|---|---|---|---|
| July 2021 | ~$16M | Bifrost ETH router incorrectly trusted msg.value instead of verifying actual deposits | Halborn analysis |
| May 2026 | ~$10.7M | A validator that joined two days earlier accumulated partial GG20 key material across signing ceremonies and reconstructed a vault key | CryptoTimes coverage |
The Thorchain Asgard breach landed less than a week before the RetoSwap one. Two different "DEXs," two different intermediary models (pooled TSS vaults on one side, per-trade 2-of-3 arbitrator multisig on the other), two different exploits inside seven days. Both rooted in the same category mistake: letting any party other than the two traders hold authority over the funds.
Thorchain is one instance of a wider pattern. Cross-chain bridges that pool user deposits into validator-controlled or admin-controlled vaults have collectively lost more than a billion dollars to exploits in recent years:
| Date | Bridge | Loss | Root cause |
|---|---|---|---|
| February 2022 | Wormhole | ~$325M | Signature verification bypass on the Solana side let an attacker mint wrapped ETH with no real backing (CertiK incident analysis) |
| March 2022 | Ronin | ~$625M | Five of nine validator keys compromised through a social-engineering chain (Halborn analysis) |
| August 2022 | Nomad | ~$190M | A single fraudulent message in an upgraded replica contract let anyone "prove" any transfer (Nomad root-cause analysis) |
Different protocols, different specific bugs, the same architectural shape: pooled deposits sitting behind a small set of validator keys or signers, drained at once when the set is compromised or the verification logic fails. The total dollars lost are larger than the entire treasury of most centralized exchanges that ever collapsed. The blockchains themselves remained perfectly secure throughout each incident. What failed was the layer of human-administered authority bolted on top of them.
Arbitrator-based DEXs (Haveno, RetoSwap, Bisq)
Non-custodial in the happy path, but the happy path itself is never something a trader can verify in advance. When you take a trade, you have no way to prove that your counterparty does not also control the arbitrator key, no way to prove the arbitrator has not been compromised by an outside party, and no way to prove the two are not silently colluding. Unless you personally know the other swapper, "happy path" is a hope, not a guarantee.
Beyond that per-trade question, the network is governed by privileged signing keys whose existence is documented in the projects' own deployment guides. Any of the following can alter user-visible state: a compromised arbitrator, a flaw in arbitrator-message authentication (the May 20 exploit, where one party effectively became both counterparty and arbitrator), an unsigned-message-acceptance bug, or misuse of the filter-signing keys. The exploit demonstrated that the second is not hypothetical.
The same central control shows up in the aftermath. In the days after the exploit, RetoSwap adjusted trade fees network-wide to help affected traders recover: maker fees left untouched, crypto taker fees raised to 0.8%, fiat taker fees to 2%, with affected makers directed to reach out to admins through in-app chat. That is a humane response to a bad situation. It is also only possible because a party exists that can change the network's economic terms for everyone and coordinate a recovery, which is the kind of authority BasicSwap has no place for.
Atomic-swap rendezvous protocols (BasicSwap)
Non-custodial throughout. Funds never enter a pooled vault. They never get bridged into a wrapped representation on another chain. They never pass through a contract that includes any party other than the two traders. They lock on the native chain, settle on the native chain, and at no moment in the swap (not for a block, not for a second) does custody pass to a protocol, a validator set, or an arbitrator. No governance signing keys with network-altering authority. No role that can be impersonated to compromise a trade. Once a swap is broadcast onto the underlying chains, no third party can pause it, censor it, freeze it, or reverse it — not even the contributors who wrote the software, because BasicSwap is a decentralized messaging protocol, not an operator. No single party can blacklist an address. No middleman can push an update to a node without the node operator choosing to install it.
The underlying argument is one this blog has made before, in different forms:
- The DEX Revolution — The Evolution of Atomic Swaps, on why atomic swaps are the right architecture for decentralized exchange.
- HTLC vs Adaptor Signature Swaps in BasicSwap, on the cryptographic guarantees of each primitive.
What changed on May 20 is that one of the alternatives walked into the failure mode this blog has been describing.
What this means going forward
No software is bug-free. BasicSwap can have implementation bugs. Its dependencies (coin cores, libraries, the underlying chains themselves) can have bugs. The project's own terms page lists those risks in §07, and they are real.
What BasicSwap cannot have is a trust failure, because no third party, no single party, no middleman has any authority the system depends on. The architectural principle is straightforward: eliminate the trusted role rather than secure it. Security through structure, not through vigilance.
The running network continues to operate even if every current contributor stops contributing. That is what "no central point of failure" means in practice. No protocol fees. No KYC. No account. Run your own node, hold your own keys, settle peer to peer on the chains you already trust.
Stay Connected
Stay connected with us on our social media channels for real-time updates, news, and more.
- Twitter: @basicswapdex
- Matrix: BasicSwap channel
- GitHub: BasicSwap repositories
- Support the project: Donation page
BasicSwap Team
The official team behind BasicSwap. We're a group of passionate contributors dedicated to making atomic swap technology ubiquitous by creating accessible, user-friendly solutions for everyone.
Related Posts
Welcome to the BasicSwap DEX Blog — MDX Showcase
By Cryptoguard on May 23, 2025
Explore the powerful capabilities of BasicSwap's new MDX blog platform.
The DEX Revolution — Atomic Swaps and Web Access Gateways
By Cangrejo on July 13, 2023
Exploring considerations on BasicSwap and its future integrations into alternative access gateways.
The DEX Revolution — The Evolution of Atomic Swaps
By Cangrejo on June 29, 2023
Making atomic swaps more accessible and private than ever before.