Balancer tiene su GitHub l’elenco dei propri audit e sopra la tabella mette un avvertimento: «Gli audit non sono una garanzia di correttezza. Alcuni contratti sono stati modificati dopo essere stati sottoposti ad audit» (pagina degli audit di Balancer). 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 3 novembre 2025 i suoi pool stabili V2 sono stati svuotati lo stesso, per oltre 120 milioni di dollari secondo il calcolo di OpenZeppelin, che include i fork del codice. I report erano pubblici da anni e, letti con attenzione, dicevano che cosa i revisori non avevano guardato.
Dieci minuti con un audit smart contract bastano per trovare quelle informazioni da soli, se si sa dove cercare: il commit, il perimetro, i risultati, il loro stato e la distanza tra il codice esaminato e quello che gira oggi. L’esempio svolto è una coppia di report reali sullo stesso codice di Aave V3, seguita dal percorso a ritroso dal contratto Aave attivo fino ai suoi audit e da alcuni casi in cui l’audit non ha evitato la perdita. Le citazioni dai report, scritte in inglese, sono riportate in traduzione.
Uno smart contract non si corregge con la facilità di un sito web e custodisce denaro fin dal primo minuto. Per questo i protocolli pagano revisioni esterne. La lezione precedente, sul MEV e su come proteggere uno scambio, ha mostrato che un contratto che funziona come previsto può comunque costare caro a un utente. L’audit affronta un problema diverso: il codice che non fa ciò che gli autori intendevano.
Che cos’è un audit smart contract: una revisione a tempo di una sola versione del codice
Meglio dimenticare la parola «certificato». Un audit è una quantità fissa di tempo di esperti dedicata a un’istantanea del codice. Trail of Bits ha impiegato 12 persone-settimana su Aave V3, con tre ingegneri, tra il 25 ottobre e il 24 novembre 2021, lavorando sul commit 14f6148 (report di Trail of Bits). OpenZeppelin scrive che tre suoi revisori hanno lavorato sullo stesso commit per sette settimane (report di OpenZeppelin). Quando il tempo finisce, la revisione si ferma, siano stati trovati tutti i bug o no.
Il commit è la parte che molti lettori saltano. L’hash di un commit è l’impronta digitale di uno stato preciso del codice nel repository. Se cambia una riga cambia l’impronta e, a rigore, l’audit non descrive più quel codice.
Il cliente paga e il report è indirizzato al cliente, e questo condiziona la lettura. I risultati sono reali e li firma la società di audit, ma il perimetro è stato concordato con il team che ha pagato, e lo stesso team decide se e quando pubblicare. Nessuno dei report usati in questa lezione indica un prezzo: la cifra leggibile è l’impegno, e le persone-settimana dicono più di un logo. Chi cerca il prezzo di un audit smart contract non lo trova nei report, e nemmeno una cifra attendibile.
Si incontrano tre tipi di documento. L’audit manuale è scritto da un gruppo di revisori con nome e cognome. Il report di verifica formale controlla il codice rispetto a regole matematiche. Il report di un contest raccoglie quello che molti ricercatori in gara hanno segnalato e che i giudici hanno confermato. Ognuno ha limiti propri, trattati più avanti. I bug dei contratti sono una famiglia tra le altre mappate nella nostra tassonomia dei rischi DeFi: un audit non dice nulla sulla maggior parte delle altre.
Come leggere un audit report di smart contract, passo dopo passo
Passo 1: copertina e riquadro riassuntivo
Ogni audit report si apre con i dati che lo identificano. Nelle prime pagine conviene annotare quattro cose: la data, il repository, l’hash del commit e le date dell’incarico. I report di Trail of Bits hanno un riquadro con l’impegno e il conteggio dei risultati per gravità. Anche il registro delle modifiche merita un’occhiata: il report su Aave porta due date, un rapporto iniziale del 29 novembre 2021 e un registro delle correzioni aggiunto il 21 gennaio 2022, segno che la società è tornata a controllare.
Un report senza hash del commit è quasi inutile per chi legge, perché non si capisce che cosa descriva.
Passo 2: il perimetro e ciò che è rimasto fuori
Si passa poi alla sezione chiamata scope, o «coverage limitations», e la si legge lentamente. Qui la società si tutela e informa il lettore. Il report di OpenZeppelin su Aave dichiara: «Presumiamo che tutti gli oracoli di prezzo funzionino come previsto, perché sono fuori perimetro per questo audit». È una frase corretta e pesante, dato che l’oracolo è una via frequente verso la perdita (la nostra lezione sul design e la manipolazione degli oracoli spiega perché).
Trail of Bits è stata altrettanto esplicita sul Composable Stable Pool di Balancer nel 2022 (report). Ha scritto di non aver «cercato opportunità di condurre attacchi economici di alto livello» e di non aver coperto le librerie StableMath e WordCodec, «esplicitamente indicate come fuori perimetro». Quelle righe contano più avanti in questa lezione.
Passo 3: la tabella dei risultati
Poi viene il riepilogo: una tabella dei risultati con gravità e, nella versione finale, stato. Si contano le voci High e Critical e si va subito a vedere il loro stato. Un lungo elenco di note Informational è spesso il segno di un revisore scrupoloso, non di un codice scadente, quindi il totale grezzo dice poco.
Passo 4: le scale di gravità cambiano da società a società
Non esiste una scala comune. Ogni società definisce le proprie parole, di solito in un’appendice. Quello che per una è High per un’altra può essere Critical, come mostra più sotto l’esempio di Aave.
| Chi | Livelli | Come è definito il livello massimo | Fonte (come letta il 1 novembre 2026) |
|---|---|---|---|
| Trail of Bits | Informational, Undetermined, Low, Medium, High, più una valutazione separata della difficoltà | High: può riguardare numerosi utenti, con gravi conseguenze reputazionali, legali o finanziarie per il cliente | Report su Aave V3, Appendice A, 2021 |
| OpenZeppelin | Critical, High, Medium, Low, Notes | Nel report su Aave ci sono solo i titoli: nessuna definizione stampata | Report su Aave V3, 2021 |
| Sherlock (contest e giudizio degli audit) | High, Medium | High: «Perdita diretta di fondi senza limitazioni (rilevanti) da condizioni esterne» | Linee guida di giudizio (in inglese) |
| Programmi di bug bounty | Stabiliti da ciascun programma | Si legge la tabella di gravità nella pagina di quel programma | Pagina di ciascun programma |
Trail of Bits valuta a parte anche la difficoltà. Un High con difficoltà Low è una notizia peggiore di un High che richiede un insieme raro di condizioni. E bisogna fare attenzione a «Undetermined», che nella definizione della stessa società indica che l’entità del rischio non è stata determinata durante l’incarico: è una domanda lasciata aperta, non un risultato lieve.
Passo 5: le parole dello stato
La gravità dice quanto fosse serio un problema. Lo stato dice che cosa ne è stato. Il vocabolario varia, ma queste sono le parole che ricorrono:
- «Fixed» significa che il team ha modificato il codice e il report di solito rimanda alla pull request. Va verificato se la società ha riesaminato la correzione.
- «Partially fixed» significa che una parte del problema resta. Si legge quale.
- «Acknowledged» significa che il team ha visto il risultato. Non dice nulla su una modifica del codice.
- «Risk accepted by client» significa che il team ha deciso di convivere con il rischio, spesso con motivazioni scritte.
- «Not fixed» significa ciò che dice, e conviene cercarne il motivo.
- «Intended behaviour» significa che il team contesta che si tratti di un bug.
«Acknowledged» è la parola che inganna di più. Nel report di OpenZeppelin su Aave, il risultato H03 avverte che il protocollo conia aToken per l’importo richiesto senza verificare quanto ha realmente ricevuto, un problema per ogni token che applica una commissione sul trasferimento. Lo stato è Acknowledged e la motivazione del team di Aave è riportata così: «È una scelta di progetto non avere alcuna implementazione per gestire comportamenti non standard nel codice di base». Può essere una scelta difendibile. Resta comunque una proprietà viva del codice, e adesso il lettore la conosce.
Passo 6: il registro delle correzioni e la seconda revisione
Un risultato segnato come corretto dal team è un’affermazione, e una correzione riesaminata dalla società di audit è più solida. Il registro delle correzioni di Trail of Bits descrive il controllo fatto dalla società sulle correzioni successive all’incarico. La conclusione di OpenZeppelin su Aave aggiunge che «raccomandiamo sempre di sottoporre il codice a un altro ciclo di audit dopo che tutte le correzioni sono state applicate». Le correzioni sono codice nuovo, e il codice nuovo può contenere bug nuovi.
Esempio svolto: due società, un solo commit di Aave
Aave V3 è un buon caso perché due società hanno esaminato lo stesso commit e pubblicato lo stesso tipo di documento. Aave è qui l’esempio didattico: nei casi trattati più avanti non è stata violata.
| Report sul commit 14f6148 | Impegno | Critical | High | Medium | Low | Informational o notes | Totale |
|---|---|---|---|---|---|---|---|
| Trail of Bits, 29 novembre 2021 (registro correzioni 21 gennaio 2022) | 12 persone-settimana, 3 ingegneri | n.d. | 5 | 1 | 2 | 7 | 15 |
| OpenZeppelin (file datato 1 novembre 2021 nel repository) | 3 revisori, 7 settimane | 2 | 3 | 1 | 7 | 14 | 27 |
Il registro delle correzioni di Trail of Bits chiude il cerchio: 11 risultati corretti, 4 con rischio accettato dal cliente, tutti e quattro valutati Informational. Gli stati di OpenZeppelin sono scritti risultato per risultato, quindi lì si legge ogni riga «Update».
Un bug in parole semplici
Aave consente a un utente di prendere in prestito sfruttando il credito delegato da un altro. Il risultato TOB-AAVE-007 di Trail of Bits dice che la funzione borrow «recupera in modo errato la categoria eMode di msg.sender invece di quella di onBehalfOf». In altre parole, il codice leggeva le impostazioni di chi effettuava la chiamata, non di chi aveva messo la garanzia a copertura del prestito.
Il report fornisce i numeri. Si ipotizzi che DAI abbia un rapporto prestito/valore dell’80% e una soglia di liquidazione dell’85%, mentre l’eMode delle stablecoin (un’impostazione ad alta efficienza per asset correlati) consente 97% e 98%. Alice, senza eMode, delega credito sui suoi 100 DAI a Eve, che ha l’eMode attivo. Eve prende in prestito 97 USDC. Alice può ora essere liquidata, perché un prestito dimensionato sulla regola del 97% poggia su una posizione vincolata da quella dell’85%. La gravità è High, la difficoltà Low.
Il C02 di OpenZeppelin, «eMode category is skipped in borrows», è lo stesso difetto, e i due report permettono di verificarlo. Entrambi rimandano alla stessa correzione, la pull request 204 di aave-v3-core, che cambia un solo argomento in Pool.sol da _usersEModeCategory[msg.sender] a _usersEModeCategory[onBehalfOf]. Trail of Bits classifica il bug come High, OpenZeppelin come Critical. È l’argomento più chiaro contro il confronto dei conteggi di gravità tra società diverse.
Che cosa aggiungono due audit
I report si sovrappongono e differiscono. Entrambi hanno segnalato il debito in modalità isolation non aggiornato correttamente (risultato 11 di Trail of Bits, H01 di OpenZeppelin). OpenZeppelin riporta anche C01, sul conio di token di debito con lo stato dell’utente sbagliato. Trail of Bits segnala il risultato 2, un controllo mancante sull’ID di catena che permetterebbe di riusare le firme tra fork, valutato High e corretto. Due squadre indipendenti sullo stesso commit hanno trovato cose in comune e cose diverse, ed è la ragione per cui conviene pagare due volte.
Che cosa significa «risk accepted» in pratica
Conviene leggere le motivazioni, perché mostrano come ragiona un team. Sulle ottimizzazioni del compilatore (risultato 1), il team di Aave ha risposto che i benefici «superano i rischi» e che la sua comunità avrebbe monitorato il compilatore. Su un’interfaccia Chainlink deprecata (risultato 13), il report registra che quella consigliata costa più gas e che la scelta è stata lasciata alla comunità di Aave. Si può essere d’accordo o no. Il punto è che la decisione si può leggere e datare.
Perimetro dell’audit e codice distribuito
Un report descrive un commit. Il denaro sta in un contratto a un indirizzo. Il divario tra le due cose ha un nome, usato dalla società di sicurezza Zellic: audit drift. Colmare quel divario è la competenza più utile di questa lezione, e chiunque può farlo con un block explorer.
Dal Pool di Aave attivo ai suoi audit
Ecco i passaggi, con i risultati ottenuti il 1 novembre 2026.
- Si prende l’indirizzo dalla documentazione o dal registro degli indirizzi del progetto, mai da un annuncio sponsorizzato o da un post social. Per Aave, l’address book indica il Pool su Ethereum come 0x87870Bca3F3fD6335C3F4ce8392D69350B4fA4E2.
- Si apre quell’indirizzo su Etherscan e si va nella scheda Contract, cercando il segno di verifica. La pagina mostra il codice sorgente verificato con corrispondenza esatta, e il contratto è un proxy.
- Si individua l’implementazione. Un proxy custodisce i fondi e inoltra le chiamate a una logica conservata altrove, in una posizione standardizzata da ERC-1967. Etherscan la mostra direttamente: 0x728a138A4823392C2EFA55e028d434F526fE03CF, di nome PoolInstance, anch’essa verificata. La lettura diretta dello slot di memoria restituisce lo stesso indirizzo.
- Si identifica la versione. In «Read as Proxy», la funzione POOL_REVISION restituisce 11.
- Si cerca la versione nel repository. Il tag v3.7.0 imposta POOL_REVISION a 11, quindi il numero di revisione corrisponde a quella release.
- Si elencano gli audit di quella release, non quelli del protocollo in generale. La cartella degli audit contiene sei report sulla v3.7, datati dal 26 al 31 marzo 2026: MixBytes, Sherlock, Pashov, Certora, Savant ed Enigma.
- Si aprono quei report e si confronta il loro commit con il tag. GitHub data la release v3.7.0 al 5 agosto 2026, mesi dopo i report. Un intervallo di date non è di per sé una colpa: è il segnale per controllare quale commit abbia esaminato ciascuna società e che cosa sia cambiato dopo.
A questo punto si capisce quanto vale il primo audit per chi usa oggi il protocollo. I report del 2021 studiati sopra descrivono codice che precede di molte release il Pool attivo. Un protocollo che cita il proprio primo audit racconta il passato. Si contano gli audit per release, non in totale: la cartella di Aave contiene 49 file al 1 novembre 2026, ovvero 47 report una volta messi da parte due che compaiono sia in PDF sia in Markdown. Coprono più di quattro anni e molte versioni, e alcuni riguardano contratti accessori e non il Pool.
Il numero di revisione è un indizio forte, non una prova. Per la prova, uno sviluppatore compila il codice del tag e confronta il risultato con il bytecode on-chain. E il segno di verifica di Etherscan dimostra una cosa sola e ristretta: che il sorgente pubblicato si compila nel bytecode distribuito. Come dice la pagina stessa: «La verifica del codice sorgente non implica che sia sicuro interagire con il contratto».
Aggiornamenti e chiavi di amministrazione
I contratti aggiornabili aggiungono un secondo divario. Chi controlla il proxy può sostituire l’implementazione, e il nuovo codice non ha alcun audit finché qualcuno non lo commissiona. Conviene quindi chiedersi chi detenga quel potere: una chiave sola, un multisig o un voto di governance con un ritardo. Un proxy ERC-1967 emette un evento Upgraded a ogni modifica, quindi il registro degli eventi del contratto mostra quante volte quel potere è stato usato. Un contratto cambiato la settimana scorsa e un audit dell’anno scorso non descrivono la stessa cosa.
Che cosa resta di solito fuori dal perimetro
Salvo diversa indicazione del report, restano fuori di norma gli oracoli di prezzo, i componenti di terzi come i rate provider, i contratti di base condivisi, il sito su cui si clicca davvero, le chiavi degli operatori e gli altri protocolli collegati in seguito. Trail of Bits ha notato nel report su Balancer del 2022 di aver coperto solo in parte componenti di base come BasePool.
Più di un audit: gli strati di garanzia
I team seri sommano metodi, perché ciascuno individua cose diverse. Uniswap v4 è l’esempio classico: il suo team ha riferito il 26 novembre 2024 nove audit indipendenti, con sei società citate per nome, poi una competizione di sicurezza da 2,35 milioni di dollari con oltre 500 ricercatori, in cui «non sono state trovate vulnerabilità critiche», e infine un bug bounty da 15,5 milioni di dollari sulla piattaforma Cantina.
Verifica formale: la prova delle regole che qualcuno ha scritto
Strumenti come il Certora Prover controllano il codice rispetto a regole scritte in ogni stato possibile, mentre un test ne prova solo alcuni. È un metodo più forte e più stretto. Il risultato vale solo per le regole scritte e per il modello usato. Lo dice lo stesso report di Certora su Balancer: «le garanzie del Certora Prover sono limitate alla specifica fornita» (report, 2022). Per rendere il problema risolvibile, quel lavoro ha sostituito la libreria StableMath con un surrogato che restituisce «valori arbitrari, ma coerenti», e ha fatto restituire valori non deterministici a _upscaleArray() e alle funzioni collegate. Leggendo un report simile si vanno a vedere le ipotesi e l’elenco delle funzioni semplificate prima dell’elenco delle regole dimostrate.
Contest: Sherlock, Code4rena e un mercato che si è mosso
In un contest uno sponsor pubblica il codice e un montepremi, i ricercatori gareggiano per un tempo limitato e i giudici decidono che cosa è valido e quanto è grave. Si ottiene ampiezza per un periodo fisso. Le linee guida di Sherlock definiscono High una perdita diretta di fondi senza forti limiti da condizioni esterne e Medium una perdita che richiede certe condizioni o che è molto vincolata.
Quel mercato è cambiato. Code4rena, il nome più legato a questo formato, ha annunciato il 13 maggio 2026 la chiusura delle attività, con Immunefi che prende in carico i clienti dei suoi bug bounty. Il suo sito mostra ancora il bilancio al 1 novembre 2026: 512 audit e 1.607 vulnerabilità High uniche. I report passati restano utili. La documentazione di Sherlock apre oggi con i Collaborative Audits, un Audit Engine che combina intelligenza artificiale e ricercatori umani, e con i bug bounty. Quando un progetto cita un contest, quindi, vanno controllati la piattaforma, la data e il report finale.
Bug bounty: l’audit che non si ferma mai
Un bounty paga persone esterne per i bug nel codice attivo, e copre quindi il tempo dopo che i revisori se ne sono andati. Lo studio di Immunefi su 593 programmi, pubblicato il 20 aprile 2026 e relativo al periodo da gennaio 2021 a febbraio 2026, fornisce i numeri qui sotto. Immunefi vende questo servizio e i dati riguardano solo i suoi programmi, quindi vanno trattati come ricerca di un fornitore.
| Età del programma | Quota con almeno un bug critico confermato e pagato |
|---|---|
| 1 anno o più | 61,4% |
| 2 anni o più | 73,9% |
| 3 anni o più | 87,2% |
| 4 anni o più | 92,9% |
| 5 anni o più | 93,9% |
Va letto accanto a qualunque dichiarazione «completamente sottoposto ad audit»: più a lungo un programma è rimasto attivo, più probabile è stato che facesse emergere un bug critico. Lo stesso studio indica una mediana di 20.000 dollari per un bounty critico e una media di 114.355 dollari, con 107,3 milioni di dollari pagati per i critici. Il massimo indicato nella pagina di un programma è un tetto, non un pagamento. Il pagamento più noto è quello di Wormhole, un record all’epoca: 10 milioni di dollari a un ricercatore noto come satya0x, che il 24 febbraio 2022 segnalò un’implementazione proxy non inizializzata. Fu corretta lo stesso giorno e, secondo Immunefi, nessun fondo degli utenti andò perso. All’inizio di quel mese il ponte aveva subìto un exploit che The Block valutò in quasi 323 milioni di dollari; l’avviso dell’FBI citato più sotto parla di circa 320 milioni.
| Strato | Che cosa fa | Che cosa non può fare |
|---|---|---|
| Audit manuale | Esperti ragionano su un commit per un tempo fisso | Coprire modifiche successive o ciò che è fuori perimetro |
| Verifica formale | Dimostra regole scritte in ogni stato modellato | Controllare regole che nessuno ha scritto o parti semplificate |
| Contest | Molti revisori gareggiano per un periodo limitato | Coprire modifiche successive; la qualità varia con montepremi e data |
| Bug bounty | Paga i bug nel codice attivo, senza scadenza | Fermare un attaccante che preferisce sfruttare il bug anziché segnalarlo |
| Monitoraggio e operatività | Sorveglia contratti e chiavi attivi | Sostituire gli strati precedenti o impedire che un firmatario venga ingannato |
Perché un audit non garantisce nulla: casi reali
I protocolli sottoposti ad audit continuano a perdere denaro. Anche quelli senza audit, e in un conteggio più spesso: Zellic ha scritto nel novembre 2022 che 15 dei 20 maggiori hack della classifica di Rekt erano privi di audit, un conteggio che include Nomad, e Zellic vende audit. Nessuno pubblica un rapporto pulito tra fallimenti con e senza audit, quindi chi ne cita uno va guardato con sospetto. I casi che seguono mostrano come una perdita nasca intorno a un audit, e nessuno di essi è un verdetto sulla società nominata.
Balancer, novembre 2025: gli avvertimenti nei report
Il 3 novembre 2025 un attaccante ha svuotato i pool stabili di Balancer V2 e i fork di quel codice. Il rapporto preliminare ha attribuito il problema a un errore di arrotondamento nel passaggio di upscale degli scambi exact-out dentro batchSwap, come lo ha riassunto The Block. Minuscoli errori di arrotondamento, ripetuti in una catena di scambi dentro una sola transazione contro pool portati a saldi bassi, si sono sommati. OpenZeppelin ne fornisce una ricostruzione dettagliata. Le cifre della perdita cambiano con il metodo: circa 116 milioni di dollari per Cointelegraph il 5 novembre, oltre 120 milioni con i fork per OpenZeppelin e 128,64 milioni di dollari nel conteggio progressivo di PeckShield. Balancer ha precisato all’epoca che le cifre non erano confermate.
| Data | Documento | Che cosa dice, nei suoi termini |
|---|---|---|
| 22 dicembre 2021 | Trail of Bits, Linear e Phantom Pools | Risultato TOB-BALANCER-004 sugli arrotondamenti, gravità Undetermined, difficoltà Low: nessun rischio significativo individuato, eppure «un attaccante potrebbe usarli per ottenere un profitto» |
| 22 settembre 2022 | Trail of Bits, Composable Stable Pool | Sei risultati. StableMath e WordCodec fuori perimetro; nessuna ricerca di attacchi economici di alto livello; BasePool coperto in parte |
| 23 settembre 2022 | Certora, Stable Pool | Tre questioni, nessuna oltre Low. StableMath sostituita da un surrogato; _upscaleArray() impostata su valori non deterministici |
| 3 novembre 2025 | Exploit | Arrotondamento nel passaggio di upscale degli scambi exact-out |
Serve cautela. Il risultato del 2021 riguarda l’arrotondamento in LinearMath e LinearPool, e osserva che _upscaleArray è usata in modo simile in tutti i pool di Balancer. Appartiene alla stessa famiglia di preoccupazioni dell’exploit del 2025: non è la descrizione di quell’attacco, e la società ha dichiarato di non aver trovato rischi significativi. Ciò che la tabella mostra è che un lettore paziente nel 2022 avrebbe potuto vedere tre cose: l’arrotondamento era stato segnalato e lasciato Undetermined, la libreria matematica era fuori perimetro in un audit e il passaggio di scaling era semplificato nelle dimostrazioni. È un’affermazione su ciò che i documenti coprivano, non la prova che una società avrebbe dovuto individuare l’attacco.
OpenZeppelin, che nel 2021 ha esaminato codice precedente di Balancer V2, data al 16 luglio 2021 il primo override dello scaling e dice che i pool portatori del vettore d’attacco sono stati aggiunti dopo la fine del suo secondo audit, quindi i suoi report non li coprivano. È la versione della società sul proprio lavoro, e lo stesso articolo non attribuisce colpe ad alcun revisore. Parla inoltre solo per OpenZeppelin: la pagina di Balancer elenca i due report del settembre 2022 sul Composable Stable Pool, ciascuno con i limiti indicati in tabella.
Euler, marzo 2023: una modifica successiva
Euler ha perso circa 197 milioni di dollari il 13 marzo 2023, secondo il conteggio di Rekt. La via d’attacco passava da donateToReserves, che per Rekt è entrata in Euler con un aggiornamento chiamato EIP-14 e che non aveva il controllo di liquidità applicato ai trasferimenti ordinari (analisi di Zellic). Rekt contava sei società di audit. Riferiva inoltre che Sherlock, da lei definito un protocollo di assicurazione sugli smart contract, si era assunta la responsabilità di non aver visto il difetto nella revisione di EIP-14. The Block ha riportato il 14 marzo che Sherlock aveva accettato di pagare un risarcimento di 4,5 milioni di dollari. I resoconti divergono sui dettagli di quella revisione e qui ci si ferma. Il finale è stato insolito: Euler ha comunicato il 3 aprile 2023 che l’attaccante aveva restituito tutti i «fondi recuperabili» (CoinDesk).
L’attacco ha usato un flash loan, spiegato nella nostra lezione sui flash loan. La lezione di lettura è più semplice: il numero dei revisori non dice chi ha esaminato una determinata funzione.
Nomad, agosto 2022: codice sottoposto ad audit e codice distribuito
Il ponte Nomad ha perso circa 190 milioni di dollari nell’agosto 2022. Zellic ha scritto che, secondo Quantstamp, la società di audit, «il codice difettoso responsabile dell’hack è stato introdotto dopo l’inizio dell’audit», e che il suo tracker mostrava come sottoposto ad audit solo il 18,6% del codice on-chain in Replica.sol. Cointelegraph ha riferito il 3 agosto 2022 che il difetto era stato segnalato nel report di giugno di Quantstamp, aggiungendo poi la tesi di Nomad secondo cui la vulnerabilità evidenziata da Quantstamp era diversa dalla causa dell’exploit. Sono dichiarazioni delle parti riportate da altri, e qui non si prende posizione. Solo un confronto commit per commit stabilisce che cosa sia stato esaminato.
2026: firmatari e livelli di messaggistica
Drift ha perso 285 milioni di dollari il 1 aprile 2026. Il rapporto sull’incidente di Nexus Mutual lo definisce «il risultato di un fallimento della sicurezza operativa, non di un exploit degli smart contract di Drift» e descrive malware sui dispositivi dei collaboratori e approvazioni pre-firmate da due dei cinque membri del Security Council. Il 18 aprile 2026 il ponte di Kelp DAO ha rilasciato 116.500 rsETH, circa 292 milioni di dollari, dopo che un attaccante aveva fatto accettare come valida una falsa istruzione al livello di messaggistica di LayerZero, secondo CoinDesk, che osservava come Kelp non avesse ancora spiegato come fosse stata aggirata la validazione. Un report su un contratto dice poco sui suoi firmatari o sul livello di messaggistica di cui si fida.
Che cosa ha detto l’FBI agli investitori
L’avviso dell’FBI del 29 agosto 2022 raccomandava agli investitori: «Assicurarsi che la piattaforma di investimento DeFi abbia eseguito uno o più audit del codice da parte di revisori indipendenti». Lo stesso avviso citava un attacco con flash loan da circa 3 milioni di dollari, un difetto nella verifica delle firme di un ponte che è costato circa 320 milioni e una manipolazione dell’oracolo di prezzo da circa 35 milioni. L’avviso non dice se quelle piattaforme avessero subìto audit, quindi la riga sull’audit va letta come una precauzione tra le altre, non come una promessa.
Badge di audit falsi o fuorvianti
Un logo su una pagina di presentazione non costa nulla. CertiK ha avvertito il 17 gennaio 2024 che siti truffa usavano certificazioni di audit contraffatte a suo nome, e ha citato Lymex, una truffa con uscita improvvisa da circa 300.000 dollari che indicava CertiK come società di audit benché, secondo CertiK, non avesse mai ricevuto il servizio. È un fornitore che difende il proprio marchio e quindi parla per il proprio caso, ma il metodo è generale. Le nostre guide al rug pull e a come evitare le truffe crypto mostrano dove compaiono questi badge.
Sei controlli su un audit report richiedono pochi minuti:
- Cercare il report sul sito della società di audit o sul suo GitHub ufficiale. Un PDF sul sito del progetto, da solo, non prova nulla.
- Verificare che la data e l’hash del commit esistano e che il commit sia nel repository pubblico del progetto.
- Aspettarsi revisori con nome e un perimetro dichiarato. Un report vero dice che cosa non è stato coperto.
- Aspettarsi risultati con ID e stati. Un report fatto solo di elogi merita sospetto.
- Confrontare l’indirizzo del contratto o il commit del report con ciò che è distribuito.
- Ignorare qualunque link di «verifica» arrivato in messaggio privato e raggiungere il sito della società con un segnalibro proprio.
Anche un punteggio su una pagina di rating della sicurezza non è un audit. Prima di fidarsene, si legge che cosa misura il punteggio. E un report autentico su un contratto diverso, su una versione vecchia o su una piccola parte del sistema è il trucco più sottile: «auditato da» su un sito può essere vero e non dire comunque nulla sul codice che custodisce il denaro.
Checklist di dieci minuti per leggere qualsiasi report
- Annotare la data, il repository e il commit.
- Leggere il perimetro e le limitazioni di copertura prima di qualunque risultato.
- Contare i risultati Critical e High, con le definizioni di quella società.
- Controllare lo stato di ciascuno: fixed, acknowledged, risk accepted o not fixed.
- Leggere ogni «Undetermined» e le motivazioni di ogni rischio accettato.
- Verificare che la società abbia riesaminato le correzioni.
- Annotare che cosa è dato per presupposto: oracoli, amministratori, token esterni, funzioni semplificate.
- Risalire dall’indirizzo attivo all’implementazione e alla release.
- Elencare gli audit di quella release e annotare ogni aggiornamento successivo.
- Cercare un bug bounty attivo e quanto pagherebbe una segnalazione riuscita.
Come pesare ciò che si è trovato
Dopo quei dieci minuti si hanno fatti, non un verdetto. Un audit report pulito sul codice in uso, con correzioni riesaminate, più società e un bounty attivo, riduce un solo tipo di rischio. Non fa nulla contro i guasti degli oracoli, i firmatari, la governance o i ponti. Risultati aperti sulle gravità massime, un perimetro che salta la parte su cui si fa affidamento o un aggiornamento successivo all’ultimo audit sono domande da approfondire, e la risposta pubblica del protocollo a quelle domande dice molto.
La prossima lezione del percorso smonta gli attacchi stessi, famiglia per famiglia, con reentrancy, flash loan e oracoli manipolati, e un elenco datato dei casi più grandi.
