monero-gui: the Qt desktop wallet for the Monero core daemon

A QML front end over a separate core daemon

monero-gui is the desktop wallet for Monero, and the README is clear that it is not the protocol implementation. It is the GUI for the core Monero implementation, which lives in a separate repository. So the cryptography, the ledger handling and the network protocol are all in monero-project/monero, and this repository is the interface a person looks at.

The interface is Qt Quick. GitHub reports the language as C, which is the C and C++ core that GitHub attributes the bulk of the bytes to, but the repository tree tells the actual story of the user experience: `main.qml`, `LeftPanel.qml` and `MiddlePanel.qml` at the root, a `qml.qrc` resource file, `qtquickcontrols2.conf` for the control styling, and `components/`, `pages/`, `wizard/`, `js/` and `lang/` directories. There is a `start-low-graphics-mode.bat` for machines that struggle with the default, which is a reasonable signal about the rendering approach.

The project describes Monero as a private, secure, untraceable, decentralised digital currency, and explains the three properties separately. Privacy comes from transactions not being easily revealed on the blockchain. Untraceability comes from ring signatures giving an optional ambiguity so a transaction cannot be tied back to an individual user or computer. Security is the distributed peer-to-peer consensus network, plus the wallet-level detail that a 25 word mnemonic seed is displayed only once and wallet files are encrypted with a passphrase.

Master is a staging area, so use a tagged release

The most operationally important paragraph in the README is about repository policy. The GitHub repository is described as the staging area for the latest changes. Before changes are merged into that branch on the main repository, they are tested by individual developers in their own branches, submitted as a pull request, and then tested by contributors who focus on testing and code review.

The README then draws the conclusion directly: the repository should be considered carefully before using it in a production environment, unless there is a patch for a particular show-stopping issue, and it is generally a better idea to use a tagged release for stability.

That advice is unusual to see stated this plainly in a README, and it should shape how you deploy. If you are building a wallet image for yourself or for others, build from a release tag. GitHub reports the repository as not archived with the last push on 2026-09-23, so the staging branch is genuinely active and genuinely ahead of any release.

There is also a vulnerability response process linked from the README, along with a HackerOne program, which tells you what to do if you find a flaw rather than leaving you to guess at the reporting channel.

Point releases that read like a security changelog

The release history is where this project's engineering priorities become visible. There are three recent releases and all three are worth reading.

Point release 5.2, version v0.18.5.2, published 2026-07-21, is described narrowly: it fixes wallet generation during first use. The specific items are the fix itself, a warning when adjusting KDF rounds, a fix for precision loss when generating payment requests with large amounts, and creating wallets in memory in the wizard.

Point release 5.1, version v0.18.5.1, published 2026-07-08, carries a longer list that is worth reading as a threat model. It fixes a memory safety issue during QR code scanning, prevents CSV formula injection during export, applies consistent text escaping across rich text views, adds a confirmation dialog for unauthenticated OpenAlias, and checks that the wallet file directory is writable during wallet creation. Those five items describe an application that renders attacker-influenced content: a QR code someone hands you, a spreadsheet you open after exporting, text from a remote source, an address you are about to send to.

Major point release 5, version v0.18.5.0, published 2026-05-12, moves the P2Pool install location to LocalAppData on Windows, disables offline transaction creation with a long payment ID, escapes untrusted text in the QR code scanning scenario, and fixes an edge case in URI parsing.

The pattern across all three is that the fixes cluster around inputs a user does not control. If you are evaluating this wallet, that is the reassuring thing about its recent history rather than a reason for concern.

A release train separate from the command line client

The releases carry names as well as numbers, following a chemical element scheme: Fluorine Fermi, GUI, Point Release 5.2. The version numbers track the core rather than running independently, since v0.18.5.2 is a GUI point release on top of the 0.18.5 core line.

Each release notes page links out to the CLI release notes and downloads, which is how the two tracks stay aligned. There is a detail there worth noting: the notes for GUI point release 5.2 link to the CLI release page for v0.18.5.1, not v0.18.5.2. So the GUI and CLI version suffixes are not identical even within the same core release, and a link in the GUI notes is not necessarily pointing at the matching CLI build.

The download links in the notes are served from downloads.getmonero.org and are named by platform and version: a zip for Windows 64-bit, an installer executable for Windows 64-bit, a dmg for macOS on Intel, and equivalents for macOS on Apple silicon and Linux. Verify those rather than installing from a third-party mirror, because the download host is part of the trust story for a wallet.

The bundled mining component is P2Pool, and it is versioned independently of the wallet, moving to v4.15 in the 0.18.5.0 release and v4.17.1 in 5.1. So a wallet release can carry a mining pool update that nothing else in the notes explains.

Packages, translations and how to build from source

Prebuilt packages are listed for five systems: Arch Linux as `monero-gui`, NixOS via `nix-shell -p monero-gui`, Flatpak from Flathub under `org.getmonero.Monero`, GuixSD via `guix package -i monero-gui`, and macOS through homebrew as a cask named `monero-wallet`. Note that the homebrew cask name does not match the repository name, which is the kind of small inconsistency that sends people to the wrong formula.

Translations are handled on Weblate at translate.getmonero.org, with a step-by-step Weblate guide in a separate monero-translations repository. The design work is on Figma. Development contact is IRC on Libera in `#monero-gui`, plus a dev mailing address.

Building from source needs CMake with Ninja and a QML test option. The Makefile's default target does the work:

mkdir -p build && cd build && cmake -G Ninja -D DEV_MODE=$(or ${DEV_MODE},OFF) -DQML_TESTS=${QML_TESTS} -DMANUAL_SUBMODULES=${MANUAL_SUBMODULES} -D BUILD_64=ON -D CMAKE_BUILD_TYPE=Release .. && cmake --build .

The Makefile also has a `debug` target that flips `CMAKE_BUILD_TYPE` to Debug and adds `--verbose`, a `depends` target for static builds with a platform toolchain file, a `devmode` target that sets `DEV_MODE=ON` while still building Release, a `clean` target, and a `scanner` target. Two build knobs are worth knowing: `MANUAL_SUBMODULES` controls whether the git submodules in `external/` are handled for you, and `ANDROID_STANDALONE_TOOLCHAIN_PATH` defaults to `/usr/local/toolchain` for the Android build. Reproducible Windows and Linux static binaries and the experimental Android APK each have their own Dockerfile: `Dockerfile.windows`, `Dockerfile.linux` and `Dockerfile.android`.

Two facts about the repository that need reconciling

First, licensing. GitHub reports no license identifier for this repository. The README's license section is a single sentence pointing at a `LICENSE` file, which is present in the repository tree. So there is a license file and no machine-readable license field, and the file is the authoritative one. If you need the grant for compliance, read `LICENSE` rather than relying on the metadata.

Second, provenance and dates. The README header reads Copyright (c) 2014-2024, The Monero Project, and the repository's GitHub description is the project tagline about a secure, private, untraceable cryptocurrency rather than anything specific to a desktop wallet. Both look like long-lived boilerplate that predates the current repository. The concrete signals are elsewhere: releases published in 2026, and a last push on 2026-09-23.

There is one more detail with real user impact. The wallet's stated protection is a 25 word mnemonic seed shown once, plus a passphrase-encrypted wallet file. Combined with the CSV injection fix and the untrusted text escaping, the shape of the risk this application handles is consistent: it takes secrets it must never leak and it displays content it did not author.

Editorial conclusion

monero-gui is a competent thin front end over a daemon that does the real cryptographic work, and its value to most users is that it ships verifiable binaries with a named release rather than asking anyone to compile a wallet. The release notes are the best evidence of how it is maintained: point release 5.1 fixed a memory safety issue in QR scanning and a CSV formula injection on export, which is the kind of defect surface a wallet has that a general application does not. Use a tagged release rather than the master branch, since the README says so plainly, and verify the download rather than trusting the mirror you found it on.

Frequently asked questions

Official sources

1. Issues
2. monero-project/monero-gui on GitHub
3. README
4. Releases