Securing a Monero wallet: seeds, signed downloads and hardware

Everything a Monero wallet hides depends on two secrets: the private spend key, which moves funds, and the private view key, which reads them. This guide covers where those keys come from, how to check the software that holds them, and the hardware that keeps the spend key off the computer.

The 25-word seed

A standard Monero wallet is one 256-bit secret, the private spend key; the view key is derived from it, as the view key guide explains. The seed writes that secret as 25 words from a list of 1626 words. The first 24 carry the key, three words to every 32 bits. The 25th is a checksum: electrum-words.cpp takes a CRC32 over the unique prefix of each of the 24 words — the first three letters in English — and repeats the word it points to. A mistyped word is caught; the right words in the right order are the wallet.

Polyseed

Polyseed, a newer format by tevador, writes a wallet in 16 words of 11 bits each: a 150-bit secret, plus the wallet's birthday and a few flags. The birthday matters for restoring: a wallet that knows when it was made does not have to scan the chain from the beginning. The specification gives the range of birthdays as November 2021 to February 2107 and the security level as 128 bits. The key is derived with PBKDF2-HMAC-SHA256 over 10,000 iterations, a seed can be encrypted with a passphrase, and a coin flag mixed in by XOR keeps a seed for one coin from restoring a wallet of another.

In Monero's own software, Polyseed support for wallet2, the wallet API, the CLI wallet and the wallet RPC server was merged into the master branch on 20 September 2026 (pull request #10765). It is not in the v0.18 releases.

Checking a download

The Monero project publishes a file, hashes.txt, with the SHA-256 hash of every release file, signed with the GPG key of binaryFate. The verification guide's steps are these:

1. Import the key with gpg --import binaryfate.asc, and check that its fingerprint is 81AC 591F E9C4 B65C 5806 AFC3 F0AF 4D46 2A0B DF92. The same key is in the repository under utils/gpg_keys.

2. Verify the file with gpg --verify hashes.txt and look for a good signature. The warning that the key is not certified with a trusted signature is expected: it says you have not signed binaryFate's key yourself, not that the signature is bad. The fingerprint is the check that matters.

3. Hash the download with shasum -a 256 on macOS and Linux, or certUtil -hashfile on Windows, and compare the result with the line for that file in hashes.txt.

The downloads page notes that mobile and light wallets are not managed by the Monero core team, so each comes with its own project's way of checking it.

Hardware wallets

The downloads page lists the hardware wallets that support Monero: Ledger Nano S with firmware 2.1.0 or later, Nano S Plus with 1.0.3 or later and Nano X with 2.0.2 or later, and Trezor Model T, Safe 3 and Safe 5 with firmware 2.5.2 or later. A hardware wallet keeps the private spend key on the device and signs there, so a compromised computer cannot spend without it.

The rest of the checklist

Run the recommended release. As of 6 November 2026 that is v0.18.5.4, of 17 October 2026, whose notes list a fix for DNSSEC.

Use your own node. A wallet connected to someone else's node gives that node its IP address and the transactions it sends. The node guide has how to run one over Tor or I2P.

Treat multisig as experimental. Since v0.18.0.0, of 20 July 2022, multisig has been off by default; the CLI wallet turns it on with set enable-multisig-experimental 1.

Share proofs, not keys. A view key discloses every incoming payment; a transaction proof discloses one. The view key guide has what each proof reveals.