In May 2026, RetoSwap’s users were the victims of a $2.7 million hack. The attacker exploited vulnerabilities in the Haveno trading protocol that the platform used to hijack multisig wallets during the wallet creation process.
Inside the Attack
RetoSwap uses Haveno’s trade protocol to create multisig wallets to secure trades of Monero. When a trade is initiated, a 2-of-3 multisig wallet is created, with keys being distributed to the maker, taker, and a third-party arbitrator. Under normal circumstances, the maker and taker can approve the transaction themselves. The arbitrator is only actively involved in the event of a dispute, but they have several tasks that are completed automatically throughout the trade setup process.
The attacker took advantage of a flaw in how Haveno managed ACK messages within its Tor-based wallet setup process. They created a trade as a taker or maker, granting them legitimate access to one of the three keys within the multisig wallet.
Then, they sent a spoofed ACK message that was designed to look like it originated from the platform’s arbitrator. The platform accepted this message without validation and registered the sender’s address as the official arbitrator for the trade. This registered their own key as a second signing key for the wallet.
With two keys, the attacker could unilaterally perform transactions on behalf of the multisig wallet. Once a third party deposited funds into the wallet (as the open maker/taker role), the attacker could redirect them to the attacker’s account.
In total, they stole an estimated $2.7 million from RetoSwap users via these fake trades. Additionally, since the stolen currency was in Monero — a privacy cryptocurrency — it's infeasible to trace the stolen tokens and attempt to freeze or retrieve them.
Lessons Learned from the Attack
The RetoSwap hack was made possible by a supply chain vulnerability. The issue wasn’t in the platform's code; it was how Haveno handled authentication messages while setting up the multisig wallets used to secure trades. The attacker could impersonate the arbitrator because the protocol didn’t verify the source of an ACK message before labeling its source address as the official arbitrator.
This type of business logic error can be difficult to identify because it’s not caused by a vulnerable code pattern that a scanner can pick up. Instead, detecting these issues requires a comprehensive security audit that considers both code intent and implementation. For help with protecting your project, get in touch.