It’s Already Priced. — RTFM

Reading a Token Contract Before You Buy the Rug

2026-08-26T00:00:00+00:00

The rug is not a surprise. It is a function. Somewhere in the bytecode you approved, there is almost always a line that lets someone mint supply, freeze your balance, or tax your exit to zero, and it was there before you bought, sitting in public storage, waiting for you to not read it. People will spend forty minutes comparing gas fees and zero seconds checking whether the contract owner can blacklist their wallet. The information asymmetry in a rug pull is not technical. It is behavioral.

The Standard

The OWASP Smart Contract Top 10 is the closest thing this industry has to a shared checklist, and it exists precisely because these failures repeat. It is not a novel document. It restates, in a form auditors and builders can point at, the categories of defect that keep draining wallets: access control flaws, price oracle manipulation, logic errors, reentrancy, unchecked external calls, and so on. For the specific problem of buying a token that is engineered to trap you, three entries carry most of the weight.

The first is access control (the perennial top entry in one form or another). The standard says, in plain language, that privileged functions must be restricted to the correct roles, that those roles must be intentional, and that ownership must be either renounced or governed transparently. A mint function guarded by onlyOwner is not a bug. It is a documented capability. The standard does not tell you it is forbidden. It tells you that you, the reader, are supposed to know it exists and reason about who holds the key.

The second is logic errors, which OWASP uses as a catch-all for functions that do something other than what a naive user assumes. A transfer function that silently applies a 99 percent fee when a flag is set is not broken. It executes exactly as written. The defect is in your expectation, not the code.

The third is unchecked or dangerous external calls and upgradeability, because a proxy pattern (EIP-1967, transparent or UUPS) means the code you read today is not necessarily the code that runs tomorrow. The standard’s guidance is blunt: know whether the contract is upgradeable, and know who can upgrade it. An immutable contract with a mint function is a known quantity. An upgradeable contract that looks clean today is a promise from a stranger.

The framework does not promise safety. It gives you a vocabulary for the ways you are about to be robbed.

Where It Breaks Down

The failures are boring and consistent, which is what makes them survivable if you look.

Mint functions with no cap. The most common trap is an ERC-20 with an owner-callable mint that has no maximum supply check. The token page shows a fixed supply. The contract shows that supply is a suggestion. When the deployer decides to leave, they mint themselves several orders of magnitude more tokens and sell into whatever liquidity you provided. This is not hidden. It is a public function in the verified source. People miss it because they read the token’s marketing supply number on an aggregator and never open the code.

Ownership theater. A deployer calls renounceOwnership, the explorer shows the owner as the zero address, and everyone relaxes. Meanwhile the contract has a second privileged role, _authority or _taxWallet or a plain unnamed address checked in a require, that was never renounced and never will be. OpenZeppelin’s Ownable is one pattern. AccessControl with named roles is another. A hand-rolled require(msg.sender == someHardcodedAddress) is a third, and it does not show up as an “owner” anywhere convenient. Renouncing Ownable while retaining a custom admin is one of the oldest sleights in the deck.

Blacklists and allowlists disguised as compliance. A _isBlacklisted mapping, or an _isExcludedFromFee inverted into a de facto whitelist, lets the deployer prevent specific addresses from selling. The honeypot variant is elegant: anyone can buy, but the transfer function reverts for any address not on an allowlist that only ever contains the deployer. Your buy succeeds. Your sell reverts every time. On-chain, this looks like a token nobody can sell, which is exactly what it is.

Mutable fees. A setFee function with no upper bound. You buy at a 3 percent tax. Before you sell, the fee is set to 100 percent, or to 99 with a floor that swallows the rest to gas. The fee variable is a state variable, the setter is onlyOwner, and the ceiling that should be enforced in the setter is simply absent.

Upgradeable proxies as a blank check. The implementation contract you read on the explorer is clean. It is also not the contract users interact with. The proxy at EIP-1967 storage slots delegates to an implementation the admin can swap at will. A malicious upgrade replaces transfer with a honeypot after liquidity has accumulated. The tell is in the storage slots and the admin address, not in the pretty implementation code everyone reads.

Wallet behavior finishes the job. The reason none of this gets caught is the approval flow. Users click through approve for type(uint256).max because the wallet UI presents unlimited approval as the default convenience, and because reading a hex calldata blob in a signing prompt is not something the interface encourages. The contract’s malice and the wallet’s opacity meet exactly at the confirm button. Simulation is available. Most people confirm blind.

Unverified source, or verified-but-unread. Half the rugs ship unverified bytecode, and people buy anyway on the theory that the chart looks good. The other half verify the source, correctly assuming that verification itself functions as a trust signal and that almost nobody reads what was verified.

Doing It Right

You do not need to be an auditor. You need a checklist and fifteen minutes.

Open the verified source. If it is not verified, that is your answer. If it is, read the token functions specifically: transfer, transferFrom, _transfer, and every function with an access modifier. You are looking for branches, fee math, and mappings that gate transfers.

Grep for the capabilities, not the promises. Search the source for mint, blacklist, whitelist, setFee, setTax, pause, onlyOwner, setMax, and owner. Every match is a capability someone holds over your position. For mint, confirm whether there is a hard cap enforced in the function body, not just declared as a constant that is never checked.

Enumerate every privileged role. Do not stop at owner. Look for AccessControl roles, hardcoded addresses in require statements, and secondary admin variables. Check whether ownership is actually renounced by reading the current owner from storage, and confirm no shadow admin survives.

Check for a proxy. Read EIP-1967 implementation and admin slots. If it is a proxy, the admin can change everything, and your analysis of the implementation has a shelf life of exactly one upgrade. Treat an upgradeable token with an EOA admin as a token controlled by one person’s private key.

Simulate the sell before the buy. Use a transaction simulator or a honeypot-detection tool to execute a buy and a sell against the live contract state. If the sell reverts or returns dust, you have found the trap without funding it. Tooling categories exist for exactly this. Use them.

Scope your approvals. Never approve type(uint256).max to a contract you have owned for four minutes. Approve the amount you are spending. Revoke approvals you no longer use. This does not stop a mint or a blacklist, but it caps the blast radius of the ones you missed.

For builders: renounce completely or govern transparently through a timelock and multisig, cap your mint in the function body, put a hard ceiling in every fee setter, and if you must be upgradeable, put the proxy admin behind a timelock so users can exit before a malicious upgrade lands. Make the contract boring to read. Boring is the compliment.

The Bottom Line

The rug was in the source the whole time. It was public, it was verified, and it was legible to anyone willing to spend less time than they later spent explaining the loss to their spouse. The tooling exists, the standard is written down, and none of it matters if the confirm button is faster than the checklist. You will read the contract next time. Everyone says that.

It was priced in before you signed.

More: Issues · Field Notes · RTFM

Oracle Manipulation and Price Feed Integrity

2026-08-19T00:00:00+00:00

Every few months someone loses eight figures and the postmortem describes it as a “hack.” Read the transcript and you will usually find no reentrancy, no integer overflow, no signature bypass. The contract executed exactly as written. It just executed against a number the attacker chose. This is the uncomfortable truth of DeFi security: the smart contract was fine. It believed a lie, and belief was the whole design.

Oracle manipulation is not an exotic attack. It is the default failure mode of any protocol that turns an external value into money, and it persists not because it is subtle but because trusting a price feels like plumbing rather than a trust boundary. You would never let an attacker set your access control. Protocols let attackers set their prices every day.

The Standard

An oracle is any mechanism that brings off-chain or cross-contract information onto the chain where a contract can act on it. For prices, the reference implementation almost everyone benchmarks against is Chainlink Data Feeds, so it is worth stating what it actually provides, because most people cite it without reading it.

A Chainlink Data Feed is an on-chain contract (the aggregator) whose value is updated by a decentralized network of independent node operators. Each operator sources a price from multiple exchanges and data providers, the network aggregates those observations, and a new answer is written on-chain when either a deviation threshold is crossed (the price moves more than some percentage) or a heartbeat elapses (a maximum time between updates). Consumers read it through the AggregatorV3Interface, primarily via latestRoundData(), which returns not just the answer but roundId, startedAt, updatedAt, and answeredInRound.

The important part is what those extra fields are for. Chainlink does not just hand you a number. It hands you a number plus the metadata required to decide whether you should trust it. The updatedAt timestamp tells you how stale the value is. The answeredInRound versus roundId comparison tells you whether the answer is from the current round or a carried-over stale one. The feed also exposes decimals() so you interpret the fixed-point integer correctly.

The design intent is a market-wide price aggregated across many venues and many reporters, which is expensive to move because you would have to move the whole market, not one pool. That is the standard. A volume-weighted, multi-source, freshness-stamped price with a documented deviation and heartbeat behavior. Anything less than that, you are building your own oracle whether you admit it or not.

Where It Breaks Down

The failures are boringly consistent.

The first and most common is using a spot price from a single liquidity pool as an oracle. Reading getReserves() on a constant-product AMM pair and computing reserve1 / reserve0 gives you an instantaneous price that any actor with enough capital can move within a single transaction. Combine that with a flash loan, which lends you arbitrary capital for the duration of one atomic transaction, and the attacker does not even need money. They borrow ten million, skew the pool, trigger your contract to read the skewed price, extract value, and repay the loan, all before the block closes. The pool “price” was real for exactly one transaction, which is all the attacker needed.

The second is treating a TWAP as a magic ward. A time-weighted average price (for example the Uniswap V3 cumulative tick oracle) is genuinely harder to manipulate than spot, because you have to sustain a distorted price across the averaging window rather than for one block. But a short window on a low-liquidity pair is still cheap to push, and a long window makes your protocol dangerously slow to react to real moves, which is its own liquidation risk. A TWAP is a tradeoff, not a solution, and people ship it as if the acronym were a security proof.

The third is consuming Chainlink correctly and then ignoring everything Chainlink told you. This is the failure that hurts most, because the team did the “right” thing and stopped halfway. Common patterns:

Calling latestAnswer() (the deprecated function) and discarding all metadata, so you have no freshness check at all.
Reading latestRoundData() but only using the price, never comparing updatedAt against the feed’s known heartbeat. If the feed stalls, halts, or a node network degrades, you keep trading against a frozen number.
Never checking that answeredInRound >= roundId, so a carried-over stale round passes as current.
Not checking price > 0. Aggregators can return zero or negative sentinel values under certain conditions, and a naive division downstream turns that into nonsense collateral valuations.
Hardcoding decimals at 8 or 18 by assumption rather than reading decimals(), which quietly breaks the moment you add a feed with a different scale.

The fourth is the price-of-a-derived-asset problem. You want the price of an LP token, a wrapped staking token, or a rebasing asset, and no direct feed exists, so someone computes it from underlying reserves or a redemption rate. Now you have reintroduced a manipulable pool read inside a wrapper, and the Chainlink feed you were so proud of is decorating an unsafe computation. LP token pricing in particular has a well-known correct form (using the invariant and the fair reserves derived from external prices) and a naive form (reserves times spot), and protocols pick the naive one constantly.

The fifth is L2 and cross-chain assumptions. On some rollups the sequencer can go down, during which feeds do not update and cached prices go stale while the market moves. Chainlink publishes a sequencer uptime feed precisely so you can pause liquidations when the sequencer has just come back. Most integrations do not read it.

The common thread: the exploit was not in the loop or the math. It was in the assumption that a number was a fact.

Doing It Right

Treat every external value as attacker-controlled until proven otherwise, and design the trust boundary explicitly.

Source prices from a decentralized, multi-venue aggregator, not from a single pool you happen to be near. If you use Chainlink Data Feeds, validate every read. Concretely, on each latestRoundData() call: require price > 0, require answeredInRound >= roundId, and require block.timestamp - updatedAt <= maxStaleness, where maxStaleness is set from the specific feed’s documented heartbeat plus a margin, not a magic constant copied from a tutorial. Read decimals() rather than assuming. If any check fails, do not fall back to a spot price. Revert or pause. A protocol that halts is embarrassing. A protocol that liquidates users on a stale price is insolvent.

If you must derive a price with no direct feed, use the mathematically manipulation-resistant construction. For AMM LP tokens, price the pool from external per-asset feeds and the pool invariant, never from raw reserve ratios. For staking and wrapped tokens, prefer the protocol’s on-chain redemption rate over a market pool where possible, and understand that redemption rates can also be gamed if the underlying protocol is manipulable.

If you need a pool-based oracle at all, use a TWAP with a window sized to the liquidity you are actually protecting, and stress test the cost to move it. Ask the concrete question: how much capital, sustained over how many blocks, would it take to move this price by the amount that makes an attack profitable? If the answer is less than the value your protocol holds, you do not have an oracle, you have a bounty.

Add circuit breakers. Bound how far a price can move between updates before the protocol pauses and requires human or governance review. Read the sequencer uptime feed on L2s and gate liquidations on it. Assume the feed will one day return garbage and decide, in advance and in code, what happens when it does.

Finally, model this in testing. Fork mainnet, simulate a flash loan, push the pool, and confirm your contract reverts instead of paying out. If your test suite never once tries to lie to your oracle, your test suite is not testing your oracle.

The Bottom Line

Oracle manipulation endures because it does not look like a vulnerability. It looks like reading a variable. The code is clean, the audit is green, and the number is a knife someone else is holding. You can write flawless Solidity around a price you do not control and you will still be drained, and the postmortem will still, wrongly, call it a hack.

The number is not the market. The number is a claim, and every claim has an author. Find out who that is before you settle a position against it.

It was already priced. You just trusted the wrong feed.

More: Issues · Field Notes · RTFM

Upgradeable Contracts and the Admin Key Problem

2026-08-12T00:00:00+00:00

“Immutable” is the most abused word in this industry. It gets stamped on landing pages, printed in audit summaries, and repeated in Discord by people who have never read the storage layout of the thing they are defending. The uncomfortable truth is that most “immutable” contracts sit behind a proxy, and behind that proxy is a key, and behind that key is a person, or a multisig, or a compromised laptop. Code you cannot change is a security property. Code that one address can replace at will is a promise, and promises are not a threat model.

The Standard

The dominant pattern for upgradeability in the EVM ecosystem is the proxy, and OpenZeppelin’s proxy libraries are the reference implementation most teams actually deploy. The mechanics are worth stating plainly because the abstraction is where people stop thinking.

A proxy is a thin contract that holds the state and the balance. It contains almost no logic of its own. Every call it receives, it forwards via delegatecall to a separate implementation contract (also called the logic contract). Because delegatecall executes the implementation’s bytecode in the proxy’s storage context, the implementation defines behavior while the proxy owns the data. Upgrading means pointing the proxy at a new implementation address. The state stays; the logic is swapped underneath it.

Two patterns dominate. The Transparent Proxy Pattern (EIP-1967 for storage slots, plus a ProxyAdmin contract) routes upgrade calls through a dedicated admin address and everything else through to the implementation, avoiding function selector clashes. UUPS (Universal Upgradeable Proxy Standard, EIP-1822) moves the upgrade logic into the implementation itself via an upgradeTo function guarded by an access control check, which makes the proxy cheaper but means a botched implementation can permanently remove the ability to upgrade. EIP-1967 standardizes the specific storage slots (implementation, admin, beacon) so tooling can find them deterministically instead of colliding with application state.

The critical detail that every one of these standards shares: upgradeability requires a privileged role. The ProxyAdmin owner. The account authorized to call upgradeTo. The beacon owner in the Beacon Proxy pattern, who can upgrade an entire fleet of proxies in a single transaction. OpenZeppelin’s documentation is not shy about this. The library gives you AccessControl and Ownable and expects you to lock the role down. What it cannot do is stop you from setting that role to a hot wallet and forgetting about it.

So the standard, stated honestly, is this: you get to change the code, and the only thing standing between users and arbitrary new code is whoever controls the admin key. Everything else is implementation detail.

Where It Breaks Down

The failure modes are boring, repetitive, and entirely predictable, which is exactly why they keep happening.

The admin is an EOA. A single externally owned account, one private key, controls the upgrade. This is the original sin. Now the “immutability” of the protocol is exactly as strong as one seed phrase, and that seed phrase is subject to phishing, malware, a compromised CI pipeline that had deploy keys, or a founder who signs a malicious transaction because the wallet UI rendered upgradeTo as an opaque blob of calldata.

The multisig is theater. Teams graduate to a Safe and consider the problem solved. But a 2-of-3 where all three signers use the same hardware in the same office, or where two of the three keys live on machines the same DevOps engineer administers, is a 2-of-3 in name and a 1-of-1 in practice. Signer independence is the entire point of a multisig, and it is the first thing sacrificed for convenience. Worse is the multisig with a low threshold and inactive signers, where the “quorum” is really just the two people who reliably show up.

No timelock, or a timelock that lies. OpenZeppelin ships a TimelockController for a reason: it forces a delay between when an upgrade is queued and when it can execute, giving users a window to read the proposed implementation and exit if they do not like it. Plenty of protocols skip it entirely, so an upgrade lands atomically with no warning. Others deploy a timelock and then hold the admin role over the timelock itself, or set the delay to something cosmetic like an hour, or retain a separate “emergency” path that bypasses the delay. A timelock you can cancel or route around is documentation, not a control.

Storage layout mistakes turn upgrades into corruption. Because the implementation runs in the proxy’s storage, appending a variable in the wrong slot, reordering existing variables, or changing a type reinterprets existing state as something else. The __gap variable convention exists precisely to reserve slots in upgradeable base contracts, and it is routinely omitted or miscounted. Storage collisions do not always announce themselves. A balance mapping can quietly start reading from a different slot, and the first sign of trouble is funds that no longer add up.

Uninitialized implementations. Upgradeable contracts replace constructors with initialize functions, because a constructor runs in the implementation’s context, not the proxy’s, and therefore never touches proxy state. If the implementation contract is deployed and left uninitialized, an attacker can call initialize on the implementation directly, take ownership of it, and (in UUPS setups) call upgradeTo or selfdestruct through it. The _disableInitializers call in the constructor exists to prevent exactly this, and it is exactly the line people delete when they are copying code and hitting compiler errors.

Opaque governance that is upgrade-in-disguise. A DAO that can pass a proposal to change the admin, or to upgrade directly, is an admin key wearing a costume. If a small number of delegates or a single large holder can push a proposal through, the decentralization is nominal. The threat model did not disappear; it moved to the token distribution, where nobody is auditing it.

Doing It Right

If you are a builder, the target is not “never upgrade.” Upgradeability is a legitimate tool for fixing bugs. The target is to make the upgrade path slow, visible, and expensive to abuse.

Put the admin behind a timelock, and put the timelock in front of everything. Use OpenZeppelin’s TimelockController with a delay measured in days, not hours. The multisig proposes; the timelock enforces the wait; the community can watch. Do not keep a bypass. If you have an emergency pause requirement, separate pause (a narrow, reversible circuit breaker) from upgrade (the thing that can replace all logic) and never let the pause role touch the upgrade slot.
Make the multisig real. Independent signers, independent hardware, geographic and organizational separation, a threshold that survives losing your least reliable signer. Rotate keys when people leave. Document who holds what, and treat that document as sensitive.
Publish the storage layout and diff it on every upgrade. Use OpenZeppelin Upgrades plugins (Hardhat or Foundry) which validate storage compatibility and flag unsafe operations before deployment. Keep __gap slots in your base contracts and account for them. Verify the new implementation on a block explorer before, not after, execution.
Disable initializers on implementations. Call _disableInitializers() in the constructor of every UUPS or transparent implementation. Confirm it. This is a one-line defense against a catastrophic class of takeover.
Consider a credible path to immutability. If your endgame is a fixed protocol, hand the admin to a burn address or a timelock with no owner, and say so on-chain in a way that can be verified. “We will decentralize later” is not a control; a renounced admin key is.

If you are a holder, do the boring work. Read the EIP-1967 slots. Find out who holds the upgrade role. Check whether there is a timelock and what its delay is. Watch the admin address for queued proposals. A protocol that will not tell you who can replace its code has already told you something.

The Bottom Line

Immutable code is a real and valuable property, and almost nothing you interact with actually has it. What most protocols have is upgradeable code with a governance story, and the security of that story collapses to the security of one key, one quorum, one timelock delay. The word “immutable” costs nothing to print and buys a great deal of trust it has not earned. Read the slots. Trust the delay, not the tweet. The code you are relying on is only as fixed as the person who can change it lets it be.

It’s already priced. The admin key isn’t.

More: Issues · Field Notes · RTFM

Bridge Risk and Why Cross-Chain Is the Weakest Link

2026-08-05T00:00:00+00:00

Every serious person in this industry knows bridges are the softest target on the board, and yet the collective response is to keep piling value into them anyway. The reasoning is always the same: the yield is over there, the liquidity is over there, the users are over there, and the bridge is just plumbing. Plumbing is exactly how attackers see it too, except they understand something the average integrator does not, which is that a bridge is not plumbing. It is a bank vault whose combination is held by five to nine people you have never met, protected by code that reconstructs authority across two execution environments that were never designed to trust each other.

The Standard

Trail of Bits, in Building Secure Contracts, does not treat bridges as a special exotic category. It treats them as an aggravated instance of the same discipline it demands everywhere: minimize trust assumptions, make those assumptions explicit, and validate every input that crosses a trust boundary. A cross-chain message is the ultimate untrusted input. It originates on a chain your contract cannot see, is relayed by parties your contract cannot verify directly, and asserts facts your contract must accept or reject with no ability to independently re-execute the source transaction.

The guidance decomposes into a few durable principles. First, know precisely who your trusted parties are and what happens when they misbehave or collude. In bridge terms this is the validator set, the guardians, the multisig signers, or the oracle committee that attests to events on the origin chain. The framework insists you enumerate the exact threshold at which security fails (the classic m-of-n), and treat compromise of that threshold as a live scenario, not a tail risk.

Second, validate messages, not just senders. A bridge endpoint typically exposes a privileged function, something shaped like receiveMessage(bytes payload, bytes[] signatures), that mints, unlocks, or executes on the strength of attestations. The standard requires that this function verify signature validity, verify the signer set matches the currently authorized set, enforce nonce or message-id uniqueness to prevent replay, and confirm the payload decodes to something the contract expects. Every one of those is a check that has been omitted in production more than once.

Third, follow checks-effects-interactions and guard against reentrancy across the message boundary, because a bridge callback that hands control to an arbitrary target is a reentrancy vector with a longer fuse than usual. Fourth, respect upgradeability discipline: most bridges are proxies (EIP-1967 storage slots, transparent or UUPS patterns), and the upgrade key is frequently the single most valuable key in the entire system, more valuable than the validator set itself, because whoever holds it can rewrite the verification logic wholesale.

Where It Breaks Down

The failures are depressingly consistent, and they cluster in a few mechanisms.

The first is signature verification that verifies the wrong thing. A bridge accepts a batch of signatures and checks that they are valid ECDSA signatures over the message. It does not adequately check that the recovered addresses are in the authorized validator set, or it checks membership but does not enforce that they are distinct, allowing one compromised key to be counted m times toward an m-of-n threshold. ecrecover returning address(0) on malformed input is a related classic: if address(0) is ever treated as a valid signer, the whole threshold collapses to zero. Any verification path that does not explicitly reject the zero address is a loaded gun.

The second is the trusted initialization and root-of-trust problem. Many bridges verify a Merkle proof against a state root or a receipt root that some relayer submitted. If the contract accepts a root without verifying who was allowed to post it, or if the light-client logic that validates block headers has a gap (accepting a header without checking the validator signatures that finalized it, mishandling epoch or validator-set transitions, trusting a checkpoint that was never actually finalized), then the Merkle proof is theater. The proof is only as strong as the root it terminates at, and the root is only as strong as the process that admitted it.

The third is replay and cross-domain confusion. Message IDs that are not domain-separated allow a valid message on chain A to be replayed on chain B, or on a testnet-to-mainnet path, or across a fork. Nonces that are not enforced per-source-chain allow the same withdrawal to be processed twice. This is the same discipline EIP-712 formalizes for typed structured data with its domain separator, and bridges that roll their own encoding tend to skip the parts of EIP-712 that actually matter, namely binding the chain id and the verifying contract into the signed digest.

The fourth is the privileged callback. A general-purpose bridge that executes arbitrary calldata on the destination (the “call any contract with these funds” feature that integrators love) turns the bridge into a universal msg.sender that other protocols trust. If a downstream contract uses msg.sender == bridgeAddress as an authorization check, the bridge’s arbitrary-call feature becomes an authorization bypass for that contract. This is trust boundary erosion: the bridge’s compromise now propagates into every protocol that trusts it as a caller.

The fifth, and the one that renders the other four almost academic, is key management. The validator threshold is often much larger than the upgrade multisig. A bridge might advertise a 13-of-19 guardian set and secure its entire proxy behind a 2-of-3 Gnosis Safe whose signers share an operational team, a cloud provider, and in the worst cases a hardware wallet seed derived on an internet-connected machine. The attacker does not need to break the cryptography. They need to phish two people or find one leaked key, and the guardian set becomes irrelevant.

On the wallet side, the failure is that users sign bridge approvals blind. An approve to a bridge router for type(uint256).max, or a Permit2 signature with a distant deadline, hands standing authority to a contract the user will never re-examine. When the bridge is later compromised or upgraded to hostile logic, that approval is still live.

Doing It Right

For builders, start by writing down the trust model as an explicit artifact, not a diagram in a pitch deck. State the exact threshold, the identities and independence of signers, the upgrade key custody, and the blast radius of each key’s compromise. If the upgrade key is weaker than the validator set, fix that first, because it is the real key.

Verify the full chain of custody in code. Reject address(0) from ecrecover. Enforce signer distinctness with a sorted, strictly-increasing address check. Domain-separate every message with chain id and contract address in the digest, following EIP-712 semantics even for internal encodings. Enforce per-source nonces or a consumed-message-id mapping, and make replay structurally impossible rather than statistically unlikely.

Constrain the destination execution surface. If you must support arbitrary calls, isolate them behind a dedicated executor contract with no privileges of its own, so a compromised bridge cannot impersonate a trusted caller. Add rate limits and per-asset caps enforced on-chain, plus a circuit breaker with a delay, so that draining the vault takes long enough for a human to intervene. A time-delayed withdrawal for large amounts is unglamorous and effective.

Run the standard tooling before you ship: static analysis (Slither) for the obvious authorization and reentrancy patterns, fuzzing (Echidna, Foundry invariant tests) against properties like “no message processed twice” and “total unlocked never exceeds total locked,” and a real audit that reviews the off-chain relayer and light-client code, not just the Solidity.

For holders, treat bridge approvals as expiring, revocable grants. Approve exact amounts, not infinite. Revoke standing approvals (Etherscan’s token approval tool or equivalent) after use. Prefer bridges with published, verifiable validator sets and on-chain rate limits over ones whose security is a marketing claim. Assume any funds sitting in a bridge contract are at the mercy of that bridge’s weakest key, and size your exposure accordingly.

The Bottom Line

None of this is secret. The framework is public, the failure modes are catalogued, the tooling is free, and the incentive to concentrate value behind a small quorum is stronger than all of it combined. Bridges will keep being the weakest link because the weakest link is where the liquidity is, and the liquidity does not care about your threat model. Verify the keys, cap the outflow, revoke the approvals, and accept that the vault sits behind a lock you did not design and cannot inspect.

It was already priced. It just hadn’t cleared yet.

More: Issues · Field Notes · RTFM

Multisig and Threshold Signing, Beyond Buying a Safe

2026-07-29T00:00:00+00:00

Everybody knows a multisig is safer than a single key. Everybody says so. And then everybody deploys a 2-of-3 Safe where all three keys live on the same laptop, in the same MetaMask profile, backed up to the same iCloud account, and signed from the same chair. Congratulations: you have paid gas to deploy a smart contract whose only function is to make you feel responsible.

The Standard

A Safe (formerly Gnosis Safe) Smart Account is not a wallet in the EOA sense. It is a smart contract account that holds assets and executes transactions only when it receives enough valid signatures to satisfy a configured threshold. The core parameters are the owner set (a list of signer addresses) and the threshold M, where M-of-N owners must sign before a transaction executes.

Mechanically, each Safe transaction is hashed according to EIP-712 typed structured data, producing a unique digest that binds the destination, value, calldata, operation type, and the Safe’s internal nonce. Owners sign that digest. The contract’s execTransaction function collects those signatures, verifies each one against the owner set (supporting ECDSA signatures from EOAs, EIP-1271 contract signatures, and pre-approved hashes via approveHash), and only proceeds when the count of valid, distinct owner signatures reaches the threshold.

That is the entire security model, and it is a good one. The threshold means no single key compromise drains the treasury. The nonce means transactions cannot be replayed. The modular architecture (modules, guards, fallback handlers) means you can extend behavior without touching the core. Safe gives you the primitive. What it does not give you, and cannot give you, is the thing that actually matters: independence between the entities holding those N keys.

The standard requires M valid signatures. It says nothing about who signs, on what device, from what location, under what authority. The contract counts signatures. It does not count humans. That distinction is where every failure lives.

Where It Breaks Down

The most common failure is the one in the opening: threshold theater. A 3-of-5 where all five keys are derived from the same seed phrase is a 1-of-1 wearing a costume. If those five addresses came out of the same BIP-39 mnemonic through BIP-32 derivation, then whoever holds the mnemonic holds all five. The Safe contract sees five distinct owner addresses and is perfectly satisfied. An attacker who phishes one seed backup satisfies the threshold instantly. You did not build a multisig. You built a single point of failure with a more expensive deployment cost and a false sense of security that will stop you from taking real precautions.

The second failure is correlated infrastructure. The keys are genuinely separate, held by separate people, but every signer uses the same wallet software, the same browser extension, connects through the same WalletConnect session to the same interface, and reviews transactions on the same class of hot device with no independent verification. A malicious or compromised frontend can present one payload to the screen while the wallet signs another. If every signer is looking at the same lying interface, the threshold provides no protection, because all N humans are being deceived by the same lie simultaneously. Blind signing on hardware wallets that display an opaque hash instead of decoded EIP-712 fields turns your signers into rubber stamps. They are approving a digest they cannot read.

The third failure is the delegatecall problem. Safe supports two operation types: CALL and DELEGATECALL. A transaction executed as a delegatecall runs arbitrary code in the context of the Safe itself, with access to its storage. A delegatecall to a malicious contract can rewrite the owner set, change the threshold, or install a module that bypasses signing entirely. Signers who approve delegatecall transactions without understanding what the target contract does are handing over the account. The signature was valid. The threshold was met. The Safe is now owned by someone else.

The fourth failure is modules and guards misunderstood as features rather than attack surface. A module is code with permission to execute transactions without meeting the threshold at all. Install a sketchy module and you have added a signer that never sleeps and never says no. Guards run on every transaction and can be used defensively, but a poorly written guard can brick the Safe (a guard that reverts on all transactions locks the account permanently, because you need to execute a transaction to remove the guard, and the guard reverts it).

The fifth failure is the one nobody rehearses: signer loss. A 2-of-3 sounds resilient until you realize what it actually tolerates. It survives the loss of exactly one key. Lose two (a dead laptop and a forgotten passphrase, or one person leaving the company while another loses their Ledger) and the treasury is frozen forever. There is no recovery. The contract does not care about your circumstances. People conflate “multisig” with “backup” and set thresholds that leave zero margin.

The sixth failure is address and chain confusion. The same Safe address can exist on multiple chains, but the owner set and threshold are per-deployment. People assume a Safe deployed on one chain is configured identically on another. It may not be. Sending assets to “the same” Safe address on a chain where it was never deployed, or was deployed with different owners, is a slow-motion loss.

Doing It Right

Start with independence as the design goal, not signature count. N keys held by one person is not a multisig. Enforce that every owner key is generated on a separate device, from a separate entropy source, and controlled by a separate person or role with genuinely separate compromise conditions. If two keys share a threat (same building, same admin, same seed, same cloud backup), treat them as one key when you reason about your threshold.

Diversify signer hardware. Do not standardize your entire signer set on one hardware wallet vendor or one firmware version. A vendor-specific supply chain issue or firmware bug should not be able to compromise your threshold in one move. Mix hardware types. Require that signers verify the decoded EIP-712 transaction on the device screen, not a bare hash. If your hardware cannot decode Safe transactions, use tooling that lets signers independently compute and compare the transaction hash out of band before approving.

Ban blind delegatecall as policy. Install a transaction guard that restricts operations to CALL unless a delegatecall target is on an explicit allowlist. Treat any transaction that modifies the owner set, threshold, modules, guard, or fallback handler as a high-ceremony event requiring out-of-band confirmation on a separate channel by every signer.

Size the threshold for both attack and loss. A 3-of-5 tolerates two independent compromises and two independent losses at the same margin, which is why it is the sane default for anything holding real value. A 2-of-3 is the absolute floor and only acceptable when key custody is genuinely disciplined. Distribute geographically. Keep at least one signer in cold storage that never touches a hot interface.

Rehearse recovery before you need it. Actually execute an owner-swap on a testnet deployment. Actually simulate losing a signer and adding a replacement. Document the exact swapOwner and changeThreshold calldata. Use transaction simulation tooling (Tenderly-class simulators, Safe’s own simulation) on every non-trivial transaction so signers see state changes, not intentions. Verify the chain ID and deployment address every single time.

The Bottom Line

The Safe contract will do exactly what it promises: it will count to M and execute. It will never tell you that your M signers are one person in a trench coat, that they all sign blind from the same poisoned frontend, or that the delegatecall they just approved rewrote the owner set. The primitive is sound. The people deploying it are the vulnerability, and they always have been. A multisig is a distribution of trust, and if you have not actually distributed anything, you have distributed nothing but the illusion.

You didn’t build a multisig, you built a group chat that spends money.

More: Issues · Field Notes · RTFM

Signature Requests and Blind Signing

2026-07-22T00:00:00+00:00

Every wallet you have ever used has a button that says “Sign.” Almost nobody who clicks it can tell you what they just authorized, and the industry has spent years building tooling that makes this ignorance feel safe. It is not safe. The single most efficient way to empty a wallet in production today is not a smart contract exploit or a bridge failure, it is a human being clicking “Sign” on a structured message they did not read and could not have read if they tried.

The Standard

EIP-712 is the specification for signing typed structured data. It exists because the older approach, eth_sign and personal_sign over an opaque hash or arbitrary byte string, was unreadable by design. When you signed a raw 32-byte hash, you were signing entropy. You had no way to know whether that hash committed you to a harmless login challenge or to a transfer of your entire balance.

EIP-712 tried to fix the human-facing half of the problem. It defines a canonical way to encode a structured message so that a wallet can display it as fields instead of a hash. The message has a types definition, a domain separator, and the actual message payload. The domain separator is the important part most people ignore: it binds a signature to a specific name, version, chainId, and verifyingContract. In principle this means a signature intended for one contract on one chain cannot be replayed against another.

The encoding is deterministic. You hash the type definition to get a typeHash, you hash the struct data according to that type, you concatenate the domain separator, and you produce the digest that gets signed. keccak256("\x19\x01" || domainSeparator || hashStruct(message)). That prefix is not decoration. It exists specifically so that an EIP-712 digest can never collide with a regular transaction or a personal_sign payload. The standard did its job. It gave wallets everything they need to show you a legible, scoped, human-readable description of what you are about to authorize.

The problem is that legibility is optional, and almost everyone opts out.

Where It Breaks Down

Start with the mechanism that does most of the damage: EIP-2612 permit. This is an EIP-712 typed signature that authorizes a token spend without an on-chain approval transaction. The signed struct contains an owner, a spender, a value, a nonce, and a deadline. When you sign it, you produce a signature that anyone holding it can submit to the token contract to grant spender an allowance of value. No gas from you. No second confirmation. The signature is the authorization.

Now consider what a drainer does. It presents a dApp that needs you to “verify your wallet” or “approve to continue.” What you are actually signing is a permit with spender set to the attacker’s contract, value set to type(uint256).max, and a deadline far in the future. You click Sign. Nothing happens in your wallet. No transaction appears. There is no pending confirmation, no gas estimate, no red warning, because from your wallet’s perspective you did not transact, you merely signed a message. The attacker then submits your signature and the follow-up transferFrom in a single bundle, often through a batch contract, and your balance is gone in one block.

The related pattern is Permit2, the router-based approval system many aggregators use. Permit2 signatures are also EIP-712, and they encode a PermitTransferFrom or PermitBatch with a spender, amounts, and a sigDeadline. A single Permit2 signature can authorize transfers of multiple tokens at once. This is convenient for legitimate routers and catastrophic when the router address in the message is hostile. The signed data will faithfully contain the malicious spender. It is right there in the struct. Nobody reads it.

Here is why nobody reads it, and this is where the wallets share the blame. A large fraction of dApps do not sign proper EIP-712 typed data. They fall back to eth_sign or feed raw bytes, and the wallet renders the infamous full-width warning that users have been trained to click through. Worse, many wallets that do receive valid EIP-712 payloads still render the message as a wall of raw fields: hex-encoded addresses, a value printed as 115792089237316195423570985008687907853269984665640564039457584007913129639935, a deadline as a Unix timestamp. Technically legible. Practically meaningless to a human at click speed. The domain separator, the one field that would tell you which contract this signature binds to, is usually collapsed or hidden entirely.

Then there is the deeper failure, which is that the signing surface and the transacting surface look different to users and identical to attackers. People have internalized that a transaction costs gas and shows a confirmation, so they treat transactions with suspicion. A signature is “free” and “just a message,” so they treat it as harmless. This mental model is exactly backwards for permits. An off-chain signature can be more dangerous than a transaction because it produces no on-chain footprint until the attacker chooses to use it, which may be days later, from an address you never interacted with.

Contract-side, builders make it worse by requesting broad, long-lived permits when they need narrow, short-lived ones. Requesting type(uint256).max as the permit value because it saves a future signature is normalizing infinite approvals as the default UX. A deadline set to type(uint256).max turns a one-time authorization into a permanent standing order. Every one of these is a decision to trade the user’s safety for one fewer click.

Doing It Right

For holders, the rules are unglamorous and they work.

Treat every signature request as a transaction. The absence of a gas fee is not evidence of safety, it is the opposite. If a site asks you to sign something to “connect” or “verify,” it does not need that. Connection is eth_requestAccounts and costs no signature. A signature request during login is either SIWE (EIP-4361, which is human-readable plain text and says exactly what it is) or it is something you should refuse.

Read the domain and the spender. On any typed-data prompt, find verifyingContract in the domain and the spender in the message. If either is an address you do not recognize and cannot map to the protocol you think you are using, stop. This is the single highest-value habit available to you.

Use a wallet or extension that decodes and simulates. The tooling category you want performs transaction and message simulation, showing you the net asset changes a signature would enable, not just the raw fields. A simulator that says “this signature can move all of your USDC to 0xUnknown” is worth more than any amount of self-discipline.

Revoke standing allowances periodically. Use an allowance dashboard to review and zero out approvals and Permit2 authorizations you no longer need. An infinite allowance you granted a year ago is a loaded weapon left on the counter.

For builders, the guidance is equally direct.

Sign real EIP-712 typed data, never personal_sign over encoded structs. If your wallet integration shows a raw-bytes warning, you have already failed the user. Populate domain fully and correctly, including chainId and verifyingContract, so replay protection actually holds.

Scope your requests. Request the exact value you need, not uint256 max. Set a deadline measured in minutes, not centuries. If your product cannot function without infinite, perpetual approvals, redesign the product, do not offload the risk onto users who cannot read the request.

Name your types honestly. The typeHash is derived from the type string, and wallets display field names to users. A struct field called spender communicates intent. A field called data communicates nothing.

The Bottom Line

EIP-712 gave us everything we needed to make signing legible, and we responded by building interfaces that hide the one field that matters behind a button people have been conditioned to reflexively press. The standard is not broken. The habit is. You will keep hearing that self-custody means being your own bank, and the part nobody says out loud is that it also means being your own signing officer, the one who is supposed to read the document before stamping it. Most people will not. The drainers are counting on exactly that, and they are rarely disappointed.

Read the message. It is the only part of the transaction that was ever actually yours to control.

More: Issues · Field Notes · RTFM

Seed Phrases and Where Keys Actually Leak

2026-07-15T00:00:00+00:00

Nobody has ever brute-forced your seed phrase. Let that sink in before you buy another metal plate. The entropy math has been settled for a decade, and it is not the weak link. The weak link is you, photographing twelve words on a kitchen table because typing them into a password manager felt paranoid and a screenshot felt convenient. The attacker did not beat the cryptography. The attacker read your camera roll.

The Standard

BIP-39 defines how a random number becomes a set of human-readable words, and how those words become the seed that feeds a hierarchical deterministic wallet (BIP-32) through a derivation path (BIP-44 and friends). The mechanism is deliberately simple. You start with entropy: 128 bits for a twelve-word phrase, 256 bits for twenty-four. You append a checksum derived from the SHA-256 hash of that entropy (four bits for the twelve-word case, eight for the twenty-four). You slice the combined bits into eleven-bit chunks, and each chunk indexes into a fixed wordlist of exactly 2048 words. That is the whole trick.

The security claim is a claim about entropy, and only about entropy. A twelve-word phrase encodes 128 bits of it. To guess a 128-bit secret by brute force you would need to search a space of 2^128 possibilities, which is the same order of magnitude protecting the AES keys that run the internet. No one is doing that. No one will do that. The number is not large in some hand-wavy sense; it is large in the sense that all the computers that will ever exist could run until the heat death of the sun and not scratch it.

BIP-39 also specifies an optional passphrase, sometimes called the “25th word.” This is not part of the mnemonic. It is a separate string mixed into the PBKDF2 key derivation (2048 iterations of HMAC-SHA512, salted with the literal string “mnemonic” concatenated with your passphrase). Change the passphrase and you get an entirely different seed, and therefore an entirely different wallet, from the same words. Remember that. It matters later.

So the standard does exactly one job well: it turns strong randomness into something a human can write down. The word “write” is where the trouble starts. BIP-39 says nothing about where you write it, how you store it, or what machine generated the entropy in the first place. Those are precisely the parts that get people killed, financially speaking.

Where It Breaks Down

The seed leaks at the boundary between the cryptographic object and the human handling it. Every real-world compromise I have seen lives in one of a few categories, and none of them involve mathematics.

The phrase becomes a photograph. You generate the wallet, and the screen shows you twelve words with a countdown-timer sense of urgency. You take a picture. That picture goes to your camera roll, which syncs to iCloud or Google Photos by default, which means your seed phrase now exists as plaintext (well, as pixels containing plaintext) on a server owned by a company that is a permanent target and that will hand data to anyone with the right subpoena or the right breach. Cloud photo backups are also increasingly run through OCR and machine-vision indexing so you can search “receipt” or “dog.” That same indexing turns your words into searchable text sitting in a database you do not control.

The phrase becomes a synced note. People paste seed phrases into Notes, into a Google Doc, into a password manager, into a Telegram “saved messages” chat to themselves. The password manager is the least-bad of these and still bad, because it collapses your entire portfolio’s security into a single credential that is phished daily. The synced note is worse: it rides your account’s session tokens across every device you have ever logged in on, including the old laptop you sold.

The phrase gets typed into a compromised machine. This is the quiet killer. Clipboard-hijacking malware watches for anything that looks like a BIP-39 mnemonic or an address and either exfiltrates it or swaps it. Infostealers (the commodity malware category that scrapes browser storage, wallet extension vaults, and clipboard history) do not need to break anything. They wait for you to paste. A “wallet recovery” or “validate your wallet” web form is the same attack wearing a suit. The moment the words touch a networked, general-purpose computer, entropy stops being your protection.

The generation itself was poisoned. BIP-39’s entropy claim assumes the entropy was actually random. A fake hardware wallet with a pre-loaded seed, a compromised random number generator, a “wallet generator” website that seeds its PRNG from something predictable, or a supply-chain-tampered device all produce phrases that look perfectly valid (the checksum passes) and are known to the attacker in advance. The funds are drained the instant they arrive. There was no leak because the key was never secret.

The passphrase gets misunderstood. The 25th-word passphrase is powerful precisely because it is not stored with the words. People then store it with the words, defeating the entire point, or they forget it and permanently lose access, or they treat it as a password with 30 bits of guessable entropy and assume it protects a phrase an attacker already has. A weak passphrase on a leaked seed is brute-forceable, because now the attacker is only searching your passphrase space, not the 128-bit seed space.

Import sprawl. A hardware wallet only protects the seed if the seed never leaves it. The moment you import those same words into a hot software wallet “just to check a balance” or to use a dapp, you have copied a cold key into a hot environment, and every guarantee the hardware gave you is void for that seed forever.

Doing It Right

Assume the phrase will eventually be exposed to whatever you store it near. Design backward from that.

Never let the words touch a camera, a network, or a general-purpose OS after generation. Generate on a hardware device that displays the words on its own screen. Transcribe by hand. If you must verify, verify on the device, not by typing back into software.

Store the transcription offline and redundantly. Paper is fine for a lot of threat models and burns in a house fire; steel plates solve fire and water but not theft or discovery. Two or three geographically separated copies beats one “perfect” copy. The failure mode for most people is loss, not theft, so redundancy is not optional.

Use the passphrase correctly or not at all. If you use a BIP-39 passphrase, treat it as an independent secret with real entropy, memorized or stored separately from the words, never in the same location. Understand that losing it loses everything. This is a plausible-deniability and second-factor tool, not a magic wand.

Consider Shamir-style splitting (SLIP-39) or multisig for meaningful amounts. Multisig (a 2-of-3 across independent devices and locations) removes the single point of failure entirely. A leaked single share does nothing. This is the correct answer for anything you would be sick to lose, and it is underused because it is slightly annoying to set up once.

Verify the device and the entropy. Buy hardware from the manufacturer directly. Check that the device generates a fresh seed in front of you rather than shipping one. Never, ever accept a pre-filled phrase from anyone or anything.

Keep cold keys cold. If a seed has been imported into a hot wallet, treat it as hot forever. For serious storage, the phrase is generated, written down, and used only on the airgapped or hardware device. It never gets typed into a browser.

The Bottom Line

The cryptography did its job. It always does. The 128 bits held. What failed was the two feet of air between the screen and the phone camera, the checkbox for cloud sync you never unchecked, the machine you assumed was clean. Nobody is coming for your entropy. They are coming for your convenience, and you keep leaving it out on the counter.

Write it down. Don’t take a picture of it. This is not hard, which is exactly why you won’t do it.

Token Approvals and the Infinite Allowance

2026-07-08T00:00:00+00:00

Your seed phrase is probably fine. That is the part nobody wants to hear, because it means the thing that emptied a wallet was not some sophisticated key extraction or a compromised hardware device. It was a signature the owner produced voluntarily, months earlier, and forgot about. Token approvals are the most boring attack surface in the entire ecosystem, which is exactly why they remain the most productive one.

The Standard

EIP-20, the fungible token standard that everything on Ethereum and its clones descends from, does not let contracts touch your balance directly. A token is just a ledger inside a contract: a mapping of addresses to numbers. When you hold 1000 USDC, there is no coin in your wallet. There is an entry in the USDC contract that says your address is owed 1000, and your private key is the only thing that can authorize moving that entry.

The problem the standard had to solve is that most useful things (swapping, lending, providing liquidity, staking) require a different contract to move your tokens on your behalf. You cannot hand a DEX router your private key. So EIP-20 defines a delegation primitive built from two functions.

approve(spender, amount) is you, the token owner, telling the token contract: “this spender address is permitted to move up to amount of my tokens.” The contract records this in an allowance mapping, keyed by owner and spender.

transferFrom(from, to, amount) is the spender later saying: “move amount of tokens from this owner to this destination.” The contract checks the recorded allowance, and if there is enough, it moves the tokens and decrements the allowance.

That is the whole mechanism. allowance(owner, spender) is a public view function so anyone can read how much any spender is authorized to pull from any owner. There is no expiry. There is no per-transaction confirmation. Once the allowance is set, the spender can call transferFrom at any point in the future, as many times as it likes, up to the approved amount, with no further input from you. The standard was designed this way on purpose. It is a standing authorization, not a one-time permission slip.

Where It Breaks Down

The rot is in a single number: amount.

Setting an exact allowance for every interaction is annoying. If you want to swap 500 DAI, you would approve the router for 500 DAI, then swap. Next week, when you want to swap another 500, the allowance is spent and you have to approve again. Each approval is its own transaction with its own gas cost and its own wallet popup. So the industry converged, years ago, on a shortcut: approve 2^256 - 1. The maximum value a uint256 can hold. Infinite allowance.

Now the router never has to be re-approved. The UX is smooth. You swap once and never see the approval prompt again. This became the default behavior baked into front ends, into router integrations, into the “Approve” button you click without reading. Most people have granted unlimited allowances to dozens of contracts and have no memory of doing so.

Here is the failure mode, and it has nothing to do with your keys.

An infinite allowance is a permanent, standing right for a contract to drain a specific token from your wallet. Its safety is entirely contingent on that contract remaining honest and remaining uncompromised, forever. The contract you approved might be a genuine protocol today. But consider what “the contract” actually is:

Upgradeable proxies. A huge fraction of DeFi contracts sit behind a proxy pattern (transparent proxy, UUPS, diamond). The address you approved is the proxy. The logic can be swapped by whoever controls the admin key. You approved an address, not a behavior. If the implementation behind that address changes, or the upgrade key is compromised, your standing allowance now points at code you never reviewed.
Phishing approvals. The classic drain. A malicious site presents a transaction that looks like a claim, a mint, or a connect step. What you are actually signing is approve(attacker, 2^256-1) on a token you hold. Nothing leaves your wallet in that transaction, so nothing looks wrong. The gas is trivial. Days later, the attacker calls transferFrom and your balance is gone. Your seed never left the hardware wallet. You signed the theft yourself and confirmed it on the device screen.
Permit and Permit2. EIP-2612 permit lets you approve via an off-chain signature instead of an on-chain transaction, gasless from the token owner’s perspective. Permit2 generalizes this. The security tradeoff is that a signature request looks even more innocuous than a transaction, and wallets historically rendered these as opaque hex or unhelpful typed-data blobs. A signed permit is a bearer authorization: whoever holds it can submit it. Phishing a signature is often easier than phishing a transaction because users have been trained that “signing is free and safe.”
The approve race condition. The original EIP-20 has a known flaw: changing a nonzero allowance to a new nonzero value creates a window where a watching spender can front-run and spend both the old and new allowances. This is why the convention is to set allowance to zero first, then to the new value. Many integrations still get this wrong.
Compromised front ends. The contract can be flawless and the approval legitimate, but the website serving the interface can be hijacked (DNS, a poisoned dependency, a malicious script injection). The front end silently swaps the approval target. You think you are approving the protocol. You are approving an attacker’s address.

In every one of these, the seed phrase is irrelevant. The exploit rides on an authorization the owner granted and never revoked.

Doing It Right

For holders:

Treat every approval as a liability you are carrying until you cancel it. Audit them. Wallet-scanner tools and approval dashboards (the category exists across every major chain) let you enumerate every outstanding allowance your address has granted and revoke the ones you no longer need. Do this on a schedule, not after something goes wrong.

Prefer exact approvals over infinite ones. Modern wallets increasingly let you edit the approval amount at signing time. Approve what the transaction needs. The extra gas of occasional re-approval is cheap insurance against a standing unlimited grant.

Read what you sign. If a wallet shows you approve with an amount of 115792089237316195423570985008687907853269984665640564039457584007913129639935, that is 2^256 - 1. That is infinite. Treat any signature request on a page you did not fully trust as hostile, especially permit and Permit2 typed-data prompts, which do not cost gas and therefore feel harmless.

Segregate. Keep long-term holdings in an address that never interacts with contracts, and use a separate “hot” address for DeFi. An approval on your hot wallet cannot touch tokens it does not hold. A drained hot wallet is an inconvenience. A drained cold vault is a life event.

For builders:

Stop defaulting to infinite approvals in your front end. Request the exact amount. If your UX genuinely needs standing allowances, make that a deliberate, visible choice, not the silent default behind an “Approve” button.

Support and encourage revocation. If your protocol issues approvals, give users a first-class path to see and cancel them.

Render signatures honestly. If you build wallets, decode approve, permit, and Permit2 payloads into human language: which spender, which token, how much, and flag infinite amounts loudly. Opaque hex is complicity.

Use minimal, time-bounded authorizations where the primitive allows it. Permit2 supports expirations. Use them.

The Bottom Line

The approval mechanism is not broken. It does exactly what EIP-20 says it does, which is grant a standing, expiry-free right to move your tokens to whoever you point it at. The failure is entirely social and habitual: an ecosystem that trained an entire generation of users to click “Approve” without reading, to sign gasless messages without thinking, and to leave unlimited allowances open for years. The drain does not need your keys because you already signed the permission. You will keep granting infinite approvals, and you will keep meaning to revoke them, and most of you will get around to it right after the transfer clears.

It was already priced in the moment you clicked Approve.

It’s Already Priced. — RTFM

Reading a Token Contract Before You Buy the Rug

The Standard

Where It Breaks Down

Doing It Right

The Bottom Line

Related

Oracle Manipulation and Price Feed Integrity

The Standard

Where It Breaks Down

Doing It Right

The Bottom Line

Related

Upgradeable Contracts and the Admin Key Problem

The Standard

Where It Breaks Down

Doing It Right

The Bottom Line

Related

Bridge Risk and Why Cross-Chain Is the Weakest Link

The Standard

Where It Breaks Down

Doing It Right

The Bottom Line

Related

Multisig and Threshold Signing, Beyond Buying a Safe

The Standard

Where It Breaks Down

Doing It Right

The Bottom Line

Related

Signature Requests and Blind Signing

The Standard

Where It Breaks Down

Doing It Right

The Bottom Line

Related

Seed Phrases and Where Keys Actually Leak

The Standard

Where It Breaks Down

Doing It Right

The Bottom Line

Token Approvals and the Infinite Allowance

The Standard

Where It Breaks Down

Doing It Right

The Bottom Line