EIP-8476 : un opt-out définitif à l'EIP-7702, après le piratage Binance

Un développeur signant « nicolashw » a publié le 30 octobre 2026 sur Ethereum Magicians un draft Core EIP numéroté EIP-8476 — Permanent EOA Delegation Opt-Out. Le mécanisme : une transaction de type 4 à authorization list vide, destination égale à l'émetteur, valeur nulle, data et access list vides — forme invalide aujourd'hui — qui écrit le marker 0xef0200 dans le code du compte émetteur, pour un coût fixe de 33 500 gas. Une fois ce marker posé, l'EIP-7702 — la délégation d'exécution d'un EOA vers un smart contract — devient définitivement indisponible sur ce compte, qui continue par ailleurs de fonctionner comme un EOA ordinaire. Sources primaires : thread Ethereum Magicians #30134 (PR ethereum/EIPs #12600). Couverture : Cryptoast.

Ce qui est proposé

Le format standard d'un EIP-7702 est une transaction de type 4 portant une liste d'autorisations signées par l'émetteur, chaque autorisation désignant un contrat de délégation. L'exécution de la transaction écrit, dans le code de chaque signataire concerné, un pointeur vers ce contrat.

EIP-8476 détourne ce format pour en faire un opt-out :

• Même type 4, mais authorization_list vide.
• to = from, value = 0, data et access_list vides.
• Résultat : le code de l'émetteur reçoit le marker fixe 0xef0200, non-exécutable.
• Coût d'exécution : 33 500 gas fixe. Aucun code EVM n'est lancé.
• Toute autorisation EIP-7702 issue d'un compte marqué est ensuite ignorée.
• L'exception EIP-3607 est étendue de sorte qu'un compte marqué puisse continuer à émettre des transactions.

Le draft prévoit aussi que eth_getCode et eth_getProof renvoient le marker brut, tandis que l'EVM traite le compte comme s'il avait un code vide. Ce dédoublement vise à préserver la compatibilité avec ERC-721 et ERC-1155, dont les hooks de transfert sûr vérifient que la destination n'est pas un contrat — un cas soulevé en commentaire par le relecteur « Zealynx ».

Mécanisme — pourquoi ce marker

Le préfixe 0xef02 fait partie d'une famille de sentinels utilisés depuis EIP-3541 pour marquer un code non-exécutable réservé à l'écosystème. EIP-7702 utilise déjà 0xef0100 pour signaler une délégation active. EIP-8476 propose 0xef0200 comme signalement d'un opt-out permanent, sans contrat associé.

Deux conséquences notables :

1. La portée est par chaîne. Une autorisation EIP-7702 signée avec chain_id = 0 reste valide sur une autre chaîne, et doit donc être retirée par chaîne. L'opt-out ne s'étend pas à l'ensemble des L2 EVM.
2. Le marker ne protège pas contre un vol de clé privée. Un attaquant qui dispose de la clé peut toujours signer des transferts standards — l'opt-out ferme uniquement la shortcut EIP-7702, pas l'ensemble des capacités de signature.

Le pool de transactions est également concerné : la limite de transactions en attente par compte à code non-vide côté geth doit être relâchée pour les comptes marqués, afin qu'ils soient traités comme des EOA ordinaires. Le draft a été révisé une seconde fois pour l'intégrer.

Le lien avec le piratage Binance du 29 octobre

Un commentateur signant « it44 » a publié dans le thread une analyse on-chain de la portion EIP-7702 de l'attaque de Binance :

• Une seule transaction de type 4 émise le 29 octobre contenait 50 autorisations de délégation.
• Nonces utilisés : 18 914 775 à 18 914 824.
• Signataire : l'adresse qu'Etherscan étiquette « Binance 14 ».
• Chaque autorisation pointait vers un contrat de drainage préparé par l'attaquant.
• Une seule autorisation valide suffisait, puisqu'une délégation EIP-7702 reste active jusqu'à révocation.

Selon TRM Labs, cité par Cryptoast, Ethereum est la seule chaîne où l'attaquant a utilisé la shortcut EIP-7702 ; les autres chaînes affectées ont été vidées par des transferts signés ordinaires. Dans sa première version, EIP-8476 citait directement l'épisode ; nicolashw a retiré la mention nominative à la demande du relecteur, pour ne garder qu'une description neutre du schéma d'attaque dans la section Security Considerations.

Binance n'a pas publié de root-cause officielle. L'analyse de « it44 » reste donc une lecture d'un participant sur la donnée publique, pas une attribution confirmée par l'exchange.

Chiffres

• Numéro : EIP-8476
• Titre : Permanent EOA Delegation Opt-Out
• Proposant : nicolashw
• Dépôt sur Ethereum Magicians : 30 octobre 2026 (thread #30134)
• PR : ethereum/EIPs #12600
• Statut : Draft Core EIP (pas de statut formel sur la page)
• Révisions depuis le dépôt : 2 (compatibilité ERC-721/1155, règles de mempool)
• Marker écrit dans le code : 0xef0200, non-exécutable
• Coût de l'opt-out : 33 500 gas
• Impact post-opt-out : les autorisations EIP-7702 du compte deviennent définitivement sans effet
• Incident déclencheur (analyse publique, non confirmée) : tx type-4 à 50 autorisations, nonces 18 914 775 à 18 914 824, signataire étiqueté « Binance 14 », 29 octobre 2026

Ce qu'il faut surveiller

1. Choix du prefix. La discussion est ouverte sur 0xef0200 : des numéros voisins — EIP-8141, EIP-7851, EIP-8164 — réservent déjà d'autres marker. Un chevauchement complique la lecture de l'EVM par les outils tiers.
2. Format de transaction. La discussion ouvre la question d'un type de transaction dédié plutôt que la réutilisation du type 4 à liste vide. Un type dédié rend la sémantique plus facile à analyser côté portefeuilles.
3. Coût gas. Le 33 500 est provisoire, en attendant des benchmarks d'implémentation.
4. Portefeuilles et outils. L'intérêt pratique de l'EIP suppose que les portefeuilles exposent l'opt-out par un bouton — pas par une interface bas-niveau. Sans intégration côté MetaMask, Rabby, Frame, l'opt-out reste réservé aux utilisateurs techniques.
5. Chemin d'inclusion. EIP-8476 est un Core EIP et doit passer par l'AllCoreDevs (ACD), avec un test net, avant d'entrer dans un hard fork. La prochaine fenêtre côté client est Pectra+1 ; la vitesse réelle d'inclusion dépendra de la lecture par les client teams.

Contexte

EIP-7702, activée au hard fork Pectra en mai 2025, a été présentée comme un outil d'account abstraction partielle : donner à un EOA le pouvoir de déléguer, le temps d'une session ou de façon persistante, l'exécution à un smart contract. L'avantage attendu — paiement de gas en stablecoin, batch, récupération sociale — a été réel. Le prix caché a été la surface d'attaque d'une autorisation unique qui, signée hors d'un contexte confirmé, suffit à drainer un compte.

L'épisode de Binance — même sous réserve d'une root-cause officielle — est le premier à grande échelle où la mécanique EIP-7702 est pointée comme vecteur d'exfiltration. EIP-8476 est la première proposition qui ferme la fonctionnalité au niveau du protocole, par acte volontaire du détenteur du compte.

Deux approches concurrentes sont déjà sur la table dans le même thread et dans les threads voisins : une révocation globale par registre on-chain (variante proche d'EIP-7612) et une borne temporelle automatique aux autorisations EIP-7702. EIP-8476 a l'avantage d'être off-by-default — un compte normal garde les capacités EIP-7702 — et réversible seulement par création d'un nouvel EOA. Ce dernier point sera la ligne de clivage du débat ACD à venir : un opt-out définitif pèse sur l'UX des utilisateurs qui changeraient d'avis, mais c'est précisément cette finalité qui rend la clé compromise moins exploitable par l'attaquant.