Wallets and Key Management

3.7 million Bitcoin are lost forever. That's $150 billion locked in the blockchain with no way to access them. The reason? People lose 256-bit numbers. A forgotten Gmail password is recovered in a minute. A forgotten seed phrase is a verdict with no appeal. An industry managing trillions of dollars cannot be built on 'write down 24 words and don't lose the paper'. From HD wallets, where one seed generates infinite keys, through MPC, where the key never exists whole anywhere in the world, to account abstraction, where a fingerprint login replaces a cryptographic ceremony - this is the story of how blockchain learns to be convenient without sacrificing security.

• **Ledger** has sold 6+ million hardware wallets - people pay $80-400 for a device whose sole function is to securely store a 256-bit number
• **Safe (Gnosis Safe)** holds $100B+ in smart contract wallets with multisig - the largest DAOs and protocols do not trust a single key
• **Coinbase** launched Smart Wallet with passkeys - Face ID login, no seed phrase, gas sponsored via ERC-4337 paymaster

Предварительные знания

• Digital Signatures: ECDSA and EdDSA

HD Wallets: one seed - infinite keys

Early Bitcoin wallets (Bitcoin Core before v0.13) generated each private key **independently**. The `wallet.dat` file contained a pool of 100 random keys. Creating a new address added the key to the file. Losing the file meant losing all funds. Restoring an old backup revealed that new addresses created after the backup **were not restored**.

**BIP-32** (Hierarchical Deterministic Wallets) solved this problem radically: all keys are derived from a **single master seed** through a deterministic function. One number (256 bits) generates an infinite tree of child keys. One backup - all addresses restored, including those that will be created in the future.

A **derivation path** is an 'address' in the key tree. The path `m/44'/60'/0'/0/0` is read as: - `m` - master key - `44'` - BIP-44 standard (hardened) - `60'` - Ethereum (coin type per SLIP-44: Bitcoin = 0, Solana = 501) - `0'` - first account - `0` - external chain (receive addresses) - `0` - first address The apostrophe `'` means **hardened derivation**: the child key cannot be computed from the extended public key. Without hardened levels, the leakage of a single child private key + xpub exposes **all** keys in the branch.

**Extended Public Key (xpub)** - allows generating all **public** keys in a branch without access to private ones. This is invaluable for watch-only wallets: an accountant can see all company transactions but cannot spend funds. However, sharing xpub is dangerous: whoever knows your xpub can see **all** your addresses and balances.

**Hardware wallets** (Ledger, Trezor, GridPlus) store the master seed in a **secure chip** (Secure Element). Private keys never leave the device: the transaction is signed inside the chip, and only the signature goes out. Even if the computer is infected with a virus, the seed is safe.

**Ledger Recover (2023)** caused a scandal: Ledger added a feature to shard the seed phrase and send encrypted parts to servers. The crypto community reacted harshly - if the seed can leave the chip, then the Secure Element is not so secure after all. Ledger made the feature optional, but trust was shaken.

BIP-39: mnemonic phrases

A master seed is 256 bits of entropy. In hex this looks like: `7f8a3c...d4e1b9` (64 characters). Impossible to memorize, easy to make a mistake copying. **BIP-39** solves this by encoding the entropy as a sequence of **ordinary words** from a dictionary of 2048 words.

The **checksum** is a built-in integrity check. If one word is written incorrectly, the wallet will detect the error on recovery. But checksum does not catch all errors - it is only 4-8 bits. Two random words will match the checksum with a probability of ~1/16 for a 12-word phrase.

**Passphrase (25th word)** - an optional password added when deriving the seed from the mnemonic: `seed = PBKDF2(mnemonic, "mnemonic" + passphrase, 2048, 64)` Different passphrases generate **different wallets** from the same mnemonic. This enables 'plausible deniability': real funds in the passphrase wallet, and an empty wallet (without passphrase) as a decoy under physical coercion.

**The main mistakes when storing a seed phrase:** 1. **Photo** - syncs to iCloud/Google Photos. Account breach = loss of funds 2. **Notes / password manager** - digital storage is vulnerable to malware and cloud backups 3. **Paper** - burns, gets wet, fades. One fire and everything is gone 4. **Splitting into parts** (6+6 words in different locations) - reduces security! 6 words = 66 bits, brute-force is feasible **Solution:** metal backups (Cryptosteel, Billfodl) - engraving or assembling letters on a steel plate. Survives fire up to 1500°C, water, and corrosion.

**BIP-39 wordlist** contains 2048 words. Each word is uniquely identified by its first **4 letters** (e.g., `aban` → `abandon`). This is not coincidental - the standard guarantees no two words share the same 4-letter prefix. Wordlists exist in various languages (English, Japanese, Spanish, etc.), but in practice almost all wallets use **English** - other languages introduce confusion with Unicode normalization.

MPC Wallets: a key that no one has

A seed phrase solves the backup problem but creates a new one: a **single point of failure**. Whoever knows the 12/24 words owns everything. For institutional investors storing billions, this is an unacceptable risk. The requirement is that **no single person** should hold the complete key - not during generation, not during signing.

**MPC (Multi-Party Computation)** is a cryptographic protocol where several participants **jointly compute** the result of a function **without revealing** their inputs to each other. In the context of wallets this is **TSS** (Threshold Signature Scheme): N participants hold 'shares' of the key, and any T of N are needed to sign - while the complete key is **never assembled** in one place.

**Key properties of MPC-TSS:** 1. **Distributed Key Generation (DKG)** - the key is generated distributedly. Each participant receives a share, but the full key is never created, even for a moment 2. **Threshold signing** - signing requires T of N shares. The GG18/GG20 (Gennaro & Goldfeder) protocol is the most widely used for ECDSA 3. **Key resharing** - shares can be 're-sliced' without changing the public key. An employee leaves? Their share becomes useless after resharing 4. **Proactive security** - periodic resharing protects against an attacker who slowly accumulates shares

**Who uses MPC wallets:** - **Fireblocks** - institutional custodian, $4+ trillion in transactions. MPC-CMP protocol, 8 signatures per second - **ZenGo** - consumer wallet without a seed phrase. 2-of-2 MPC: one share on the phone, second on ZenGo servers. Recovery via 3D Face Map - **Coinbase WaaS** (Wallet-as-a-Service) - API for embedding MPC wallets into any application - **Banks and funds** - Fidelity, Galaxy Digital, Revolut use MPC for storing crypto assets

**Why not just Shamir's Secret Sharing?** SSS splits a secret into shares and reconstructs it when the threshold is reached. But for signing, SSS **reassembles** the full key in one place - the single point of failure returns! MPC-TSS signs **without reassembly**: each participant computes a 'partial signature', and these are mathematically combined into a single valid signature.

**MPC is not a silver bullet.** In June 2023, hackers stole **$100M** from Atomic Wallet despite its MPC architecture. The problem turned out to be not in the cryptography but in the infrastructure: a vulnerability in the key generation process allowed shares to be intercepted. MPC protects storage and signing, but does not protect against bugs in the protocol implementation.

Account Abstraction: wallet as a smart contract

Ethereum has two types of accounts: **EOA** (Externally Owned Account) - controlled by a private key, and **Contract Account** - controlled by smart contract code. EOA is the only type that can initiate a transaction. And it has serious limitations:

**Account Abstraction** is the idea that **a wallet = a smart contract** with arbitrary validation logic. Instead of a hardcoded `ecrecover(signature) == owner`, the contract itself decides which signature is valid. This unlocks capabilities that are impossible with EOA.

**Social Recovery** is one of the most important capabilities of smart contract wallets. You designate **guardians** (trusted parties): friends, family, a hardware wallet, another wallet of yours. If you lose your key - guardians vote to change the owner. **Argent Wallet** implemented this first: 3-of-5 guardians + a 48-hour timelock (protection against guardian compromise).

**Session Keys** - another revolutionary feature. Instead of confirming every transaction in MetaMask, you grant a dApp a temporary key with restrictions: - Duration: 1 hour - Limit: up to 0.1 ETH per transaction - Contracts: Uniswap Router only The dApp signs transactions using the session key without your involvement. This is Web2-level UX with Web3 security.

**Passkeys (WebAuthn)** - biometric authentication instead of a seed phrase. The chip in an iPhone/Android creates a key pair (P-256) secured by Face ID / fingerprint. A smart contract wallet verifies the P-256 signature on-chain. Coinbase Smart Wallet and Safe already support passkeys. For the user it looks like: touch with your finger → transaction signed.

ERC-4337: Account Abstraction without protocol changes

The idea of account abstraction has been discussed since 2016 (EIP-86), but required **changing the Ethereum protocol** (a hard fork). That meant years of discussions and the risk of splitting the community. **ERC-4337** (Vitalik Buterin et al., 2023) found a workaround: implementing AA **entirely at the smart contract level**, without changing consensus.

**Paymaster** - a contract that **pays for gas** on behalf of the user. This removes the main barrier to entry: a new user doesn't need to buy ETH. Two main patterns: 1. **Sponsoring Paymaster** - the dApp pays gas for its users. A GameFi project sponsors the first 10 transactions for free 2. **ERC-20 Paymaster** - the user pays gas in USDC/DAI. The paymaster converts it to ETH via a DEX and sends it to the bundler

**Bundler** - a node that collects UserOperations from the alt mempool into a bundle and sends it as a **regular transaction** to the EntryPoint. The bundler pays gas from its own ETH, and the EntryPoint reimburses the cost (from the user's wallet or paymaster). Leading bundler providers: **Pimlico**, **Stackup**, **Alchemy**, **Biconomy**.

**Real implementations:** - **Safe{Core}** (formerly Gnosis Safe) - $100B+ in assets under management. Modular architecture with an ERC-4337 module - **Biconomy** - SDK for integrating AA into dApps in 15 minutes. Paymaster, bundler, and smart account out of the box - **ZeroDev** - kernel architecture: minimal base wallet + plugins (session keys, recovery, automation) - **Pimlico** - infrastructure: bundler, paymaster, permissionless.js (TypeScript SDK)

**The future: Native Account Abstraction (RIP-7560).** ERC-4337 works, but has overhead: EntryPoint is an extra contract, bundler is extra infrastructure. RIP-7560 proposes embedding AA **into the Ethereum protocol**: validators themselves process UserOperations, eliminating the middleware. This requires a hard fork, but after the success of ERC-4337 the community is ready. On L2s (zkSync Era, StarkNet), native AA is already working - every account is by default a smart contract.

**Evolution in numbers (2023→2025):** - Active ERC-4337 wallets: 500K → 12M+ - UserOperations per month: 200K → 30M+ - Networks with support: 3 → 20+ (including L2: Base, Optimism, Arbitrum, Polygon) - Average gas savings with batching: 30-50% compared to separate EOA transactions

Key ideas

• **HD Wallets (BIP-32)** - one seed (master seed) generates an infinite key tree through deterministic derivation. One backup = all addresses, including future ones. Derivation path determines which key is for which network
• **BIP-39** - encodes 128/256 bits of entropy into 12/24 words from a 2048-word dictionary. A passphrase creates hidden wallets. But physical storage remains an unsolved problem: paper burns, photos leak, digital copies get hacked
• **MPC-TSS** - the key is split into shares that are never assembled together. Signing via a distributed protocol. Key resharing allows rotating participants without changing the address. For institutions, this is the standard
• **Account Abstraction (ERC-4337)** - wallet = smart contract with arbitrary logic. Social recovery, session keys, batching, gas abstraction via paymaster. Those $150 billion in lost Bitcoin? With AA they could have been recovered through guardians - friends and family designated in advance
• **ERC-4337 architecture**: UserOperation → Alt Mempool → Bundler → EntryPoint → Smart Wallet + Paymaster. Everything works on top of existing Ethereum without a hard fork. On L2s (zkSync, StarkNet), native AA is already built into the protocol

Related topics

Wallets and key management sit at the intersection of cryptography, blockchain architecture, and user experience:

• Digital signatures (ECDSA, EdDSA) — The foundation of wallets - every wallet type ultimately creates a signature that the network verifies. HD wallets, MPC, AA - these are different ways to manage signing keys
• Threshold Cryptography — MPC-TSS is a concrete implementation of threshold schemes. Threshold signatures (t-of-n) allow distributing trust without a single point of failure
• Ethereum Roadmap — Account abstraction is part of the Ethereum roadmap (The Splurge). RIP-7560 (native AA) is planned for future hard forks, and ERC-4337 is already working
• Ethereum Accounts — EOA vs Contract Account - the basic distinction that account abstraction blurs. EIP-7702 will allow an EOA to temporarily delegate logic to a smart contract

Вопросы для размышления

• If passkeys (Face ID / fingerprint) replace seed phrases, who stores the private key? Apple/Google own the Secure Enclave of your device. How is this different from a bank that stores your password? Are we returning to centralization?
• The ZenGo MPC wallet stores one share on the company's servers. If ZenGo shuts down, will users lose access? How can this problem be solved while keeping the experience convenient for non-technical users?
• Account abstraction allows a wallet to change its signature algorithm. If a quantum computer capable of breaking ECDSA emerges tomorrow, AA users can migrate to post-quantum signatures without transferring funds. EOA owners will lose everything. Should Ethereum forcibly migrate everyone to AA for security reasons?

Связанные уроки

• crypto-18-key-management