Trending in crypto

Ethereum

Two draft EIPs opened on 30 October, the day after the Binance theft, would tighten EIP-7702 account delegation: EIP-8476 would let a wallet opt out of delegation permanently, and EIP-8477 would bind each authorization to a recent block.

Updated 2 November 2026 · 1 update · first published 27 October 2026 · 13 sources

Ethereum draft EIP would let wallets opt out of EIP-7702 delegation

Two draft proposals opened in Ethereum's EIPs repository on 30 October would change how EIP-7702 account delegation works. EIP-7702, live since Pectra on 7 May 2025, gives delegated code unrestricted access to the account (EIP-7702), and the drafts follow the 29 October Binance theft, in which TRM Labs said the attacker used a delegation with 50 authorizations signed in advance to turn a Binance hot wallet into a sweeper (Decrypt).

A permanent opt-out

Pull request 12600, "Permanent EOA Delegation Opt-Out", was opened on 30 October by the developer nicolashw and was assigned the number EIP-8476 the same day. It would let a wallet permanently disable EIP-7702 delegation while keeping its address and ordinary transaction powers. The draft installs a non-executable three-byte marker, provisionally 0xef0200, and the EVM would treat it as empty code, so a marked account still passes the receiver checks that contracts run on ordinary accounts (PR 12600). It does not protect an account whose private key is stolen, which can still sign ordinary transfers and approvals (PR 12600).

The proposed charge is 33,500 gas, which the author notes has not been benchmarked. Because the state trie keeps the raw marker while contracts see empty code, a marked account's state-trie code hash differs from what EXTCODEHASH returns, which state proofs, light clients and stateless verifiers still need to review (PR 12600).

A freshness bound, and an older alternative

Pull request 12601, "Recent Block Bound Delegation Authorizations", from Joseph Delong and numbered EIP-8477 on 30 October, would require each authorization to sign an execution block number and header hash, and to be applied only while that block is among the inclusion block's preceding 256 ancestors. It would not expire delegation that is already installed (PR 12601). An older draft, EIP-7851 from December 2024, takes a different line: it would let delegated code update delegation while permanently disabling the residual ECDSA authority of the original key (EIP-7851).

What to watch

  • Editorial review of EIP-8476, whose marker is provisional and overlaps with the 0xef02 namespace EIP-8141 discusses (PR 12600).
  • Wallet and signer recognition of the empty-authorization-list transaction form the opt-out relies on (PR 12600).
  • Whether either draft reaches a network upgrade. Neither is scheduled, and EIP-8477's author lists client implementations, test fixtures and benchmarks as still needed before activation (PR 12601).

Background3 min read

Ethereum's Glamsterdam upgrade has lost its next test date. The activation on the Hoodi testnet, set for 26 October at 17:42:48 UTC, was postponed at the All Core Devs Execution call on 22 October after security researchers showed that two of the upgrade's gas proposals could change how contracts already on mainnet behave when a call fails (CoinDesk, Cointelegraph).

It is a delay to a test network rather than to mainnet (Ethereum Foundation).

What ChainSecurity found

The security firm ChainSecurity published an analysis against specifications reviewed on 13 October 2026, when EIP-8037 and EIP-8038 were scheduled for Glamsterdam and carried Last Call status. EIP-8037 changes how the creation of permanent state is charged and introduces a separate gas reservoir for it; EIP-8038 reprices access to state. The firm's summary is blunt: even with unchanged contract code, a failure path that previously reverted can now complete (ChainSecurity).

The class of attack at issue is insufficient gas griefing, where a malicious caller deliberately supplies too little gas for an otherwise valid operation to succeed while leaving just enough for the contract to record the failure. Contracts defend against it three ways: checking before the call that a chosen gas budget can be forwarded, checking the gas remaining after a failed call, or relying on the failure handler itself running out of gas and reverting (ChainSecurity).

Why the accounting change undoes those defences

Under current rules a call can forward at most about 63/64 of the gas available to it, so a failed call leaves the caller a small remainder that a check can reject. EIP-8037 adds a reservoir that travels with calls in full, while the 63/64 limit applies only to the execution balance, and the GAS opcode reports only that execution balance. Gas above a transaction maximum of 16,777,216 is placed in the reservoir first, and a target that reverts or runs out of gas has its reservoir restored to its value at call entry (ChainSecurity).

The numbers are large enough to change control flow. Creating a fresh storage slot costs 64 bytes at 1,530 gas per byte, or 97,920 in state gas, on top of EIP-8038 execution charges of 10,100 for a warm slot and 12,100 for a cold one. When the reservoir is exhausted, a cold fresh-slot write needs 110,020 gas from execution, against 22,100 under pre-Glamsterdam rules (ChainSecurity, CoinDesk). Clearing a slot allocated earlier in the same transaction can also restore up to 97,920 execution gas immediately, rather than through the end-of-transaction refund counter that cannot pay for the next instruction (ChainSecurity).

On 23 October ChainSecurity said it had identified 13 real-world examples of contracts at risk and was coordinating responsible disclosure with the projects involved, without naming them (Cointelegraph). The firm has demonstrated the mechanisms but has not publicly established that a major production protocol is exploitable (CoinDesk). On 21 October the security researcher pcaversaccio called the risks "serious" on GitHub and asked for a reassessment of the hard fork (Cointelegraph).

What was withdrawn, and what was not

The postponement removes the planned increase of Hoodi's gas limit to 200 million, and strips the Amsterdam execution layer and Gloas consensus layer activations out of Hoodi's configuration. Hoodi's chain history is untouched and no mainnet user needs to take any action (CryptoPotato). As of 27 October no replacement date had been set, and the Ethereum Foundation said the rescheduled upgrade would be announced at a later date (Ethereum Foundation). Ethereum's mainnet has no confirmed Glamsterdam date, with early December having been under discussion before the delay (Cointelegraph), and Bankless quoted Nixo as expecting that the delay "more than likely" pushes Glamsterdam on mainnet into 2027 (Bankless).

Glamsterdam had already activated on Sepolia on 6 October, before Hoodi was scheduled (CoinDesk). The proposals themselves are aimed at slowing the growth of Ethereum's state database, and EIP-8037's pricing model targets annual state growth of 120 GiB at a reference block gas limit of 150 million (Blockonomi).

What to watch

  • Any revised Hoodi activation date and the client releases that carry the corrected configuration, since the 200 million gas limit increase was withdrawn with the fork (CryptoPotato).
  • Whether EIP-8037 and EIP-8038 change before Glamsterdam reaches mainnet, which would end the discussion earlier than a mainnet date would (ChainSecurity).
  • The outcome of ChainSecurity's responsible disclosure, and whether affected projects revise contracts that rely on post-call gas checks or on reverts to stop griefing (ChainSecurity).

Other topics

Query the news index yourself — free, no signup