Haveno

Haveno is the decentralised P2P XMR / fiat exchange platform — the Monero-native successor to Bisq, built on Tor with on-chain multisig escrow, no central operator, and no KYC. Listed at Grade A- following two protocol-level exploits in the same class (2026-05-20 and 2026-06-24) and the v1.8.0 hardening release (2026-06-20) that closes the underlying signature-verification gap — see the Incident section below before opening any new trades. The structural privacy posture (P2P, Tor-only, multisig, non-custodial) remains the strongest in the swap category, but the exploit demonstrated a real protocol-level attack surface in the multisig flow.

Background. Haveno is the open-source protocol, primarily authored by woodser (the lead developer who has been the public face of the project since the Bisq fork). Haveno itself doesn't operate a network — it's software you install (desktop client for Linux / macOS / Windows) that connects to one of several independent, community-run networks with their own arbitrators and seed nodes. The notable operators include Haveno-Reto / RetoSwap (haveno-reto.com, retoswap.com — the highest-liquidity public network) and a small handful of others. Each network can set its own arbitrator policies, payment-method whitelists, and fees. Liquidity is concentrated on Haveno-Reto / RetoSwap. Code at github.com/haveno-dex/haveno.

What you trust. Architecture: Tor-only transport between peers; non-custodial wallet (Monero, multisig); the user holds their own keys throughout. Multisig escrow: trades use 2-of-3 Monero multisig — buyer, seller, and arbitrator — so the arbitrator only signs to release funds if a dispute escalates, and cannot unilaterally move funds in normal flow. What you don't have to trust: no operator custody of XMR mid-trade in the happy path, no centralized KYC of buyer or seller, no central account; signup is the act of installing the client. What you *do* have to trust: the multisig protocol implementation (which the 2026 exploit demonstrated is non-trivial — see Incident); the integrity of the arbitrator for the network you join (different operators run different arbitrators with different reputations); and the fiat-payment leg, which happens outside Haveno (cash-by-mail, SEPA, Zelle, Wise, etc. — each with their own KYC + privacy properties).

Incident — 2026-05-20. Severity: high. A protocol-level exploit using spoofed arbitrator-ACK messages allowed an attacker to hijack the 2-of-3 multisig wallets before deposits could be locked, draining funds from active offers (large crypto offers were the primary target). Approximately 7,000 XMR (~$2.7M) lost across affected RetoSwap users — the primary operator impacted. Response was rapid and transparent: lead developer woodser publicly disclosed the active exploit, RetoSwap suspended trading and banned the attacker, and an emergency patch (Haveno v1.5 / RetoSwap v1.6.0-reto) shipped within days — a targeted defensive check verifying peer identity in the ACK message flow. Trading was paused network-wide via forced minimum client version. Funds had not been recovered as of this review date (2026-05-25); the operator has not ruled out partial recovery and the incident window is still open. The network is returning to operation under the patched protocol but liquidity has been impacted. Curator advice: do not open new offers on any Haveno operator until your client reports a min-version bump confirming the patch is active; if you have outstanding offers, back up your wallet and follow your operator's advisory.

Incident — 2026-06-24 and v1.8.0 response. A second protocol-level exploit in the same arbitrator/dispute-message verification class surfaced on 2026-06-24 against RetoSwap users, before the May v1.5 patch's coverage proved sufficient against a more refined variant. Haveno v1.8.0 shipped 2026-06-20 as the proper hardening pass — explicit arbitrator-signature verification on structured dispute payout fields, verified-sender enforcement across trade-setup messages, deposit-response and deposit-NACK sender verification against the arbitrator identity, and a Tor loopback-bypass fix. The v1.5 fix from May was a targeted check on one message; v1.8.0 closes the broader class. Operators running the upstream code pick up the fix automatically; downstream networks (RetoSwap, others) have to roll their own clients and arbitrators onto v1.8.0 before reopening trading. Curator advice: do not open new offers on any Haveno operator's network until your client reports a minimum version of v1.8.0 or later, and verify the operator has confirmed the rollout.

Operational specs. Surfaces: desktop client (Linux + macOS + Windows). Coins: XMR primary; fiat via P2P arrangement (no on-chain fiat — the buyer sends fiat off-chain, the seller releases XMR from multisig). Payment methods (negotiated per offer): cash by mail, SEPA, Zelle, Wise, Revolut, Strike, Pix, Interac, ACH, Faster Payments, Bizum, Paysera, F2F (face-to-face), and many more. Fees: per-offer maker/taker spread + network operator fee (varies by operator). Trading limits: per-operator and per-payment-method (no-deposit small trades supported on some flows). Network access: Tor-only. Bounty program for development funded in XMR.

Philosophy. Haveno's editorial differentiator is the bet on P2P + multisig + Tor as the only structurally non-custodial fiat-XMR ramp. Centralised exchanges custody your funds during the swap and require KYC; aggregators reduce that to a routing-layer custody window but still touch your funds; Haveno never custodies — escrow is on-chain Monero multisig, signed by you. That architectural commitment is what makes Haveno the canonical privacy-first fiat ramp and what makes it more complex to operate safely than a centralised swap (the multisig flow has more moving parts, as 2026-05 demonstrated).

Grade rationale. Grade A- reflects the architectural strengths still intact — non-custodial multisig, Tor-only transport, open-source codebase, no operator-level KYC, a long-running team led by woodser since the Bisq fork — minus one full step for two exploit events in five weeks (2026-05-20, 2026-06-24) in the same arbitrator/dispute-message class. The May v1.5 patch covered one variant; the June incident hit a related one before v1.8.0's broader signature-verification pass landed. Path back to A: 90 days of incident-free operation on v1.8.0 or later across the major operator networks, a published Haveno post-mortem that names the exact failure mode and the v1.8.0 mitigations, and visible coordination with downstream operators on fund-recovery for affected users. Without those, the grade holds at A- or drops further if a third same-class incident lands.

Useful when. You want to swap XMR for fiat (or vice versa) in a non-custodial, no-KYC flow and you understand the trade-offs of P2P (variable liquidity, requires patience, fiat leg uses traditional payment rails with their own KYC). You want the strongest privacy posture available in the exchange category — accept the operational complexity for that property. You're comfortable installing a desktop client and configuring Tor. You want to support the decentralized-exchange thesis with your actual trading volume.

Caveats. Incident-aware: see Incident section above. Do not open new offers until the patched client minimum is enforced on your operator's network. Liquidity is lower than centralised swaps — expect to wait for a counterparty match, and large trades (>50 XMR) may not find takers quickly. Desktop only — no mobile, no web. Fiat-leg privacy depends on the payment method you choose — cash-by-mail is the most private; SEPA / Zelle / Wise carry full bank-level KYC on the fiat side. Multisig dispute resolution takes time — when a trade goes sideways, the arbitrator process can take days; this isn't a "instant swap" experience. Network choice matters — different operators have different arbitrator quality, fee structures, and reliability. Haveno-Reto / RetoSwap has the most liquidity but was also the operator hit hardest by the May 2026 exploit. Protocol risk is real — May 2026 demonstrated that a sophisticated protocol-level attack is possible against multisig swap flows, and the architectural commitment to multisig means future similar vulnerabilities cannot be ruled out structurally; the patch model is "find, fix, ship min-version bump" rather than "no attack surface in the first place."