EIP-7702, la funzione di Ethereum introdotta con l’aggiornamento Pectra, è lo strumento usato su Binance 14, uno degli hot wallet colpiti nell’hack di Binance, e le registrazioni della blockchain mostrano come. Una singola transazione delle 20:20:59 UTC del 29 ottobre conteneva 50 autorizzazioni firmate per quel wallet. Una sola era valida. smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">Il prelievo totale è arrivato 3 minuti e 24 secondi dopo, per circa 2,5 miliardi di dollari secondo le stime di CoinDesk e Blockaid. Le registrazioni non possono dire come l’attaccante abbia ottenuto, in origine, firme del wallet di Binance.
La discussione sul disegno di Ethereum ruota intorno a questo vuoto. Ido Ben-Natan, amministratore delegato della società di sicurezza Blockaid, ha detto a Cointelegraph che i fondi si sarebbero potuti rubare anche senza EIP-7702. Ivo Georgiev, amministratore delegato del produttore di wallet Ambire, sostiene che gli attaccanti potevano già autorizzare transazioni. Per il furto in sé, le cifre e i congelamenti, rimandiamo al nostro articolo principale sull’hack di Binance. Qui ci occupiamo di una sola domanda: quanto di tutto questo dipende dalla funzione.
EIP-7702 e hack Binance: lo strumento su un solo wallet, non la causa della perdita
Binance stima l’impatto complessivo in circa 6,3 miliardi di dollari e TRM Labs conta 6,36 miliardi, mentre Blockaid parla di oltre 5,5 miliardi. Binance 14 è stato l’unico wallet con una delega, secondo drk.vc, un blog di analisi. Il prelievo finito in prima pagina vale dunque circa due quinti del totale nel conto di TRM, che sulle altre blockchain descrive normali trasferimenti firmati.
Sull’Ethereum circolano due cifre, e misurano cose diverse. CoinDesk scrive di circa 2,5 miliardi di dollari usciti da un solo wallet di Binance in meno di quattro minuti. TRM conta 3,79 miliardi di dollari complessivi su Ethereum, un totale che comprende anche i prelievi successivi e wallet che non sono mai stati delegati.
Cos’è EIP-7702? Un permesso che non indica né importo né destinatario
Un account Ethereum di tipo ordinario, controllato da una chiave privata, non ha codice. EIP-7702 ha cambiato le cose quando Pectra è entrato in funzione, il 7 maggio 2025. Secondo il testo della proposta, il titolare firma un breve messaggio che indica una rete, l’indirizzo di un contratto e un nonce, il contatore progressivo delle transazioni dell’account. Chiunque può poi inserire quella firma in una transazione del nuovo tipo 4 e pagare le commissioni (gas). Da quel momento l’account si comporta come lo smart contract indicato.
Gli usi previsti sono banali: raggruppare più azioni in una sola transazione, oppure far pagare le commissioni a qualcun altro. Il pericolo sta in ciò che la firma non dice. Non fissa né un destinatario né un importo. Chi controlla il codice del contratto delegato controlla ciò che fa l’account, e la delega resta attiva finché il titolare non la sostituisce.
Gli autori avevano segnalato una versione più ristretta del rischio. Un delegato costruito male, avverte la proposta, può «consentire a un malintenzionato di ottenere il controllo quasi totale dell’EOA» di chi firma, dove EOA è il nome tecnico di un account ordinario controllato da una chiave. Un contratto scritto dall’attaccante non ha bisogno di alcun difetto.
Per quanto segue contano due regole. Un’autorizzazione vale solo se il suo nonce è uguale al nonce attuale dell’account, e una volta accettata lo aumenta di uno, quindi non si può usare due volte. Un nonce sbagliato non fa fallire la transazione: l’EIP chiede ai nodi di saltare quell’autorizzazione e passare alla successiva dell’elenco. Il titolare può inoltre annullare tutto in qualsiasi momento delegando all’indirizzo zero, il che cancella il codice.
Una transazione, 50 firme, un solo colpo a segno
Queste regole spiegano la forma insolita dell’attacco. La transazione del 29 ottobre è partita da un indirizzo dell’attaccante, 0x7C86…5CA0, che Etherscan etichetta «Binance Hot Wallet Exploiter», nel blocco 26300753. Tutte le 50 autorizzazioni indicavano Binance 14 come firmatario e lo stesso contratto come delegato. I loro nonce andavano da 18.914.775 a 18.914.824. La rete ne ha saltate 49 e la transazione è riuscita lo stesso. Quella che corrispondeva era la 18.914.809, 34 sopra il tentativo più basso. La pagina di Etherscan cita Blockaid: «Only 1 of 50 was a hit», cioè solo una su 50 ha colpito nel segno.
Perché 50? Il nonce di un wallet cresce a ogni transazione inviata, e questo stava elaborando prelievi dei clienti: una firma preparata in anticipo deve quindi indovinare dove sarà il contatore quando arriverà. Journal du Coin riferisce che l’attaccante non conosceva il nonce in tempo reale. TRM Labs ci legge di più: il blocco di firme «suggerisce che l’accesso potesse essere limitato nel tempo», oppure che le firme dovessero essere richieste «attraverso un sistema». È una valutazione. Il fatto che ci sta sotto è più semplice: 50 firme per Binance 14 esistevano prima delle 20:20:59 UTC.
Il contratto era pronto da un bel po’. Blockaid, in un rapporto riassunto da TechFlow, e CoinDesk collocano entrambi la sua distribuzione intorno alle 16:00 UTC, più di quattro ore prima. Il codice sorgente non è pubblicato su Etherscan. Drk.vc afferma che il codice impone che a chiamarlo sia l’indirizzo dell’attaccante, e anche CoinDesk descrive un contratto che solo quel wallet poteva azionare.
Dalla delega alla revoca: 3 ore e 50 minuti di accesso aperto
Il primo prelievo mostra che cosa ha fruttato la delega. L’attaccante ha chiamato su Binance 14 stesso una funzione chiamata sweep, con valore zero, e ha pagato 0,000413776 ETH di commissioni, meno di un dollaro. Ne sono usciti 167.464,2479 ETH e 63 token, tra cui circa 1,615 miliardi di USDT. Non è servita nessuna nuova firma di Binance.
Poiché la delega è rimasta in vigore, sono stati portati via anche i depositi arrivati su Binance 14 dopo il primo prelievo. Il wallet era inoltre operatore di un wallet custodial intelligente che CoinDesk e Blockaid chiamano Hot Wallet 34, quindi le chiamate passate da lì hanno spostato anche USDC.
| Ora (UTC) | Evento | Fonte |
|---|---|---|
| 29 ott, circa 16:00 | Distribuzione del contratto sweeper | Blockaid via TechFlow, CoinDesk |
| 29 ott, 20:20:59 | Delega: 50 autorizzazioni, una valida | Etherscan |
| 29 ott, 20:24:23 | Primo prelievo da Binance 14, 3 min 24 s dopo | Etherscan, TRM |
| 29 ott, 20:41:23 | 780 milioni di USDC spostati tramite Hot Wallet 34; altri 43 milioni dopo | Blockaid via TechFlow |
| 29 ott, dalle 20:41 alle 23:56 | Prelievi successivi alle 20:41, 20:59, 21:04, 21:44, 22:39 e 23:56 | TRM |
| 30 ott, 00:10:35 | Binance 14 revoca la delega verso l’indirizzo zero | Etherscan |
La revoca è una transazione di tipo 4 che Binance 14 ha inviato a se stesso, con un’autorizzazione valida verso l’indirizzo zero. Poiché il wallet è il mittente, la firma viene dalla sua stessa chiave. Ne deriva che Binance aveva ripreso il controllo delle proprie firme entro le 00:10 UTC, circa 3 ore e 50 minuti dopo la delega, anche se nelle fonti che abbiamo letto Binance non l’ha detto.
Il resto della perdita non ha avuto bisogno di EIP-7702
La prova migliore a favore degli scettici viene dalla stessa serata. Ventiquattro secondi dopo il primo prelievo, Binance 16, che non è mai stato delegato, ha firmato un trasferimento di 28.005,6 ETH e di circa 108 milioni di dollari in token, secondo drk.vc. Su Bitcoin, Tron, XRP Ledger e Solana i fondi sono usciti con normali trasferimenti firmati, riferiscono CoinDesk e drk.vc.
L’attaccante poteva dunque ottenere firme su Ethereum con o senza EIP-7702, e sulle blockchain prive della funzione, come Bitcoin. Perché sia stata usata su un solo wallet resta senza spiegazione.
Chiave rubata o sistema di firma dirottato: le versioni non coincidono
Qui la blockchain smette di aiutare. Ciascuna spiegazione qui sotto è compatibile con le transazioni, e nessuna è stata dimostrata pubblicamente.
| Chi | Che cosa dice | Stato |
|---|---|---|
| Binance | La prima indagine «potrebbe riguardare il portatile di un ingegnere DevOps compromesso»; «nessuna prova di una fuga di chiavi private di wallet»; da allora trovati altri punti di violazione, non indicati | Versione dell’azienda, non verificata in modo indipendente |
| Blockaid | Il suo post, ripreso da crypto.news: «an attacker used a stolen key to drain $5.5B» (un attaccante ha usato una chiave rubata per svuotare 5,5 miliardi di dollari); il suo rapporto dice che la fuga di chiave e il meccanismo 7702 sono stati confermati in 11 minuti, secondo TechFlow | Affermazione di un fornitore, nessuna prova pubblica |
| TRM Labs | La spiegazione più probabile è che l’attaccante potesse far «firmare al sistema di firma degli hot wallet di Binance transazioni a sua scelta» su più blockchain | Valutazione, dichiarata come tale |
| drk.vc | Chi avesse avuto la chiave grezza avrebbe potuto inviare i trasferimenti direttamente, perciò deduce un accesso al percorso di firma; cita SlowMist, secondo cui una fuga di chiave «potrebbe essere coinvolta» | Deduzione di un analista |
Il ragionamento di TRM è il più dettagliato tra quelli disponibili. Indica firme valide su blockchain, tipi di chiave e schemi di firma diversi nell’arco di circa mezz’ora, cosa che un attacco di phishing a un solo firmatario Ethereum non spiegherebbe. Il co-amministratore delegato Richard Teng ha aggiunto su X, come citato da CoinDesk: «L’attaccante non ha semplicemente usato i permessi di un ingegnere, e non si è trattato di una singola azione “con un clic”».
Lette una accanto all’altra, la «nessuna prova» di Binance e la «chiave rubata» di Blockaid non stanno insieme, anche se crypto.news, che riporta entrambe, non prova a conciliarle. Lo stesso Ben-Natan, secondo Journal du Coin, parla di uso improprio della chiave e non di furto. Una disputa simile si è già vista: all’inizio della settimana anche il caso del bot di trading Bloom ha contrapposto il «nessuna chiave trapelata» a wallet che avevano firmato ciascuno il proprio svuotamento. Per capire perché la distinzione conta, la nostra guida a chiavi private e chiavi pubbliche spiega le basi.
Che cosa dicono Ben-Natan, Georgiev e VEER su EIP-7702
Tre voci con nome e cognome, o quasi, animano finora il dibattito, tutte nell’articolo di Cointelegraph del 30 ottobre firmato da Helen Partz.
Ben-Natan afferma che il denaro si sarebbe potuto rubare anche senza la funzione. «L’aggiornamento 7702 è un modo per farlo con un solo prelievo e forse un modo per aggirare alcuni controlli che potrebbero avere», ha detto alla testata. Senza, secondo lui, gli attaccanti avrebbero avuto bisogno di più transazioni. Ritiene che il computer compromesso di uno sviluppatore possa aver raggiunto l’infrastruttura di firma e che il firmatario abbia «firmato una transazione che non avrebbe dovuto». Ha avvertito che altri exchange sono esposti allo stesso tipo di attacco ai propri sistemi di firma, e ha detto che simulare le transazioni potrebbe intercettare le richieste malevole prima dell’approvazione.
Per Georgiev la funzione ha cambiato poco, dato che gli attaccanti potevano già autorizzare transazioni e avrebbero potuto svuotare i fondi in altri modi. «Questo è un problema di EIP 7702, solo che è capito molto, molto male», ha detto. La sua preoccupazione pratica: gli ingegneri di un exchange che riprendono il controllo di un wallet potrebbero dimenticare di revocare una delega malevola.
VEER, che Cointelegraph identifica solo come membro della comunità Ethereum, ha richiamato gli avvertimenti emersi nelle discussioni del 2024 sulla proposta. VEER ha anche detto che l’attacco sembrava più ampio di una singola firma malevola, ma che la funzione ha dato agli attaccanti «un comodo pulsante di prelievo su Ethereum».
Cointelegraph ha riassunto il tutto dicendo che EIP-7702 non ha causato l’hack ma forse l’ha amplificato, e la formula è della testata. Quella che segue è la lettura di Coindaro, non un accertamento e non un’accusa. La frase di Ben-Natan sull’aggirare i controlli apre una domanda: se un’analisi a posteriori dovesse mostrare che le regole di Binance avrebbero fermato i normali prelievi ma lasciato passare un’autorizzazione di tipo 4, la funzione passerebbe da comodità a qualcosa di più vicino a una causa. Nulla di quanto pubblicato dimostra che quelle regole funzionassero così, e non diciamo che fosse così.
Abusi di EIP-7702 prima di Binance: sweeper e perdite modeste
Lo schema è più vecchio di questo hack, ma di ben altra dimensione. Il 30 maggio 2025, tre settimane dopo Pectra, Wintermute ha scritto su X che «oltre il 97% di tutte le deleghe EIP-7702 era autorizzato verso più contratti con lo stesso identico codice», contratti che ha descritto come sweeper. Quella formulazione compare nel resoconto di CoinDesk e in altre coperture. Circolano due cifre: il testo di CoinDesk e una sintesi di Bitget News parlano di oltre l’80% delle deleghe verso contratti copiati, mentre il 97% è quello del post di Wintermute. Non siamo riusciti ad aprire il post originale. L’azienda ha scritto: «Il contratto CrimeEnjoyor è breve, semplice e ampiamente riutilizzato».
Taylor Monahan, ricercatrice di sicurezza, disse allora che il problema di fondo era la scarsa protezione delle chiavi private, mentre SlowMist, fondata da Yu Xian, consigliò ai wallet di mostrare con chiarezza il contratto di destinazione quando un utente firma una delega. Scam Sniffer segnalò nel maggio 2025 che un wallet aveva perso circa 146.551 dollari in un lotto di transazioni malevole, che SlowMist collegò a Inferno Drainer. Cointelegraph ricorda anche che nel settembre 2025 alcuni detentori di World Liberty Financial segnalarono perdite legate a deleghe malevole.
Blockaid conta quattro incidenti legati a EIP-7702 nella prima metà del 2026, per circa 1,08 milioni di dollari in totale. Il solo primo prelievo da Binance 14 supera quella cifra di oltre 2.000 volte. Bybit, il record precedente con circa 1,5 miliardi di dollari nel febbraio 2025, è anteriore a Pectra, quindi la funzione non c’entrava: gli attaccanti avevano compromesso un’interfaccia di firma.
Che cosa possono cambiare exchange e wallet
La maggior parte delle proposte finora punta al momento che precede la firma, e viene da chi ha un interesse in gioco. Blockaid vende questo tipo di protezione, quindi i suoi consigli vanno letti tenendone conto. Vuole che ogni transazione, comprese le liste di autorizzazioni 7702, sia simulata e confrontata con whitelist e limiti prima della firma, e respinta anche se gli approvatori hanno dato l’ok. Vuole anche un monitoraggio che segnali un hot wallet che acquisisce codice all’improvviso, con spostamenti o revoche automatici in risposta. Aggiunge che i wallet dovrebbero avere transazioni di revoca preparate in anticipo, e sostiene di aver lanciato gli avvisi 1 minuto e 55 secondi dopo il primo prelievo.
- Journal du Coin elenca tre protezioni: bloccare le transazioni di tipo 4 dagli hot wallet dei prelievi, ammettere solo contratti delegati approvati e simulare prima di firmare.
- Il consiglio di SlowMist del 2025 vale per i wallet dei privati: mostrare il contratto delegato prima che l’utente firmi.
- L’avvertimento di Georgiev vale dopo qualsiasi incidente: controllare le deleghe e revocarle, come ha fatto Binance 14 alle 00:10:35 UTC.
Per chi usa un wallet personale vale lo stesso ragionamento, in scala minore. Una richiesta di delega somiglia più alla consegna di un account che all’approvazione di un pagamento, perché non indica né una somma né un destinatario. Per rimuoverne una, il titolare dell’account delega all’indirizzo zero, il metodo definito dall’EIP e quello usato su Binance 14.
Che cosa non si sa ancora dell’attacco con EIP-7702
Binance ha promesso un’analisi a posteriori e una prova delle riserve aggiornata, senza indicare la data di nessuna delle due. Finché l’analisi non arriva, restano aperti questi punti:
- Come sono state prodotte le 50 firme: un portatile, un servizio di firma o una chiave.
- Se una chiave sia davvero trapelata, date la «nessuna prova» di Binance, la chiave rubata di Blockaid e il sistema di firma di TRM.
- Perché Ethereum sia stata l’unica blockchain con una delega, e solo su Binance 14.
- Se altri exchange abbiano deleghe sui loro hot wallet, dato che non abbiamo trovato alcuna scansione pubblicata.
- Che cosa ne pensino gli sviluppatori di Ethereum: non abbiamo trovato dichiarazioni di uno sviluppatore del nucleo, di Vitalik Buterin o della Ethereum Foundation nelle fonti controllate entro mezzogiorno del 30 ottobre.