Paper Wallet

Overview

Traditional paper wallets often printed a public address and corresponding private key, sometimes as QR codes. Because the key remains offline, the method was promoted as cold storage. Mnemonic backups on paper are related but may represent an entire deterministic wallet rather than one key.

Paper is vulnerable to fire, water, fading, copying, theft, printer memory, insecure generation websites, and transcription errors. Importing or sweeping the key into software exposes it, and partial spending can mishandle change in older workflows. A printed key created by untrusted software may never have been secure.

Modern users generally need safer generation, durable backups, and tested wallet recovery rather than printable key generators. If paper is used, creation must be offline and trusted, copies controlled, and context recorded. Spending should migrate the full balance to a newly secured wallet.

Paper Wallet should be distinguished from the asset balance and from the application that displays it. For example, a customer-facing success message does not prove that the intended transaction executed on the correct network; operations should verify execution and reconcile the result before irreversible fulfillment.

Records for Paper Wallet should preserve account and address identifiers, asset and network identity, policy version, requester, approvers, signed payload or transaction reference, fees, timestamps, status history, confirmations, exceptions, and final balance and accounting effects. For Paper Wallet, corrections must remain linked rather than overwrite the original event.

The Paper Wallet workflow operates through several distinct states: request creation, user or policy approval, signature generation, network submission, execution, confirmation, balance recognition, and accounting. For Paper Wallet, a wallet interface or provider response can report progress, but it cannot replace verified transaction and ledger evidence.