# Haveno: Monero P2P Exchange Architecture and Setup

> Haveno is a Java-based, non-custodial Monero exchange for peer-to-peer trading over Tor. It can be built locally, but the official repository does not support direct mainnet trading without a separately supplied network.

**haveno-dex/haveno** — Decentralized P2P exchange platform built on Monero and Tor

- Repository: https://github.com/haveno-dex/haveno
- Website: https://haveno.exchange
- Stars: 1,408 · Forks: 190
- Language: Java
- License: AGPL-3.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/haveno-dex-haveno

## What Haveno Solves for Monero Traders

Haveno targets a specific exchange problem: trading Monero for fiat or other supported assets without routing the entire interaction through a central custody platform. The README names USD, EUR, and GBP as fiat examples and BTC, ETH, and BCH as cryptocurrency examples. Its intended users are traders who want direct counterparties and are comfortable with Monero, Tor, self-managed software, and the operational demands of a peer-to-peer market.

The project does not describe a conventional order book or centralized liquidity pool. The README states that trades happen between people, with no central authority. Users must therefore assess counterparties and arrange the external exchange of Monero and fiat or another cryptocurrency. This makes Haveno different from an exchange account where a company holds deposits and processes withdrawals.

Its non-custodial model also limits what the application can solve. Haveno can coordinate communication and protect trader funds through Monero multisignature, but it cannot make every counterparty trustworthy. Payment methods, identity expectations, dispute evidence, available liquidity, and network participation remain operational concerns. The design is most suitable for users who value direct settlement and can manage those factors.

## Tor, Multisignature, and the Haveno Trade Flow

Haveno's privacy mechanism begins with Tor. The README states that communications are routed through Tor to preserve privacy. Once a trade is accepted, the trade is peer-to-peer rather than submitted to a central authority. The README describes trader transactions as being secured by non-custodial multisignature transactions on the Monero network.

That mechanism creates a division of responsibility. Haveno supplies the exchange interface and communication path. Traders arrange the external exchange of Monero and fiat or another cryptocurrency. Monero multisignature secures the trader-side transaction without granting an arbitrator access to the funds.

The project says there is no token because it is not needed. Haveno is written primarily in Java, while the README identifies `haveno-ts` as a separate TypeScript library for using Haveno. The main repository contains `desktop/`, `daemon/`, `p2p/`, `seednode/`, `apitest/`, and `monitor/` directories. Based on that repository layout, it is a full application with multiple deployment and test surfaces, not a narrow payment library. The README does not document the detailed trade state machine or network handshake rules, so those mechanisms cannot be described more precisely.

## Building Haveno Locally with Gradle and Make

The repository provides wrapper-based Gradle tooling and Make targets, but the README does not give a complete installation sequence for connecting a local build to a public network. The first useful command is the Makefile's help target. It reports that the build uses the Java version declared in `gradle/libs.versions.toml`, and the displayed help text identifies Gradle 8.14.

From the repository root, run:

```bash
make help
```

The command prints the available build targets. The Makefile describes a full build as compiling the project, running tests, and downloading Monero binaries through Gradle:

```bash
make build
```

For development iteration, the Makefile provides a separate target that skips tests and Checkstyle:

```bash
make skip-tests
```

The repository does not state a guaranteed console message for these commands. The first observable check is that the selected command completes without a Java or Gradle failure. The Makefile also documents `make test`, `make check-java`, `make daemon`, `make desktop`, and `make package`, but it does not document a daemon launch command or a complete network-connection procedure in the README. The stated source for build and test-network instructions is `docs/installing.md`.

## Test Trades, Mainnet, and the Network Boundary

The most important setup constraint appears before installation: the official Haveno repository does not support making real trades directly. For actual mainnet trading, the README says to find a third-party network and use its installer or build its repository. The project does not endorse any such network.

This makes the network an external trust dependency. A user cannot infer from the core Haveno repository whether a supplied network has suitable peers, payment support, dispute handling, seed infrastructure, or timely software updates. Installing a third-party package would also require reviewing that package separately from this repository.

Haveno does document a safer learning path through Monero stagenet. The test network supports test trades and is connected through the instructions in `docs/installing.md`. For an operator who wants mainnet access without relying on an existing network, the README points to `docs/create-mainnet.md` as the route for creating one. That option carries infrastructure responsibilities that the README does not enumerate. A successful local build therefore does not establish readiness for real funds.

## Arbitration and Non-Custodial Failure Boundaries

Haveno's dispute model is narrower than a traditional exchange support system. Arbitrators can help when something goes wrong during a trade, yet the README explicitly states that they never have access to user funds. This is an important security boundary. It is not a claim that every payment dispute can be reversed automatically.

A direct Monero transaction can be secured through non-custodial multisignature, but the fiat or third-cryptocurrency side may depend on the payment method used outside Haveno. The README does not describe chargeback handling, bank disputes, identity verification, or automatic refund guarantees. It also does not claim that every peer is online or that every trade can complete without human negotiation.

The application is the wrong tool for users who require guaranteed liquidity, a central support desk with custody, instant fiat settlement, or a formal refund process. It may also be unsuitable for a first-time cryptocurrency user who does not understand Tor availability, Monero stagenet versus mainnet, wallet operations, multisignature transactions, or the need to verify an external network. Peer-to-peer settlement reduces custody exposure, but it transfers more responsibility to the trader.

## Desktop, Daemon, Packaging, and Integration Choices

The repository exposes several build shapes through the Makefile. A desktop package, daemon JAR, seednode JAR, and combined application build are separate targets. This matters because "install Haveno" does not identify one universal artifact. A desktop user needs a packaged application, while an integrator or service operator may be interested in the daemon or the related components.

The Makefile documents the daemon and desktop outputs as Gradle shadow JAR tasks. It also exposes `package` for platform installers, `test` for unit tests, and `check-java` to verify that the configured Java version is active. The `haveno-ts` repository is described separately as a TypeScript library for Haveno, so JavaScript integration is not achieved merely by installing the core desktop application.

The README does not document daemon configuration files, API endpoints, authentication settings, or a complete integration example. It would be speculative to claim that the daemon is ready for production deployment or that `haveno-ts` supports a particular operation. The project-specific first check should remain the selected build target and the network attachment process, rather than an undocumented service setup.

## AGPL-3.0, Releases, and Upgrade Work

Haveno is licensed under AGPL-3.0. That matters for engineers who modify the application, distribute it, or operate a modified version over a network, because the license includes source-availability and notice obligations. This is not legal advice, and the repository does not provide a compliance guide for a particular deployment. Engineers should read the actual `LICENSE` file and assess their distribution and network-use model before shipping modifications.

The repository is not archived. Its last push was on 2026-10-15, and the listed releases include `v1.10.0` on 2026-10-10 and `v1.9.0` on 2026-10-06. The release list also includes `v1.8.0` from 2026-06-20. This is evidence of recent project activity, but it does not remove upgrade work.

For an operator, the practical cost includes rebuilding or redistributing Java artifacts when AGPL obligations apply, checking network compatibility, and validating changes to Monero or Tor dependencies. The Gradle wrapper and version catalog reduce version discovery work, but they do not eliminate the need to review release notes and the selected network's maintenance state. The README does not promise compatibility between every Haveno release and every third-party network.

## When a Centralized Monero Exchange Is the Better Choice

A centralized exchange takes a different approach. It may aggregate orders or manage liquidity through one operator, gives users an account balance under that operator's custody rules, and centralizes authentication, support, and transaction processing. Haveno instead connects peers through Tor and secures trader funds with non-custodial Monero multisignature transactions.

The choice is custody versus control. Centralized services can be simpler for a user who values a predictable interface and does not want to manage external payments or third-party networks. Their counterparty is the exchange, and any trust requirements come with that operator's terms and controls. Haveno removes that central trading authority but leaves the user responsible for counterparty selection, network choice, payment coordination, and software provenance.

Haveno is not documented as a generic DEX for arbitrary blockchain assets. The README specifically identifies Monero as the underlying network and lists other cryptocurrencies mainly as things exchanged for Monero. An engineer looking for Ethereum smart-contract settlement, a centralized order book, or regulated custody is outside the documented scope.

## Conclusion

Haveno fits users who specifically want peer-to-peer Monero trades, can assess the network that supplies their client, and accept responsibility for payment coordination and software provenance. It does not fit someone expecting the official repository to connect directly to mainnet or provide a centrally operated exchange. Verify first that the selected third-party network is available, its installer and repository can be inspected, and its Monero connection and upgrade policy fit the intended use.

## FAQ

### Can Haveno make real trades directly from the official repository?

No. The README states that the official Haveno repository does not support making real trades directly. Real trading requires a third-party network and its installer or repository.

### Does Haveno keep user funds in custody?

No. Haveno describes trades as non-custodial, with trader transactions secured through non-custodial multisignature transactions. Arbitrators may assist with disputes but never have access to user funds.

### How can a new user try Haveno without trading real funds?

The README points to the test network instructions in `docs/installing.md`. That network uses Monero stagenet and is intended for test trades.

## Sources

- [haveno-dex/haveno on GitHub](https://github.com/haveno-dex/haveno)
- [License: AGPL-3.0](https://github.com/haveno-dex/haveno/blob/master/LICENSE)
- [Project website](https://haveno.exchange)
- [README](https://github.com/haveno-dex/haveno/blob/master/README.md)
- [Releases](https://github.com/haveno-dex/haveno/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/haveno-dex-haveno