OAK — OnChain Attack Knowledge

Worked example · 2026-05

RetoSwap / Haveno — unauthenticated ACK → arbitrator impersonation → 2-of-3 multisig instantiation hijack — 2026-05-21

Loss
~$2.7M — approximately 7,000 XMR stolen from RetoSwap users via a flaw in the Haveno trade protocol RetoSwap is built on. Because the stolen funds are Monero, a privacy coin, the proceeds are effectively untraceable — there is no realistic freeze-or-recover path, unlike the Binance/ChangeNOW or Tornado Cash trails of transparent-chain incidents.
OAK Techniques observed
OAK-T11.003 (In-Use Multisig Smart-Contract Manipulation — the canonical anchor, in its instantiation-hijack sub-shape. Each Haveno trade creates a fresh 2-of-3 multisig (maker, taker, arbitrator). The attacker hijacked the wallet during setup by impersonating the arbitrator, taking effective control of 2 of the 3 keys and thus unilateral authority over the multisig. See techniques/T11.003-multisig-contract-manipulation.md). OAK-T9.004 (Access-Control Misconfiguration — the root primitive: Haveno did not verify the source of an ACK message before treating its sender address as the official arbitrator's node, so a forged, out-of-order ACK let the attacker rebind the "arbitrator" role to an attacker-controlled onion address). OAK-T11.001 (cross-referenced — the practical effect is a signing-authority compromise of the trade multisig achieved through a protocol-message flaw rather than key theft).
Attribution
pseudonymous attacker operating over Tor (onion-service addresses). RetoSwap disclosed via X on 2026-05-21 and blocked the attacker's onion address while freezing trading within ~2 minutes via a client update. No public attribution to a named operator group; the Monero settlement layer precludes the on-chain attribution work that transparent chains permit.
Key teaching point
RetoSwap is the 2026 worked example of a multisig hijacked at instantiation via an unauthenticated control message — and a reminder that the canonical "the signatures were never the weak point" lesson applies to who the protocol believes the co-signers are, not just to the signing UI. Haveno builds each trade on a fresh 2-of-3 multisig whose third key belongs to an arbitrator; the protocol identified the arbitrator's node by the source address of an ACK message it never authenticated. By sending a fake, out-of-order ACK impersonating the arbitrator during the Tor-based wallet-setup handshake, the attacker caused the client to update the arbitrator node address to the attacker's own, so the "arbitrator" key was attacker-controlled. With 2 of 3 keys (the attacker's taker/maker position plus the captured arbitrator role), the attacker could unilaterally move funds the moment a counterparty deposited. The detection-signal locus is the protocol-message-authentication layer: any message that binds an identity or a key to a role (here, "this address is the arbitrator") must be authenticated to its claimed origin before it is trusted — an unauthenticated role-binding message is an access-control hole regardless of how sound the multisig cryptography is.

Summary

RetoSwap is an anonymous, Tor-based, peer-to-peer Monero exchange built on the Haveno trade protocol. Haveno secures each trade with a 2-of-3 multisig wallet whose keys are distributed to the maker, the taker, and a third-party arbitrator (the arbitrator key exists to resolve disputes). The trade-setup process runs over Tor and uses ACK messages to coordinate the participants' nodes.

On 2026-05-21, RetoSwap disclosed that an attacker had drained roughly 7,000 XMR (~$2.7M) from users. The mechanism, per RetoSwap's disclosure and Halborn's analysis:

  1. When the attacker took a trade, they sent a fake, out-of-order ACK message impersonating the arbitrator during the Tor-based wallet-setup handshake.
  2. Haveno did not verify the source of the ACK message before treating its sender as the official arbitrator. The client therefore updated the arbitrator's node address to the attacker's own onion address, binding the arbitrator role to the attacker.
  3. With the arbitrator role captured and the attacker's own legitimate trade position, the attacker effectively controlled 2 of the 3 multisig keys — enough to act unilaterally — and could create a compromised multisig before funds were deposited.
  4. Once a counterparty deposited XMR into the trade multisig, the attacker redirected the funds to their own account.

Because Monero is a privacy coin, the stolen XMR is infeasible to trace, freeze, or recover. RetoSwap's emergency response — blocking the attacker's onion address and freezing trading within about two minutes via a client update — limited further losses but could not reverse those already incurred. Commentary framed the incident as Haveno's re-introduction of arbitrator multisig functionality exposing an unauthenticated-message surface, and as an unaudited-dependency failure: RetoSwap users "did everything right," but inherited a flaw in the underlying Haveno protocol.

Why this is structurally significant

RetoSwap is distinct from every other May-2026 custody/multisig case in the corpus on two axes — platform and primitive — and that distinctiveness is the value:

  1. Platform: a Tor-based P2P Monero DEX, not an EVM/Safe deployment. The multisig is a Monero 2-of-3, the coordination layer is Tor onion services, and the settlement asset is a privacy coin. This stresses OAK's custody taxonomy outside its EVM-centric comfort zone and shows the same failure class (a hijacked multisig) arising from a non-EVM, non-smart-contract message-handling bug. It also makes the laundering/recovery posture categorically different: there is no transparent trail, no exchange-freeze lever, no mixer to demix — the privacy coin is the laundering.
  2. Primitive: instantiation-time hijack via unauthenticated role-binding. Where Superfortune (examples/2026-05-superfortune-gua-multisig-destination-tampering.md) diverted a signed transaction's destination, and SquidRouterModule (examples/2026-05-squidroutermodule-safe-module-constant-string-authorization.md) abused an enabled module to bypass the threshold, RetoSwap corrupts the multisig's membership at creation: the attacker is installed as one of the keyholders (via the captured arbitrator role) before the wallet is even funded. The cryptography is sound — the 2-of-3 works exactly as designed — but the protocol bound a key to an identity on the strength of an unauthenticated message.

The unifying thread across Superfortune, SquidRouterModule, and RetoSwap is that multisig security depends on the integrity of everything around the signature: the destination, the delegated modules, and the membership. RetoSwap is the membership-integrity case, and its specific lesson — authenticate any message that binds an identity or key to a privileged role — is a clean, generalisable access-control rule. An ACK that says "this onion address is the arbitrator" is a role-binding assertion; trusting it unauthenticated is the same category of error as accepting a cross-chain message without verifying its origin (CrossCurve) or a Safe-module call authorised by a public constant (SquidRouterModule).

Timeline (UTC)

When Event OAK ref
Pre-2026-05-21 Haveno secures each trade with a fresh 2-of-3 multisig (maker / taker / arbitrator); the trade-setup handshake runs over Tor and uses ACK messages; the arbitrator node is identified by the source address of an ACK that is not authenticated to its claimed origin (standing T9.004 / T11.003 surface)
2026-05-21 Attacker takes a trade and sends a fake, out-of-order ACK impersonating the arbitrator; Haveno updates the arbitrator node address to the attacker's onion address T9.004 (unauthenticated role-binding message)
2026-05-21 With the arbitrator role captured plus the attacker's own trade position, the attacker controls 2 of 3 keys and creates a compromised multisig before funds are deposited T11.003 (multisig instantiation hijack)
2026-05-21 A counterparty deposits XMR into the trade multisig; the attacker redirects the funds to their own account; repeated across fake trades for 7,000 XMR ($2.7M) T5 outflow
2026-05-21 RetoSwap discloses via X; blocks the attacker's onion address and freezes trading within ~2 minutes via a client update (operator response)
Post-2026-05-21 Monero settlement renders the proceeds untraceable; Halborn publishes a root-cause explainer (forensic surface — recovery infeasible)

What defenders observed

  • Pre-event (message-authentication layer): the Haveno trade protocol bound the arbitrator role to the source address of an ACK message it did not authenticate. Defender lesson: any protocol message that assigns or changes a privileged role / keyholder must be authenticated to its claimed origin (signed by the genuine arbitrator's key, validated against a pinned identity) before it is acted upon. An unauthenticated role-binding message is an access-control vulnerability independent of the multisig's cryptographic soundness.
  • At-event (handshake signal): an out-of-order / unexpected ACK that rebinds the arbitrator node mid-setup is an anomalous control-flow event. A client that enforced ACK ordering and required arbitrator messages to be signed by the arbitrator's known key would have rejected the forged ACK. The hijack happened before funding, so the actionable detection point is the setup handshake, not the fund-movement step.
  • At-event (recovery posture): the settlement asset is Monero. There is no transparent trail to trace, no exchange deposit address to freeze, and no mixer output to correlate — the privacy coin removes the entire post-event recovery toolkit that transparent-chain incidents rely on. This raises the premium on prevention and on fast client-side circuit-breaking.
  • Post-event (containment): RetoSwap froze trading within ~2 minutes via a client update and blocked the attacker's onion address — a fast operator response that capped further losses even though it could not reverse completed thefts. Rapid client-side kill-switches are the main available mitigation when on-chain recovery is impossible.

What this example tells contributors writing future Technique pages

  • T11.003 should cover the instantiation-hijack sub-shape, not only in-use manipulation. Corrupting a multisig's membership at creation (installing the attacker as a keyholder via a spoofed role-binding) is mechanically distinct from manipulating an already-deployed multisig contract, but it produces the same outcome (attacker controls the threshold). Record "multisig hijacked at instantiation via unauthenticated role assignment" as a sub-shape.
  • "Authenticate role-binding messages" is the generalisable access-control rule. The defect is a T9.004 message-authentication gap (the ACK's source was trusted unverified). Contributors should record, for any multi-party protocol, which messages assign identities/keys to roles and whether those messages are authenticated — it is the predictive field for this class.
  • Privacy-coin settlement changes the impact and mitigation profile. When the asset is Monero (or another privacy coin), record that on-chain tracing/freeze/recovery is infeasible and that the available mitigations collapse to prevention + fast client-side circuit-breaking. This is a distinct recovery-posture field from transparent-chain incidents.
  • "Unaudited dependency" / inherited-protocol risk is recordable. RetoSwap users were exposed through a flaw in the underlying Haveno protocol, not in RetoSwap's own additions. The trust boundary is the dependency; record inherited-protocol/dependency risk as a distinct surface (adjacent to T15.002 supply-chain reasoning, though here it is protocol logic rather than a poisoned build).

Public references

Discussion

RetoSwap rounds out the May-2026 multisig-custody trio — Superfortune (destination integrity), SquidRouterModule (delegated-module authority), RetoSwap (membership integrity at instantiation) — and is the one that pushes the corpus furthest from its EVM defaults: a Tor-based P2P Monero DEX whose 2-of-3 trade multisig was hijacked not by stealing a key or forging a signature, but by handing the attacker a key through an unauthenticated role-binding message. The cryptography did exactly what it was supposed to; the protocol simply believed an unverified ACK about who the arbitrator was.

The case's two durable lessons are general. First, authenticate any message that assigns an identity or key to a privileged role — the ACK-source-trust failure is the same access-control category as accepting an unverified cross-chain message origin or a public-constant authorization, and it belongs in every multi-party-protocol threat model. Second, privacy-coin settlement inverts the recovery calculus: with Monero there is no trail to follow, no address to freeze, and no mixer to demix, so the only defenses that matter are prevention (authenticated handshakes, ACK ordering, pinned arbitrator keys) and fast client-side circuit-breaking — which RetoSwap demonstrated by freezing trading within two minutes, capping the damage even though the ~7,000 XMR already taken were gone for good.

Techniques demonstrated (3)