Polygon propone il recupero di 70 milioni di POL senza le firme dei detentori dei portafogli

Proposta di Recupero di Polygon

La proposta di recupero avanzata da Polygon prevede il trasferimento di circa 70 milioni di POL da cinque portafogli collegati a hack, senza la necessità di ottenere le firme dei loro detentori. Questo piano modificherebbe i saldi attraverso le regole della rete, conferendo all'autorità di governance e ai validatori il compito di restituire i fondi rubati.

Dettagli della Proposta

La proposta, presentata il 4 novembre, si concentra su cinque indirizzi associati a fondi sottratti in seguito a incidenti di sicurezza che hanno colpito il mercato delle previsioni Polymarket e l'exchange Binance. Secondo le tabelle di riferimento, circa 24 milioni di POL sono attribuiti a quattro indirizzi legati a Polymarket e 47 milioni di POL a un indirizzo associato a Binance.

È importante notare che il recupero effettivo si baserebbe sui saldi al momento dell'attivazione, piuttosto che sugli importi di riferimento indicati. A partire dal 9 novembre, la proposta pubblicata non ha ancora chiarito il nome del fork di recupero, il rilascio del client e il blocco di attivazione.

Processo di Recupero

L'agenda di governance del 5 novembre include la proposta per discussione, ma non ha registrato alcuna approvazione. Il rilascio separato di Bor v2.11.0 implementa le modifiche di StateReceiver di Uburu, piuttosto che il recupero proposto. Secondo il design suggerito, il software aggiornato leggerebbe il saldo di ciascun indirizzo elencato immediatamente prima dell'attivazione, azzerandolo e accreditando la stessa somma all'indirizzo di recupero designato.

Questo processo avverrebbe prima che le transazioni vengano eseguite nel blocco di attivazione. L'offerta totale rimarrebbe invariata e la storia della catena precedente non verrebbe alterata. La proposta sottolinea che l'ingegneria di Bor deve ancora confermare il design.

Requisiti di Verifica

Ciò comporterebbe che l'autorità di recupero dipenderebbe da una combinazione di approvazione della governance, l'elenco degli indirizzi specificati e le regole del software adottate dai validatori. Le aziende coinvolte designerebbero i destinatari. Polygon Labs confermerebbe la proposta di prova di controllo del destinatario.

"La proposta di sweep non richiederebbe una transazione firmata dagli indirizzi sorgente, poiché queste sono responsabilità separate."

Tracciare le monete rubate fino a un indirizzo supporta il caso per includerlo; dimostrare il controllo di un indirizzo di recupero verifica dove andrebbero le monete. Tuttavia, la proposta avverte che identificare erroneamente un indirizzo controllato da un attaccante potrebbe comportare lo spostamento di un saldo legittimo.

Limitazioni e Considerazioni

I requisiti di verifica del destinatario richiedono una prova di controllo, come un messaggio firmato o un piccolo trasferimento di prova confermato da Polygon Labs, oltre a una conferma scritta che attesti che l'indirizzo appartiene al destinatario. La proposta esclude anche altri token e una categoria separata di indirizzi bloccati, limitando il proposto sweep ai POL nativi nei cinque conti elencati.

La regola del saldo totale crea un'altra questione di proprietà: anche i depositi successivi si sposterebbero. La proposta richiede che i saldi vengano controllati nuovamente prima dell'attivazione e che eventuali modifiche vengano pubblicate. Questi controlli rivelerebbero quali monete sono incluse nello sweep, ma non stabilirebbero che ogni deposito successivo apparteneva a una vittima dell'incidente.

Implicazioni per Exchange e Custodi

Per gli exchange e i custodi, il movimento proposto creerebbe una discrepanza tra il saldo mostrato da un nodo aggiornato e il saldo ricostruito esclusivamente da transazioni ordinarie. La proposta segnala esplicitamente questo problema per esploratori, indicizzatori e strumenti contabili.

Una riconciliazione dovrebbe quindi collegare ciascun indirizzo sorgente interessato, il suo saldo prima dell'attivazione, il destinatario designato e il corrispondente accredito nel blocco di attivazione. Per i custodi, la regola implica un aggiustamento del saldo separato, poiché non ci sarebbe alcuna transazione di trasferimento ordinario da abbinare.

Conclusioni e Prossimi Passi

I controlli pianificati affrontano parte di quel carico: una prova di Amoy testerebbe che l'offerta rimanga costante e che gli account non correlati rimangano invariati, seguita da un replay del fork della mainnet. La proposta richiede anche di pubblicare il cambiamento di saldo senza transazioni e uno script di verifica dopo l'attivazione.

Insieme, quei registri consentirebbero agli operatori di confrontare il cambiamento implementato con l'ambito approvato. Il rimborso ai clienti è un processo separato. Nel suo post-mortem del 30 ottobre, Polymarket ha dichiarato che il 95% dei portafogli interessati era stato rimborsato completamente quel pomeriggio e ha annunciato il ritorno di 4 milioni di dollari, inclusi 1 milione di dollari per perdite legate alla pausa.

Quei rimborsi compensano i trader; il fork proposto restituirebbe gli asset agli indirizzi di recupero designati dall'azienda. Il prossimo traguardo di recupero richiederà una decisione di governance, una specifica finale del software, destinatari verificati e un blocco di attivazione.