TAC afferma che l’hack ha sottratto il 28,6% dell’offerta dal pool di staking
Punti chiave
- •L’exploit ha svuotato l’account che deteneva TAC delegati ai validatori e ha trasferito circa 2,986 miliardi di token su BNB Chain entro 95 secondi.
- •TAC ha affermato che il monitoraggio del bridge è rimasto soddisfatto perché l’attaccante ha usato TAC autentici dal pool di staking, quindi l’offerta mirror è rimasta completamente coperta.
- •La falla alla base era in un modulo Cosmos EVM condiviso, non nel codice del bridge specifico di TAC, e l’offerta totale di token non è aumentata.
- •TAC prevede una modifica mirata dello stato per ripristinare il pool vincolato e le posizioni di staking dei delegatori, preservando le transazioni non correlate.
- •Gli holder su BNB Chain non hanno ancora un piano finale di trattamento e TAC ha avvertito gli utenti di non fare trading di TAC su BNB Chain finché la questione non sarà risolta.

Punti chiave
L’attacco ha spostato TAC già esistente invece di creare nuova offerta.
Il monitoraggio del bridge è rimasto soddisfatto perché ogni token mirror era coperto.
Il piano di recupero di TAC propone di ripristinare i saldi di staking tramite una modifica dello stato.
Gli holder su BNB Chain non dovrebbero fare trading finché il trattamento dei token non sarà chiarito.
Il bridge era coperto da TAC rubati
Il post-mortem del 2 settembre di TAC afferma che i suoi controlli di monitoraggio hanno continuato a funzionare durante l’intero attacco. Tali controlli erano progettati per rilevare la mancanza di collaterale del bridge, mentre il furto è avvenuto prima che i token raggiungessero il bridge. TAC è una blockchain basata su Cosmos con un execution layer compatibile con Ethereum, costruita per collegare le applicazioni Ethereum con l’ecosistema TON e Telegram. Quando TAC si sposta su un’altra rete supportata, i token nativi restano bloccati su TAC e una rappresentazione equivalente viene emessa sulla chain di destinazione.
Un controllo automatizzato ha confrontato i TAC nativi detenuti in custodia con l’offerta mirror su BNB Chain ed Ethereum. L’attaccante ha presentato TAC autentici presi dal pool di staking, li ha bloccati e ha ricevuto la quantità corretta di token mirror. Entrambe le parti del bridge hanno continuato a corrispondere. Questo dettaglio aiuta a spiegare perché i controlli a livello di bridge possono non rilevare un problema quando i registri di saldo sottostanti sono già compromessi.
Come ha spiegato TAC, “a solvency check cannot detect a theft that preserves solvency.” Il bridge è rimasto completamente coperto anche se gli asset che fornivano tale copertura erano stati rubati pochi secondi prima.
Il pool di staking si è mosso in 95 secondi
L’exploit è stato eseguito alle 19:46:37 UTC del 22 agosto e ha svuotato l’account che deteneva tutti i TAC delegati ai validatori. Il primo trasferimento via bridge è iniziato 32 secondi dopo, mentre un secondo ha completato il movimento di circa 2,986 miliardi di token verso BNB Chain entro 95 secondi. Le vendite sono iniziate pochi minuti dopo. L’attaccante ha scambiato 1,208 miliardi di TAC su BNB Chain per 950,293 USDT e ha venduto altri 49,9 milioni di TAC tramite TON per 55,481 USDT. Il ricavato totale ha raggiunto circa $1,006 milioni.
La produzione dei blocchi si è fermata alle 23:58:11 UTC, oltre quattro ore dopo che il pool di staking era stato svuotato. La rete resta sospesa mentre i validatori preparano il software corretto e il processo di recupero.
Gli avvisi per i grandi trasferimenti erano attivi, ma il primo movimento sul bridge è iniziato solo 32 secondi dopo il drain. Un controllo che richiede revisione umana potrebbe aiutare a tracciare gli asset in seguito, ma non poteva sostituire il codice che impediva la creazione del saldo non valido.
L’exploit è avvenuto prima del bridge
La vulnerabilità alla base è stata trovata nel modulo Cosmos EVM condiviso, non nel codice del bridge specifico di TAC. TAC mantiene un saldo account nella sua chain basata su Cosmos e un altro nel suo layer compatibile con Ethereum, e l’attacco ha sfruttato le differenze tra quei registri.
Il software interessato gestiva in modo errato la delega di token bloccati da vesting, li detraeva da un saldo spendibile pari a zero e consentiva al risultato di andare in overflow fino a un numero estremamente grande. Un controllo mancante ha quindi lasciato il pool di staking controllato dal protocollo esposto a quel saldo non valido.
L’exploit ha ridotto il pool a zero e ha accreditato all’attaccante il TAC già esistente. L’offerta totale è rimasta invariata perché la transazione ha spostato token tra account senza generare una mint permanente.
Il bridge è entrato nella sequenza solo dopo che la rete aveva accettato il saldo dell’attaccante come valido. Ha quindi elaborato i TAC rubati nello stesso modo in cui elaborerebbe token ottenuti tramite una normale transazione.
TAC è stata una delle sei reti colpite dalla vulnerabilità condivisa. La precedente indagine di Coindoo su come Cosmos Labs abbia interpretato male il bug prima dell’hack sulle sei chain spiega perché la falla sia rimasta pericolosa dopo la segnalazione iniziale e come avvisi incompleti abbiano lasciato esposte reti indipendenti.
Il piano di recupero preserva le transazioni non correlate
TAC intende correggere specifici saldi nel blocco in cui la rete si è fermata. Questa modifica mirata dello stato preserva il resto della storia della blockchain invece di riportare l’intera rete a un punto precedente.
Un rollback avrebbe cancellato 7.772 transazioni legittime inviate da 218 indirizzi senza alcun legame con l’attacco. Avrebbe inoltre lasciato TAC mirror su altre reti senza una corrispondente copertura nativa dopo che i trasferimenti cross-chain erano già avvenuti.
La modifica proposta ripristinerebbe il pool vincolato al saldo precedente all’incidente e riporterebbe i delegatori alle posizioni di staking registrate. Rimuoverebbe anche i 65,1 milioni di TAC congelati negli indirizzi collegati all’attaccante quando la rete si è fermata. Il deficit di mercato residuo sarebbe coperto con circa 1,258 miliardi di TAC dalle riserve di tesoreria della TAC Foundation. Tale importo corrisponde alla porzione venduta tramite BNB Chain e TON, che non può essere rimossa onchain senza annullare i saldi detenuti dagli acquirenti sul mercato aperto.
Nessuno di questi passaggi è stato completato. I validatori devono prima adottare il software corretto, eseguire la modifica dello stato e riprendere la produzione dei blocchi, mentre TAC non ha annunciato una data di riavvio.
Gli holder su BNB Chain non hanno ancora una risposta definitiva
Altri 1,662 miliardi di TAC restano in indirizzi associati all’attaccante su BNB Chain. Il bridging è disabilitato in entrambe le direzioni, il che significa che i TAC su BNB non possono attualmente essere riscattati contro i token nativi bloccati su TAC. Il saldo rimanente è superiore all’importo già venduto e resta la principale parte irrisolta del recupero. Il ripristino del pool di staking non decide come verranno trattati quei token mirror quando i trasferimenti cross-chain riprenderanno.
TAC sta lavorando con piattaforme di trading e fornitori di infrastrutture, ma non ha pubblicato il meccanismo, i tempi o le azioni richieste per gli holder su BNB Chain. Finché tali termini non saranno stabiliti, il progetto ha detto agli utenti di non fare trading di TAC su BNB Chain perché ciò comporta un rischio di perdita.
Gli staker non devono presentare alcuna richiesta
I delegatori non sono tenuti a registrarsi, inviare prove o collegare un wallet. Il piano di recupero utilizzerebbe i registri di staking acquisiti prima dell’incidente per ripristinare i saldi a livello di protocollo una volta che la rete riprenderà.
Gli holder sulla rete TAC sospesa devono attendere un annuncio ufficiale di riavvio. TAC afferma che non è richiesta alcuna azione da parte degli utenti che detengono il suo token su TON o Ethereum, mentre gli asset diversi da TAC sulla rete nativa non sono stati colpiti dall’attacco. Il recupero crea un’occasione per truffe di impersonificazione. TAC afferma che non chiederà mai agli utenti di visitare un sito esterno per la richiesta, collegare un wallet o inviare fondi per ricevere i token ripristinati. Qualsiasi messaggio che faccia tale richiesta dovrebbe essere considerato fraudolento.
Il controllo mancante veniva prima del bridge
I controlli di TAC hanno confermato che i saldi dei token nativi e mirror corrispondevano. L’exploit è riuscito perché quel test è iniziato dopo che la rete aveva già accettato gli asset rubati come collaterale valido.
I controlli di corrispondenza dei saldi possono identificare la mancanza di copertura, ma non possono proteggere gli account che la forniscono. La patch di TAC affronta proprio questo punto precedente, impedendo che il saldo non valido venga creato prima che possa raggiungere il bridge.
Disclaimer : Questo articolo ha solo scopo informativo e non costituisce consulenza finanziaria o di investimento.
L’articolo Blockchain Hack Drains 28.6% of TAC Supply From Staking Pool è apparso per la prima volta su Coindoo .