Polygon valuta un hard fork per restituire 70 milioni di POL a Polymarket e Binance, ma non c’è ancora alcuna decisione

Ai validatori di Polygon viene chiesto di approvare un hard fork che sottrarrebbe circa 70,49 milioni di POL a cinque indirizzi controllati dagli attaccanti per accreditarli a Polymarket e Binance, senza alcuna firma da parte dei wallet che custodiscono le monete. La proposta sul forum di governance di Polygon, pubblicata blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">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 4 novembre 2026 dall’account Parvez03, indica Polymarket e Binance come proponenti e quantifica la somma in circa 6,5 milioni di dollari, al prezzo del 29 ottobre di 0,0924 dollari per POL.

A cinque giorni di distanza, nulla è stato deciso. La proposta non ha un numero PIP, un nome per il fork, una release del client né un blocco di attivazione: ciascuno di questi campi riporta «TO BE Decided once approved». Il thread sul forum ha raccolto tre risposte, l’ultima il 5 novembre alle 10:43 UTC, e nessun validatore, né Polygon Labs, Binance o Polymarket, vi ha preso posizione.

Anche le monete sono ferme. Coindaro ha letto i cinque saldi tramite un nodo RPC pubblico di Polygon PoS al blocco 97.012.802, intorno alle 11:45 UTC del 9 novembre, e di nuovo pochi minuti dopo: insieme contenevano 70.489.562,54 POL, a circa 233 POL di distanza dalle cifre elencate nella proposta.

I fondi provengono da due incidenti distinti del 29 ottobre: lo script di un fornitore che ha svuotato i wallet degli utenti di Polymarket e l’attacco all’hot wallet di Binance. Secondo la proposta, sul fronte Polymarket erano coinvolti circa 28 milioni di POL, di cui circa 24 milioni si trovano ora nei quattro indirizzi bloccati.

Cosa cambierebbe con la proposta di hard fork di Polygon

Il meccanismo è semplice. All’inizio di un blocco di attivazione, chiamato blocco F nel testo, e prima che venga eseguita qualsiasi transazione al suo interno, il client leggerebbe il saldo nativo in POL di ciascun indirizzo elencato così com’era alla fine del blocco F-1, lo porterebbe a zero e aggiungerebbe lo stesso importo a un indirizzo di recupero indicato dalla vittima. L’offerta totale non cambierebbe. I blocchi passati non cambierebbero. È in gioco solo il POL nativo, il token usato per il gas.

Quattro indirizzi hanno ricevuto fondi dall’incidente di Polymarket e uno da quello di Binance. La proposta riporta saldi di riferimento letti ai blocchi 96.399.251 e 96.413.185 del 29 ottobre. L’ultima colonna contiene invece la lettura fatta da Coindaro il 9 novembre.

Gli indirizzi di Polymarket si sono mossi appena: i pochi centesimi di POL sono polvere. L’indirizzo legato a Binance ha guadagnato circa 233 POL dalla lettura di riferimento, con un trasferimento in entrata di cui non sono noti né il mittente né lo scopo. Poiché il fork preleverebbe il saldo al blocco F-1 e non la cifra della tabella, anche quei POL in più verrebbero spostati. La proposta lo dice chiaramente: chiunque può inviare POL a un indirizzo bloccato prima del fork, e la regola del saldo completo li porterebbe via.

Gli indirizzi di recupero sono 0x3dcE…D952 per Polymarket e 0xd9fd…0b80 per Binance. Prima dell’attivazione, ciascuna vittima deve dimostrare di controllare il proprio indirizzo, con un messaggio firmato o un piccolo trasferimento di prova confermato da Polygon Labs, e confermare per iscritto di essere il destinatario corretto. Il thread non dice che questo sia già avvenuto. Al blocco 97.012.802 l’indirizzo di recupero di Polymarket conteneva 0,1 POL e quello di Binance nulla. È compatibile con un trasferimento di prova su uno solo dei due lati, ma nessuno lo ha confermato.

Due elementi restano fuori di proposito. I 6.185.900,1 USDT ricevuti dall’hacker di Binance nello stesso blocco sono già congelati da Tether, quindi a rischio c’è soltanto il POL nativo. E gli indirizzi «Class B» aggiuntivi di Binance, che l’exchange ha chiesto in seguito ai produttori di bloccare, non verrebbero svuotati: a differenza dei cinque indirizzi Class A, non sono legati al furto da trasferimenti elencati nella proposta.

Come la blocklist di Bor ha congelato i fondi, e cosa non copre

Le monete sono ferme oggi per via di un filtro, non di una regola del protocollo. Su richiesta delle vittime, i quattro block producer che attualmente costruiscono i blocchi di Polygon PoS, indicati nella proposta soltanto come anonymous-91 ad anonymous-94, hanno aggiunto gli indirizzi alla lista di blocco delle transazioni di Bor, il client di esecuzione di Polygon. Binance ha fatto la richiesta il 30 ottobre. Un produttore che usa quella lista non include le transazioni inviate da un indirizzo elencato.

Gli autori della proposta definiscono la misura un rimedio provvisorio e ne elencano i limiti. Ogni produttore legge la lista solo all’avvio di Bor, perciò ogni modifica richiede un nuovo deployment più un riavvio o una rotazione di span. Le voci non scadono mai. E il filtro guarda soltanto al mittente esterno di una transazione e alle autorità EIP-7702, ragione per cui gli autori scrivono che non è «un blocco completo degli asset».

Quest’ultima lacuna conta nel caso Binance. L’Hot Wallet 34 di Binance è un wallet smart contract che accetta user operation ERC-4337, e un filtro basato su chi firma la transazione esterna non può fermarle. È una voce Class B, quindi il fork la lascerebbe stare. Il nostro articolo su EIP-7702 e l’hack di Binance spiega come funzionano le autorità delegate.

L’attaccante non si è fermato. Il 30 ottobre una transazione in attesa offriva una commissione di circa 219.450 POL, pari a 10,45 POL per unità di gas, pur di passare. Secondo la proposta, l’attaccante ha anche contattato dei validatori offrendo denaro per aiutare a far uscire una transazione. Polymarket ha aperto un canale di recupero verso l’attaccante tramite il safe SEAL Safe Harbor e non ha ricevuto risposta.

Nella lettura della proposta, il congelamento regge solo finché ogni produttore continua a riavviarsi con un file non modificato, e l’attaccante ha tutte le ragioni per cercare un modo di aggirarlo. Come dice il testo, i fondi «non possono muoversi, ma nulla nella configurazione attuale permette nemmeno di restituirli».

Una blockchain che sposta monete senza le chiavi dei titolari

È questo l’aspetto che rende la richiesta insolita. Su una blockchain basata su account come Polygon PoS, l’unico modo di spostare monete da un indirizzo è una transazione firmata con la sua chiave privata. La proposta ammette che riscrivere un saldo senza quella chiave sia possibile solo con una modifica del consenso. E descrive lo spostamento del saldo di un utente come «l’azione più delicata che possa verificarsi su una chain».

Gli autori cercano di delimitarla. Respingono uno strumento generale di congelamento e recupero nel protocollo, perché sarebbe un potere permanente sui fondi degli utenti. Chiedono un solo fork con una lista chiusa di indirizzi fissata in anticipo e pongono delle condizioni: vittime che abbiano riconosciuto pubblicamente il furto e presentino la richiesta di persona, un blocco applicato da ogni produttore, un importo abbastanza grande da giustificare un fork, fondi tracciabili onchain e nessuna pretesa concorrente. Il testo definisce il tutto «un’azione estrema che non dovrebbe essere riprodotta comunemente».

L’obiezione più forte messa per iscritto è arrivata da un utente del forum di nome S1W, il 5 novembre. S1W ha fatto notare che emittenti di stablecoin come Tether e Circle possono già congelare asset, anche su richieste legittime delle autorità. Se Polygon dimostra che anche il POL nativo può essere riassegnato, sosteneva il post, le forze dell’ordine ne prenderanno nota e potrebbero seguire richieste di assistenza giudiziaria reciproca e ordini del tribunale di congelare o recuperare asset su Polygon. S1W ha chiesto chi distinguerebbe un recupero legittimo da un sequestro politicamente motivato, e se Polygon sia «pronta alle conseguenze legali, di governance e di decentralizzazione derivanti dall’aver stabilito questo precedente».

La proposta segnala anche un rischio proprio. Se uno degli indirizzi elencati risultasse non appartenere all’attaccante, verrebbe spostato un saldo legittimo. Gli autori rispondono che ogni indirizzo Class A è legato a trasferimenti onchain dai wallet delle vittime e che i casi più deboli sono stati esclusi. L’unica altra risposta sostanziale, di Williamsj043, chiedeva cose pratiche: il blocco di attivazione, un elenco leggibile da macchina di indirizzi e importi, e una nota di migrazione per exchange e custodian. Un terzo utente ha sostenuto la proposta senza condizioni.

La dimensione fa parte dell’argomento. Tra le sue condizioni la proposta considera soddisfatta quella per cui «la somma è significativa», con circa 6,5 milioni di dollari, ma non fissa alcuna soglia che una richiesta futura dovrebbe superare.

I recuperi precedenti: il DAO fork e il voto di Sui sul caso Cetus

Ethereum ha già fatto qualcosa di paragonabile, una volta. Al blocco 1.920.000, il 20 luglio 2016, un cambiamento irregolare dello stato ha spostato i fondi sottratti a The DAO in un nuovo contratto la cui unica funzione permetteva ai titolari dei token di ritirare, nella misura di 1 ETH ogni 100 token DAO, secondo la pagina di storia di ethereum.org. Alcuni miner si rifiutarono, sostenendo che l’incidente del DAO non fosse un difetto del protocollo, e continuarono a far girare la vecchia chain, che divenne Ethereum Classic.

Il caso più vicino è recente. Dopo che l’exchange Cetus su Sui ha perso circa 223 milioni di dollari il 22 maggio 2025, i validatori di Sui hanno bloccato circa 162 milioni di dollari custoditi in due indirizzi dell’attaccante, secondo The Block. Un voto di governance dei validatori si è chiuso il 29 maggio con il 90,9% di favorevoli, l’1,5% di astenuti e il 7,2% di non votanti, ha riferito Cointelegraph, e un aggiornamento della rete ha mandato i fondi a un multisig in mano a Cetus, OtterSec e Sui Foundation. Come su Polygon, è venuto prima un blocco a livello di validatori e poi un voto per spostare il denaro.

BNB Chain mostra l’opzione più leggera. Il 6 ottobre 2022, dopo che un attaccante aveva sottratto 2 milioni di BNB dal bridge BSC Token Hub, i validatori della chain sono stati spenti e la rete è rimasta ferma per diverse ore, ha riferito The Block. Era uno stop per contenere i danni, non un voto per riscrivere i saldi.

Il caso di Polygon differisce dal DAO fork in due punti. Le vittime sono due aziende, non migliaia di titolari di token. E l’asset è il token per il gas della chain stessa, che il client può riscrivere direttamente, senza toccare alcun contratto. La nostra guida su come funzionano soft fork e hard fork spiega perché una modifica come questa divide i nodi che non si aggiornano.

Cosa manca ancora prima del voto e del fork

La proposta era all’ordine del giorno della 47ª Polygon Protocol Governance Call del 5 novembre, al punto 4, «Binance / Polymarket proposal for retrieving funds». La proposta aveva fissato la presentazione per le 14:30 UTC di quel giorno. La pagina dell’agenda non riporta alcun esito né registrazione, e da allora sul forum non sono stati pubblicati verbali. La stessa call ha trattato due fork mainnet non correlati, Karwar su Heimdall e Uburu su Bor, che non hanno nulla a che fare con il recupero.

Nel repository pubblico delle proposte di miglioramento di Polygon non compare alcuna pull request per il recupero, ed è per questo che non ha un numero PIP. La richiesta aperta più recente risale al 25 agosto 2026; le pull request unite il 9 novembre hanno solo portato vecchie PIP allo stato finale.

Se la governance approverà, la proposta elenca i passaggi seguenti, in ordine:

• Gli ingegneri di Bor confermano il design (il testo lo chiama ancora un design proposto, con un’opzione a importo fisso come alternativa).
• Gli sviluppatori costruiscono il client e provano il fork sulla testnet Amoy; circa due settimane dopo l’approvazione sono considerate fattibili, una sola settimana è giudicata stretta.
• Validatori, provider RPC ed explorer vengono avvisati. Il team operativo dei validatori di Polygon si aspetta che dal 70% all’80% dello stake passi rapidamente alla nuova versione dopo la release.
• La data di rilascio viene fissata quando è confermato l’aggiornamento di una quota sufficiente di stake, e il fork si attiva al blocco F sulla mainnet.
• In seguito vengono pubblicati la variazione dei saldi e uno script di verifica. Le voci Class B escono dalla blocklist quando Binance conferma, e le voci Class A vengono riesaminate una volta svuotate.

Le condizioni devono valere ancora il giorno del voto finale e alla verifica finale su Amoy: le analisi post-incidente restano pubblicate, le liste di blocco restano in vigore su ogni produttore e i saldi vengono riletti al blocco di snapshot, pubblicando ogni variazione.

Cosa significa per chi detiene POL e per chi gestisce nodi

Per chi detiene POL

I saldi ordinari non vengono toccati. La modifica riguarda cinque indirizzi elencati e nient’altro, l’offerta resta la stessa e nessuna cronologia viene riscritta. Cambia un principio: i titolari scoprirebbero che l’insieme dei validatori può spostare POL nativo senza una chiave, quando la governance è d’accordo. La nostra pagina del progetto Polygon spiega come si incastrano il validator set e Heimdall.

Per operatori di nodi, exchange e indexer

È una modifica che rompe il consenso. Ogni validatore, provider RPC, exchange e operatore di nodi dovrebbe eseguire la nuova release di Bor prima del blocco F; i nodi che non si aggiornano seguirebbero da quel blocco una chain diversa. Heimdall, lo StakeManager e i contratti del bridge non cambierebbero.

La variazione di saldo al blocco F non ha alcuna transazione corrispondente. Explorer, indexer e strumenti contabili che ricostruiscono i saldi rieseguendo le transazioni mostrerebbero uno scarto, a meno di aggiungere un caso speciale. È la lacuna segnalata da Williamsj043, ed è il motivo per cui gli exchange che tracciano i depositi di POL nativo vorranno conoscere il blocco di attivazione e gli importi esatti ben prima della release.

Cosa resta ancora sconosciuto

Nessuno ha detto quando o come si svolgerà il voto, quale soglia varrà o quali validatori sostengano il piano. Gli operatori dietro i produttori da anonymous-91 ad anonymous-94 non sono nominati. La proposta non dice se gli indirizzi di recupero abbiano superato la verifica, e l’attaccante potrebbe ancora provare a spostare i fondi o a comprarsi l’aiuto di un produttore prima di un eventuale fork.

I prossimi segnali da seguire sono un numero PIP nel repository, un tag di release per Bor e una data per una prova su Amoy. La proposta stessa colloca circa due settimane di lavoro sul client e di prova su testnet tra l’approvazione e qualsiasi data in mainnet.