The Ethereum Wallet & Signing Bible

1 · A Brief History: From One Key to Programmable Accounts

Every standard in this guide exists because of one design decision made in 2014 — and a decade spent escaping its consequences.

When Ethereum launched (Frontier, July 2015), it inherited Bitcoin's account security model: an account is a keypair, and a signature from the private key is absolute, unconditional authority. That was the simplest thing that could work. But Ethereum also introduced something Bitcoin didn't have — contract accounts, on-chain programs with their own storage and balance. From day one there were two kinds of citizens: EOAs (key-controlled, can start transactions, zero logic) and contracts (logic-controlled, infinitely programmable, but unable to act on their own).

The tension was visible almost immediately. 2016–2017: the first multisig wallets appeared (the Parity multisig — famously frozen in 2017 by a library self-destruct, losing 513k ETH — and Gnosis Safe, which survived and became the institutional standard). These proved people wanted accounts with rules: multiple approvers, daily limits, recovery. 2016: EIP-155 added chainId to signatures after the ETH/ETC split made cross-chain replay a live exploit. 2018: ERC-1271 answered "how does a contract sign things?"; EIP-1014 (CREATE2) made counterfactual wallet addresses possible — an address you can fund before the wallet exists. 2017–2020: EIP-712 gave signatures human-readable structure, and EIP-2612 used it to make token approvals gasless.

Meanwhile the "make accounts programmable at the protocol level" dream kept stalling: EIP-86, EIP-2938 (native account abstraction) both died — consensus changes are slow and risky. 2021: Vitalik Buterin and the eth-infinitism team (Yoav Weiss, Dror Tirosh et al.) published ERC-4337: account abstraction with zero protocol changes, using an alternative mempool and a singleton EntryPoint contract. The EntryPoint went live on mainnet in March 2023, and an industry grew around it — bundlers, paymasters, smart account SDKs (Biconomy, ZeroDev, Alchemy, Pimlico, Safe modules).

But 4337 accounts have new addresses — useless for the hundreds of millions of existing EOAs. 2024: EIP-3074 (AUTH/AUTHCALL opcodes) was approved for inclusion, then withdrawn after a community storm over its security model. Vitalik proposed EIP-7702 as the replacement in about a day. May 7, 2025: the Pectra upgrade shipped 7702 — EOAs can now carry code, and the same account you made in 2017 can be a smart wallet today. 2026: the mainstream architecture is "7702 + 4337": your old address, delegated to a modular (ERC-7579) implementation, transacting through bundlers with sponsored gas — while EIP-7701 (native AA, the "endgame") sits on the long-term roadmap.

2 · From Seed Phrase to Keys: BIP-39, BIP-32, BIP-44

Before any EIP matters, a wallet has to make keys. Every "12 words on paper" wallet you've ever used is three Bitcoin standards stacked together — Ethereum adopted them wholesale.

2.1 BIP-39: entropy → mnemonic → seed

A mnemonic is not the key — it's a human-readable encoding of randomness:

1. entropy  = 128 or 256 random bits                    (from a CSPRNG)
2. checksum = first (entropy_bits / 32) bits of SHA-256(entropy)   → 4 or 8 bits
3. concat   = entropy ‖ checksum   → 132 or 264 bits
4. split into 11-bit chunks → 12 or 24 indexes into a fixed 2048-word list
   (2048 = 2¹¹ — each word carries exactly 11 bits)

5. seed = PBKDF2-HMAC-SHA512(
            password = mnemonic,
            salt     = "mnemonic" + optional_passphrase,
            iterations = 2048)                → 512-bit seed

• The checksum is why a mistyped word is usually caught: only 1 in 16 random 12-word strings is valid.
• The optional passphrase (the "25th word") creates a completely different seed — plausible-deniability hidden wallets, but also a classic way to lose funds (no checksum protects it).
• The 2048-word list is fixed and language-specific; the first four letters of each word are unique — hardware wallets exploit this for entry.

2.2 Worked example: 16 bytes → 12 words → an address every value below is real

The algorithm above is easier to trust once you've watched every byte move. Here is one complete run, start to finish, with nothing elided.

Step 1 — entropy. 128 bits from a CSPRNG. Ours is deliberately the least random value imaginable, so you can follow the bits by eye:

entropy (hex)  = 7f7f7f7f 7f7f7f7f 7f7f7f7f 7f7f7f7f          (16 bytes = 128 bits)
entropy (bits) = 01111111 01111111 01111111 01111111 ... (0x7f = 0111 1111, ×16)

Step 2 — checksum. Hash the entropy and keep the first 128/32 = 4 bits:

SHA-256(entropy) = 87dcde7fa6df23e15fa7ba9b2a1f31408eac832f4e615ea815ae92024e3d818b
                   ^^
                   first byte 0x87 = 1000 0111
                                     ────
                                     first 4 bits = 1000  ← the checksum

Step 3 — concatenate and slice into 11-bit words. 128 + 4 = 132 bits = exactly 12 × 11. Each chunk is an index into the 2048-word list:

128 entropy bits ‖ 1000  →  132 bits  →  twelve 11-bit indexes

  #   11 bits        index   word
  ─────────────────────────────────────
   1  01111111011     1019   legal
   2  11111011111     2015   winner
   3  11011111110     1790   thank
   4  11111110111     2039   year
   5  11110111111     1983   wave
   6  10111111101     1533   sausage
   7  11111101111     2031   worth
   8  11101111111     1919   useful
   9  01111111011     1019   legal      ← repeats: the entropy repeats every 8 bytes
  10  11111011111     2015   winner
  11  11011111110     1790   thank
  12  11111111000     2040   yellow     ← last word carries the checksum
                └── the 4 checksum bits live here, which is why word 12
                    differs from word 4 ("year") despite identical entropy bits

Word 12 is where the checksum earns its keep: change any earlier word and the final word almost certainly stops agreeing with the hash. That is the "1 in 16" check from §2.1 made concrete.

Step 4 — stretch the words into a seed. This is the step people misread. The words are not hashed into the seed directly; they are run through PBKDF2 2048 times, and the passphrase goes in the salt, not the password:

seed = PBKDF2-HMAC-SHA512(
         password   = "legal winner thank year wave sausage worth useful legal winner thank yellow",
         salt       = "mnemonic" + passphrase,     ← passphrase lands HERE
         iterations = 2048,
         dkLen      = 64 bytes)

The passphrase: same words, a different wallet

Run the identical 12 words twice, once bare and once with the passphrase trezor, and the 512-bit seeds share nothing:

salt = "mnemonic"            (no passphrase)
seed = 878386efb78845b3355bd15ea4d39ef97d179cb712b77d5c12b6be415fffeffe
       5f377ba02bf3f8544ab800b955e51fbff09828f682052a20faa6addbbddfb096

salt = "mnemonictrezor"      (passphrase = "trezor")
seed = 9fad48776d59511b5d532911300fd684daf464c06865041dc045a0f3dfe9e284
       1219290013bfc454f2bb9aade52751f5e9f0cd67c0dad602df3ca4b5001b5304
       ▲ not one byte in common — this is a whole separate wallet

Step 5 — the seed becomes the tree. From here §2.3 takes over: the 512-bit seed is HMAC'd into a master key + chain code, and the BIP-44 path walks down to an address:

no passphrase                          passphrase = "trezor"
────────────────────────────           ────────────────────────────
master key 7e56ecf5943d79e1…           master key 578e0c6b44d56f83…
chain code 598b4595ea728027…           chain code a8806347c85e7acb…

m/44'/60'/0'/0/0                       m/44'/60'/0'/0/0
  0x58A57ed9d8d624cBD12e2C467D…          0x34FF70540588fa9B3f7df225e…
m/44'/60'/0'/0/1                       m/44'/60'/0'/0/1
  0x0D3eB21b6b21833A4939Cfff48…          0xBDCEeacb069fD88B7f39F5Ae30…

Want to check the arithmetic yourself? Every number above is reproducible in a few lines:

Reproduce it

import { mnemonicToSeedSync } from '@scure/bip39'
import { HDKey } from '@scure/bip32'

const M = 'legal winner thank year wave sausage worth useful legal winner thank yellow'

for (const pass of ['', 'trezor']) {
  const seed = mnemonicToSeedSync(M, pass)            // passphrase → PBKDF2 salt
  const addr = HDKey.fromMasterSeed(seed).derive("m/44'/60'/0'/0/0")
  console.log(pass || '(none)', Buffer.from(seed).toString('hex').slice(0, 16))
  // → ''       878386efb78845b3…  → 0x58A57ed9…
  // → 'trezor' 9fad48776d59511b…  → 0x34FF7054…
}

2.3 BIP-32: the HD (Hierarchical Deterministic) tree

The 512-bit seed becomes the root of an infinite key tree:

I = HMAC-SHA512(key = "Bitcoin seed", data = seed)      // yes, even on Ethereum
master_private_key = I[0..32]        // left half
master_chain_code  = I[32..64]       // right half — extra entropy for derivation

child derivation (index i):
  normal   (i < 2³¹):  child = f(parent_pubkey,  chain_code, i)   // xpub can derive
  hardened (i ≥ 2³¹):  child = f(parent_PRIVkey, chain_code, i)   // notated i′ or i'

• An extended key (xprv/xpub) = key + chain code. An xpub can derive all normal child public keys without ever seeing a private key — how watch-only wallets and exchanges generate deposit addresses.
• Hardened derivation breaks that property on purpose: leaking one child private key + the parent xpub would otherwise let an attacker walk back up the tree. That's why the account levels are hardened.

2.4 BIP-44: the derivation path — one seed, every account

m / purpose' / coin_type' / account' / change / address_index
m /   44'    /    60'     /    0'    /   0    /      0        ← your first ETH account
m /   44'    /    60'     /    0'    /   0    /      1        ← MetaMask "Account 2"
m /   44'    /    0'      /    0'    /   0    /      0        ← same seed, Bitcoin
                  └── 60 = Ethereum's registered coin type (SLIP-44)

One seed, many chains. The coin_type' level (registered in SLIP-44) is how a single mnemonic drives wallets on completely different networks:

Note Solana's oddity: ed25519 doesn't support BIP-32's normal (non-hardened) derivation math, so it uses SLIP-0010 with every level hardened — no xpub-style watch-only trees. Full non-EVM comparison in §19. BSC/Polygon/Arbitrum/etc. all reuse 60' — same key, same 0x address on every EVM chain (which is exactly why EIP-155 chainId matters).

• Ethereum ignores change (a Bitcoin UTXO concept) — it's always 0.
• Ledger historically used m/44'/60'/i'/0/0 (bumping account) vs MetaMask's m/44'/60'/0'/0/i (bumping index) — why "my Ledger shows different addresses" is a FAQ, and why wallets offer path pickers.
• Each leaf is an independent secp256k1 private key → public key → address = last20(keccak256(pubkey)). Compromising one leaf key does NOT compromise siblings or the master (you'd need the extended parent).

import { english, generateMnemonic, mnemonicToAccount } from 'viem/accounts'

const mnemonic = generateMnemonic(english)          // BIP-39: entropy → 12 words

const account0 = mnemonicToAccount(mnemonic)        // default m/44'/60'/0'/0/0
const account1 = mnemonicToAccount(mnemonic, { addressIndex: 1 })   // …/0/1
const ledger3  = mnemonicToAccount(mnemonic, { accountIndex: 3 })   // m/44'/60'/3'/0/0

console.log(account0.address)   // 0x… — last20(keccak256(pubkey))
// account0.signTypedData(…), signMessage(…), signTransaction(…) all available

2.5 Two kinds of citizens

2.6 ECDSA in five lines

An EOA's address is derived from its secp256k1 public key:

privkey (32 bytes, random)
  → pubkey = privkey × G            (elliptic curve point, 64 bytes)
  → address = last20( keccak256(pubkey) )

A signature is 65 bytes — r (32) ‖ s (32) ‖ v (1) — and Ethereum's superpower is public key recovery: given a hash and (v, r, s), the ecrecover precompile (address 0x01) returns the address that signed. You never store or transmit public keys.

2.7 Why EOAs hurt — the problem statement for the rest of this guide

• One key = single point of failure. No rotation (the address is the key), no recovery, no 2FA.
• No batching. approve + swap = two transactions, two wallet popups, two fees.
• Gas must be ETH, paid by the sender. A new user with $50 of USDC and zero ETH is stuck — the classic onboarding wall.
• No custom rules. Spending limits, session keys, passkeys, multisig — all impossible.

Smart wallets fix all four, but pre-2023 they had a bootstrap problem: contracts can't start transactions, so a centralized "relayer" EOA had to poke them. ERC-4337 (§7) standardizes and decentralizes the relayer layer; EIP-7702 (§8) removes the migration cost.

3 · Transaction Anatomy & the Typed Envelope

3.1 Legacy transactions and EIP-155 replay protection · 2016

A legacy (type-0) transaction is the RLP encoding of nine fields:

rlp([nonce, gasPrice, gasLimit, to, value, data, v, r, s])

The bug: originally the chain wasn't part of what you signed. After the 2016 ETH/ETC split, any transaction broadcast on one chain could be replayed verbatim on the other — same key, same nonce, same validity. EIP-155 folds chainId into the signed preimage and encodes it into v:

signed:  keccak256( rlp([nonce, gasPrice, gasLimit, to, value, data, chainId, 0, 0]) )
v      = chainId × 2 + 35  (or 36)     // recover chainId from v

3.2 EIP-2718: the typed transaction envelope 2020

Rather than torturing the legacy format forever, EIP-2718 declares: a transaction is simply

TransactionType (1 byte) ‖ TransactionPayload (opaque, type-defined)

One leading byte selects the format, and each new type defines its own payload and its own signature scheme. This is the extension point that made everything after 2020 possible:

3.3 EIP-1559: the fee market London · 2021

Type-2 transactions replace one gasPrice with two caps, against a protocol-computed, burned baseFee that rises when blocks are full and falls when they're empty:

effectiveGasPrice = min(maxFeePerGas, baseFee + maxPriorityFeePerGas)
validator tip     = effectiveGasPrice − baseFee        // baseFee is burned 🔥

3.4 Gas mechanics in practice — units, limits, and who gets what

Two numbers that beginners conflate, kept strictly apart:

gas      = WORK — how many units of computation/storage the tx consumes
gasPrice = MONEY PER UNIT — what you pay for each unit, in wei

fee paid = gasUsed × effectiveGasPrice

units:  1 ether = 10⁹ gwei = 10¹⁸ wei      (gas prices are quoted in gwei)

4 · Signing Messages: EIP-191 & EIP-712

Wallets sign two different things: transactions (state changes, §3) and messages (proofs and intents — logins, orders, permits). If the two byte-formats could ever collide, a "harmless login" could secretly be a valid transaction. Both standards exist to make that collision impossible.

4.1 EIP-191: personal_sign 2016

digest = keccak256("\x19Ethereum Signed Message:\n" + len(message) + message)

• The leading byte 0x19 can never begin a valid RLP transaction — so a signed message can never replay as a transaction. That single byte is the whole security argument.
• Generalized format: 0x19 ‖ version ‖ version-data ‖ payload. Version 0x45 ('E') is personal_sign; version 0x01 is reserved for EIP-712; version 0x00 binds data to one intended validator contract.

Weakness: the user sees a text blob or hex. Fine for "Sign in to OpenSea", terrible for "sell 3 NFTs for X" — no structure, nothing a wallet can render or a contract can decompose. Hence 712.

4.2 EIP-712: typed structured data the important one · 2017

EIP-712 lets the wallet show the user exactly what they're signing, field by field — and lets a contract rebuild the identical digest on-chain to verify it.

import {EIP712} from "@openzeppelin/contracts/utils/cryptography/EIP712.sol";
import {ECDSA}  from "@openzeppelin/contracts/utils/cryptography/ECDSA.sol";

contract Orders is EIP712 {
    bytes32 private constant ORDER_TYPEHASH =
        keccak256("Order(address maker,uint256 amount,uint256 nonce,uint256 deadline)");

    mapping(address => mapping(uint256 => bool)) public usedNonces;

    constructor() EIP712("OrbitXPay", "1") {}   // builds the domain separator

    function fill(Order calldata o, bytes calldata sig) external {
        require(block.timestamp <= o.deadline, "expired");
        require(!usedNonces[o.maker][o.nonce], "replayed");

        bytes32 digest = _hashTypedDataV4(keccak256(abi.encode(
            ORDER_TYPEHASH, o.maker, o.amount, o.nonce, o.deadline)));

        require(ECDSA.recover(digest, sig) == o.maker, "bad sig");
        usedNonces[o.maker][o.nonce] = true;
        // …execute the order
    }
}

const signature = await walletClient.signTypedData({
  domain: { name: 'OrbitXPay', version: '1', chainId: 1, verifyingContract: ordersAddr },
  types: {
    Order: [
      { name: 'maker',    type: 'address' },
      { name: 'amount',   type: 'uint256' },
      { name: 'nonce',    type: 'uint256' },
      { name: 'deadline', type: 'uint256' },
    ],
  },
  primaryType: 'Order',
  message: { maker, amount: 500_000_000n, nonce: 7n, deadline },
})

Where you've already met 712: EIP-2612 permit, Permit2, Safe's SafeTx, Uniswap orders, OpenSea Seaport, CoW Swap, Sign-In-With-Ethereum variants, and — since EntryPoint v0.8 — the ERC-4337 userOpHash itself.

4.3 Signature pitfalls checklist interview-grade

5 · Proving Wallet Ownership: ERC-1271, SignatureChecker, ERC-6492

This is the standard you remembered as "EIP-1270" — it's ERC-1271, and the OpenZeppelin helper is SignatureChecker. It answers: how does a wallet with no private key "sign" anything?

5.1 The problem

ecrecover answers "which private key made this signature?" — but a smart contract wallet has no private key. A Safe with 3 owners: whose handwriting is "the Safe's"? If your dApp verifies logins or orders with ecrecover alone, every smart-wallet user is locked out.

5.2 ERC-1271: flip the question isValidSignature · 2018

Instead of recovering a signer, ask the account itself: "is this signature valid, by your own rules?"

interface IERC1271 {
    /// @return magicValue 0x1626ba7e when valid
    function isValidSignature(bytes32 hash, bytes calldata signature)
        external view returns (bytes4 magicValue);
}

• Magic value 0x1626ba7e = bytes4(keccak256("isValidSignature(bytes32,bytes)")). Returning the selector instead of true means a contract that accidentally returns non-zero garbage still fails the check.
• The contract defines validity: a Safe checks threshold-of-owners signatures; a passkey wallet verifies a P-256 WebAuthn assertion; a session-key module checks the key and its permissions haven't expired.

contract MiniWallet is IERC1271 {
    using ECDSA for bytes32;
    address public owner;
    bytes4 constant MAGIC = 0x1626ba7e;

    function isValidSignature(bytes32 hash, bytes calldata sig)
        external view returns (bytes4)
    {
        return hash.recover(sig) == owner ? MAGIC : bytes4(0xffffffff);
    }
}

5.3 OpenZeppelin SignatureChecker — the one-liner your dApp should use

import {SignatureChecker} from "@openzeppelin/contracts/utils/cryptography/SignatureChecker.sol";

bool ok = SignatureChecker.isValidSignatureNow(signer, digest, signature);

import { createPublicClient, http } from 'viem'
import { mainnet } from 'viem/chains'

const client = createPublicClient({ chain: mainnet, transport: http() })

const valid = await client.verifyTypedData({
  address: signer,          // EOA, deployed smart wallet, or undeployed smart wallet
  domain, types, primaryType, message,
  signature,
})   // ✅ ecrecover → ERC-1271 → ERC-6492, all attempted for you

5.4 ERC-6492: verifying wallets that don't exist yet counterfactual

Modern smart wallets are counterfactual: CREATE2 fixes the address before any code is deployed; deployment happens lazily with the first transaction. So a brand-new user signs "Sign in" → your backend calls isValidSignature → there's no code there yet → verification fails, even though the wallet is real.

ERC-6492 wraps the signature with its own deployment recipe:

sig' = abi.encode(factory, factoryCalldata, originalSig) ‖ magicSuffix
magicSuffix = 0x6492649264926492649264926492649264926492649264926492649264926492

A 6492-aware verifier that spots the suffix: simulate the factory deployment inside an eth_call, then run the 1271 check against the now-materialized code — nothing is actually deployed. viem/ethers and the universal validator contract handle this transparently.

5.5 ERC-7739: defensive rehashing current best practice

A naive 1271 wallet that just runs ECDSA.recover(hash, sig) == owner creates a replay hole: the owner's one signature validates against every account that trusts that key (same EOA owning several smart accounts), and an identical 712 digest can mean different things to different apps. ERC-7739 nests the app's typed data inside a TypedDataSign envelope bound to the account's own domain, so each signature is valid for exactly one account. Solady and OpenZeppelin 5.x ship implementations; Kernel, Coinbase Smart Wallet, and Alchemy accounts adopted it. Know it exists — and use library code, not hand-rolled 1271.

6 · Gasless UX: permit, Gas Relayers & Gas Sponsorship

The classic UX wart: to let a contract spend your USDC you must first send approve(spender, amount) — a full gas-costing transaction — before the action you actually wanted.

6.1 EIP-2612 — approval by signature

function permit(address owner, address spender, uint256 value,
                uint256 deadline, uint8 v, bytes32 r, bytes32 s) external;
function nonces(address owner) external view returns (uint256);
function DOMAIN_SEPARATOR() external view returns (bytes32);

The owner signs an EIP-712 Permit struct off-chain (free); anyone — typically the dApp contract, inside the same transaction as the swap/deposit — submits it. The token verifies the 712 digest via ecrecover and sets the allowance. Approve + action collapse into one transaction, signed once, gas payable by someone else.

Permit(address owner,address spender,uint256 value,uint256 nonce,uint256 deadline)

6.2 Gas relayers: meta-transactions & ERC-2771 the pre-4337 era

permit only moves the gas cost of one function on one token. The general problem — "user signs, someone else pays, for any call" — was solved before 4337 with meta-transactions: the user signs an EIP-712 request off-chain, a relayer EOA wraps it in a real transaction and pays the gas.

The catch: inside the target contract, msg.sender is now the relayer, not the user. ERC-2771 standardizes the fix — a trusted forwarder verifies the user's signature + nonce, then calls the target with the real sender's address appended to the last 20 bytes of calldata:

// Forwarder (OpenZeppelin ERC2771Forwarder): verifies EIP-712 ForwardRequest
// (from, to, value, gas, nonce, deadline, data), then:
//   target.call{...}(abi.encodePacked(req.data, req.from))   // ← sender appended

// Recipient inherits ERC2771Context instead of using msg.sender directly:
abstract contract ERC2771Context {
    function _msgSender() internal view returns (address sender) {
        if (msg.sender == TRUSTED_FORWARDER && msg.data.length >= 20) {
            assembly { sender := shr(96, calldataload(sub(calldatasize(), 20))) }
        } else {
            sender = msg.sender;
        }
    }
}
// Rule: a 2771-aware contract must use _msgSender() EVERYWHERE, never msg.sender

• GSN (Gas Station Network) — EIP-1613/OpenGSN — decentralized this: a network of relayers, a RelayHub escrow, and a contract that agrees to repay relayers. GSN is where the word "paymaster" was born; ERC-4337 later absorbed the whole concept into the EntryPoint design.
• Biconomy's first act was exactly this: relayer-infrastructure-as-a-service with hosted forwarders (their old "dashboard + dApp gas tank" product) — before pivoting the same idea into 4337 paymasters. The lineage is direct.
• Still used today for plain old contracts that want one gasless function without the full 4337 stack (and by OpenSea/Polygon-era dApps everywhere).

6.3 Gas sponsorship — every way to pay someone else's gas, compared

7 · ERC-4337: Account Abstraction Without a Fork 2021 → live Mar 2023

"Account abstraction" = decouple who pays, who validates, and what logic approves from the protocol's hardcoded ECDSA+nonce rules. After native attempts (EIP-86, EIP-2938) died, ERC-4337 rebuilt the entire transaction pipeline in contract-land + off-chain infrastructure — zero consensus changes.

7.1 The cast of characters

7.2 The UserOperation struct EntryPoint v0.7/v0.8 packed form

struct PackedUserOperation {
    address sender;              // the smart account
    uint256 nonce;               // 2D: 192-bit key ‖ 64-bit sequence (parallel nonces!)
    bytes   initCode;            // factory address + calldata — only on first-ever op
    bytes   callData;            // what the account should execute
    bytes32 accountGasLimits;    // packed: verificationGasLimit ‖ callGasLimit
    uint256 preVerificationGas;  // bundler overhead compensation
    bytes32 gasFees;             // packed: maxPriorityFeePerGas ‖ maxFeePerGas (1559-style)
    bytes   paymasterAndData;    // paymaster + its gas limits + its data
    bytes   signature;           // ⭐ OPAQUE — whatever your validation logic understands
}

interface IAccount {
    function validateUserOp(
        PackedUserOperation calldata userOp,
        bytes32 userOpHash,
        uint256 missingAccountFunds        // pay EntryPoint what you owe
    ) external returns (uint256 validationData);
    // validationData packs: authorizer(0=ok,1=fail) ‖ validUntil ‖ validAfter
}

Why two loops? The bundler must be guaranteed payment even if your execution reverts, and must be able to simulate ops cheaply. So validation runs first for the whole bundle (restricted by ERC-7562 rules: limited opcodes/storage so one op can't invalidate another — DoS protection), execution second. Your op failing mid-swap still pays the bundler.

7.3 Paymasters — the onboarding superpower

interface IPaymaster {
    function validatePaymasterUserOp(PackedUserOperation calldata, bytes32, uint256 maxCost)
        external returns (bytes memory context, uint256 validationData);
    function postOp(PostOpMode mode, bytes calldata context,
                    uint256 actualGasCost, uint256 actualUserOpFeePerGas) external;
}

• Verifying paymaster — your backend signs "we sponsor this op"; the paymaster contract checks that signature. The dominant sponsored-gas model (Pimlico, Alchemy Gas Manager, Biconomy).
• ERC-20 paymaster — user pays gas in USDC; the paymaster fronts ETH and pulls tokens in postOp.
• Paymasters stake ETH in the EntryPoint — skin in the game against griefing the mempool.

7.4 EntryPoint versions — know the addresses

(A v0.9 with further paymaster parallelization exists; v0.7/v0.8 dominate production. Check which your bundler supports.)

7.5 Honest tradeoffs

• Gas overhead (~42k+ baseline vs 21k plain transfer) — trivial on L2s, noticeable on mainnet L1.
• New address ≠ your old EOA: migration friction for existing users — exactly the pain EIP-7702 removes.
• Infra dependency: bundler/paymaster uptime (mitigated by many providers + a shared P2P mempool).

8 · EIP-7702: Your EOA Becomes a Smart Wallet Pectra · May 7, 2025

8.1 The mechanism: type-0x04 + authorization tuples

A new transaction type 0x04 (SetCode) carries an authorization_list. Each entry is a tuple the EOA's key signed:

authorization = [chain_id, address, nonce, y_parity, r, s]
signed over:    keccak256( 0x05 ‖ rlp([chain_id, address, nonce]) )

When processed, the EOA's account code becomes a delegation designator:

code = 0xef0100 ‖ <20-byte implementation address>     (23 bytes total)

• 0xef is an unreachable opcode prefix for normal deployment (EIP-3541 reserved it) — the designator can only come from a 7702 transaction.
• Delegation is persistent until replaced or cleared. It survives across transactions — unlike the withdrawn EIP-3074's per-call model.
• chain_id = 0 → the authorization is valid on every EVM chain. Powerful for multichain UX; dangerous if the implementation isn't identically deployed everywhere.
• Tuple nonce = the EOA's account nonce — so an authorization can't be replayed after the account moves on.

8.2 Why 7702 + 4337 is the 2026 architecture, not 7702 vs 4337

Point your delegation at an ERC-4337-compatible implementation and your EOA gains the entire 4337 stack — bundlers, paymasters, session keys, passkeys, batching — without changing address. EntryPoint v0.8 supports this natively. Wallets (MetaMask's delegator framework, Coinbase, OKX, Trust, Ambire) ship vetted implementation lists and surface capabilities via wallet_getCapabilities (EIP-5792, §10).

import { walletClient } from './client'

// 1. sign the authorization tuple with the EOA's key
const authorization = await walletClient.signAuthorization({
  contractAddress: KERNEL_V3_IMPLEMENTATION,   // vetted implementation
})

// 2. include it in a type-0x04 transaction (can be sent by a relayer!)
const hash = await walletClient.sendTransaction({
  type: 'eip7702',
  authorizationList: [authorization],
  to: walletClient.account.address,            // call yourself…
  data: encodeFunctionData({                   // …now running smart-account code
    abi: kernelAbi,
    functionName: 'executeBatch',
    args: [[approveCall, swapCall]],           // ⚡ two actions, one signature
  }),
})

8.3 Security model — what YOU must re-check

8.4 The road not taken (context)

EIP-3074 (AUTH/AUTHCALL — per-call invoker model) was approved, then withdrawn in 2024 after security controversy; 7702 replaced it with a persistent, proxy-like, 4337-compatible design. EIP-2938 (native AA) was abandoned in 2020. EIP-7701 (native account abstraction — every account a contract, no more special-cased ECDSA) remains the roadmap "endgame": 4337 and 7702 are the migration path toward it.

9 · Modular Smart Accounts: ERC-7579 & ERC-6900

Once everyone has a smart account, you want an app-store model: install a spending-limit module, a 2FA module, a recovery module — without redeploying the wallet.

9.1 ERC-7579 — minimal, won the market

// Module types: 1 = validator · 2 = executor · 3 = fallback · 4 = hook
interface IERC7579Account {
    function execute(bytes32 mode, bytes calldata executionCalldata) external;
    function installModule(uint256 typeId, address module, bytes calldata init) external;
    function uninstallModule(uint256 typeId, address module, bytes calldata deinit) external;
    function isModuleInstalled(uint256 typeId, address module, bytes calldata ctx)
        external view returns (bool);
}

Backers: Rhinestone, ZeroDev (Kernel v3+), Biconomy (Nexus), Safe (via the Safe7579 adapter), OKX, Etherspot. ERC-7484 adds an on-chain module registry — accounts check audited-module attestations before installing.

9.2 ERC-6900 — Alchemy's richer, stricter spec

More prescriptive: plugins carry manifests; validation/execution/hooks are wired per function selector. Powers Alchemy's Modular Account. Heavier to implement and less ecosystem traction than 7579 — but influential (its lineage feeds ERC-7715 permission requests). Rule of thumb 2026: build modules against 7579 unless you live in Alchemy's stack.

10 · Wallet↔dApp Plumbing You'll Touch

const caps = await provider.request({ method: 'wallet_getCapabilities', params: [account] })
// { "0x1": { atomic: { status: "supported" }, paymasterService: { supported: true } } }

const { id } = await provider.request({
  method: 'wallet_sendCalls',
  params: [{
    version: '2.0.0', chainId: '0x1', from: account, atomicRequired: true,
    calls: [
      { to: USDC,   data: approveCalldata },
      { to: ROUTER, data: swapCalldata },
    ],
    capabilities: { paymasterService: { url: 'https://paymaster.orbitxpay.com' } },
  }],
})   // one popup, one atomic batch, gas sponsored — regardless of wallet type

11 · The Ecosystem: Who Builds What (2026)

11.1 Safe (formerly Gnosis Safe) — the elder statesman

Launched 2017–18, Safe predates every AA standard and still secures the most institutional value on EVM chains (DAO treasuries, protocol multisigs, exchanges). Architecture: a minimal proxy per user pointing at a shared singleton, with n-of-m ECDSA owner signatures checked over an EIP-712 SafeTx digest, plus its own pre-7579 extension points (Modules = executors, Guards = hooks, fallback handlers). It implements ERC-1271 (a Safe can "sign" for governance votes, orders, logins), gained ERC-4337 support via the Safe4337Module, and joins the modular world through the Safe7579 adapter (with Rhinestone). If you hear "smart wallet" in an institutional context, it's probably a Safe.

// SafeTx is an EIP-712 struct: to, value, data, operation, nonce, gas params…
bytes32 txHash = keccak256(abi.encodePacked(
    hex"1901", domainSeparator(), safeTxStructHash));
checkNSignatures(txHash, signatures, threshold);
// each 65-byte slice: ECDSA owner sig, OR approved-hash flag, OR
// v=0 → nested ERC-1271: the "owner" is itself a contract wallet 🤯

11.2 Smart account implementations compared

11.3 Infra providers — Biconomy · ZeroDev · Alchemy · Pimlico

One sentence each: Pimlico sells neutral rails, ZeroDev sells the nicest developer experience on its own account, Biconomy sells cross-chain execution products, Alchemy sells the integrated platform. Because all of them speak ERC-4337 + EIP-5792 + ERC-7677, accounts and infra are mix-and-match — that is the entire point of the standards.

// — Pimlico (permissionless.js): bring-your-own account
const account = await toSafeSmartAccount({ client, owners: [owner], version: '1.4.1' })
const smartClient = createSmartAccountClient({
  account, bundlerTransport: http(PIMLICO_URL),
  paymaster: pimlicoClient,      // sponsorship policy checked server-side
})
await smartClient.sendUserOperation({ calls: [approveCall, swapCall] })

// — ZeroDev: Kernel + session keys in a few lines
const kernel = await createKernelAccount(client, { plugins: { sudo: ecdsaValidator } })
const kernelClient = createKernelAccountClient({ account: kernel, paymaster: zerodevPaymaster })
await kernelClient.sendUserOperation({ calls: [approveCall, swapCall] })

// — Alchemy Account Kit
const alchemyClient = await createModularAccountV2Client({
  chain, transport: alchemy({ apiKey }), signer,
  policyId: GAS_POLICY_ID,       // Gas Manager sponsorship
})
await alchemyClient.sendUserOperation({ uo: [approveCall, swapCall] })

11.4 Choosing, quickly

• Institutional treasury / multisig governance → Safe (add the 4337 module if you need gasless).
• Consumer app, passkey onboarding, embedded wallets → Kernel (ZeroDev), Coinbase Smart Wallet, or Alchemy Account Kit.
• Existing EOA users you can't migrate → 7702 upgrade to a 7579 implementation (ZeroDev, Biconomy, MetaMask delegator, OZ).
• Zero vendor lock-in → account-agnostic permissionless.js + Alto, any 7579 account.

12 · End-to-End Flows: Putting It All Together

Flow A — "Sign in with your wallet" (any wallet type)

Flow B — Gasless USDC payment from a brand-new smart account

Flow C — Existing MetaMask user gets batching + sponsorship (7702)

13 · The EVM & Smart Contract Fundamentals

To understand proxies, 7702 delegation, and half the hacks in §15, you need three EVM primitives cold: storage slots, the four call types, and CREATE2.

13.1 The machine in one screen

Per-transaction (ephemeral)              Per-account (persistent)
────────────────────────────             ────────────────────────
stack     1024 × 32-byte words           storage   2²⁵⁶ slots × 32 bytes
memory    byte array, grows, wiped       code      immutable after deploy*
calldata  read-only input bytes          balance / nonce
                                         (* except selfdestruct†, 7702)
logs/events: write-only receipts — contracts can never read them back

• Function selectors: calldata starts with bytes4(keccak256("transfer(address,uint256)")) — the ABI is a convention, not a protocol rule. This is where 1271's magic value and proxy selector-clash issues (§14) come from.
• Storage layout (Solidity): state variables occupy slots 0,1,2… in declaration order (packed if they fit); mapping values live at keccak256(key ‖ slot); dynamic arrays at keccak256(slot)+i. Slot assignment is per-source-code — two different contracts reading the same account's storage (delegatecall!) will happily interpret each other's slots. Remember this for §14.

13.2 The four call types — the heart of everything

The fourth type, CREATE/CREATE2: CREATE derives the new address from (deployer, nonce); CREATE2 from keccak256(0xff ‖ deployer ‖ salt ‖ keccak256(initcode)) — deterministic, nonce-independent, the enabler of counterfactual wallets (§5.4, §7) and of the "redeploy different code at the same address" trick used in the Metamorphic-contract attacks (§15).

14 · Upgradeability: Proxy Patterns in Solidity

Deployed bytecode is immutable, but storage is forever. Proxies split the two: a permanent address holding state, delegatecalling into replaceable logic. Here is the whole pattern family, how each works, and how each fails.

14.1 The core mechanism + EIP-1967

contract Proxy {
    // EIP-1967: implementation pointer lives at a "random" slot so it can
    // never collide with the implementation's own slot-0,1,2… variables:
    // bytes32(uint256(keccak256("eip1967.proxy.implementation")) - 1)
    bytes32 constant IMPL_SLOT = 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc;

    fallback() external payable {
        address impl;
        assembly { impl := sload(IMPL_SLOT) }
        assembly {
            calldatacopy(0, 0, calldatasize())
            let ok := delegatecall(gas(), impl, 0, calldatasize(), 0, 0)
            returndatacopy(0, 0, returndatasize())
            switch ok case 0 { revert(0, returndatasize()) }
                      default { return(0, returndatasize()) }
        }
    }
}

Constructors don't work through proxies — a constructor runs during the implementation's deployment, writing the implementation's storage, which the proxy never sees. Hence initializers:

contract VaultV1 is Initializable {
    function initialize(address owner_) public initializer {   // callable once
        __Ownable_init(owner_);
    }
    constructor() { _disableInitializers(); }  // ⚠️ brick the RAW implementation
}                                              // so nobody can initialize it directly (§15)

14.2 The pattern family

contract VaultV1 is Initializable, UUPSUpgradeable, OwnableUpgradeable {
    uint256 public totalDeposits;                       // slot 0 — FROZEN forever now

    function initialize(address owner_) public initializer {
        __Ownable_init(owner_); __UUPSUpgradeable_init();
    }
    function _authorizeUpgrade(address) internal override onlyOwner {}
    constructor() { _disableInitializers(); }
}

contract VaultV2 is VaultV1 {
    mapping(address => uint256) public rewards;         // NEW slots APPENDED — never
    function version() external pure returns (string memory) { return "2"; }
}   // upgrade: proxy.upgradeToAndCall(address(new VaultV2()), "")

14.3 Storage-layout law (where upgrades die)

• Append-only: never reorder, remove, or change the type of existing state variables; never change inheritance order. New variables go at the end.
• Gaps: classic OZ contracts reserve uint256[50] __gap; in bases so future base-class variables don't shift children.
• ERC-7201 namespaced storage: the modern answer — each module keeps its state in a struct at keccak256(namespace)-1-style slots, so unrelated components can't collide. This is also the mitigation for 7702 re-delegation collisions (§8.3) and what OZ v5 upgradeable contracts use internally.
• Tooling: openzeppelin-upgrades plugins diff layouts before letting you upgrade. Use them; humans are bad at this.

15 · Known Issues & Famous Hacks — the Scar-Tissue Catalog

Every rule in §14 and every "wallets must…" in this guide was paid for. Study the receipts.

15.1 The canon, chronologically

15.2 The recurring defect classes

16 · Scaling: Sidechains vs Rollups

The block gas limit (§3.4) makes L1 blockspace scarce and expensive. Every scaling design answers one question differently: who do you trust when the operator misbehaves?

16.1 Sidechains — a different chain wearing an EVM costume

Polygon PoS, BNB Chain, Gnosis Chain: independent blockchains with their own validator set and consensus, connected to Ethereum only by a bridge contract. Security = their validators, full stop. If the sidechain's validators collude, your bridged funds are gone and Ethereum can't help — the bridge just holds locked tokens against the sidechain's word. Cheap, fast, EVM-compatible… and trust-them-shaped. (This trust surface is why bridges headline §15's loss tables — Ronin was a sidechain bridge.)

16.2 Rollups — execute elsewhere, settle on Ethereum

A rollup executes transactions on its own fast chain, then posts (a) the compressed transaction data and (b) a state commitment to L1. Ethereum stores the data (since Dencun, in cheap EIP-4844 blobs — §3.2), so anyone can reconstruct the rollup's state and check the operator. The two families differ in how the state commitment is checked:

16.3 What changes for wallet & contract developers

• Same keys, same address: every EVM L2 reuses coin type 60' — your EOA is identical everywhere, and only EIP-155's chainId (§3.1) separates the networks. Corollary: a 7702 chain_id=0 authorization (§8) sweeps across all of them at once.
• L2 fees are two-part: cheap L2 execution + your share of the L1 blob posting cost. That second component doesn't live in your gasLimit — it's added by the sequencer's pricing contract, which is why L2 fee estimation feels "off" if you only think in §3.4 terms.
• The sequencer is a centralization point (today): it orders transactions and can censor or go down (escape hatches let you force-include via L1, slowly). Decentralizing sequencers is the open workstream.
• L2s are where account abstraction actually lives: 4337's gas overhead (§7.5) is trivial at L2 prices, so smart-wallet UX (paymasters, session keys, passkeys) shipped on Base/Arbitrum/Optimism first. zkSync went further with native AA in the protocol — every account is a contract, no EntryPoint needed — a preview of EIP-7701 (§8.4).
• Contracts deploy mostly unchanged, but re-check assumptions: block.timestamp/block.number semantics differ per rollup, PUSH0/newer opcodes may lag on some zkEVMs, and address aliasing applies to L1→L2 contract calls.

17 · Zero-Knowledge Proofs: SNARKs, STARKs & Friends

§16 waved at "validity proofs" — here's what's inside. A zero-knowledge proof lets a prover convince a verifier that a statement is true without revealing why it's true — and, just as importantly for Ethereum, without the verifier re-doing the work.

17.1 The idea, three ways

• The colorblind friend: you hold a red and a green ball; your colorblind friend can't tell them apart. He hides them behind his back, maybe swaps them, shows you one — you say "swapped" or "not swapped". One round is a 50% lucky guess; thirty rounds and he's convinced the balls differ… yet he never learns which is red. That's the whole shape: repeated challenges → overwhelming confidence → zero leaked knowledge.
• Where's Waldo: prove you found Waldo by covering the page with a huge board that has a Waldo-sized hole over him. The verifier sees Waldo — but learns nothing about where on the page he is.
• Sudoku: prove you solved the puzzle by letting the verifier check any one row/column/box of a shuffled, sealed copy — enough rounds convince them, no round reveals the solution.

Formally, a proof system needs three properties: completeness (true statements convince), soundness (false statements can't, except with negligible luck), and zero-knowledge (the verifier learns nothing beyond "it's true").

17.2 From riddles to circuits

Real systems prove statements of one canonical form:

"I know a secret witness  w  such that  C(x, w) = true"
   x = public inputs (everyone sees)      w = private witness (never revealed)
   C = an arithmetic circuit — the statement compiled into addition/multiplication
       gates over a finite field (R1CS / PLONKish constraint systems)

Examples of C: "hash(w) equals this public commitment", "w is a valid Merkle path into this tree root", "w is a batch of 10,000 transactions whose execution moves state root A to state root B" — that last one is a ZK rollup (§16).

17.3 SNARK vs STARK vs the rest

• Trusted setup, plainly: SNARKs need structured randomness ("toxic waste") generated once — if anyone who contributed destroys their share, the setup is safe (1-of-N honest). Hence giant public ceremonies (Zcash's, Ethereum's KZG ceremony for 4844 with >140k contributors). STARKs skip the problem entirely, paying with proof size.
• Recursion & folding (Nova, etc.): proofs that verify other proofs — how rollups aggregate thousands of transaction proofs into one L1-sized receipt, and how zkVMs prove long computations chunk by chunk.
• zkVMs (RISC Zero, SP1, Jolt): instead of hand-writing circuits, prove "this Rust/RISC-V program ran correctly." Slower proving, massively better developer ergonomics — the current direction of travel.
• Naming honesty: most "zk-rollups" use the succinctness of SNARKs, not the zero-knowledge part — the transactions are public. Privacy systems (Aztec, Zcash, Tornado) use both properties.

17.4 Production example #1 — Tornado Cash: the commitment/nullifier machine

The canonical ZK dApp, and the pattern half the ZK ecosystem reuses. The problem: deposit 1 ETH from address A, withdraw it to fresh address B, with no on-chain link between A and B — while making double-withdrawal impossible.

wallet generates two random 31-byte secrets:   nullifier k,  secret s
commitment C = PedersenHash(k ‖ s)

deposit(C) { 1 ETH in }  → contract inserts C as a leaf in an on-chain
                            Merkle tree (height 20, ~1M leaves, MiMC hash)
// A's deposit is now one anonymous leaf among everyone else's.

public inputs:  root          (a recent Merkle root the contract knows)
                nullifierHash = PedersenHash(k)
                recipient, relayer, fee                       ← note these!
private witness: k, s, merklePath[20], pathIndices[20]

constraints:
  C == PedersenHash(k ‖ s)                       // I know the secrets behind SOME leaf
  MerkleVerify(C, merklePath, pathIndices) == root   // that leaf is in the tree
  nullifierHash == PedersenHash(k)               // and this is ITS unique serial number
  // recipient/relayer/fee are "squeezed" into the circuit as constrained
  // public inputs — the proof is only valid for THIS exact payout

function withdraw(bytes calldata proof, bytes32 root, bytes32 nullifierHash,
                  address payable recipient, address payable relayer, uint256 fee) external {
    require(!nullifierHashes[nullifierHash], "already spent");   // double-spend gate
    require(isKnownRoot(root), "stale root");                    // one of last 30 roots
    require(verifier.verifyProof(proof,
        [uint256(root), uint256(nullifierHash),
         uint256(uint160(recipient)), uint256(uint160(relayer)), fee]), "bad proof");
    nullifierHashes[nullifierHash] = true;
    recipient.transfer(1 ether - fee);
    if (fee > 0) relayer.transfer(fee);
}

Why each piece exists — this is the part worth internalizing:

• The nullifier is the double-spend defense: the contract never learns which leaf you're spending, so it can't mark leaves used. Instead you disclose hash(k) — deterministic per deposit, unlinkable to the commitment (different hash inputs), and stored forever. Spend twice → same nullifierHash → rejected. World ID, Semaphore, Aztec, Privacy Pools and every private-airdrop scheme reuse exactly this trick.
• recipient/relayer/fee inside the proof kills front-running: a withdraw tx sits in the public mempool; without this, any bot could copy your valid proof and swap in its own recipient. Because the proof constrains the payout, a tampered tx fails verification. (Compare §4.3's replay defenses — same instinct, ZK edition.)
• The relayer is gas abstraction, pre-4337: fresh address B has zero ETH to pay withdrawal gas — paying from A would deanonymize you. So a relayer (§6.2's concept!) submits the tx and takes fee from the note. Tornado needed a paymaster before paymasters existed.
• Anonymity set = the tree: your privacy is exactly "one of the N depositors of this pool" — why fixed denominations (0.1 / 1 / 10 / 100 ETH pools) exist: variable amounts would fingerprint you.

17.4b Production example #2 — how a zk-rollup batch actually lands on L1

§16 said "validity proof per batch." Concretely, a zkSync/Scroll-style pipeline does this:

Where you can see it: zkSync Era's commitBatches/proveBatches/executeBatches on its L1 diamond contract, Scroll's ScrollChain.finalizeBatchWithProof — open Etherscan and watch the cadence: many commits, periodic proofs covering several batches each (proving lags sequencing by minutes to hours; that gap is "soft finality" and it's why bridges quote two different finality times).

17.5 Where you'll meet ZK in the wild

18 · Consensus, Chain Security & the Quantum Question

Everything above assumed the chain itself is honest. This chapter is about why that's (economically) true — and about the one scheduled event that breaks the cryptography under every EOA on the planet.

18.1 What consensus actually does

A blockchain needs agreement on two things only: ordering (which tx came first — the double-spend question) and validity (state transitions follow the rules). Every consensus family is a different answer to "who gets to order, and what does cheating cost?"

18.2 Attack economics — what "secure" quantitatively means

• 51% on PoW: majority hash power lets you reorg recent blocks and double-spend. Not theoretical — Ethereum Classic was 51%-attacked three times in August 2020 alone (thousands of blocks reorged) because its hash rate was small enough to rent. Security budget = cost of hash power, and small PoW chains are chronically underfunded.
• PoS thresholds: ⅓ of stake can halt finality (blocks still flow, finalization stops); ½ can control fork choice; ⅔ can finalize an invalid chain. But attacking stake is visible and slashable — the protocol can identify and burn it, and the community retains the nuclear option of socially forking the attacker out. PoW punishment is only "wasted electricity"; PoS punishment is confiscation.
• Long-range attacks: old validator keys (already-withdrawn stake) could re-sign an alternate history from way back. Defense: weak subjectivity — new nodes must start from a recent trusted checkpoint, not genesis alone. A real, accepted trade of PoS.
• The other 90% of real losses aren't consensus attacks at all — they're §15's application bugs, bridges, and key compromise. Consensus is the strongest layer of the stack; that's why attackers aim above it.
• MEV (maximal extractable value): orderers can front-run/sandwich/reorder within a block. Ethereum's live mitigation is PBS (proposer-builder separation via MEV-Boost) + private orderflow; full "enshrined PBS" and encrypted mempools are roadmap. For wallet devs this is why "send via private RPC" options exist.

18.3 Quantum computing vs your private keys

Blockchain cryptography stands on two different pillars, and quantum computers hit them very differently:

So the question becomes: who has revealed their public key? Remember §2.6 — an address is keccak(pubkey)[12:], and a hash is quantum-safe. The pubkey itself only becomes public when you sign:

• Ethereum EOAs: every transaction you have ever sent revealed your pubkey (that's literally how ecrecover works — the signature is pubkey recovery, §2.6). Any address that has ever transacted is harvestable today and crackable the day Shor-scale hardware arrives. A never-used address (funds received, nothing sent) hides behind the hash — until its first signature hits the mempool, where a fast quantum attacker could in principle race-forge before inclusion.
• Bitcoin: same split — modern hashed addresses are protected until first spend (but address reuse re-exposes), while millions of early pay-to-pubkey coins, including Satoshi-era ones, sit permanently exposed. Estimates put ~a quarter of all BTC in quantum-vulnerable outputs — the canary everyone watches.
• Your seed phrase is not the weak point: BIP-39/BIP-32 (§2) are hash/HMAC constructions — Grover-only territory. It's the secp256k1 keys derived from the seed, once used, that are Shor-vulnerable. Harvest-now-decrypt-later applies to encrypted data, not signatures — but "harvest pubkeys now, forge signatures later" is the blockchain equivalent, and chains are a public, permanent pubkey archive.

The escape routes (and one you already know)

• NIST post-quantum standards (2024): ML-DSA (Dilithium, lattice), SLH-DSA (SPHINCS+, pure hash-based), FN-DSA (Falcon). Blockchain problem: signatures are huge (Dilithium ~2.4 KB, SPHINCS+ ~8–17 KB vs ECDSA's 65 bytes) — naively swapping them in would blow up block space. Hash-based one-time schemes (Winternitz/XMSS) are attractive precisely because their security is only hashes.
• STARKs are already post-quantum (§17.3 — hashes only): the research direction is wrapping many fat PQ signatures, or the whole state transition, inside one STARK. Aggregation turns "PQ signatures are too big" into "one proof per block."
• Account abstraction is the migration vehicle — the punchline of this whole guide: an EOA's ECDSA is hardcoded, but a smart account's validator is a module (§7 validateUserOp, §9's validator modules, §8's re-delegation). Rotating to a Dilithium or Winternitz validator is an installModule call, not a hard fork. Ethereum's 7701 endgame plus a PQ precompile is the orderly path; Vitalik has also sketched the disorderly one — an emergency hard fork where users prove key ownership from the quantum-safe part (a STARK over the BIP-32 seed derivation) to migrate frozen accounts.
• Timelines: current devices are orders of magnitude away from Shor-scale (thousands of logical, error-corrected qubits ≈ millions of physical). Serious forecasts cluster in the 2030s, with wide error bars — the industry posture is "no panic, but design escape hatches now," which is exactly what AA quietly is.

19 · Beyond the EVM: Solana, Tron, Cosmos

Everything so far assumed Ethereum's model: secp256k1 keys, account-state, gas markets, contract storage. Other major chains made different bets — and each difference changes how "wallets" and "signing" even work.

13.1 Solana — everything is an account, and storage pays rent

Keys & signing. Solana uses ed25519, not secp256k1. Derivation is SLIP-0010, all-hardened (m/44'/501'/0'/0'), so there are no xpub watch-only trees. The address is simply the base58-encoded public key — no hashing step, no 0x, no checksum casing (base58 excludes look-alike characters instead). Signing is plain ed25519 over the serialized message — fast, deterministic, no malleability drama, and no ecrecover: verification takes the pubkey as input rather than recovering it.

The account model — inverted from Ethereum. On Ethereum, a token contract owns a giant mapping(address => uint256) inside its own storage. On Solana, programs are stateless: code lives in one executable account, and every piece of state lives in its own separate account owned by that program. A transaction must declare up front every account it will touch (which is what lets the runtime execute non-overlapping transactions in parallel — think EIP-2930 access lists made mandatory and turned into a scheduler).

ATAs — Associated Token Accounts

Because state is externalized, your USDC balance is not an entry in the USDC program — it's a separate token account holding {mint, owner, amount}. The Associated Token Account program standardizes where it lives: a PDA (program-derived address) computed deterministically from seeds:

ATA = find_program_address(
        seeds = [wallet_pubkey, TOKEN_PROGRAM_ID, mint_pubkey],
        program_id = ASSOCIATED_TOKEN_PROGRAM_ID )
// PDAs are addresses WITHOUT private keys — bumped off the ed25519 curve.
// Only the owning program can "sign" for them. (Compare: a contract wallet
// with no key that ERC-1271 lets speak — same idea, protocol-native.)

• One ATA per (wallet, mint) pair — deterministic, so senders can compute your USDC ATA without asking you.
• The ATA must be created before first receipt, and someone must fund its rent (below). Wallets/dApps usually create it silently in the same transaction — that "account creation fee" when receiving a new token is this.

Rent — storage as a leased resource

Every account must keep a lamport balance proportional to its data size — the rent-exempt minimum (~0.002 SOL for a token account). In practice "rent" is a refundable storage deposit: close the account and the lamports come back. Ethereum makes you pay gas once to write storage forever; Solana makes you escrow for as long as the bytes exist. This is why Solana wallets have a "close empty token accounts, reclaim SOL" button — and why dust-token spam literally locks up attacker capital.

Other wallet-relevant differences: fees are tiny and mostly fixed (plus priority fees); the fee payer is just the first signer — someone else can pay for your transaction natively, no ERC-4337 apparatus needed; replay protection uses a recent blockhash (~60–90s validity) instead of a nonce, with "durable nonces" as the escape hatch; and there's no protocol distinction between "EOA" and "contract account" to abstract away in the first place.

13.2 Tron — the EVM cousin with a staking-based gas model

• Keys: same secp256k1 + keccak256 pipeline as Ethereum (path m/44'/195'/…). The 20-byte hash is prefixed with 0x41 and base58check-encoded — that's why every Tron address starts with T. Under the hood, a Tron address and an Ethereum address from the same key contain the same 20 bytes.
• Contracts: the TVM is an EVM fork — Solidity compiles for it; TRC-20 is a byte-for-byte ERC-20 clone. This is why Tron became the USDT settlement rail: familiar contracts + cheap transfers.
• The big difference — resources instead of a gas market: transactions consume Bandwidth (bytes) and Energy (computation), which you earn by staking (freezing) TRX. Stake enough and your transfers are effectively free, forever; unstaked users burn TRX at fixed rates. It's a prepaid capacity model versus Ethereum's per-transaction auction — great UX for high-frequency payment flows, at the cost of capital lockup.
• Consensus: DPoS with 27 elected "Super Representatives" — fast blocks and cheap fees, materially more centralized than Ethereum's validator set. Signing is ordinary ECDSA over sha256 of the raw transaction (txID = that hash).

13.3 Cosmos — not a chain, a kit for building chains

• One key, many addresses: most Cosmos-SDK chains share coin type 118' and secp256k1; the address is bech32(ripemd160(sha256(pubkey))) with a per-chain human prefix — the same key renders as cosmos1…, osmo1…, juno1…. Wallets like Keplr show them as different "accounts", but it's one keypair wearing different name tags.
• Signing: transactions are protobuf messages signed under SIGN_MODE_DIRECT (legacy Amino JSON still around for hardware wallets). Replay protection = account number + sequence (a per-account nonce), and the chain-id is inside the signed doc — EIP-155's lesson, learned independently.
• App-chains, not contracts-first: each Cosmos chain is a sovereign application (dYdX v4, Osmosis, Celestia…) with its own validator set and its own fee token; smart contracts (CosmWasm, Rust) are an optional module rather than the foundation. Cross-chain composability runs over IBC — light-client-verified message passing, protocol-level rather than bridge-contract-level.
• Fee model: gas exists, but prices are set per-chain (often near-zero, sometimes with fee-grant modules that let another account pay — their native paymaster analog).

13.4 Side-by-side: what "different from EVM" actually means

20 · Cheat Sheet — Every Number, One Memory Hook

Suggested learning order

1. §2–3 (keys, transactions) then §4 (191/712) — the foundation everything sits on
2. §5 (1271 / 6492 / SignatureChecker) — your original question; every dApp needs it
3. §7 (4337) — the big one; internalize the restaurant
4. §8 (7702) — short, but it changes assumptions everywhere
5. §6, §9–11 — permit, modules, ecosystem, as your build requires
6. §13–15 (EVM, proxies, hacks) — before you ship or audit any contract
7. §16–19 — scaling, ZK, consensus/quantum, multi-chain, as your product grows