Wallets

:::section{mins=5} What a Wallet Actually Is :::

:::lead A [[gloss:wallet|wallet]] does not hold your coins. The coins live in the [[gloss:blockchain|blockchain]] — the same database that runs in copies on tens of thousands of [[gloss:node|nodes]] around the world. The [[gloss:wallet|wallet]] holds a 256-bit number that proves the coins are yours. Confusing the two is the most common beginner mistake. :::

:::p{html} When the FTX exchange collapsed in November 2022, around $8 billion of client funds were recorded on its balances. By May 2026, after four distribution rounds, many creditor classes had received 100% and more back — the "convenience class" of small holders was repaid 119% of face value plus 9% annual interest on top. It sounds almost like a happy ending. But there is a catch: the calculation was done at November 2022 prices, when [[gloss:bitcoin|Bitcoin]] was worth $16,000. At its 2025 peak, [[gloss:bitcoin|Bitcoin]] reached $126,000. Those who waited for the payout received dollars worth roughly 12% of what they could have withdrawn from the exchange the week before the collapse. :::

:::p{html} This story is not about FTX. It is about what separates an account on a centralized exchange (CEX: Coinbase, Binance, Kraken, Bybit) from a [[gloss:wallet|wallet]]. By "exchange" in this section we mean specifically a CEX: the place where you deposit crypto, where it is held by the exchange under its own keys, in your name. The opposite is DEX (Uniswap, Jupiter, Hyperliquid), where trading happens through [[gloss:smart contract|smart contracts]] and the coins stay under your key — there, you act as your own custodian. The rest of this section is about CEX. :::

:::p{html} An account on an exchange is a claim: the exchange owes you N coins, recorded in its internal database. The coins themselves are tracked in the [[gloss:blockchain|blockchain]] on the exchange's addresses, under its keys. A [[gloss:wallet|wallet]] works differently: you hold the [[gloss:private key|private key]] that directly controls an address in the [[gloss:blockchain|blockchain]], the coins on that address are recorded in the shared ledger, and only you can sign a [[gloss:transaction|transaction]] from it. The difference between the two forms of ownership shows up exactly at the moment of failure. An exchange can go bankrupt, be frozen by a regulator, or be drained by an insider, and the record "owes you N coins" loses its connection to reality. A [[gloss:private key|private key]] works the opposite way: as long as you have it, no one can freeze the address, reverse [[gloss:transaction|transactions]], or mint a duplicate of your balance. This is both the strength and the burden: [[gloss:self-custody|self-custody]] removes every intermediary, including the ones you could have turned to when you lost the key yourself. :::

:::p{html} Technically a [[gloss:wallet|wallet]] is an interface to a key pair: private (a 256-bit secret) → public → an address of the form 0x1a2b...3c4d. The chain runs only one way, and the math is covered in → 1.4 §2. What follows from it in practice is the phrase "not your keys, not your coins" — repeated so often that the edge has worn off, but the meaning is still literal. If the exchange holds the key, the exchange decides what happens to your balance during a failure. If you hold the key, only you decide, and the weight of consequences is also yours. Every decision in this card — which [[gloss:wallet|wallet]] to install, where to record the [[gloss:seed phrase|seed phrase]], what to sign, what to revoke — is a decision about where on this scale you stand right now. :::

:::callout{icon=💡} It works like a public museum vitrine behind locked glass. Any visitor sees what's on display: a coin, a manuscript, a meteorite — the exhibit, its appraisal, even the history of moves from one hall to another if the museum keeps a catalog. What is not visible is who holds the key to the glass. The donor's name on the plaque may be there, may not be there, may be a pseudonym like "private collection." Only whoever has the key can remove the item; if the key is lost, the museum will not force the case open: there is no duplicate, and that's not an oversight but the condition under which the vitrine was installed in the first place. A [[gloss:wallet|wallet]] works the same way, with one adjustment: the vitrine sits not in a single museum but in a distributed database with copies held by tens of thousands of independent keepers. :::

:::keypoints{label="Key Points"}

• FTX is not an anomaly but the most recent example of a pattern: Mt. Gox (2014, payouts still ongoing), QuadrigaCX (2019, founder died with the only keys), Celsius, BlockFi. The same regime every time: bankruptcy freezes the accounts, payouts stretch over years, and the amount is calculated at the prices on the day of collapse. A CEX is not "crypto, made convenient"; it is a claim on a solvent counterparty.
• A [[gloss:private key|private key]] is not the "password to your account" — it is the account itself. There is nowhere to recover it from: no exchange, no [[gloss:wallet|wallet]] vendor, no [[gloss:ethereum|Ethereum]] Foundation knows or can compute someone else's key.
• Address, [[gloss:public key|public key]], and [[gloss:private key|private key]] are three levels of one chain that runs only one way. Sharing the address with a friend is safe; sharing the [[gloss:public key|public key]] is usually safe too; sharing the [[gloss:private key|private key]] gives away everything, irreversibly.
• "Not your keys, not your coins" describes a trade-off, not a moral imperative. A CEX is the rational choice for active trading, for amounts whose loss would not be catastrophic, and for people who honestly rate their risk of losing a [[gloss:seed phrase|seed phrase]] above the counterparty risk. The question is not "exchange or [[gloss:wallet|wallet]]" but "which part of the capital goes where." :::

:::details{badge=Advanced title="Wallets Without a Key: What Watch-Only Reveals About the Word "Wallet""} :::p{html} Type someone else's public address into MetaMask, Rabby, Phantom, or Ledger Live, and you get a fully functional watch-only [[gloss:wallet|wallet]]: balance, incoming and outgoing [[gloss:transaction|transactions]], tokens, [[gloss:nft|NFTs]], history of [[gloss:defi|DeFi]] interactions — all visible. The only thing that isn't visible is the ability to sign anything. There is no [[gloss:private key|private key]] in this [[gloss:wallet|wallet]], and there is not supposed to be. Same interface, same network, same chain; the "Send" button is either missing or leads to a dead end. :::

:::p{html} In practice, watch-only solves three problems. First, monitoring public addresses: a trader keeps Vitalik's address (0xd8dA...6045), Binance's hot [[gloss:wallet|wallet]], and the MakerDAO treasury in their Rabby; an alert fires the moment a whale moves. Second, separating reading from signing in a hardware setup. The Ledger sits in a safe and is only plugged in at the moment of a transfer; the rest of the time, MetaMask runs as a watch-only observer of the same address. Balance is visible, prices refresh, the portfolio tracker works — but if someone compromises the computer, no signing is possible: there is no key in that MetaMask. Third, audit and compliance: a DAO finance lead has watch-only access to every treasury address and sees every outgoing [[gloss:transaction|transaction]] in real time, with no signing rights. :::

:::p{html} Watch-only is the cleanest demonstration of the point made in the main body of the section. A [[gloss:wallet|wallet]] with no [[gloss:private key|private key]] at all still functions as a [[gloss:wallet|wallet]]: it sees the "life" of the address in the same chain, the same database, that the real owner sees. The difference between a watch-only [[gloss:wallet|wallet]] and a "real" one comes down to one thing: the presence or absence of the key that signs outgoing [[gloss:transaction|transactions]]. Everything we are used to calling "the [[gloss:wallet|wallet]]" — the app icon, balance, tokens, history, network UI — is the interface. The actual fact of ownership lives in a single string of bytes, which in watch-only mode is simply not loaded. ::: :::

:::quiz{id=q-3-1-s1 correct=1 explanation="Correct. [[gloss:ethereum|ETH]] on a CEX is a record in its database saying the exchange owes you 1 [[gloss:ethereum|ETH]]. The actual [[gloss:ethereum|ETH]] is recorded on one of the exchange's own addresses, controlled by the exchange's private keys. As long as the exchange is solvent, there is no visible difference between the two arrangements. When the exchange fails (FTX, Mt. Gox, QuadrigaCX), the difference becomes very visible, and not in the user's favor. Option C is wrong on its premise: nothing in the [[gloss:blockchain|blockchain]] is stored "locally on a disk" — both the [[gloss:wallet|wallet]] and the CEX account work with the same shared ledger. Option D conflates two different layers of security."} CEX A's balance and [[gloss:wallet|wallet]] B both show "1 [[gloss:ethereum|ETH]]" in your name. What is the principal difference between these two [[gloss:ethereum|ETH]]?

• Nothing — a balance is a balance, both display the same amount
• On the CEX, the [[gloss:ethereum|ETH]] is recorded on the exchange's own address, and the exchange's internal database notes that it owes you 1 [[gloss:ethereum|ETH]]; in the [[gloss:wallet|wallet]], your key controls the address on which the [[gloss:ethereum|ETH]] is recorded directly in the chain
• In the [[gloss:wallet|wallet]], the [[gloss:ethereum|ETH]] is stored locally on your disk; on the CEX, it's stored in the cloud
• In the [[gloss:wallet|wallet]], the [[gloss:ethereum|ETH]] is better protected because the [[gloss:blockchain|blockchain]] is more reliable than the cloud :::

:::section{mins=4} Seed Phrase :::

:::lead Your [[gloss:seed phrase|seed phrase]] is your [[gloss:private key|private key]], rewritten as a list of words. Not "a password to your [[gloss:wallet|wallet]]" — the [[gloss:wallet|wallet]] itself, in portable form: feed the same 12 or 24 words into any compatible program and you get back the same addresses with the same balance. :::

:::p{html} In 2013, James Howells, an IT worker from Wales, threw out a hard drive from an old IBM ThinkPad. The drive landed in a Newport landfill. On it sat a [[gloss:bitcoin|Bitcoin]] Core [[gloss:wallet|wallet]] with the [[gloss:private key|private key]] controlling roughly 8,000 [[gloss:bitcoin|BTC]] mined in 2009 — about $750 million at 2025 prices. For twelve years Howells fought for permission to excavate. In January 2025 the High Court rejected his case for the final time; the March 2025 appeal failed; the site is being closed and repurposed as a solar farm in the 2025–26 budget year. The coins are still on chain. The address is visible in any explorer, the balance has not moved since 2013. The key is under tons of garbage. :::

:::p{html} Howells's story is a literal example of the class of problem that seed phrases were invented to solve. Before 2013, "backing up" a [[gloss:wallet|wallet]] meant copying a [[gloss:wallet|wallet]].dat file: lose the disk, lose the key. In September 2013 — only months after Howells discarded his HDD — Marek Palatinus and Pavol Rusnak (the founders of Trezor) published [[gloss:bip|BIP]]-39. The standard describes how 128 or 256 bits of randomness become a list of 12 or 24 English words drawn from a fixed dictionary of 2,048. You can write the list on paper, engrave it in metal, memorize it. Any [[gloss:wallet|wallet]] implementing [[gloss:bip|BIP]]-39 will recover the same keys and addresses from those words. By 2026, the standard is supported by essentially every mainstream [[gloss:wallet|wallet]] on the market. :::

:::p{html} A [[gloss:seed phrase|seed phrase]] gets confused with three different things. It is not the MetaMask password: the password encrypts a local copy of the [[gloss:wallet|wallet]] on your specific device, and you can reset it freely as long as you still have the seed. It is not the account name shown in the UI ("Account 1"): that label is metadata layered on top of an address, with no relation to keys. It is not the exchange password: a CEX does not give you a [[gloss:seed phrase|seed phrase]], which makes sense — the keys there are not yours. Local protections (password, biometrics, PIN) and the [[gloss:seed phrase|seed phrase]] work on different layers: the first guards physical access to the device, here and now; the second lets you restore the [[gloss:wallet|wallet]] anywhere, on a new device, a year from now. :::

:::p{html} The standard has an optional extension: the [[gloss:bip|BIP]]-39 passphrase, sometimes called "the 25th word." It is an arbitrary string that the [[gloss:wallet|wallet]] mixes into the seed when deriving keys. An empty passphrase produces one set of addresses; any non-empty string produces a completely different set, unrelated to the first. The same seed plus a passphrase gives you addresses with your main balance; the same seed without it gives you an empty decoy [[gloss:wallet|wallet]]. This is what "hidden [[gloss:wallet|wallet]]" means in Trezor and Ledger. The cost: the passphrase is never written to the device, you must remember it separately, and losing it is as irrecoverable as losing the seed itself. :::

:::callout{icon=💡} A [[gloss:seed phrase|seed phrase]] works the way a genome does. DNA is a sequence of nucleotides encoding an entire future organism — every cell, every protein, every blood vessel is derived from it deterministically. The body is the implementation; the DNA is the source. Take the same DNA, place it in any suitable environment, and the same organism grows back, with the same traits. Seed phrases follow the same logic: 24 words are the "genome" of your [[gloss:wallet|wallet]], and any [[gloss:bip|BIP]]-39-compatible [[gloss:wallet|wallet]] (MetaMask, Ledger, Trezor, Rabby) will grow the same keys and addresses from them deterministically. With one caveat: living genomes mutate, seed phrases cannot. Change one word, get a different organism. And the "different organism" will be penniless. :::

:::keypoints{label="Key Points"}

• [[gloss:bip|BIP]]-39 appeared in autumn 2013 — almost in sync with the first wave of stories about lost hard drives full of bitcoins. This is not a coincidence; it is a reaction. The industry realized that a [[gloss:private key|private key]] held as a single file on a single device is a system with a single point of failure, and standardized a way to write the key in a form that can be backed up on anything.
• A [[gloss:seed phrase|seed phrase]] is the [[gloss:wallet|wallet]] in portable form, not a password to the [[gloss:wallet|wallet]]. Importing the seed into any [[gloss:bip|BIP]]-39-compatible program instantly gives access to all funds on every address derived from it. There is no "device binding," no "authorized login" — neither is needed, nor possible, given how the standard works.
• In practice, only the English wordlist matters. [[gloss:bip|BIP]]-39 defines lists in eleven languages (Russian, Japanese, and Chinese among them), but the [[gloss:wallet|wallets]] people actually use — MetaMask, Phantom, Ledger Live, Trust, Rabby — support English only. Writing a seed "in Russian" means hand-transliterating every word, which breaks the spec and the compatibility with every other [[gloss:wallet|wallet]].
• 12 words or 24 — that is the tradeoff between convenience and entropy. 12 words encode 128 bits of randomness; 24 encode 256. By 2026 [[gloss:cryptography|cryptography]], both are unbreakable by brute force; the difference will only matter once quantum computers become a real threat. Until then, the choice is about ergonomics: 12 words are easier to remember and write down; 24 are the hardware-[[gloss:wallet|wallet]] default and required for institutional-grade [[gloss:multisig|multisig]] setups. :::

:::details{badge=Advanced title="How BIP-39 Got Its 2048 Words — and Why the List Can't Be Changed"} :::p{html} Before [[gloss:bip|BIP]]-39, [[gloss:wallet|wallets]] experimented with all sorts of backup formats. [[gloss:bitcoin|Bitcoin]] Core stored [[gloss:wallet|wallet]].dat — a binary file you had to copy verbatim. Services like bitaddress.org gave you the [[gloss:private key|private key]] as a 51-character base58 string (5J3mBb...) for hand-copying, with the obvious risk of a transcription error. Brain [[gloss:wallet|wallets]] appeared: the user invented a passphrase from which [[gloss:sha-256|SHA-256]] derived the [[gloss:private key|private key]]. The idea failed catastrophically — passphrases turned out predictable, and bots running dictionary attacks emptied such [[gloss:wallet|wallets]] within minutes of the first deposit. Electrum 1.0 introduced its own mnemonic, but without a public standard, and its wordlist is still incompatible with [[gloss:bip|BIP]]-39 today. In September 2013, Marek Palatinus and Pavol Rusnak — the founders of Trezor, who were finishing the first serial-production hardware [[gloss:wallet|wallet]] — published the spec that brought the industry to a common denominator. :::

:::p{html} The dictionary design is itself a small piece of engineering. 2048 words = 11 bits per word, giving round numbers: 12 words × 11 = 132 bits (128 bits of entropy + 4 bits of checksum), 24 words × 11 = 264 bits (256 + 8). The list of 2,048 English words was selected by hand under three rules: the first 4 letters of every word are unique (so you can recover from a half-remembered word), no homophones or easily-confused pairs (no "flour" and "flower"), no semantic duplicates ("cat" but not "kitten"). The trailing checksum is not a security feature — it is a typo guard: if you wrote down one word incorrectly, the [[gloss:wallet|wallet]] rejects the phrase on import before showing any addresses. A randomly typed 12-word string has a 1-in-16 chance of passing the checksum; for 24 words it is 1 in 256. This is not "the chance of being hacked" — guessing someone else's working seed remains statistically impossible. There are 2¹²⁸ ≈ 3.4 × 10³⁸ valid 12-word phrases, about 10¹⁷ times the number of sand grains on every beach and desert on Earth. The checksum catches typos; entropy provides security. :::

:::p{html} By 2026, [[gloss:bip|BIP]]-39 has petrified. Every [[gloss:seed phrase|seed phrase]] ever generated rests on exactly the wordlist fixed in 2013: remove one word, and hundreds of millions of [[gloss:wallet|wallets]] stop validating. Could there be a "[[gloss:bip|BIP]]-39 v2" with a refreshed dictionary or a different checksum? Technically yes. Practically no — migration would require decrypting the old seed, computing the keys, moving funds to new addresses derived from a new seed. That is not a protocol upgrade; that is a forced [[gloss:transaction|transaction]] for every [[gloss:wallet|wallet]] holder on the planet. So the standard is dead in the sense of evolution and alive in the sense of use — a state that formal standards rarely reach, and almost never leave. ::: :::

:::quiz{id=q-3-1-s2 correct=1 explanation="Correct. The MetaMask password is a local encryption key for the [[gloss:wallet|wallet]] database on a specific device. It protects data "at rest" on your machine and plays no part in generating addresses. The [[gloss:seed phrase|seed phrase]] is the only carrier of key information; entering it on a new device gives you the full [[gloss:wallet|wallet]] with all addresses and balances. MetaMask will then ask for a new password — but this is a fresh local protection for the new installation. Option D is wrong by construction: MetaMask has no "support" that can reset the password or recover the key, because they do not have the key, and never did."} You install MetaMask on a new computer and enter your [[gloss:seed phrase|seed phrase]]. You don't remember the password that protected MetaMask on your old device. What happens?

• MetaMask will demand the old password and refuse access to the [[gloss:wallet|wallet]] without it
• The [[gloss:wallet|wallet]] restores in full; the password was a local protection of the old installation and has no relation to the [[gloss:seed phrase|seed phrase]]
• Some addresses restore, others do not, because the password participated in deriving them
• You need to reset the password through MetaMask support first, then import the seed :::

:::section{mins=4} Wallet Types :::

:::lead [[gloss:self-custody|Self-custody]] is not one method but a spectrum. At one end sits a browser-extension [[gloss:wallet|wallet]] with the key encrypted in a local device database; at the other, a sheet of paper in a safe at your mother's place out of town. Between them lie hardware devices, MPC providers, smart-contract [[gloss:wallet|wallets]]. The choice is always the same: convenience of access versus attack surface. :::

:::p{html} The defining question about any [[gloss:wallet|wallet]] is where the key lives. In MetaMask it is stored encrypted in a local browser database; the password decrypts it at the moment of signing. In a Ledger, the key is burned into a Secure Element — a separate chip that physically refuses to release the key to the computer, or even to Ledger Live; only a finished signature ever leaves it. In Coinbase Custody, the key is split across the provider's servers via an MPC protocol, and you have no direct access to it at all. These are three different worlds, and most practical security decisions reduce to which of them you have chosen. :::

:::p{html} In practice, [[gloss:wallet|wallets]] fall into four categories: :::

:::p{html}

• Hot software [[gloss:wallet|wallet]] (MetaMask, Rabby, Phantom — as a browser extension or mobile app): the key sits in an encrypted database on your device, protected by a password or biometrics, and the device stays online. Convenient for daily use, vulnerable to a compromised machine.
• Hardware [[gloss:wallet|wallet]] (Ledger, Trezor, Keystone): the key lives in a dedicated chip, never physically leaves the device, and the device only connects to the computer at the moment of signing.
• Custodial [[gloss:wallet|wallet]] (Coinbase [[gloss:wallet|Wallet]], Binance Web3 [[gloss:wallet|Wallet]], BitGo): the key is held by the provider, usually distributed via MPC; you reach the interface through a login and password. Not full [[gloss:self-custody|self-custody]], but not an "exchange account" either.
• Smart-contract [[gloss:wallet|wallet]] (Safe, Argent, ZeroDev): the "[[gloss:wallet|wallet]]" is a contract on the [[gloss:blockchain|blockchain]], with its own signing logic, [[gloss:multisig|multisig]], and recovery. Detailed treatment is in → 3.2.

:::p{html} The most common practical setup as of 2026 is a hybrid: Rabby or MetaMask as the UI, plus Ledger or Trezor as the signer. The software [[gloss:wallet|wallet]] only knows the public address and is used for viewing balance, choosing operations, and assembling [[gloss:transaction|transactions]] (effectively running in the watch-only mode introduced in §1); the signing itself is delegated to the hardware device, which is connected for the duration of the operation and unplugged immediately after. This is not "two [[gloss:wallet|wallets]] on one balance" but a split of roles within one: the UI handles convenience, the hardware handles key protection. Understanding this split matters more than picking any specific brand: the "best [[gloss:wallet|wallet]]" is whichever combination pairs a convenient UI with a secure signer on the devices that suit you. :::

:::callout{icon=💡} It works the way we store valuables in everyday life, in tiers. Loose change and a transit pass sit in a jacket pocket on the hallway hook: convenient, but the moment someone walks off with the coat, it's all gone. Your passport and other documents go in a desk drawer; that needs a small key, but a burglar will find it. Your grandmother's earrings and watch sit in the home safe in the bedroom; only you know the code, and forcing it takes hours. The deed to the apartment and the will go in a safe-deposit box at the bank; you have to walk in with your ID, but a fire in the apartment can't touch them. A childhood box of pressed flowers stays at your mother's place out of town, opened once a decade. Each tier has its price: the safer the storage, the slower the access. [[gloss:wallet|Wallets]] are arranged in exactly the same way. :::

:::keypoints{label="Key Points"}

• "Where the key lives" is the defining axis of classification; "hot vs cold" only follows from it. The same mobile [[gloss:wallet|wallet]] becomes cold the moment the phone is powered off and in airplane mode, and turns hot again as soon as it connects to the network. A more useful question than "is this [[gloss:wallet|wallet]] hot or cold" is "what would need to be compromised to extract the key."
• A hardware device by itself doesn't guarantee security. Security comes from using it correctly: check the address on the device screen before signing; never enter your [[gloss:seed phrase|seed phrase]] into a form on the computer, even if the page looks like Ledger Live or Trezor Suite (the real official apps never ask for it); don't buy second-hand or from boxes without factory tamper seals. Most hardware-[[gloss:wallet|wallet]] losses come from social engineering around a correctly working device.
• A custodial [[gloss:wallet|wallet]] and an exchange account are not the same, even though both fall into the "key is not yours" category. Coinbase [[gloss:wallet|Wallet]] (a product with MPC-distributed keys) ≠ an account on the Coinbase exchange: in the first case, key shares are split between you and the provider; in the second, the company holds the keys outright. The legal status of the assets and the recovery scenario in bankruptcy differ sharply between the two products.
• A smart-contract [[gloss:wallet|wallet]] is an address backed by code, not by a [[gloss:private key|private key]]. The address looks indistinguishable from an ordinary one (0x...), but the signing logic lives inside the contract itself: [[gloss:multisig|multisig]], daily limits, social recovery, [[gloss:gas|gas]] paid by someone else. The cost: bugs in the [[gloss:wallet|wallet]] code as a new class of risk. Full treatment is in → 3.2. :::

:::details{badge=Advanced title="MPC, Hardware, Smart Contracts: Three Engineering Answers to One Question"} :::p{html} MPC (Multi-Party Computation). The [[gloss:private key|private key]] never exists in one piece anywhere in the system. It is split into n shares distributed across servers (typically n=3 or more); to sign, you need t of n shares, and they compute the signature jointly without ever reconstructing the full key. An attacker who breaks into one server walks away with a useless fragment. MPC is the foundation under Fireblocks (institutional custody, with over $5 trillion in [[gloss:transaction|transactions]] processed through the system), ZenGo (consumer), Coinbase [[gloss:wallet|Wallet]], MetaMask Institutional. The trade-off: you have to trust the provider to actually distribute the shares across physical infrastructure and to implement the protocol without bugs. MPC sits between pure [[gloss:self-custody|self-custody]] and custodial holding: control is neither entirely yours nor entirely a single counterparty's. :::

:::p{html} Hardware. The key lives in a Secure Element — an isolated chip with physical tamper resistance. The signature is computed inside the chip and never leaves it, nor does the key. Ledger uses the ST33 from STMicroelectronics with CC EAL 5+ certification. The Trezor Model One and Model T historically shipped without a secure element (running on a general-purpose STM32); after a 2023 case in which Kaspersky documented a supply-chain attack with a counterfeit Trezor Model T sold through a third-party marketplace (different chip, disabled read-out protection), Trezor released the Safe 3 with its own SE on board. The trade-off is trust in the chip manufacturer, the firmware vendor, and the supply chain that delivered the device to your hands. Against remote attacks, hardware is nearly absolute; against physical ones, it is as strong as your control over the device's origin. :::

:::p{html} Smart-contract / [[gloss:account abstraction|Account Abstraction]]. The youngest of the three approaches, and the only one that changes not the medium of the key but the very concept of an account. The "[[gloss:wallet|wallet]]" is a contract on the [[gloss:blockchain|blockchain]] with its own logic: [[gloss:multisig|multisig]], limits, address whitelists, recovery through trusted parties, [[gloss:gas|gas]] paid by a paymaster. A [[gloss:private key|private key]] is still required, but only to sign operations on the contract — not to control the address directly. The ERC-4337 standard went live in March 2023; [[gloss:eip-7702|EIP-7702]] in the [[gloss:pectra|Pectra]] upgrade (May 2025) made it possible to convert an existing [[gloss:eoa|EOA]] into a smart-contract account without migrating funds. The trade-off: contract code can carry bugs, initialization costs [[gloss:gas|gas]], and standard support is uneven across chains. All three approaches solve the same problem — removing a single point of failure — from three different angles: distribute control (MPC), isolate the medium (hardware), program the rules (AA). ::: :::

:::quiz{id=q-3-1-s3 correct=1 explanation="Correct. In this setup, MetaMask acts as a UI and a watch-only observer of an address whose key is stored in the Ledger. MetaMask knows no [[gloss:private key|private key]] at all: when you go to sign a [[gloss:transaction|transaction]], it assembles the [[gloss:transaction|transaction]] data and passes it to the device, where the Ledger checks the destination address and amount on its own screen, and then returns the signed [[gloss:transaction|transaction]] back. This is the canonical "hot UI + hardware signer" hybrid, and in substance it is a hardware [[gloss:wallet|wallet]] — what defines the [[gloss:wallet|wallet]] is where the key lives. Option C is wrong: there is only one [[gloss:private key|private key]] here; MetaMask simply has no second key of its own."} You install MetaMask and connect a Ledger Nano X to it. All [[gloss:transaction|transactions]] are confirmed on the Ledger's screen. Is this a hardware [[gloss:wallet|wallet]] or a software [[gloss:wallet|wallet]]?

• Software, because MetaMask is a software [[gloss:wallet|wallet]], and the Ledger is merely connected to it
• Hardware, because the [[gloss:private key|private key]] lives in the Ledger's chip; MetaMask only works with the public address and assembles [[gloss:transaction|transactions]] for the device to sign
• A hybrid [[gloss:wallet|wallet]] — it has two independent private keys, one in MetaMask and one in the Ledger
• It depends on the configuration: if a [[gloss:seed phrase|seed phrase]] has been imported into MetaMask, it's software; if not, hardware :::

:::section{mins=4} Hot Wallets :::

:::lead A hot [[gloss:wallet|wallet]] is the most-used tool in crypto, and for that reason the most interesting to an attacker. The choice here is not "which is better" but "whose UX team is stronger, whose defensive layers are more reliable, and whom you trust to keep updating an extension in your browser for the next five years." :::

:::p{html} The hot-[[gloss:wallet|wallet]] landscape has shifted sharply over the last two years. Before 2024 the choice was simple: MetaMask for [[gloss:evm|EVM]] chains, Phantom for [[gloss:solana|Solana]], a separate [[gloss:wallet|wallet]] for every non-[[gloss:evm|EVM]] network. By May 2026 that map is obsolete. Since July 2025 MetaMask has supported [[gloss:solana|Solana]] through its Snaps framework; since December 2025, [[gloss:bitcoin|Bitcoin]] too; eleven chains are available by default. Phantom traveled the same road from the opposite side: [[gloss:ethereum|Ethereum]], Polygon, Base, and [[gloss:bitcoin|Bitcoin]] joined [[gloss:solana|Solana]], and by the end of 2025 Phantom had 15 million MAU and $25 billion in assets under custody, plus a $150 million Series C at a $3 billion valuation. Rabby has stayed deliberately [[gloss:evm|EVM]]-only — not an oversight but a positioning choice. Where the choice once turned on the chain, it now turns on UX, the depth of the defensive layer, and who you trust. :::

:::p{html} Three [[gloss:wallet|wallets]] worth considering first in 2026: :::

:::p{html}

• MetaMask (~30 million MAU): the de-facto standard, with the widest chain and DApp coverage and built-in Blockaid protection that simulates [[gloss:transaction|transactions]] before signing (Blockaid's own figures put prevented losses at over $5.3 billion since the rollout to production). Downside: no longer fully open since late 2020, when the license changed starting with MetaMask 11+. Full support for [[gloss:eip-7702|EIP-7702]] and ERC-4337.
• Rabby: built by the DeBank team, [[gloss:evm|EVM]]-only, with the best pre-signing [[gloss:transaction|transaction]] preview on the market (detailed simulation, breakdown of approvals, warnings on suspicious contracts). Open source. [[gloss:eip-7702|EIP-7702]] support is limited so far — only delegation revokes, without full AA functionality. The choice for people who live in [[gloss:evm|EVM]] [[gloss:defi|DeFi]] and want fine-grained control over every approval.
• Phantom: historically [[gloss:solana|Solana]]-first, now multichain ([[gloss:solana|Solana]] + [[gloss:ethereum|Ethereum]] + Polygon + Base + [[gloss:bitcoin|Bitcoin]]), closed source. The best mobile UX on the market, with transparent in-[[gloss:wallet|wallet]] swaps. The choice for people who came in through [[gloss:solana|Solana]] or want a single [[gloss:wallet|wallet]] across chains on a phone.

:::p{html} What separates a good hot [[gloss:wallet|wallet]] from a mediocre one in 2026 is not the number of supported chains but the protective layer between hitting "Confirm" and the real [[gloss:transaction|transaction]]. [[gloss:transaction|Transaction]] simulation (Blockaid in MetaMask, native in Rabby) shows you, before signing, exactly which tokens will leave your address; the phishing detector (lists of dangerous domains and contracts) [[gloss:block|blocks]] connections to scam sites; integration with a hardware [[gloss:wallet|wallet]] turns any hot [[gloss:wallet|wallet]] into the hybrid setup from §3. These features do more to make a [[gloss:wallet|wallet]] "good" than a pretty interface or support for a thousand tokens. :::

:::callout{icon=💡} It works like picking your daily driver. MetaMask is a Toyota Camry: everywhere, in every parking lot, fixable by any mechanic, no surprises and nothing particularly distinctive about it. Rabby is a Tesla Model 3: more "smart" features (simulation, approval breakdown, warnings), but only in the [[gloss:evm|EVM]] "region," and with its own driving style that takes getting used to. Phantom is a multi-brand dealership: one keyfob starts the [[gloss:solana|Solana]] Audi, the [[gloss:ethereum|Ethereum]] BMW, and the [[gloss:bitcoin|Bitcoin]] Toyota, with Audi — the original marque — still the priority. A hardware [[gloss:wallet|wallet]] is the safe in the garage where the keys to all the cars sit; it doesn't replace the cars themselves. The "best car" depends on where you usually drive and how many routes a day you take. :::

:::keypoints{label="Key Points"}

• MetaMask in 2026 is not the same product as MetaMask in 2023. What used to be the symbol of "the [[gloss:evm|EVM]]-only [[gloss:wallet|wallet]]" is converging with Phantom on the same form: both are now multichain, both integrate hardware, both add defensive layers. The historical split of "MetaMask for [[gloss:ethereum|Ethereum]], Phantom for [[gloss:solana|Solana]]" no longer describes reality — the choice has shifted from chain to UX and team trust.
• Pre-sign [[gloss:transaction|transaction]] simulation is the headline defensive innovation of 2024–2026. Users used to sign unreadable hex and hope. Today, Blockaid in MetaMask and Rabby's built-in simulator show concrete balance diffs: "you will spend this much [[gloss:ethereum|ETH]], you will grant this contract approval over every [[gloss:nft|NFT]] you own." This stops more losses than user education does, because it doesn't require the user to become an expert.
• Open source does not equal automatic security, but closed source is almost always a red flag. Rabby is fully open, Phantom is closed, and MetaMask has not been fully open since late 2020. Over the long run, an open codebase lowers the risk of a swap-out in the extension store and is the first to pick up new defensive layers — including the privacy-preserving features in the Kohaku framework Vitalik presented at Devconnect in November 2025 (details in the upcoming card → B3 Privacy).
• A mobile [[gloss:wallet|wallet]] and a browser extension are vulnerable to different things, not to more or less of the same things. The mobile app lives in an iOS or Android sandbox and is protected by system biometrics — but it is open to scam apps and clipboard sniffing. A browser extension is protected by an app password and runs in the same environment as the browser itself — but it is open to compromised extensions, phishing sites, and malicious dApps. Understanding the different attack models matters more than choosing "mobile or browser." :::

:::details{badge=Advanced title="How Pre-Sign Transaction Simulation Actually Works — and What It Doesn't Catch"} :::p{html} Before 2023, the [[gloss:wallet|wallet]]'s pre-signing interface showed the user the bare minimum: the recipient address, the amount, the [[gloss:gas|gas]], and a pile of hex bytes in the "data" field. What those bytes actually do — the [[gloss:wallet|wallet]] had no idea. Victims signed setApprovalForAll en masse (granting a specific contract authority over every [[gloss:nft|NFT]] in the [[gloss:wallet|wallet]]), or [[gloss:permit|permit]] (consent to spend ERC-20 tokens via a signature), or blind-signed on a hardware device (where the device just shows "sign this [[gloss:hash|hash]]"). The arrival of Blockaid (an Israeli startup out of Tel Aviv, founded in September 2022 by Ido Ben-Natan and Raz Niv, both Unit 8200 veterans; closed a $50 million Series B in February 2025, with $83 million in total funding to date) and similar built-in simulation in Rabby changed this: it became technically possible, in the milliseconds before signing, to replay the [[gloss:transaction|transaction]] against current chain state and show the user the real effect — not bytes, but balance changes. :::

:::p{html} How it works under the hood. The [[gloss:wallet|wallet]] makes an RPC call to eth_simulateV1 (supported in Geth and Reth since 2024) or a similar non-standardized call to an external API such as Tenderly. The simulator takes the chain state at the latest [[gloss:block|block]], [[gloss:fork|forks]] it in memory, executes the [[gloss:transaction|transaction]] in that [[gloss:fork|fork]], and returns the diff: which balances changed, which events were emitted, which approvals were granted. The [[gloss:wallet|wallet]] renders the diff in human form: "You will sign: −1 [[gloss:ethereum|ETH]], −$5,000 USDC, +access for contract 0x… to every [[gloss:nft|NFT]] you own in the CryptoPunks collection." If anything looks suspicious, a red banner appears. Blockaid additionally cross-checks the contract address against its registry of known scam contracts and domains. :::

:::p{html} What simulation does not catch. [[gloss:transaction|Transactions]] that behave differently under simulation and in real execution: for example, a contract can check [[gloss:block|block]].timestamp or an oracle reading and return the innocent path during simulation, while taking the attacker path in the real [[gloss:block|block]]. Messages of the signTypedData_v4 type are not [[gloss:transaction|transactions]] but structured signatures, which the simulator does not see as balance changes — and that is exactly the channel for modern phishing schemes built on [[gloss:permit|permit]] and gasless approvals. Attacks on the [[gloss:wallet|wallet]] itself — a compromised extension, a malicious update — are also outside what simulation covers. Blockaid has published numbers on $5.3 billion in prevented losses since launch; those 5 billion do not cover the whole surface — they cover exactly the attacks where simulation works. ::: :::

:::quiz{id=q-3-1-s4 correct=1 explanation="Correct. MetaMask stopped being [[gloss:evm|EVM]]-only in July 2025 with the release of [[gloss:solana|Solana]] support through its Snaps framework; [[gloss:bitcoin|Bitcoin]] followed in December 2025. As of May 2026, the [[gloss:wallet|wallet]] works with eleven chains by default. Phantom traveled the same road from the other end — once [[gloss:solana|Solana]]-only, now multichain. The historical split of "one [[gloss:wallet|wallet]] = one ecosystem" no longer describes reality, and old advice along the lines of "you need Phantom for [[gloss:solana|Solana]]" is out of date. Option A was correct in 2023 but not today; D conflates a technical question with a product preference."} A friend says: "I use MetaMask, so I can't use [[gloss:solana|Solana]] — you need Phantom for that." In 2026, this statement is:

• Correct: MetaMask only works with [[gloss:evm|EVM]] chains, and [[gloss:solana|Solana]] requires a separate [[gloss:wallet|wallet]]
• Out of date: since July 2025 MetaMask has supported [[gloss:solana|Solana]] through the Snaps framework, and since December 2025 it has supported [[gloss:bitcoin|Bitcoin]]
• Depends on the MetaMask version — it works on desktop but not in the mobile app
• Technically correct, but most users don't need [[gloss:solana|Solana]] anyway :::

:::section{mins=4} Hardware Wallets :::

:::lead A hardware [[gloss:wallet|wallet]], on its own, does not guarantee security — it shifts the risk from the software layer to the physical one. Over time, that swap pays off for amounts whose loss would actually sting. For a couple of hundred dollars, hardware is overkill, and a misconfigured device is more dangerous than the risk it was supposed to close. :::

:::p{html} When you sign a [[gloss:transaction|transaction]] through a hardware [[gloss:wallet|wallet]], here is what happens. A program on your computer (MetaMask, Ledger Live, Trezor Suite) assembles the raw [[gloss:transaction|transaction]] and sends it to the device over USB or Bluetooth. The device shows the recipient address and the amount on its own screen; you confirm with physical buttons or a touch; the device sends the signature back. The [[gloss:private key|private key]] never leaves the chip during this — it lives inside a Secure Element, an isolated chip with physical tamper resistance. That is what "hardware security" actually means, no more and no less. Everything else (the app UI, chain coverage, swap features) is built on top of this minimal primitive. :::

:::p{html} As of 2026, three devices are worth considering: :::

:::p{html}

• Ledger Nano S Plus / X / Stax / Flex: the market leader, with the ST33 Secure Element from STMicroelectronics certified at CC EAL 5+. The firmware is closed, which works technically but is politically fraught (see KP1 on Ledger Recover). The Nano X and Stax have Bluetooth: a trade-off between UX and attack surface. Stax and Flex use an E-Ink touchscreen and cost more.
• Trezor Safe 3 / Safe 5 / Safe 7: open-source firmware, which is critical for audit. The Safe 3 (October 2023) was Trezor's first device with a Secure Element (NDA-free EAL 6+); the Safe 5 (June 2024) added a touchscreen and haptic feedback; the Safe 7 (October 2025) introduced Bluetooth, magnetic charging, and a second secure element, TROPIC01, advertised as resistant to quantum attacks. The Trezor Model One and Model T historically shipped without an SE, and the Safe line was built to close that gap.
• Keystone 3 Pro: fully air-gapped, with no USB data, Bluetooth, or Wi-Fi. The [[gloss:transaction|transaction]] travels between computer and device via QR codes: the computer shows the raw [[gloss:transaction|transaction]] as a QR, the Keystone scans it with its camera, the device displays a signed QR, and the computer scans it back. Three Secure Element chips (Microchip ATECC608B, Maxim DS28S60, Maxim MAX32520) handle three different functions; open source. The cost of the air-gapped approach: every [[gloss:transaction|transaction]] takes noticeably longer, but the attack surface narrows to a camera and a screen.

:::p{html} When hardware actually pays for itself. If you have an amount on-chain whose loss would be painful (somewhere around $5,000 and up — a subjective threshold, but roughly the industry [[gloss:consensus|consensus]]), and you use that amount regularly, hardware is justified. If you only have $200 in the [[gloss:wallet|wallet]] and you're just getting started, hardware is more often a source of risk than a defense: you can lose the device, forget the seed, buy a counterfeit, configure it wrong. Security is not the device itself but the process around it; buying hardware without a real process gives a false sense of safety and nothing more. :::

:::callout{icon=💡} It works the way an ATM PIN-pad works. You insert your card (= open the app on the computer), but you don't enter the PIN on the computer's keyboard, or on the cashier's laptop, or in a form on the bank's website — you enter it on a separate physical keypad built into the ATM, engineered so that the PIN you typed never leaves the device. The bank only receives the verdict, "right/wrong," not the code itself. Cameras above can film your hands, the ATM might stand in a foreign country, but it does not matter: the critical operation is offloaded to an isolated physical module that no one but you controls in the moment you press the keys. A hardware [[gloss:wallet|wallet]] does the same thing for signing [[gloss:transaction|transactions]]: the computer can be infected, the [[gloss:wallet|wallet]] app can be compromised, but the signature is computed inside the device, and only the result leaves it. :::

:::keypoints{label="Key Points"}

• Ledger Recover, May 2023 — the pivot point in how people think about hardware [[gloss:wallet|wallets]]. Ledger announced an optional service at $9.99 per month: the device would extract encrypted shards of the [[gloss:seed phrase|seed phrase]] and distribute them across three custodians (Ledger, Coincover, EscrowTech), letting users recover access through KYC. The community reaction was massive, because making that feature possible at all meant the firmware had to be able to export the seed — and that contradicted the central promise of hardware [[gloss:wallet|wallets]]: "the key does not leave the device." The service shipped anyway in October 2023, but trust in closed firmware was permanently damaged; the episode made open-source firmware a hot topic and elevated Trezor as the alternative.
• Bluetooth in hardware [[gloss:wallet|wallets]] is a trade-off between UX and attack surface. Ledger Nano X, Stax, Flex, and the new Trezor Safe 7 carry Bluetooth so they can connect to a phone without a cable. The link is encrypted, signatures are still confirmed on the device screen, but the attack surface really does grow physically: over the last five years, several serious vulnerabilities have been found in the Bluetooth stack (BLE [[gloss:pairing|pairing]] exploits, the KNOB attack). They do not extract the key, but they can fool the user at the protocol level. Air-gapped devices (Keystone) deliberately avoid this surface — different bets for different threat models.
• Owning hardware ≠ using it correctly. The main mistakes: typing the seed into the computer "for migration" or recovery; one [[gloss:seed phrase|seed phrase]] covering a large amount with no passphrase; ignoring the address on the device screen during confirmation; running a single seed across everything without splitting hot and cold storage. Hardware amplifies your procedures; it does not replace them. Without procedures, any Ledger or Trezor is just an expensive USB stick.
• "Hardware [[gloss:wallet|wallet]]" and "cold storage" are overlapping but not identical concepts. Hardware describes where the key lives (inside the device's chip). Cold/hot describes how isolated the device is from a networked environment. A Ledger Nano X with Bluetooth on is hardware but not cold; an air-gapped Keystone 3 Pro is both hardware and cold; a paper sheet with a [[gloss:seed phrase|seed phrase]] in a safe is cold but not hardware at all. Whenever you read or hear "cold storage," ask what is actually meant; otherwise you compare two axes at once and reach the wrong conclusion easily. :::

:::details{badge=Advanced title="What a Secure Element Actually Is — and What It Doesn't Protect"} :::p{html} A Secure Element is a microprocessor with physical tamper resistance built in. Inside: NVRAM protected from external reads, a hardware random-number generator (TRNG), hardware accelerators for cryptographic operations. The chip passes Common Criteria certification, the industry standard, where EAL 5+ and EAL 6+ describe different levels of depth in formal verification and penetration testing at certified labs (for example, ANSSI in France for the Ledger ST33). The goal is to make the cost of physically breaking the chip higher than the value of the key on the device. That works for individual holdings in the tens of thousands of dollars and fails against a targeted attack on an address holding hundreds of millions: at a $100M prize, an attacker can easily afford the budget for decapping and microprobing. One specific nuance is the "NDA-free" status: the Trezor Safe 3/5 use an EAL 6+ chip that does not require signing an NDA with the manufacturer, so the attestation can be independently audited. The Ledger chip requires an NDA and is closed to outside audit. :::

:::p{html} What a Secure Element protects against, and what it doesn't. Protects against: physical key extraction (decapping, side-channel attacks, fault injection); PIN brute force (a limited attempt count plus delays between tries); firmware that an attacker tries to flash without confirmation on the device. Does not protect against: bugs in the driver code between the SE and the microcontroller (the Trezor One was vulnerable not because of an SE — there was none — but because the general-purpose STM32 could be opened with a couple of days of engineering effort); UI-level social engineering (Trezor Suite shows one address, the device shows another; the user didn't compare and approved anyway); supply-chain attacks (the counterfeit Trezor Model T from 2023, described in §3 advanced); phishing [[gloss:transaction|transactions]] that the user signed themselves — the device displayed the [[gloss:transaction|transaction]], the user pressed "Confirm," the key stayed inside, and the funds went out. A Secure Element closes one class of risks; the rest remain. :::

:::p{html} Air-gapped as a third layer of isolation. The Keystone 3 Pro and the GridPlus Lattice1 reject any connection to a computer on principle: no USB data, no Bluetooth, no Wi-Fi. [[gloss:transaction|Transactions]] pass via QR codes: the computer shows a QR of the raw [[gloss:transaction|transaction]], the device scans it through its camera, computes the signature internally, displays a signed QR, and the computer scans it back. The attack surface shrinks to a QR scanner and a camera — much smaller than the USB stack with twenty years of accumulated vulnerabilities. The cost: every [[gloss:transaction|transaction]] takes longer; you have to physically aim the camera at the screen; firmware updates arrive on a microSD card rather than over the internet. Air-gapped and SE-based hardware are different answers to different threat models: the first isolates the whole device from the network, the second isolates the chip inside a connected device. Each is right for its own threat model. ::: :::

:::quiz{id=q-3-1-s5 correct=1 explanation="Correct. A hardware [[gloss:wallet|wallet]] and "cold storage" are two overlapping but distinct concepts. Hardware describes where the key lives (inside the device's chip). Cold/hot describes the level of isolation from a networked environment. A Ledger with Bluetooth is hardware, but classifying it as cold storage is incorrect: the device opens a wireless link to a phone that is on the network and computes signatures in response to requests from that network. Cold storage in the strict sense means air-gapped solutions (a Keystone 3 Pro with QR codes, a paper [[gloss:wallet|wallet]] with a [[gloss:seed phrase|seed phrase]], a hardware device in offline mode with no connection at all). Option D is fabricated and wrong on substance: iPhone model and iOS version do not affect the classification."} You have a Ledger Nano X with Bluetooth, and you use it through an iPhone. Can this configuration be called "cold storage"?

• Yes: a hardware [[gloss:wallet|wallet]] equals cold storage by definition, regardless of how it connects
• No: "hardware" and "cold" are different axes. A Ledger with Bluetooth is hardware but not cold; cold implies the full absence of wireless or wired connection to a networked device
• Yes, but only when Bluetooth is turned off in the device settings
• It depends on the iPhone model — on older iPhones with iOS up to 16 it's cold, on newer ones it's warm :::

:::section{mins=4} Backup & Recovery :::

:::lead Most people make a backup once, drop the sheet of paper in a drawer, and forget about it for years. The house can burn, the paper can fade, the drawer can quietly become accessible to more than just you. A good backup is not a one-time act but a process with three properties: fire-resistant, distributed across several places, and tested. :::

:::p{html} In 2011 the programmer Stefan Thomas received 7,002 [[gloss:bitcoin|BTC]] for producing a short explainer video on how [[gloss:bitcoin|Bitcoin]] works. At the time the whole amount was worth less than $7,000. Thomas wrote the [[gloss:seed phrase|seed phrase]] on a sheet of paper and duplicated the keys onto an IronKey S200 USB drive — a device with military-grade data protection, known for one feature in particular: after ten wrong password attempts, it irreversibly wipes its contents. Thomas lost the paper with the [[gloss:seed phrase|seed phrase]]; the IronKey password he "would absolutely remember forever," he also forgot. When [[gloss:bitcoin|Bitcoin]] appreciated, Thomas began trying to recover the password: eight attempts, none worked, two left. As of late 2025 the IronKey sits in a Swiss vault. Over eight months in their lab, the firm Unciphered found a way to bypass the IronKey S200's attempt counter and demonstrated a working method to a Wired journalist on a test device; Thomas declined their offer, because he had previously made verbal commitments to two other teams and was legally bound by them. At May 2026 prices, those 7,002 [[gloss:bitcoin|BTC]] in the IronKey are worth roughly $880 million. This is not a story about a lost key; it is a story about a lost backup of the key, and the only copy still in existence now sits behind a wall that cannot be crossed in the remaining two attempts. :::

:::p{html} Three properties follow from Thomas's story that any real backup needs to have: :::

:::p{html}

• Physical durability. Paper burns, fades, gets soaked. Metal (Cryptosteel, Billfodl, SafePal Cypher, Trezor Keep Metal) is the standard for long-term storage: an engraved plate costs $40–$120 and survives fire, flood, and physical crushing. For 24 words this is a one-time purchase that lasts decades.
• Distribution. A single copy in one place is a single point of failure. Minimum two copies in different physical locations: at your home plus in a safe-deposit box; with you plus with a close family member; with you plus in an office safe. The goal is that no single event destroys both locations at once.
• Verifiability. You cannot know whether the backup works until you have actually used it. A test recovery is the only way to be sure: write the seed → create a [[gloss:wallet|wallet]] from that record alone on a clean device → check the addresses against the originals → wipe the test [[gloss:wallet|wallet]]. A one-time procedure of about an hour; the alternative is to wait for the disaster and discover that one of the 24 lines didn't come out the way you wrote it.

:::p{html} For amounts of $10,000 and up, an ordinary [[gloss:seed phrase|seed phrase]] on a single plate is no longer sufficient: a single point of failure becomes too valuable a target. Shamir SLIP-39 is a standard for splitting a seed into N shares with a threshold m of n: 3-of-5, for example, means five shares held by five different people or places, any three of which reconstruct the full seed, while one or two compromised or lost shares leave the balance safe. It is supported by Trezor Safe 3/5/7, Keystone 3 Pro, and a number of software [[gloss:wallet|wallets]] (Electrum, Sparrow, Rabby, BlueWallet). Social recovery in smart-contract [[gloss:wallet|wallets]] (Argent, Safe) solves a similar problem through a contract: m of n designated "guardian" addresses can reassign control of the [[gloss:wallet|wallet]] if the primary key is lost. SLIP-39 protects the backup itself; social recovery protects access to the contract. Details in → 3.2. :::

:::callout{icon=💡} It works like an evacuation plan in a building. Every office and every school has diagrams on the walls with red arrows marking routes to the exits, with drills run twice a year. It looks redundant — until nothing happens. But the point of those drills is not the evacuation on an ordinary Tuesday; it is that on the day of a real fire, when the hallway fills with smoke and the alarm makes thought impossible, your feet know the route on their own. A plan never rehearsed becomes a piece of paper on the wall in a crisis: nobody has the minute it takes to read it. A seed-phrase backup behaves the same way: knowing the sheet is in the drawer is useless if you have never run a recovery end to end. When the main [[gloss:wallet|wallet]] is unreachable, you act in a rehearsed sequence rather than work out an unfamiliar interface for the first time. :::

:::keypoints{label="Key Points"}

• The main mistake is treating it as a one-time act. Most users write down a [[gloss:seed phrase|seed phrase]] exactly once: at the moment the [[gloss:wallet|wallet]] is created, in a hurry, under pressure from the UI. They put it in a drawer and forget. The typical outcome a few years later is "I have a backup, I think, but it's not clear whether it's still readable, whether everything is on it, what medium it's on, or whether it's even the right seed." A good backup is a calendar item: once a year check the physical medium for legibility, once every three years copy it onto a fresh one, run a test recovery.
• Never photograph the [[gloss:seed phrase|seed phrase]], and never store it in the cloud. A screenshot in the phone's gallery, a photo in Google Photos, a note in iCloud, a message to yourself in Telegram — all of these sync to the companies' servers and end up in their backups, in their machine-learning pipelines, and in their potential breaches. Attacks on iCloud and Google accounts are mass-market and constant. The seed should only exist on a physical medium (paper, metal, head) and nowhere else. The moment you take a photo "for a minute, just to transfer it," consider the seed compromised.
• The passphrase needs to be backed up separately from the seed. From §2: the passphrase is the "25th word" that turns one seed into multiple different [[gloss:wallet|wallets]] under different passphrases. If you write the seed and the passphrase on the same plate or seal them in the same envelope, the whole point of the passphrase is lost: whoever finds that medium takes both halves at once and walks straight into the main [[gloss:wallet|wallet]]. The passphrase lives on a separate medium, in a separate place, or in your head — but deliberately, and tested before you need it.
• A seed backup is not a backup of your addresses. The [[gloss:seed phrase|seed phrase]] reconstructs the private keys and all the addresses derived from them along the standard derivation path. But the list of which chains and tokens you used, which labels you put on addresses, which watch-only positions you set up — that is a separate layer the seed does not cover. After recovery you have to enable each chain and token by hand; for the most active ones this happens automatically, but rarely used chains have to be added explicitly — otherwise the balances simply will not show up in the interface. :::

:::details{badge=Advanced title="SLIP-39, Multisig, Social Recovery: Three Engineering Approaches to Distributed Custody"} :::p{html} SLIP-39 (Shamir backup). A secret-sharing algorithm based on Adi Shamir's 1979 scheme: the secret is encrypted and split via polynomial interpolation into N shares, m of which suffice to reconstruct it, while m−1 reveal nothing about the secret at all. The SLIP-39 standard was published by SatoshiLabs in late 2017, first implemented in the Trezor Model T in summer 2019, and made the default backup type for the Trezor Safe line in June 2024. As of 2026, SLIP-39 is supported by Trezor hardware [[gloss:wallet|wallets]] (Safe 3/5/7, Model T on firmware 2.7.2+) and the Keystone 3 Pro, plus the software [[gloss:wallet|wallets]] Electrum, Sparrow, Rabby, BlueWallet, and Wasabi. The shares (recovery shares) are encoded as 20-word or 33-word phrases drawn from a separate 1,024-word dictionary, distinct from [[gloss:bip|BIP]]-39's: every word has a unique four-letter prefix and the checksum is stricter (a 1-in-a-billion chance of error against [[gloss:bip|BIP]]-39's 1 in 16). The use case is protecting the backup of the seed: one compromised share leaves the balance safe; m shares assembled together reconstruct the seed. :::

:::p{html} [[gloss:multisig|Multisig]]. The classical model: M-of-N signatures are required to execute every [[gloss:transaction|transaction]]. [[gloss:bitcoin|Bitcoin]] has supported [[gloss:multisig|multisig]] natively in scripts since 2012; [[gloss:ethereum|Ethereum]] supports it through [[gloss:smart contract|smart contracts]], the most prominent of which is Safe (launched as Gnosis Safe in 2017), holding over $100 billion as of 2026. [[gloss:multisig|Multisig]] is not a backup but a real-time split of control: every outgoing [[gloss:transaction|transaction]] requires M of N keys to sign (2-of-3 or 3-of-5, for example). This protects against the compromise of a single key: even if the attacker has one key, they cannot [[gloss:move|move]] funds without signatures from the others. The cost is the friction in day-to-day use: every transfer requires coordinating signatures from several devices or people, which is often impractical for ordinary payments. :::

:::p{html} Social recovery. Works only in smart-contract [[gloss:wallet|wallets]]. N guardians are designated — other addresses (friends, your own devices on different platforms, custodian services); any M of them can initiate a change of ownership of the [[gloss:wallet|wallet]] contract. Argent was the first mass-market product with social recovery in 2019; Safe later added a guardian module. This is a split of recovery rights, not signatures: day-to-day [[gloss:transaction|transactions]] are still made with the primary key, and the guardians come in only for the "key lost, need to reassign control" scenario. Compared with SLIP-39 and [[gloss:multisig|multisig]]: social recovery protects against losing the key, but not against its compromise (if the attacker obtained the key, they have time to drain the funds before the guardians hear anything; [[gloss:multisig|multisig]] closes this vector). The three approaches solve three different problems: SLIP-39 covers durability of the backup, [[gloss:multisig|multisig]] covers protection of the signature, social recovery covers recovery of lost access. ::: :::

:::quiz{id=q-3-1-s6 correct=1 explanation="Correct. This is Stefan Thomas's scenario in miniature. The [[gloss:seed phrase|seed phrase]] itself is physically written on the drive — it is not lost. But it cannot be read: the encryption requires a password, the password is on a slip of paper, and the slip of paper is gone. The practical outcome for the user is the same as losing the seed: no access to the keys. The lesson: an encrypted backup creates a new single point of failure — the encryption password. The backup should be either an unencrypted seed on a physical medium with proper protection (a fireproof safe, a safe-deposit box), or the seed and the encryption password on separate media in separate physical locations. Option D is fabricated and wrong: neither Apple, the drive manufacturer, nor the [[gloss:wallet|wallet]] vendor can decrypt the contents without the original password — otherwise the encryption would be meaningless."} You have an encrypted USB drive with a backup of your [[gloss:seed phrase|seed phrase]]. You wrote the encryption password on a slip of paper and put it in a desk drawer. Five years later you find the drive, but the slip of paper is no longer in the drawer. Is this a lost [[gloss:seed phrase|seed phrase]], or something else?

• Yes, the [[gloss:seed phrase|seed phrase]] is lost — it can no longer be read off the drive
• No, the [[gloss:seed phrase|seed phrase]] is intact — what's lost is the encryption password for the backup; the phrase itself still sits on the drive, behind a wall you cannot cross
• Technically the seed is still on the drive, but legally it's no longer yours
• You need to take the drive to an Apple Store — they can decrypt the contents :::

:::section{mins=7} Wallet Security :::

:::lead Crypto has no "customer support" that can roll back a mistaken [[gloss:transaction|transaction]]. [[gloss:wallet|Wallet]] security is not a single trick or a single device but a set of habits you build before you need them. After is too late, and that word is meant literally here. :::

:::p{html} On December 20, 2025, a single user lost 49,999,950 USDT — almost $50 million — in one [[gloss:transaction|transaction]]. Here is the scenario. The user withdrew funds from Binance to their own [[gloss:wallet|wallet]] and, as is common practice before a large transfer, sent a test [[gloss:transaction|transaction]] of 50 USDT to verify the address. The test went through. Twenty-six minutes later the user copied the address from their [[gloss:wallet|wallet]]'s history and sent the remaining $50 million there. The attack began at the moment of the test [[gloss:transaction|transaction]]: the attacker's automated script saw it, generated a counterfeit address whose first five and last four characters matched the real one, and in that same minute sent the victim a zero-USDT transfer (with amount=0) from that address. The fake address now sat in the [[gloss:wallet|wallet]] history right next to the real one. The victim copied "their" address, checked the leading and trailing characters, and did not notice the substitution. The money was gone. Over the next 30 minutes the attacker swapped USDT for DAI (to get ahead of any Tether freeze), then for [[gloss:ethereum|ETH]], then routed everything through Tornado Cash. Recovery is impossible. :::

:::p{html} This attack is called address poisoning, and it does not exploit a single technical vulnerability. It exploits the human habit of checking an address by its ends. Over the course of 2025, address poisoning became the leading threat against large [[gloss:wallet|wallets]]: by Chainalysis and SlowMist's numbers, total losses to the scheme passed $3.4 billion; 158,000 attacks were recorded against roughly 80,000 victims. The main defensive practices for 2026: :::

:::p{html}

• Check the address in full, not by the ends. Once you've copied it, look at all 42 characters, not just the first and last six. Matching 5 characters on each side takes a few hours of GPU work for an attacker; matching the full address would take billions of years, and nobody bothers.
• Revoke approvals on a schedule. Every setApprovalForAll or [[gloss:permit|permit]] you sign stays in force forever until explicitly revoked. Services like revoke.cash and ScamSniffer show the active approvals on your address; once a quarter it makes sense to revoke the ones you no longer use.
• A separate [[gloss:wallet|wallet]] for airdrop pages and [[gloss:nft|NFT]] mints. Any [[gloss:transaction|transaction]] of the form "press Claim and receive tokens" is a potential vector through approval. If the page turns out to be phishing, the attacker drains everything that [[gloss:wallet|wallet]] had approved. The solution: a separate seed for risky activity, holding none of the main balance.
• "Support never messages first." Any DM in Discord, Telegram, or Twitter — or any email from "the project team," "MetaMask Support," or "Ledger Helpdesk" — is an attack, without exception. Real teams only reply in public channels and do not come to you in private.

:::p{html} If you have already signed something suspicious and are seeing strange [[gloss:transaction|transactions]], the first minutes matter: :::

:::p{html}

• Immediately disconnect every DApp connection in the [[gloss:wallet|wallet]] settings. This stops signature requests from the attacker's site, but does not [[gloss:block|block]] your own transfers — the [[gloss:wallet|wallet]] is still usable.
• Use revoke.cash to revoke every active approval on that address. This [[gloss:block|blocks]] the ability to drain tokens later under already-granted permissions.
• Create a new [[gloss:wallet|wallet]] with a new seed on a clean device and [[gloss:move|move]] everything that's left over to it. Never reuse the compromised seed again, even on a "cold" slice of holdings — it is treated as permanently burned.

:::p{html} Recovering already-stolen funds is not possible: [[gloss:transaction|transactions]] are irreversible, and attackers cash out in minutes. :::

:::callout{icon=💡} Security in crypto works the way hygiene does in ordinary life. Nobody washes their hands because they are about to get sick right now; people wash because otherwise, sooner or later, they catch what is always going around. Vaccinations happen years before any possible encounter with the disease; checkups happen when nothing is wrong; teeth are brushed twice a day, no drama. Each action, in isolation, looks redundant, and any single day you could skip any of them with no visible consequence. The effect shows up not in one day but across a decade. [[gloss:wallet|Wallet]] security works the same: checking an address in full, revoking approvals on a schedule, not connecting unfamiliar sites — these are not moves against today's threat but habits that make catastrophe unlikely across all the years of use. Doing none of them is the same as never washing your hands: one episode passes without consequence, and a year later somebody ends up in the hospital. :::

:::p Try address poisoning hands-on — pick the matching address from four rounds of increasing [[gloss:difficulty|difficulty]], and see why the December 2025 $50M victim never stood a chance. :::

:::keypoints{label="Key Points"}

• Address poisoning grows every year precisely because technology cannot defend against it. Generating a vanity address that matches 4–5 characters on each side takes about 10 minutes on a midrange GPU and 5 cents of electricity; matching 8 characters on each side runs to a few hours. An attacker runs thousands of attempts a day in parallel against thousands of victims. The only countermeasure is to change user behaviour: check the address in full, use an address book or an ENS name rather than copying from history. [[gloss:wallet|Wallets]] are adding warnings, but warnings do not close off the class of attacks.
• A smart-contract approval is a long-term risk, not a one-time action. Every setApprovalForAll and [[gloss:permit|permit]] you have signed stays active until explicitly revoked. The contract you granted access to three years ago for a single [[gloss:transaction|transaction]] still has that right today — and if a vulnerability has since been found in it or it has changed hands to a new team, your tokens are at risk. The leading attack vector against older [[gloss:defi|DeFi]] accounts in 2024–2026 has been exploits in forgotten approvals.
• [[gloss:permit|Permit]] and signTypedData are exactly what the [[gloss:transaction|transaction]] simulation from §4 does not catch. Blockaid and Rabby simulate [[gloss:transaction|transactions]] and show concrete balance diffs before signing; but [[gloss:permit|permit]] messages are not [[gloss:transaction|transactions]] — they are off-chain signatures, deferred in time. The effect appears later, when the attacker themselves uses the signature through their own contract. This is precisely why, through 2026, the share of phishing attacks via [[gloss:permit|permit]] and Permit2 continues to grow: the pre-sign simulator has no warning to give.
• The "support never messages first" heuristic works in reverse too: even when you are the one looking for help — on a forum, in a project's chat, from an unknown "expert" — apply the same rules. Never show your [[gloss:seed phrase|seed phrase]] to anyone under the pretext of "verifying that it's real"; never sign a message with your [[gloss:wallet|wallet]] to anyone under the pretext of "proving the address is yours"; never connect your [[gloss:wallet|wallet]] to unfamiliar "diagnostic tools." This pattern is the main channel for attacks on newcomers who have hit a problem for the first time and are looking for advice in the wrong places. :::

:::details{badge=Advanced title="How Permit2 Phishing Works — and Why Simulation Doesn't Stop It"} :::p{html} Permit2 is a Uniswap standard introduced in 2022. The idea: replace expensive on-chain approve [[gloss:transaction|transactions]] with off-chain signatures that the Permit2 contract accepts as proof of authorization. Technically it works like this: the user signs a structured message through signTypedData_v4 following the [[gloss:eip-712|EIP-712]] specification, with fields for spender (who is authorized), amount (how many tokens), deadline (its expiry time). The signature itself is not sent on-chain — it is held by whoever initiated the operation. When the signature is needed, the initiator passes it to the Permit2 contract, which validates it and moves the tokens. The UX win: the user saves [[gloss:gas|gas]] on the approve. The risk vector: the signature exists as a data object that can be used by an attacker at any time before the deadline. :::

:::p{html} The attack scenario. The victim lands on a phishing site disguised as a legitimate DApp — a Uniswap clone, a fake airdrop page, a bogus "mint [[gloss:nft|NFT]]." The site requests a [[gloss:wallet|wallet]] connection; this is a harmless action, not a [[gloss:transaction|transaction]], and the [[gloss:wallet|wallet]] does not warn about it. The site then shows a Claim, Verify account, or Approve and continue button. The victim clicks; MetaMask opens a signing request via signTypedData_v4. Inside that request is a Permit2 message with spender set to the attacker's address and amount set to the victim's entire balance for that token. Blockaid simulates the signature but sees no balance change: the signature does not produce one, and the effect is deferred. The victim sees a message that reads "signature for approval," presses Sign. The attacker takes the signature, submits it to Permit2, and every token listed flows to their address. Only seconds pass between the signature and the drain. :::

:::p{html} Defense. Several layers, working together: :::

:::p{html}

• Don't sign signTypedData_v4 without understanding the values in the spender, amount, and deadline fields. Rabby displays these fields in human-readable form — that part is critical.
• Regularly revoke active Permit2 permissions through the permit2.io or revoke.cash interface.
• For large amounts, keep a separate address that no DApp connects to at all, not even to view the balance. This is the most reliable defense against signature attacks: an address that isn't connected can't be asked to sign.
• A simple five-second pause before pressing Sign on any request. Attacks rely on fast reactions; slowing yourself down is the only defense that works universally, because it doesn't depend on software or device, only on the person.

:::p{html}

• Не подписывать signTypedData_v4 без понимания значений полей spender, amount, deadline. Rabby показывает эти поля в человекочитаемом виде — это критично.
• Регулярно отзывать активные Permit2-разрешения через интерфейс permit2.io или revoke.cash.
• Для крупных сумм держать отдельный адрес, к которому никакой DApp не подключается вообще, даже на просмотр баланса. Это самая надёжная защита от подписей: не подключив адрес, его и подписать не попросят.
• Простая пауза в 5 секунд перед нажатием Sign в любом запросе. Атаки рассчитаны на быстроту реакции; замедление себя — единственная защита, которая работает универсально, потому что не зависит ни от ПО, ни от устройства, а только от человека.

:::quiz{id=q-3-1-s7 correct=1 explanation="Correct. This is a classic address poisoning. The attacker generated a counterfeit address whose leading and trailing characters match yours and sent you a 0-USDT transfer so that the address would appear in your [[gloss:wallet|wallet]] history right next to the real ones. The bet is that on your next large transfer you will copy the address from history, check the ends, and miss the substitution. What to do: don't react to the transfer itself (it's harmless), but on future [[gloss:transaction|transactions]] always copy the address from a verified source (your address book; a test transfer made shortly before the main one; best of all, an ENS name or a QR code from the counterparty) — not from history. Tether does not send 0-USDT to "synchronize" anything; exchanges do not run "address tests" unprompted; "gifts from strangers" in crypto are never innocent."} An entry appears in your [[gloss:wallet|wallet]] history for an incoming 0-USDT transfer from an unfamiliar address. The first five characters of that address match yours, and the last four do too. What is this?

• A system [[gloss:transaction|transaction]] — Tether sometimes sends 0-USDT to synchronize balances
• Address poisoning: the attacker "poisoned" your [[gloss:transaction|transaction]] history with a counterfeit address so that you accidentally copy it on your next transfer
• A gift from an unknown user; it means nothing, ignore it
• A test [[gloss:transaction|transaction]] from your own exchange — check your Binance/Coinbase account :::