Wallet security begins before a device or app receives a seed. A counterfeit download, altered installer, or fake support page can request a recovery phrase while looking professional. Overseas readers may use a translated website, a mirror, or a second-hand device, so transport authenticity deserves its own procedure. The steps below focus on publicly verifiable release evidence and do not ask anyone to disclose a private key, seed phrase, password, or one-time code.
Start from an official source
Use a saved official domain or a vendor’s documented repository rather than an advertisement or search result. Check spelling, HTTPS, release notes, and the entity responsible for the download. A padlock only protects the connection to the domain; it does not prove the domain is genuine. Download the application or firmware once, record its version and date, and avoid “support” links that arrive through unsolicited messages.
Compare checksums correctly
A checksum lets you compare the file you downloaded with a value published by the vendor. Calculate it using a trusted local tool and compare the entire digest, not a shortened screenshot. A matching checksum proves the bytes match that published file; it does not prove the publisher’s key or process is trustworthy. Save the checksum page and software version with your installation record so a later review can repeat the comparison.
Learn release signatures
Some projects sign release files with OpenPGP or another public-key system. Verify the signature against a key obtained from an independent official channel, and note the key fingerprint. Do not paste a private key into a website that offers “verification.” If a signature fails, stop and seek an official explanation; never disable antivirus or bypass a warning merely because a guide says the installer is urgent.
Treat translations as a viewing layer
A translated page can improve comprehension but may omit a warning or alter a download link. Compare the translated instructions with the original release page, especially version numbers, network names, and file hashes. Keep the original-language URL in your notes. If family members share a device, agree on one verified source and explain how to recognize an official update so that a well-meaning person does not install a look-alike application.
Use a clean test environment
Install a new wallet on a device with current security updates and minimal extensions. For a desktop application, verify the publisher and inspect permissions before opening a seed. For a hardware wallet, use the vendor’s official initialization flow and confirm that the device generates the recovery phrase locally. A wallet that arrives with a printed phrase is suspicious; the phrase should be generated by the device, not supplied by a seller.
Record the decision without secrets
Keep a short log containing source domain, release version, checksum, signature fingerprint, installation date, and the public wallet address used for a small test. Never put seed words, private keys, PINs, or backup photos in that log. If the evidence is incomplete, postpone the setup. A slower verified download is cheaper than trying to recover funds after entering a secret into a counterfeit interface.
Operational worksheet
Before installation, print or save a short verification card containing the official download URL, release version, checksum algorithm, digest, signature fingerprint, and vendor support URL. Have a second reader compare the card with the live official page using a separate device. If a mirror is necessary because a country blocks the primary site, record who operates the mirror and verify the file against the vendor digest. After installation, review application permissions and create a public test address before importing any account. Delete temporary download folders only after the comparison is complete, and never upload the installer to an unknown “scanner.” A process that records provenance, verification, and permissions gives an overseas family a common reference when one member uses a translated guide and another uses the original release notes.
For a shared editorial or family setup, keep the verification card in the same language as the release notes and ask a second reader to verify the URL character by character. If the project publishes a transparency log, record the release commit and the date checked. A verified file still deserves a permission review after installation because a legitimate application can request more access than the wallet function requires. Stop when provenance, digest, or signature evidence conflicts.