BonkDAO, il tesoro svuotato da una proposta approvata con il voto

Non un bug del codice, ma una conquista della governance

BonkDAO ha riferito che un soggetto non identificato ha accumulato BONK attraverso wallet collegati a exchange prima di presentare o sostenere la proposta incriminata. L’obiettivo, secondo la ricostruzione del progetto, era concentrare abbastanza potere di voto da controllare l’esito della votazione ^CB.

Le analisi preliminari dei dati on-chain hanno stimato in circa 4 milioni di dollari l’importo utilizzato per acquistare una posizione sufficiente a influenzare il voto ^BM. Una volta raggiunta la maggioranza, la proposta ha autorizzato il trasferimento dei fondi del tesoro verso il wallet dell’aggressore ^IK.

In altre parole, la proposta sarebbe stata approvata secondo le regole previste dal sistema: il problema non era una firma falsificata o una funzione nascosta, ma il fatto che un singolo attore potesse acquisire abbastanza token per trasformare il voto in uno strumento di appropriazione.

Come è stato aggirato il sistema «un token, un voto»

Il meccanismo di voto ponderato sui token assegna, in sostanza, un peso maggiore a chi detiene una quantità maggiore dell’asset. Nel caso BonkDAO, la sequenza ricostruita è questa:

• Accumulo graduale: l’aggressore avrebbe costruito una posizione rilevante in BONK nell’arco di più giorni, utilizzando wallet associati a exchange per aumentare la propria influenza ^CB.
• Conquista della maggioranza: una volta raggiunto il peso necessario, avrebbe potuto presentare o far passare una proposta con l’autorizzazione al trasferimento del tesoro ^IK.
• Esecuzione del trasferimento: la proposta approvata ha permesso di spostare circa 20 milioni di dollari in BONK verso un wallet controllato dall’aggressore ^TC.
• Assenza di un exploit tecnico: non risultano, nella ricostruzione disponibile, un bug di smart contract o un attacco a un oracolo dei prezzi; la vulnerabilità sfruttata era il processo di governance stesso ^CK.

Questo distingue il caso BonkDAO dagli attacchi basati su flash loan, nei quali un aggressore prende in prestito enormi quantità di token, vota e restituisce il prestito nella stessa transazione. Nel precedente di Beanstalk del 2022, per esempio, la governance fu manipolata con questa tecnica e il danno riportato fu di circa 182 milioni di dollari ^A.

La differenza operativa non cambia però il punto centrale: quando il potere di voto dipende quasi esclusivamente dal numero di token posseduti, chi dispone di capitale sufficiente può tentare di comprare il controllo della decisione ^AA.

Le iniziative di recupero

Nelle comunicazioni disponibili al 7 luglio 2026, BonkDAO aveva indicato diverse linee d’azione:

• Coinvolgimento delle autorità: il progetto ha dichiarato di aver informato le forze dell’ordine e di collaborare alle indagini per identificare i responsabili e recuperare i fondi ^TC.
• Coordinamento con gli exchange: il team stava monitorando il movimento dei token sottratti e collaborando con le piattaforme di scambio per tracciarli o bloccarli quando possibile ^I.
• Contatti con l’ecosistema Solana: BonkDAO ha dichiarato di coordinarsi con la Solana Foundation nell’ambito della risposta all’incidente .
• Analisi dei wallet: il progetto stava seguendo l’attività degli indirizzi coinvolti per ricostruire gli spostamenti degli asset ^C.

Secondo quanto riportato da fonti sudcoreane, gli exchange Upbit e Bithumb avrebbero inoltre sospeso depositi e prelievi di BONK dopo l’attacco ^N. Nell’immediato non risultavano annunci pubblici relativi a un rollback della blockchain, a una nuova emissione di token o a un piano di compensazione per i possessori colpiti ^CN.

Perché il caso è importante per la sicurezza DeFi

La governance può diventare il punto più esposto

La sicurezza di una DAO non dipende soltanto dall’assenza di bug nel codice. Se il controllo del tesoro è trasferibile attraverso una votazione, anche la struttura economica del voto diventa una superficie d’attacco. La ricerca accademica sui sistemi di voto ponderati sui token evidenzia da tempo il rischio che un soggetto possa accumulare o prendere in prestito potere sufficiente per approvare proposte di prelievo dei fondi ^AA.

Il caso TOP Token, verificatosi poche settimane prima, ha mostrato una dinamica simile: un aggressore avrebbe ottenuto oltre il 50% del potere di voto e sottratto circa 1,58 milioni di dollari sfruttando una configurazione errata della DAO Aragon ^CH.

Servono più tempo e più controlli prima dell’esecuzione

L’incidente ha riacceso il dibattito sulle protezioni disponibili per le DAO basate su Realms, in particolare su:

• timelock, cioè un intervallo obbligatorio tra l’approvazione e l’esecuzione di una proposta;
• ritardi per i token acquistati di recente, così da impedire che un acquisto improvviso si trasformi immediatamente in potere di voto;
• controlli sull’esecuzione, che consentano alla comunità di sospendere una proposta sospetta prima che i fondi lascino il tesoro ^AB;
• portafogli multisig o meccanismi di veto, capaci di aggiungere un livello di verifica per le operazioni più rischiose.

Un modello citato nella letteratura è quello di Governor Bravo di Compound, che prevede un’attesa di due giorni per il riconoscimento del potere di voto associato a token acquistati di recente ^A.

Nessun sistema di voto è una soluzione magica

Tra le contromisure discusse figurano il voto ponderato sul tempo di possesso, i timelock obbligatori per le proposte che muovono fondi, il voto quadratico o concavo e i livelli di approvazione sociale. Tuttavia, una ricerca del 2026 avverte che anche i sistemi concavi possono essere aggirati tramite attacchi Sybil: dividendo i token tra molti wallet, un aggressore potrebbe in alcuni scenari ricondurre il potere effettivo verso una logica simile a quella lineare ^C.

La lezione di BonkDAO, quindi, non è che la governance decentralizzata non funzioni. È che una votazione formalmente valida non è necessariamente una votazione sicura. Per proteggere un tesoro DeFi non basta verificare che il codice esegua correttamente una decisione: bisogna anche chiedersi chi può comprare il controllo del processo, quanto tempo serve per rilevare un’anomalia e chi può fermare il trasferimento prima che sia irreversibile.