Procedure
How to Create a Monero Paper Wallet, and How It Goes Wrong
This is one of the few crypto procedures where doing it slightly wrong produces something that looks entirely correct. That is the reason to be slow about it.
What a paper wallet is and is not
It is a key pair generated on a machine that is not connected to anything, written down by hand, and stored physically. The coins are not on the paper; they are on the network, and the paper holds the only thing that can move them.
It is not a wallet you use. There is no balance display, no send button and no recovery process. It is an archive, suited to an amount you intend not to touch for a long time, and poorly suited to anything else.
Prepare a machine that has never been online
Or one booted from removable media with networking disabled. The point is that no process on it has had an opportunity to send anything anywhere.
Generate the keys locally
Using official wallet software transferred on removable media, with its signature checked beforehand on a different machine. Unverified software is the whole attack, and it is a cheap one to run.
Write everything down by hand
Address, spend key, view key and the mnemonic seed. By hand, on paper, twice. Not printed, because a printer is a networked computer that stores documents.
Verify before funding
Restore the wallet from what you wrote, on the same offline machine, and confirm the address matches. A backup that has not been restored once is an assumption.
Destroy the working copies
Wipe the machine or destroy the removable media. Then send a small test amount, confirm it arrives using the view key, and only then fund it properly.
The view key, which makes this usable
Monero separates the ability to see incoming transactions from the ability to spend them. The view key can be imported into ordinary software on a connected machine and will show what has arrived, with no capacity to move anything.
That solves the practical problem with archival storage: you can confirm funds arrived and monitor the balance for years without the spend key ever touching a networked device. Set this up at creation time rather than later, when the offline machine may no longer exist.
Where it looks right and is not
A mistranscribed character produces a valid-looking key for a wallet that is not yours. A printed copy that seems destroyed sits in a printer spool. A machine that was online last week is not an offline machine. All three produce a result indistinguishable from success until the day you try to recover, which may be years later.
Where the paper itself lives
The physical copy inherits every risk paper has: fire, water, fading ink, and being tidied away by someone who did not know what it was. Two handwritten copies in two locations covers most of it, and neither location should be described on any device. A note that says where the backup lives is a map to the spend key. Ink and pressure matter more than they seem; a soft pencil entry can be unreadable in a decade, which is exactly the timescale this arrangement is built for.
Verifying the tool before you trust it with keys
The whole procedure rests on the generator being genuine, and that is the step most often skipped. A tampered generator produces addresses that look correct and keys the attacker also holds, and nothing about the output reveals it. No amount of care with the paper afterwards repairs this.
The project publishes checksums for its releases and signs them. Checking the file against the published hash before running it takes a minute, and verifying the signature on the hash file takes a little longer and is what actually establishes the chain, since a hash published beside a compromised download is worth nothing.
Do the check on a machine that is still online, then take the verified file to the offline one. Doing it in the other order is a common instinct and it defeats the purpose, because the offline machine has no way to fetch the reference values. And treat a generator that offers no checksums at all as unusable for this, whatever else it appears to do well.
Plan the exit before the entry
Spending eventually requires importing the spend key into software on a connected device, which ends the offline property permanently. Decide now that when this happens you will move the entire balance to a new wallet rather than spending part of it and returning the rest.
Partial spends from a key that has been exposed are how people convince themselves an arrangement is still secure after it has stopped being one. The archive is single-use by design, and treating it that way is what keeps it worth the effort.
Questions this raises
Why generate keys offline at all?
Because a key generated on a connected machine has been exposed to whatever else is on that machine. For a long-term store that will not be touched for years, generating on a device that has never been online removes an entire category of risk at the cost of some inconvenience.
Can I check the balance without exposing the keys?
Yes, and this is the feature that makes the arrangement practical. A view key lets software see incoming transactions without any ability to spend. You can monitor an offline wallet from an ordinary machine and keep the spend key where it has always been.
What is the most common mistake?
Printing. A network printer stores documents, an office printer keeps a spool, and both defeat the entire exercise silently. Hand-copying is slower and safer. The second most common is generating on a machine that was online recently and assuming that is close enough.
How do I eventually spend from it?
By importing the key into a wallet, which by definition brings it onto a connected device. Plan for that moment: it is the point at which the offline arrangement ends, and the sensible pattern is to move the whole balance out at once rather than repeatedly exposing the key for partial spends.
Primary sources
- getmonero.org: user guidesOfficial procedures, including offline key generation.
- getmonero.org: frequently asked questionsView keys, spend keys and recovery, from the project.
- Ledger: supported coins and tokensThe manufacturer on what the device supports.