Module 8 · Practicing Safely / 8.3
The key stays inside. The decision is yours.
Understand the device, the backup, and the approval.
Imagine a locked signing desk. You slide an unsigned instruction through a slot. The person inside checks it, signs it, and slides the signed page back.
The pen stays inside.
A hardware wallet is designed around a similar boundary. The private key stays in a separate device while signatures can leave. But if you ask it to sign the wrong instruction, protecting the key alone will not save the funds.
Know what you are approving.
Your wallet software prepares a transaction and sends it to the hardware signer. The device shows details, asks for confirmation, and signs internally. The signed transaction can then be broadcast. The coins remain recorded on their network.
This design reduces exposure to malware on the connected computer. It is not an absolute defense against compromised hardware, malicious approvals, misleading displays or mistakes. The trusted screen matters only if you check it.
Compare the destination, amount, network and fee with the action you intended. For contract interactions, understand the permission or change being authorized. A device may not be able to display every complex action clearly. If the meaning is unclear, do not sign simply because the device permits it.
The computer prepares an unsigned instruction.
A teaching model of signing. No device or wallet is connected.
Begin with a wallet you created.
Use a trustworthy manufacturer or authorized sales route, and follow the authenticity checks for that model. Avoid a device prepared by someone else. A card containing recovery words supplied by a seller is a serious warning: another person may already control that wallet.
Create a new wallet through the device’s verified setup process. Backup formats vary; do not assume every device uses the same word count or recovery standard. Confirm asset and network support before relying on it.
Record the backup accurately through the manufacturer’s documented method. Keep recovery words and private keys away from websites, messages, screenshots, ordinary notes and AI chats. A password or device PIN is not a substitute for a wallet backup.
The backup is another way to the keys.
A lost device need not mean lost funds if a correct compatible backup—and any required passphrase—is available. A stolen backup can let someone recreate the wallet without the original device or its PIN.
Protect backups against both destruction and discovery. Durable media can help with fire or water, depending on the product. A second complete copy in a separate secure place reduces some disaster risks while creating another copy someone might find.
Test the backup with the manufacturer’s supported check feature when available. A dry run can compare it without first erasing the wallet. Learn recovery on a new practice wallet before depending on the process. Do not wipe a funded savings wallet to find out whether an untested backup works.
If you use an optional passphrase, understand that it can select a different wallet. Losing it can prevent recovery even when the backup words are correct. Additional complexity helps only when you can manage it reliably.
The device PIN does not make a stolen recovery phrase harmless.
A careful recovery rehearsal
Use current instructions for your actual model. First verify the backup using a supported non-destructive check. If you rehearse a full restore, do it with a new practice wallet and only a limited amount, after understanding what will be erased.
Confirm that the recovered wallet produces the expected accounts and addresses. Do not reveal real recovery material in a lesson, screenshot or support message. If a device reports a mismatch, stop and investigate with independently reached official support before depending on the backup.
Separate a connection from a permission.
Connecting a wallet to a site usually shares selected public account information and lets the site request actions. It does not, by itself, hand over the private key or grant unlimited token spending.
An approval is different: it can authorize a contract to move a specified token amount. Some signed messages can grant permissions too, even when no immediate network fee appears. Read who receives the permission, for which asset, and for how much.
Disconnecting the site does not revoke an existing on-chain allowance. Use a verified tool and the correct network to inspect and revoke permissions you no longer need. Revocation usually requires a transaction; it cannot undo a completed theft or secure an exposed recovery phrase.
Keeping savings away from experiments can limit the impact of an app approval. Separate accounts derived from one recovery phrase still share that phrase’s risk. For stronger separation, understand which keys and backups are actually independent.
No site connection and no spending allowance.
A local teaching simulation. Revocation does not repair an exposed recovery phrase.
Leave a recovery path for a person, too.
Prepare private instructions for incapacity or death: what exists, who can help, and how the appropriate person can find protected access instructions. Consider legal and estate requirements where you live.
The ordinary plan should point toward secure instructions without publishing the secrets. A family member finding a device is not the same as being able to recover the accounts. Revisit the plan when your setup changes.
The idea to keep
Hardware separates the key from everyday software. Backups protect recovery. Careful approval protects the decision. Each solves a different part of the problem.
Next, learn how a request can be shaped to make you skip those checks.