Advanced Wallets

Concepts: Why Advanced Wallets, Multisig: Safe, Account Abstraction: ERC-4337, Smart Account Features, Social Recovery, MPC Wallets, Choosing Your Strategy

:::section{mins=5} Why Advanced Wallets :::

:::lead One key, one point of failure. Multisig adds more keys – but on February 21, 2025, Bybit showed that what gets attacked isn't the key, it's the layer between the key and what gets signed. The answer isn't "more keys." It's different planes of defense. :::

:::p{html} In card 3.1 we treated a wallet as a key pair plus a way to keep the private key safe: where it lives, who holds it, what routines protect it. That picture is complete enough for most user scenarios – a hot+hardware setup (3.1 §5) covers $5K–$100K with reasonable habits. But the model "one key controls everything" has an architectural ceiling. A signed transaction goes to the network and becomes irreversible: an [[gloss:eoa|EOA]] has no built-in limit on transaction size, no "wait, let me think" delay, no way to require a second approver. This isn't bad UX or a missing feature – it's a consequence of how Ethereum validates transactions at the consensus level. :::

:::p{html} February 21, 2025, 14:13 UTC: Bybit, the exchange, initiates a routine transfer of 30,000 ETH from a cold wallet to a warm one. The wallet is Safe{Wallet}, a [[gloss:multisig|multisig]] with a 3-of-6 threshold. Three signers, sitting at their workstations, open the Safe app, see a familiar transaction (recipient address, ETH amount, ordinary transfer), and each one signs on their [[gloss:hardware wallet|hardware wallet]]. Minutes later the cold wallet loses not 30,000 ETH but 401,347 ETH – roughly $1.46 billion. The largest crypto theft in history. The multisig did exactly what it was designed to do: three signatures collected, each cryptographically valid, the contract executed what was signed. The attack happened on a different layer – on the Safe{Wallet} web interface, whose JavaScript had been swapped out via compromised AWS infrastructure two days earlier. The signers saw one transaction and signed another. The hardware devices showed a hash (an unreadable string), and three people, independently, pressed "Confirm." :::

:::p{html} The lesson here isn't "multisig doesn't work." Multisig worked. The lesson is something else: security doesn't reduce to a single parameter (the number of keys). It distributes across several planes: where the key lives, who holds it, what the interface displays, what the contract validates, how access is recovered when something is lost. Over the past decade the industry has converged on four main classes of solutions, each strengthening a different plane. Multisig divides signing authority across several key-holders, defending against compromise of any one key. [[gloss:account abstraction|Account Abstraction]] ([[gloss:erc-4337|ERC-4337]] in March 2023; [[gloss:eip-7702|EIP-7702]] in May 2025) moves validation logic into a smart contract, enabling spending limits, batching, programmable rules. Social recovery restores access when a key is lost, through trusted guardians. MPC (Multi-Party Computation) splits the private key into shards that never exist in one place. The rest of this card examines each plane separately: what it actually defends against, where its limits are, and how these layers combine in practice. :::

:::callout Schools grade students through layered assessment. If there were only one final exam with one chance to pass – that would be the EOA model: fail, you're out; get lucky with the question, you graduate. But schools have spent centuries layering different forms of assessment: cumulative grades across a semester (so one bad day doesn't erase everything), examination boards of several teachers (so no single examiner can fail you out of spite), retakes with delay and preparation time (so a stumble doesn't mean starting over), parallel formats – oral, written, practical (so a weakness in one format doesn't hide a real gap). No single layer makes students smarter. Each one reduces the risk that a single point of failure wipes out years of work. Advanced wallets work the same way: each class of solution is a separate layer of insurance against its own type of failure, not an "upgrade" to a regular wallet overall. :::

:::keypoints{label="KEY POINTS"} html: An EOA on Ethereum is a single [[gloss:ecdsa|ECDSA]] key on the secp256k1 curve and one validation rule: sender == ecrecover(tx_hash, signature). This rule is baked into the protocol's execution layer; you can't change it at the EOA level. No "above-signature" logic lives on the account itself – no way to add a spending cap, no way to batch multiple operations, no way to pay gas in USDC, no way to require "someone else also has to approve." This is an architectural constraint, and advanced wallets are different ways of working around it without changing Ethereum itself. html: Bybit, February 21, 2025, $1.46 billion: a 3-of-6 multisig worked normally. The signers signed a transaction; the contract validated it. The attack happened on the layer between the key and what was signed: the Safe{Wallet} web interface, into which Lazarus Group (DPRK) injected malicious JavaScript through compromised AWS infrastructure. The signers thought they were transferring 30,000 ETH; what they actually signed was a swap of the Safe's implementation contract for a malicious one. The hardware devices showed only a hash – undecoded – turning the signing into blind signing (see 3.1 §5). html: The four classes emerged at different times, in different contexts: Bitcoin multisig (BIP-16, 2012), Safe on Ethereum (2017), MPC custody (Fireblocks, 2018), ERC-4337 AA (2023), EIP-7702 (Pectra, 2025). They don't form a ladder where each one is better than the last. They're different answers to different classes of risk: one key compromise (multisig), uncontrolled signing (AA adds caps and batching), losing access (social recovery), the key concentrated in a single point (MPC). In any real setup they tend to combine in layers: multisig on top of hardware wallets, social recovery as insurance against losing all owners, MPC at an institutional custodian with regulatory requirements. html: A "pure" single-class strategy is rare in 2026. The practical standard is a combination by value tier: hot+hardware from 3.1 for everyday use ($5K–$100K), a Safe 2-of-3 multisig for larger sums ($100K–$10M), social recovery as insurance for long-term storage. Still, no combination replaces the manual check: verify the address, verify the amount, and reconcile both against what the hardware device's screen actually shows. :::

:::details{badge=Advanced title="What was actually signed at Bybit: one parameter, $1.46 billion"} :::p{html} What was inside Safe's infrastructure before February 21. By the time of the attack, the threat actors had already held covert operational access to Safe's AWS cloud for two weeks – meaning they could read and write files in internal storage as a legitimate developer. The entry point was February 4: through social engineering, they got a Safe{Wallet} developer to run a malicious Docker project (the "MC-Based-Stock-Invest-Simulator") on his macOS workstation, which compromised the machine and gave the attackers his AWS access tokens. They located the S3 bucket serving Safe{Wallet}'s static files (a Next.js frontend), downloaded the bundled JavaScript, and spent nearly two weeks studying it – looking for the moment when the transaction object is handed from the UI to the EIP-712 hashing function before being sent to the Ledger. When they found it, they injected a surgically precise piece of JavaScript with three properties: (1) activation only when the transaction's from matched specific addresses (Bybit's cold wallet 0x1Db92e2E…CD2dFCF4 and an attacker-controlled test wallet); (2) swapping the transaction object between "Sign clicked in the UI" and "hash sent to the Ledger"; (3) restoring the original view in the UI immediately after the signature returned. For every other user of Safe everything worked perfectly normally – which is why the attack wasn't spotted in advance. :::

:::p{html} What happened when Bybit's proposer clicked Sign. The proposer created what looked like a routine transfer in the Safe UI – 30,000 ETH from the cold wallet to the warm wallet: {to: hotWallet, value: 30000 ETH, data: 0x, operation: 0}. The injected script checked the from field, found a match, and rewrote the object before signing: to: 0x9622…7242 (the attacker's contract), value: 0, data: 0xa9059cbb…, operation: 1. The first four bytes of data are the standard ERC-20 selector for transfer(address, uint256) – chosen deliberately, so that a quick glance reads "ordinary token transfer." The hash of this swapped object – not the original – went to the three Ledger devices. Signers switched back to the Safe UI to double-check visually, but by then the UI had already rendered the original 30,000 ETH transfer again. They looked sequentially: hash on Ledger → transaction in UI → "matches" → Confirm. In reality the hashes in the UI and on the Ledger did not match at that moment – but a person sees them sequentially, not side by side. One more factor: operation: 1 showed up on the Ledger as a single field marked "1," but a week earlier Bybit had signed a legitimate delegatecall for an mETH staking operation. A "1" in that field was not a red flag for the signers. :::

:::p{html} What the on-chain transaction did, and how the tracks were covered. When the 3-of-6 threshold was reached, an executor sent execTransaction(...) on-chain. The Safe Proxy saw operation: 1 and made a delegatecall into the attacker's contract 0x9622…7242. The key semantics of delegatecall: the called contract's code executes in the Safe Proxy's own storage, not in the called contract's. Inside 0x9622… sat a function with the signature transfer(address, uint256) (the same selector 0xa9059cbb as the ERC-20 standard), but its body did exactly one thing: stor0 = _to, writing the first parameter to its own slot 0. Through delegatecall, "its own" wasn't its own – the write landed in slot 0 of the Safe Proxy, where the proxy stores masterCopy, the address of the contract holding Safe's legitimate logic. Slot 0 was 0x34CfAC…3F5F (Safe L2 v1.3.0); it became 0xbDd077…9516 – a new "implementation" controlled by the attackers, containing functions sweepETH(receiver) and sweepERC20(token, receiver) that could move any funds without signature checks. The attackers immediately called sweepETH and took 401,347 ETH. Two minutes after the execution, they deleted the malicious JavaScript from the Safe S3 bucket and replaced it with a clean version; the infrastructure compromise was therefore only discovered during the incident investigation several days later. This attack would not have been possible if even one signer had an independent verification channel for the transaction's contents – a separate service parsing the calldata out of the hash being signed, or a second screen reading the recipient contract's ABI. This is exactly what Safe began rolling out after February 2025 (see §2 for details), and why the industry is moving toward architectures where the entire class "trusting a single UI" doesn't exist (see §5 on MPC). ::: :::

:::further{label="Further Reading"}

:::quiz{id=q-3-2-s1 label="Check yourself" correct=2 explanation="Correct. All three signers saw a routine 30,000 ETH transfer to the warm wallet in the Safe{Wallet} interface, and that's what they signed – at the hash level. But the Safe web interface had been compromised: the JavaScript serving the app from AWS S3 had been swapped out two days earlier through a breach of a Safe developer's machine. Unable to decode the complex transaction on their hardware screens (see 3.1 §5, blind signing), the signers signed not a transfer but a swap of Safe's implementation contract for a malicious one – after which the funds were drained via sweepETH(). Safe's own smart contract had no vulnerability and worked exactly as designed; the keys were not compromised, and the owners retained full control of them. The attack hit the layer between the signers and the contract – the UI that everyone trusted."} On February 21, 2025, Bybit lost $1.46 billion from a 3-of-6 multisig. What was the main cause of the hack?

  • All six of the wallet's keys had been compromised by the attackers
  • The 3-signature threshold was too low for a cold wallet holding that much
  • The signers signed a transaction different from the one shown in the Safe{Wallet} interface
  • The Safe smart contract contained a previously unknown vulnerability that the attackers exploited :::

:::section{mins=6} Multisig :::

:::lead Bybit wasn't the first. Four months earlier, $50 million was drained from Radiant Capital's 3-of-11 [[gloss:safe|Safe]] multisig by the same pattern: a compromised UI, valid signatures, [[gloss:blind signing|blind signing]] on Ledger. The industry knew, but didn't rebuild its processes in time. The question isn't multisig – it's how multisig is tuned. :::

:::p{html} Multisig is a requirement to collect N signatures out of M possible to execute an operation. The idea is ancient: bank vaults with two keys, nuclear codes with two officers. It arrived in crypto early, through two architecturally different doors. Bitcoin got multisig natively in early 2012: the corresponding operation was baked into the protocol's scripting language, and the condition "N of M signatures" became a built-in rule for spending coins. There's no way to give a Bitcoin wallet arbitrary logic – signature checking is all it does. A design narrowing, but also a defense: Bybit-style attacks, where an attacker swaps the contents of what's being signed, are structurally impossible in Bitcoin, because there's nothing to swap. :::

:::p{html} Ethereum took the other path: there's no native multisig support in the virtual machine, so the implementation is a smart contract that any team can deploy. Owners' signatures are gathered off-chain (through structured signing convenient for hardware wallets), and a single transaction with an attached array of signatures goes to the blockchain. The contract verifies that there are enough valid signatures and executes the action. This flexibility opens up rich possibilities (any operation, any logic, any integration with other contracts) and, at the same time, widens the attack surface – which is what we saw in §1. :::

:::p{html} On Ethereum, Safe (formerly Gnosis Safe) became the de-facto standard. It started as Gnosis Multi-Sig Wallet in 2017, evolved into Gnosis Safe in 2018, and split off as its own product, Safe, after a 2022 spin-off from Gnosis. As of early 2026, a serious share of the entire Ethereum economy runs through Safe: :::

:::p{html} Among the users: Ethereum Foundation, Uniswap, Aave, Lido. Technically, Safe is built so that opening a new wallet costs pennies: all the "smart" logic (signature checking, transaction execution) lives in a single shared smart contract deployed once on the network. Each individual Safe is a tiny "pointer" (~50 bytes) that, on every call, says "go to that shared contract for the logic." Each wallet's own state (list of owners, required number of signatures, history) is stored at the pointer itself; the computation happens in the shared contract. Signatures are gathered off-chain: each owner signs a structured message inside the Safe interface, which sits there until enough signatures are collected, and only then does one person send one on-chain transaction with the array of signatures attached. This gives one gas fee instead of N, and doesn't require synchronizing all owners in the same moment. :::

:::p The choice of the main parameter – the threshold – is driven by what's being protected: :::

:::p{html} Multisig is powerful, though narrow. It reliably defends against: compromise of any one key (an attacker holding one key out of the owner set can't move anything), insider fraud (no single owner can wire funds to themselves), loss of any one device (the remaining owners can reassign ownership and restore access). But it doesn't defend against another class of threat: :::

:::p{html} The main risk that's often underestimated is a threshold set too low. Radiant Capital had 3 signatures out of 11 – only 27%. An attacker with a month of preparation needed to compromise just a third of the owners. After the hack, the protocol reconfigured to 4 of 7 (57%) and added an independent verification channel on top of signatures. A reasonable 2026 practice for operations on critical contracts: a threshold of at least 60% of owners, with the owners themselves heterogeneous across operating systems, jurisdictions, and people. A homogeneous set is vulnerable to a single phishing campaign – as Radiant showed. :::

:::callout A closed-door premiere at a theater runs on a similar principle. To raise the curtain, three key crew members have to give the "ready" signal simultaneously: the director, the lighting designer, the sound engineer. If one of them is sick or hasn't shown up, the show doesn't start. This eliminates a unilateral decision: no single person can either cancel the performance or launch it without the others. But this arrangement does not defend against someone, between the morning rehearsal and the evening show, swapping the set pieces backstage. All three look at the stage through their monitors, everything appears in order, all three give "ready" – and when the curtain rises, an entirely different production stands before the audience. Multisig is a collective "ready," but not a defense against the substitution of what you think is ready. :::

:::keypoints{label="KEY POINTS"} html: Bitcoin multisig has been running since April 1, 2012 – 14 years with no serious attacks on the mechanism itself. Institutional custodians (Coinbase Custody, BitGo, Gemini) keep their core reserves in it for exactly that reason: smaller attack surface. Safe appeared in 2017, and in eight years it has been hit by Radiant and Bybit – both blows landed not on multisig cryptography, but on the layer between the keys and the contract. html: Safe is modular: a baseline "N of M" can be extended with daily spending caps, deferred execution, different thresholds for different categories. The addresses are deterministic – the same Safe can be deployed across any EVM chain. And unlike MPC (see §5), Safe is fully on-chain: there is no third party holding a piece of the key or the policy rules. html: A high threshold carries its own risk, symmetric to a low one. Too low (Radiant's 3-of-11) makes a single compromise catastrophic; too high (say, 7-of-9) freezes the wallet as soon as a few owners are unavailable. So after the hack, Radiant didn't just raise the threshold – it added a parallel layer: a Snapshot vote and a 48-hour timelock, an independent channel that doesn't depend on the threshold at all. html: After Bybit, Safe rolled out ten UI changes: calldata decoding, mandatory confirmation for operation: 1, validations for high-value transactions. But these are half-measures, not a cure: half the problem is outside Safe. Safely displaying a complex transaction on a Ledger screen requires a hardware-wallet firmware update, not a change to the Safe interface. The architectural class "trust in a single frontend" remains. :::

:::details{badge=Advanced title="Safe's architecture: minimal proxy, EIP-712, and what changed after Bybit"} :::p{html} Minimal proxy and singleton implementation. Before 2018, every new multisig wallet on Ethereum was deployed as a full contract – costing roughly 700,000 gas (about $5–$50 depending on the gas price). Gnosis Safe introduced the EIP-1167 minimal proxy: a single full-featured implementation contract (Safe L2 v1.3.0 at 0x34CfAC…3F5F) is deployed to the chain once, and every new Safe is a tiny proxy of around 50 bytes. The proxy contains exactly one instruction: "whatever is sent to me, forward via delegatecall to the address in my slot 0." Slot 0 holds the address of the singleton implementation. The following storage cells hold owners, threshold, nonce, and the rest of that particular Safe's state. Deploying a new wallet costs about 50,000 gas instead of 700,000. This same architecture is the reason the Bybit attack was possible: one parameter operation: 1 + a delegatecall into the attackers' contract + a write at slot 0 = a change of implementation for the entire proxy. The attacker didn't "break" Safe; they used the proxy's standard upgrade mechanism. :::

:::p{html} [[gloss:eip-712|EIP-712]] and off-chain signature coordination. The naive way to do N-of-M multisig would be: each owner sends their own on-chain "I vote for X" transaction, and the contract waits for N of them. That's N gas fees and N nonce conflicts. Safe took a different route: it uses EIP-712 structured signing. The coordinating application (usually the Safe UI) creates a TypedData object – a structured message with the EIP712Domain namespace, a SafeTx type, and the payload (to, value, data, operation, gas parameters, nonce). Each owner signs off-chain (the Ledger shows a structured view of the fields, not a bare hash). The signatures accumulate in the coordinating application until the threshold is reached. Then any executor (not necessarily an owner, not necessarily even a participant in the multisig) sends a single execTransaction(...) with the array of signatures attached. The result: one gas fee for the entire multisig, asynchronous coordination (no need for live calls between all owners), no nonce races. The price of this elegance is a single point of coordination: if the Safe UI is compromised, every signer sees the same forged data. Bybit and Radiant are two realizations of this risk. :::

:::p{html} What Safe changed after February 2025. On February 23, Safe entered lockdown mode and rebuilt its serving infrastructure; on March 3, Martin Koeppelmann (Safe co-founder) announced that the team had rolled out ten changes to the interface and backend. Among the confirmed ones: stricter calldata decoding (the interface tries to recognize the format of data before showing it to the signer), explicit warnings on operation: 1 with a mandatory two-step confirmation, additional validations for high-value transactions, improved Tenderly-simulation integration. What these changes don't solve: the ABI-decoding problem on hardware devices (that requires a Ledger/Trezor firmware update, not a Safe one), the physical size limit of hardware-wallet screens, the trust placed in the shared supply chain (the same JS frontend on S3 is still a single point of trust for every Safe account). A reasonable 2026 practice for large-value storage is therefore: local deployment of your own Safe interface (your own frontend in your own infrastructure), an independent security-rules check (a second system that parses the transaction contents independently of the interface), and a mandatory transaction simulation on a separate machine before signing. Further in the card: §5 (MPC) shows an alternative architectural class, where the very attack surface of a multisig smart contract is absent. ::: :::

:::further{label="Further Reading"}

:::quiz{id=q-3-2-s2 label="Check yourself" correct=2 explanation="Correct. A, B and D are exactly the risks a multisig is designed for. One compromised key out of 2-of-3 gives an attacker nothing; a single owner can't move funds without the rest; losing one device out of M is not critical, because the remaining M-1 can reassign ownership. C is a different beast: a UI attack on the frontend swaps the data between signer and contract, and all N signers see the same forged data on the same compromised UI. The multisig will work “as designed” here – collecting valid signatures over a forged transaction. Radiant Capital (October 16, 2024, $50M) and Bybit (February 21, 2025, $1.46 billion) are two episodes of the same class of risk, four months apart. After Bybit, Safe rolled out a series of UI patches, but the architectural class “trust in a single frontend” remained."} Which of these does a Safe multisig not architecturally defend against?

  • Compromise of one private key out of the threshold set
  • Insider fraud by a single owner
  • Substitution of the wallet UI through compromised supply-chain infrastructure
  • Loss of a single hardware device out of M owners :::

:::section{mins=6} Account Abstraction :::

:::lead In §1 we saw the architectural ceiling of an EOA: one key, one unconditional action. Account Abstraction lifts that ceiling by moving validation logic into a smart contract. By 2026 the approach is proven at scale: tens of millions of smart accounts. But the same flexibility that provides defense also opens a new class of phishing. :::

:::p{html} Lifting the EOA's architectural ceiling is not straightforward. Since 2015 the industry has tried at least three times, and each attempt ran into the same wall: a required change to Ethereum's consensus. EIP-86 (Vitalik, 2015) proposed validation through arbitrary code. EIP-2938 (2020) added a new transaction type, AA_TX_TYPE. EIP-3074 (2021) tried the AUTH and AUTHCALL opcodes. All three required a hard fork of the whole protocol. None reached mainnet – each got stuck in governance for years. :::

:::p Why would a user who already has a working wallet want this? Account Abstraction solves several problems that can't be fixed inside the EOA model: :::

:::p{html} Technically, all of this works as follows. ERC-4337 doesn't change Ethereum's consensus – it builds an intermediary layer on top of it, entirely in smart contracts. The idea is in three steps: :::

:::p{html} On-chain everything lands in a single shared dispatcher contract, the [[gloss:entrypoint|EntryPoint]], deployed at the same address on every EVM network (Ethereum, Arbitrum, Optimism, Base, Polygon, zkSync). It verifies signatures, routes each intent to the corresponding smart account, and handles gas payment. :::

:::p By Q1 2026 the result is real: more than 40 million smart accounts deployed, more than 100 million UserOperations executed, and ERC-4337 lives on every major EVM-compatible chain. But this required migrating to a new account address – and that's where the next step appeared. :::

:::p{html} EIP-7702, part of the Pectra upgrade (May 7, 2025), solved the migration problem: an existing EOA can temporarily delegate its code to a smart contract through a special new transaction type (0x04 SET_CODE_TX_TYPE), without changing its address. Sign a delegation tuple – and from that moment on, every call to your EOA executes the code of the delegate contract. Address unchanged, balance unchanged, history unchanged. But this came with a new attack vector. The same delegation that lets MetaMask offer "switch to a smart account for one swap" also lets a phishing site convince a user to sign one authorization – and the result is a persistent proxy into the attacker's contract. By late 2025, Wintermute and GoPlus Security reported that over 80–90% of observed EIP-7702 delegations are linked to malicious sweeper contracts; the Inferno Drainer group used MetaMask's official Delegator address as cover for $146K and $1.54M heists. AA's promise – UX, batching, recovery – comes with a symmetric attack surface. The rest of this section explains where the upside and the risk both come from. :::

:::callout The difference between a basic debit card and a programmable credit card captures it well. EOA is the debit card: there's a signature (or PIN), there's a balance – if it covers the purchase, the payment goes through. No "no more than $X per day without confirmation," no chargeback, no second signer. Whatever you signed, that's what left the account. A smart account is the credit card with rules built in: a daily limit, an online-purchase limit, SMS confirmation for large amounts, chargeback for fraud, sub-cards for family members with their own caps. The same physical "carrier" – but the programmable rules decide what's allowed. ERC-4337 is like issuing a new credit card: you get a new number, you have to move your auto-payments, redo your subscriptions. EIP-7702 is different – your existing debit card can now act like a credit card without changing its number. Convenient. But the same flexibility that powers the convenience (online checkout, instant approval, programmable limits) is what opens it to phishing: someone calls the victim, they read out a one-time code, and the "smart-rules" card lets a sum through that a plain debit card couldn't have moved without their being there in person. The smarter the card, the more ways into it. :::

:::keypoints{label="KEY POINTS"} html: ERC-4337 is a deliberate 8-year compromise. Vitalik proposed Account Abstraction in EIP-86 back in 2015; three attempts to push it through consensus-level changes got stuck in governance until 2023. 4337 chose not the "correct" path (at the protocol level) but the pragmatic one: get AA through intermediaries and a gas overhead instead of changing the core. The price – every [[gloss:userop|UserOp]] is 30–50% more expensive than a plain EOA transaction. The payoff – AA on mainnet without a hard fork after 8 years of waiting. html: ERC-4337 introduces a new class of centralization that doesn't exist for a regular Ethereum transaction. Bundlers aren't Ethereum validators – they're a separate commercial layer with their own mempool and their own economics. As of Q1 2026, Pimlico holds about 30% of all UserOps, with Coinbase and Stackup taking most of the rest. If a single dominant bundler goes down, a third of AA operations on mainnet stop. On L2, this is being addressed by pulling the EntryPoint into the protocol itself (RIP-7560 on Arbitrum and zkSync), but on mainnet 4337 stays. html: EIP-7702 has an architectural quirk that widens the attack surface: an authorization signature can be chain-agnostic (with chain_id = 0). That means a single signature can be replayed on several EVM networks. Composability with ERC-4337 makes it worse: an EntryPoint on any chain can call the delegated EOA as a normal smart account without further victim involvement. One signature → potential drain across multiple chains. html: AA has a structural property that cuts both ways: programmable rules permit any behavior – trusted or hostile. With ERC-4337 this is softened by migration: the victim has to consciously open a smart account at a new address. EIP-7702 has no such threshold – one signature on their own familiar address turns an EOA into a proxy. MetaMask's answer is a delegator whitelist and a requirement that the upgrade be confirmed inside the wallet, not through a DApp. :::

:::details{badge=Advanced title="UserOperation anatomy, Bundler economics, and EIP-7702 mechanics"} :::p{html} UserOperation anatomy and the three phases. A UserOperation is a structured object with fields the EVM would normally compose itself for an EOA transaction: :::

Execution goes through three phases:

The separation between validation and execution is the architectural payoff: account-level rules can reject an action before it costs anything.

:::p{html} Bundler economics and RIP-7560. A Bundler isn't an Ethereum validator; it's a separate piece of infrastructure with its own mempool, its own MEV strategies, and its own pricing. The Q1 2026 market: Pimlico holds about 30% of bundled UserOps, with Coinbase and Stackup taking most of the rest. Bundlers profit from a small margin on each UserOp's gas: they front the gas to mainnet, the EntryPoint refunds them on success. The price of this architecture: every UserOp pays the EntryPoint's validation overhead on top of the actual call – making ERC-4337 transactions roughly 30–50% more expensive than equivalent native EOA transactions. RIP-7560 (a Rollup Improvement Proposal, not an Ethereum L1 EIP) addresses this on L2s by moving EntryPoint logic into the protocol itself: Arbitrum and zkSync treat UserOperations as first-class transaction types, skipping the contract-level overhead. Mainnet will likely stay with 4337 for the foreseeable future, but L2s that ship 7560 see materially cheaper smart accounts. :::

:::p{html} EIP-7702 mechanics and why 80% of delegations are malicious. A type-0x04 SET_CODE_TX_TYPE transaction embeds an authorization list – tuples (chain_id, address, nonce, y_parity, r, s) where the signature authorizes the installation of a delegation designator 0xef0100 || delegator_address in the EOA's code slot. After that installation, any call to the EOA executes through the delegate's fallback(). The arxiv 2512.12174 paper identifies three reliable attack trigger pathways: :::

:::p{html} Composability with 4337 is what makes the second and third pathways especially dangerous: one signed authorization enables repeated drains with no further user interaction. MetaMask's defense is a delegator whitelist – by default only its own audited Delegator contract (0x63c0c19a282a1B52b07dD5a65b58948A07DAE32B) is allowed, and the in-app upgrade flow requires manual confirmation inside the wallet. Revocation is possible via a fresh SET_CODE with address(0). The architectural limit: an authorization has no scope – the delegation works at the code level, not the call level, so you can't restrict "only this contract" or "only this amount." Either the delegate is trusted with everything, or it shouldn't be installed. ::: :::

:::further{label="Further Reading"}

:::quiz{id=q-3-2-s3 label="Check yourself" correct=2 explanation="Correct. A is wrong: EIP-7702 and ERC-4337 are two different mechanisms – 4337 is a separate smart-contract account at a new address, while 7702 keeps the original EOA address. B is wrong: this is the key trap of EIP-7702. The delegation is persistent – it stays in effect across every subsequent transaction until the user signs a new SET_CODE with address(0) to revoke. That persistence is precisely what makes the phishing vector so effective: one signed authorization is enough to permanently route every future call into the attacker's contract. D is wrong: EIP-7702 was created specifically to avoid the migration that 4337 required. The right answer is C."} Which statement about EIP-7702 is correct?

  • EIP-7702 is an alternative name for ERC-4337
  • An EIP-7702 delegation lasts only for one transaction and is revoked automatically
  • An EIP-7702 authorization signature installs a persistent delegation of the EOA's code slot until explicitly revoked
  • EIP-7702 requires migration to a new smart-account address :::

:::section{mins=5} Social Recovery :::

:::lead Stefan Thomas locked 7,000 BTC inside an IronKey – over $700 million lost from circulation forever. Chainalysis estimates roughly 20% of all Bitcoin is gone the same way: forgotten seed phrases, damaged drives, owners who died and left no usable access to their heirs. [[gloss:social recovery|Social recovery]] is the attempt to answer this class of loss. :::

:::p{html} On January 11, 2021, Vitalik Buterin published "Why we need wide adoption of social recovery wallets". The post named what the community had long treated as the unavoidable cost of self-custody: lose your seed phrase, and your account is gone permanently, with no second chance. Vitalik called this not a fact of life but technical debt: a fixable design flaw, not an inherent feature of decentralization. His parallel was simple: a bank restores access through documents, signatures, and statements; why should crypto demand all-or-nothing? Just weeks before the post, the CEO of Nexus Mutual, Hugh Karp, had lost about $8 million in NXM tokens to a targeted attack on his hardware wallet. That story, along with Stefan Thomas's 7,000 BTC, became the catalyst. :::

:::p{html} Why is "3-of-5 guardians" not the same thing as a multisig? Because guardians don't sign your everyday transactions. A social-recovery wallet has a single signing key for daily use (the same UX as a regular wallet, one signature per transaction) and a list of guardians who sit dormant in the background. Guardians activate only in one scenario: you've lost your signing device and need a new key. Here's what recovery looks like in practice: :::

:::p{html} The first production implementation was [[gloss:argent|Argent]], launched in 2018 on Ethereum L1 – the same Argent whose founder Vitalik thanked at the top of his 2021 post. Setting up a wallet on L1 cost around $120 in gas, which limited adoption. In 2023, Argent moved to [[gloss:starknet|Starknet]], a ZK-rollup, where the same wallet costs a few cents. As of 2026, Argent runs two products: Argent Mobile on Starknet, and Argent X as a browser extension. Both combine a default Argent [[gloss:guardian|Guardian]] (a service Argent runs itself, which the user can disable) with user-added guardians: friends, family, or your own hardware wallet at a different address. Coinbase Smart Wallet (2024) took a different path: instead of human guardians, it uses passkeys synced through iCloud Keychain or Google Password Manager. Two philosophies of the same problem – one places trust in people, the other in a cloud provider's account security. Each closes a different failure mode; neither is universally better. :::

:::p{html} Social recovery introduces threats a seed phrase doesn't have: social engineering against guardians, the chance that guardians collude, the risk of all guardians losing access at the same time. But these threats are countable and reversible. You can change guardians, you can cancel a fraudulent recovery during the delay window, you can structure who has authority. A lost seed phrase has none of those properties. :::

:::callout A will and its executors follow the same logic. While you're alive and competent, you sign your own documents – no one else needs to be involved. But you've named three to five executors, people you trust, who never intervene in your affairs while you can act for yourself. If something happens – you become incapacitated, you die, you simply can't access your accounts – the executors act together to give your heirs access. The law gives a contestation window: it doesn't happen instantly, there are 30-90 days during which the procedure can be cancelled if it's a mistake or fraud. While you're alive and well, you can change executors at any time, you can cancel a procedure that's started, you can revise the terms. Social recovery works the same way: guardians are not co-signers on your daily life – they're the people who can return your access if you lose it, with a window for you to say "no, that wasn't me." :::

:::keypoints{label="KEY POINTS"} html: Vitalik's 2021 post was a re-framing, not a technical breakthrough. The mechanics had existed since 2018 (Argent). What the post did was take the industry's most-cited authority and reclassify "lose your seed, lose your funds" from an inherent property of self-custody to fixable technical debt. That reclassification opened the door for AA infrastructure later. html: Social recovery is a backup channel, not an operational one. That's the architectural difference from multisig. Guardians don't co-sign payments, they don't approve trades, they don't even know what you do. They activate only to swap the key – once or twice in the wallet's lifetime, if ever. Because of this, you can afford a higher threshold (5-of-9, not 2-of-3) – guardian coordination is rare. html: The delay window is the critical mechanism, not the threshold. Atomic recovery (instant key swap after enough guardian signatures) is vulnerable to social engineering: convince three guardians, take everything. A 36-hour delay with multi-channel alerts to the owner turns that into "convince three guardians AND survive 36 hours without the owner noticing." Without the delay, social recovery becomes a social attack. html: Argent and Coinbase Smart Wallet take opposite approaches to the same problem. Argent distributes trust among people (guardian voting). Coinbase Smart Wallet distributes it across devices and cloud providers (passkey + iCloud/Google sync). They close different failure modes: Argent survives losing your devices and your cloud account; Coinbase survives losing devices but assumes your cloud account is intact. The right choice depends on what you fear losing more. :::

:::details{badge=Advanced title="Argent guardian model, recovery mechanics, and the threats no seed phrase has"} :::p{html} The Argent contract: what the data structure looks like. Argent's wallet contract stores four pieces of state that matter for recovery: :::

:::p{html} Daily transactions go through execute() and check only the owner signature – guardians are not touched, gas is the same as for a regular wallet. Recovery is a separate path: triggerEscape(newOwner) requires the threshold of guardian signatures, sets a recoveryTimestamp, and emits an event that Argent's notification service picks up. During the escape period, the original owner can call cancelEscape() from any of their channels (mobile app, browser, email link). If escapePeriod seconds pass without a cancel, the next call to completeEscape() overwrites owner with newOwner and the wallet's signing key has changed. On Starknet, the same logic runs in Cairo – cheaper per transaction, same architectural shape. :::

:::p{html} Why Vitalik recommended this shape and not pure multisig for every transaction. The natural question is: if you trust your guardians, why not make every transaction require, say, 2-of-3 instead of solo signing? Vitalik's argument was UX. Pure multisig for daily use means every payment requires coordination with at least one other person, every game interaction needs a second signature, every approve+swap+deposit pulls in two people. That breaks the wallet for ordinary use. The split – solo signing for daily life, guardian threshold only for key replacement – preserves the convenience of a single-key wallet while adding a recovery path. ERC-4337 implements this directly inside validateUserOp(): the function accepts a normal owner signature for any operation, and a guardian-threshold signature only for the specific operation type replaceOwner(). Two different signature schemes for two different paths through the same contract. :::

:::p{html} Threats that didn't exist before, and how to mitigate them. Seed-phrase wallets have one threat: losing the phrase. Social-recovery wallets have several new ones: :::

:::p{html} Practical mitigations: use guardians from different social circles (not three relatives), different jurisdictions (not three Americans), and different device classes (one phone, one hardware wallet, one separate trusted person). Set the threshold above N/2 with at least one technical guardian – a hardware wallet you control at a separate address, immune to phone-number attacks. Use multi-channel notifications (email + push + on-chain event monitored by a watcher service). And – the architectural limit worth saying out loud – social recovery defends against loss, not against compromise. If an attacker steals your owner key and drains the wallet before you notice, no guardian vote brings the funds back. For that you need spending limits, timelocks, multisig on high-value operations – the tools from §2 and §3. Social recovery is one layer among several, not a replacement for the others. ::: :::

:::further{label="Further Reading"}

:::quiz{id=q-3-2-s4 label="Check yourself" correct=2 explanation="Correct. A is wrong: guardians don't participate in daily transactions – the owner signs alone. The split between everyday signing and guardian-threshold-only-for-recovery is the architectural point. B is wrong: a delay window (typically 24-36 hours) is what makes social recovery resistant to social engineering against guardians – without it, three convinced guardians mean a drained wallet. D is wrong: multisig requires N-of-M signatures for every operation; social recovery requires one owner signature for everything and threshold-of-guardians only for key replacement. C is right: a thief who steals the owner key and drains the wallet before you notice cannot be undone by a guardian vote – for that you need spending limits, timelocks, multisig on critical operations (the tools from §2 and §3). Social recovery is one layer among several."} Which statement about social recovery wallets is correct?

  • Guardians sign every transaction the owner makes
  • Recovery happens instantly after enough guardians have voted, without any delay
  • Social recovery defends against loss of access, but not against compromise of the main key
  • Social recovery is just a special form of a 2-of-3 multisig :::

:::section{mins=5} MPC :::

:::lead In §2 we saw multisig: N separate signatures on-chain, a visible trust structure. [[gloss:mpc|MPC]] (Multi-Party Computation) is a different class – the key exists only as separated shares, and the signature gets assembled in such a way that the full key never appears anywhere. By 2026, more than $10 trillion of institutional volume has moved through MPC custody. :::

:::p{html} Multisig and MPC both protect against single-key compromise, but they do it through entirely different architectures. Multisig is several people, several keys, several signatures: each owner has their own private key, each one signs separately, the on-chain contract verifies that enough signatures were collected. The structure is visible to anyone who reads the chain – the owners, the threshold, the history of approvals. MPC takes a different path: one key, split into shares, with the full key never assembled at any point. Each participant holds a share of the key – a fragment that is useless on its own and reveals nothing about the full key. To sign a transaction, t of n participants run a distributed cryptographic protocol that produces a regular ECDSA or Schnorr signature, without anyone ever reconstructing the full key. On the blockchain, the result is indistinguishable from an ordinary EOA signature. :::

:::p Why would a company that already has a Safe multisig switch to MPC? Because at institutional scale, four things start to matter in ways they don't for a $50K personal wallet: :::

:::p{html} The market leader is [[gloss:fireblocks|Fireblocks]], founded in 2018 in Israel by veterans of military cybersecurity. By 2026 it has processed over $10 trillion in transactions, serves 2,400+ financial institutions, and supports 150+ blockchains – a scale multisig solutions can't reach. Alongside it are BitGo (IPO January 2026 at a $2 billion valuation, $90 billion under management), Coinbase Custody (the largest regulated crypto custodian, $300 billion under management), and Ledger Enterprise for those who prefer hardware-based self-custody without MPC. :::

:::p{html} There's a trade-off the marketing language tends to skip over. "No third party has the key" is technically true – no single party holds the full key. But in practice the provider usually holds at least one share, the infrastructure the protocol runs on (Intel SGX enclaves, in Fireblocks's case), and the policy engine that enforces approval rules. Self-custody through MPC is therefore trust in a specific implementation, not the absence of trust. For a regulated institution with reporting obligations and a security team capable of evaluating a vendor's audit history, that trade-off is reasonable. For a $50K personal wallet, it isn't – the operational complexity outweighs the benefit, and Safe multisig from §2 already covers the threat model. :::

:::callout A vault belonging to a banking consortium illustrates the difference. The lock has a complex combination, but instead of one person knowing the whole thing, the combination is split into five parts among five participants. None of them knows the full combination. To open the vault, three of the five have to be present and turn their dials simultaneously in the right sequence – and the lock will accept it, even though no one in the room has ever seen the full combination. To anyone watching from outside, the only visible fact is: the vault opened. They don't see how many people were involved, who they were, or what the threshold was. Compare this with multisig – several separate locks on the same door, each opened with its own key. There you can count the keys used, identify whose they were, see the whole approval structure. Same goal, different visibility profile, different attack surface. :::

:::keypoints{label="KEY POINTS"} html: MPC's path from theory to production took 36 years. Andrew Yao formalized the field in 1982 with the "Millionaire's Problem"; the first production custody (Fireblocks) launched in 2018. The theory was waiting decades for a market large enough to justify the implementation cost – crypto's institutional adoption finally delivered it. html: MPC has one architectural advantage no other class shares: the wallet address survives signer changes. In multisig, swapping signers usually means a new contract address and a migration. In ERC-4337, changing owner is an on-chain transaction. With MPC, refreshing the shares is done purely off-chain – no migration, no new address, no on-chain footprint. For institutions that rotate custody teams quarterly, this is the difference between routine operations and a major project. html: "No third party has the key" is technically true but practically misleading. Fireblocks and BitGo don't hold the full key – but they typically hold one share, the infrastructure (Intel SGX enclaves), and the policy engine. Self-custody via MPC means trust in a specific vendor implementation, not the absence of trust. The protocols are incompatible across vendors: a Fireblocks MPC-CMP wallet can't be migrated to BitGo's TSS (Threshold Signature Scheme) without reshare from scratch. html: MPC and multisig aren't competing – they solve different problems. MPC wins for institutional scale: many blockchains, frequent signer rotation, high volume, operational privacy. Multisig wins where transparency is a feature: DAO treasuries with on-chain governance, public verifiability of "who approved this." Bybit's loss in §1 wasn't because they used multisig – it was because of blind signing on the UI. Multisig was the right tool; the failure was elsewhere. :::

:::details{badge=Advanced title="TSS cryptography, the Fireblocks architecture, and why “Zero Proof” mattered"} :::p{html} Threshold signatures: how the math works. A Threshold Signature Scheme (TSS) is a cryptographic protocol that lets t-of-n parties jointly produce a digital signature on a message, without any party ever knowing the full private key. The protocol has two phases. Distributed Key Generation (DKG): the n participants together generate the key in distributed form. Each party ends up with a share that is a function of the (never-assembled) private key, plus some auxiliary information. There is no "trusted dealer" handing out pieces – a trusted dealer would itself be a single point of failure. Signing: t of the participants run a multi-round protocol where each computes a partial signature from their share, and the partial signatures combine into a final signature that verifies under standard ECDSA or Schnorr. Threshold-ECDSA was computationally heavy until breakthroughs in 2018; threshold-Schnorr (and EdDSA) was structurally simpler from the start, which is why Bitcoin's Taproot upgrade made Schnorr-based MPC dramatically cheaper. The industry standard for threshold-ECDSA today is MPC-CMP (Castagnos–Catalano–Mauromandi–Pailler), built by Fireblocks's in-house cryptography team and used across most institutional deployments. :::

:::p{html} The Fireblocks architecture in practice. Fireblocks doesn't just implement MPC-CMP – it embeds it in a stack designed for institutional operations: :::

The trade-off worth naming: the whole system's security depends on Intel SGX. SGX has had a history of side-channel vulnerabilities (Spectre, Foreshadow, ÆPIC Leak), and any future SGX break would force a fundamental reassessment of MPC custody architectures built on it. Pure-software MPC implementations (without SGX) avoid this dependency but lose the hardware-level isolation guarantee.

:::p{html} "Zero Proof" and what implementation bugs look like. In 2022, researchers at Fireblocks disclosed a vulnerability in BitGo's TSS implementation, nicknamed "Zero Proof": it allowed an attacker with access to a single compromised endpoint to recover the full private key, defeating the central security property of MPC. The bug was in the open-source Lindell-Nof zero-knowledge proof library BitGo used; BitGo patched it in February 2023. No funds were lost (the vulnerability was disclosed before being exploited), but the episode illustrates a critical point: MPC's security is the security of a specific implementation, not the security of the underlying cryptography. The math of TSS is sound and well-studied. Each shipped implementation, however, is its own attack surface: every protocol round, every zero-knowledge proof, every share-serialization choice is a place where a bug can collapse the security model. The industry response has been heavy investment in third-party audits, bug bounties, and (Fireblocks's argument) a push for NIST standardization. As of Q1 2026 NIST IR 8214C remains in draft, and there's still no formal U.S. standard for TSS. That gap is what Fireblocks and a coalition of cryptographers petitioned the agency to close in 2025. ::: :::

:::further{label="Further Reading"}

:::quiz{id=q-3-2-s5 label="Check yourself" correct=1 explanation="Correct. A describes multisig, not MPC: in multisig each owner does hold their own private key, and the on-chain contract verifies N separate signatures. C is wrong: MPC's whole appeal at institutional scale is that it works on any chain with standard ECDSA or Schnorr signatures – Bitcoin, Solana, anything. D is the common marketing trap: the provider doesn't hold the full key, but typically holds one share, the infrastructure (SGX enclaves), and the policy engine. B is right: that's the architectural definition of MPC – distributed key generation, threshold signing, the full secret never assembled at any point."} Which statement about MPC is correct?

  • Each MPC participant holds their own private key, and every transaction requires N signatures on-chain
  • The key is generated in distributed form; t of n participants jointly produce a signature, but the full key never exists in one place
  • MPC works only on Ethereum and EVM-compatible chains
  • In MPC, Fireblocks or another provider has no access to your funds or infrastructure :::

:::section{mins=3} Choosing a Strategy :::

:::lead No single class covers everything. Multisig falls to a UI compromise (Bybit); social recovery doesn't help when the main key is stolen; MPC depends on trusting a vendor; AA opens a new class of phishing through EIP-7702. A strong setup is a combination of layers, calibrated to the amount and the use case – not a choice of one class. :::

:::p{html} Three dimensions determine the right setup. The amount in the wallet – it determines how much operational complexity makes economic sense to add. The frequency of operations – a wallet you touch daily needs different tools than one meant for ten-year storage. The control structure – one person, a family, a team, a corporation, a DAO. These three lead to predictable combinations: :::

:::p{html} The goal is not picking one row. Each layer in your setup closes a different failure mode: hardware defends against malware on the signing device; multisig defends against compromise of a single key; social recovery defends against loss of the key (not against compromise); AA adds spending limits, batching, and protection against blind signing on large amounts; MPC provides the institutional infrastructure (multi-chain, off-chain signer rotation, non-public approval structure) that multisig can't. Combining classes is how real treasuries are built. :::

:::keypoints{label="KEY POINTS"} html: The default is combination, not choice. A real $5M family setup looks like: hardware signers at three locations + Safe 3-of-5 contract + Argent social recovery as an overlay + spending limits via an AA module + a quarterly review process. Five layers, each closing a different failure mode. Choosing "one of the four classes" misreads the question. html: Anti-patterns to avoid. Under-engineered: a hot wallet with $5M (every phishing click is final). Over-engineered: Fireblocks MPC for $10K (you don't qualify as a client; the operational cost outweighs the value). Multisig without a recovery overlay for long-term storage (if everyone loses their devices, the wallet is dead). An AA wallet without a delegator whitelist after EIP-7702 (see §3 – one signature opens a persistent backdoor). html: When you cross a tier, don't migrate everything in one transaction. As your balance approaches the next threshold, set up the new wallet in parallel with a small test amount, run it for two to four weeks, then move funds in tranches. A single $1M transfer to a freshly-deployed Safe is a perfect target for an attacker watching mempool – multiple smaller transfers spread over time are not. html: No combination of classes substitutes for the final human-verification step: read the destination address and amount on the hardware-wallet screen before pressing Confirm. Bybit had architecturally correct multisig (§1); the loss came from three signers who trusted the UI instead of their hardware screens. :::

:::details{badge=Advanced title="Cost economics, failure cases by tier, and what a layered $5M setup actually looks like"} :::p{html} The economics of each class. Setup cost and per-transaction overhead determine when each class is worth using: :::

The cost curve explains the tiers: at $10K, $5/transaction in multisig overhead is a 5% drag on small transfers, which is absurd. At $1M, the same $5 is invisible. At $10M with frequent operations, Fireblocks's $50K/year is roughly 0.5% – well within the acceptable range for institutional security.

:::p{html} Failure stories by tier – when the setup was wrong for the amount. Each scale has its own characteristic loss patterns: :::

:::p{html} What a real $5M family-treasury setup looks like. A working layered design has five distinct components, each closing a separate failure mode: :::

No single layer here is overkill. Removing any one of them creates a specific risk that the remaining layers don't cover. This is what "combination of layers" actually means in practice. :::

:::further{label="Further Reading"}

:::quiz{id=q-3-2-s6 label="Check yourself" correct=2 explanation="Correct. A is wrong: MPC is institutional infrastructure that's economically unjustified below ~$10M, and as an individual you typically can't even become a Fireblocks client. B is wrong: MPC closes a specific class of failures (single-key concentration, multi-chain ops) but doesn't replace recovery from key loss or transparent on-chain governance. D is wrong: at $1M+, a single phishing click is final; tier matters. C is right – real wallets are built as stacks of layers, each closing a specific failure mode. The four classes from §2-§5 are tools, not alternatives. The next card (3.3) covers how transactions actually flow through these stacks – how the layers cooperate at signing time."} Which statement about choosing a wallet strategy is correct?

  • The more money, the more layers – MPC is the right choice for anything above $100K
  • If you use MPC, multisig and social recovery become unnecessary
  • Real setups are combinations of layers: hardware as base, multisig on top, social recovery as backup, AA limits where useful
  • A hot wallet with biometric unlock is enough for any amount, given proper habits :::