Exploit Notional Finance V1: come un debito da 2^128 è diventato zero

L’incidente segnalato su Notional Finance non sarebbe stato un normale problema di garanzie insufficienti. La vulnerabilità ricostruita riguarda invece un disallineamento contabile: sarebbe stato creato un enorme debito fCash al limite 2^128, poi ridotto a zero quando il protocollo lo convertiva in uint128 per calcolare il collaterale libero. In quel passaggio cruciale la passività risultava quindi nulla e l’account poteva apparire solvibile, ottenendo accesso ad asset che non avrebbe dovuto poter prelevare. 416

La ricostruzione pubblica si basa su monitoraggio on-chain e analisi di ricercatori di sicurezza, non su un post-mortem pubblicato dal protocollo. È una distinzione importante: i movimenti dei fondi sono osservabili sulla blockchain, ma la sequenza definitiva delle chiamate, l’impatto complessivo e lo stato delle misure correttive non risultavano confermati nelle notizie disponibili. 34

Il difetto contabile: un debito valutato come zero

In Notional V1, gli obblighi di pagamento futuri erano rappresentati da token fCash. Secondo l’allerta pubblica di CertiK, l’attaccante avrebbe usato due chiamate a mintfCashPair() per creare una passività di -2^128. Durante la valutazione del collaterale libero, una conversione non sicura a uint128 avrebbe troncato quel valore a 0. 16

In termini pratici, il percorso dell’exploit descritto dai ricercatori sarebbe stato questo:

1. Creare una posizione fCash estremamente negativa. L’attaccante avrebbe generato un debito esattamente della dimensione per cui la riduzione a un intero senza segno a 128 bit poteva eliminare la rappresentazione della passività. 416
2. Attivare la valutazione delle garanzie. La contabilità dell’escrow avrebbe convertito la passività tramite un downcast non sicuro a uint128.
3. Far sparire il debito nel controllo. Anziché riflettere un’enorme obbligazione negativa, il calcolo l’avrebbe trattata come zero. 46
4. Superare il controllo sul prelievo. Senza quel debito nel calcolo del collaterale libero, l’account poteva apparire idoneo a ritirare le stablecoin liquide custodite nell’escrow. 46

Per questo il problema va letto più correttamente come un fallimento della conversione con riduzione di ampiezza e degli invarianti contabili, non come un generico «overflow intero». L’effetto cruciale segnalato è che una passività negativa sia diventata zero proprio nel percorso di valutazione che avrebbe dovuto impedire un prelievo sotto-garantito. 416

I fondi che sarebbero stati sottratti

Le segnalazioni on-chain stimano una perdita di circa 69.257 DAI e 1.650.824 USDC, per un totale vicino a 1,728 milioni di dollari. Gli asset sarebbero stati convertiti in circa 689,2 ETH e successivamente depositati in Tornado Cash. 215

Il contratto indicato nei report è l’escrow di Notional Finance all’indirizzo 0x9abd0b8868546105F6F48298eaDC1D9c82f7f683. Una ricostruzione cita una transazione di preparazione da un indirizzo che termina in Ce38, inviata alle 23:58:47 UTC del 3 settembre 2026; circa tre minuti dopo sarebbe seguita la transazione di svuotamento, nelle prime ore del 4 settembre. 1723

Gli investigatori hanno associato pubblicamente due indirizzi Ethereum ai trasferimenti:

• 0xC954…De69
• 0xDaCC…Ce38

Queste etichette indicano un’associazione investigativa on-chain, non l’identificazione di una persona, di un’organizzazione o del titolare effettivo degli indirizzi. 11

Perché il passaggio in ETH ha complicato il recupero

La conversione riportata da DAI e USDC a ETH ha cambiato il quadro del recupero. I trasferimenti iniziali di stablecoin sono chiaramente tracciabili su Ethereum, mentre lo scambio successivo ha trasformato gli asset in ETH. I depositi in Tornado Cash avrebbero poi aggiunto un livello di privacy progettato per offuscare origine, destinazione e controparti delle transazioni. 229

Questo non rende impossibile l’analisi blockchain e non dimostra chi abbia controllato eventuali prelievi successivi. Rende però molto meno lineare il collegamento diretto, asset per asset, tra l’escrow sfruttato e un destinatario successivo dopo l’ingresso dei fondi in un mixer. 29

Cosa restava da chiarire

Al momento delle segnalazioni, Notional non aveva pubblicato una risposta ufficiale all’incidente. Restavano quindi aperti diversi punti rilevanti:

• la causa tecnica definitiva e l’intera sequenza di chiamate dell’exploit;
• se le transazioni riportate rappresentassero tutti i contratti, gli account e gli asset coinvolti;
• la perdita finale, dopo swap, commissioni ed eventuali trasferimenti ulteriori;
• le opzioni disponibili per sospensione, aggiornamento, compensazione o recupero; e
• l’identità dell’attaccante e se gli indirizzi etichettati fossero gli unici wallet sotto controllo comune. 3411

La causa indicata va quindi considerata una ricostruzione preliminare solida, ma non sostituisce un post-mortem verificato o un rapporto ufficiale del protocollo.

La lezione di sicurezza per la DeFi legacy

Un contratto legacy non è a basso rischio solo perché è vecchio o non è più al centro della roadmap di un prodotto. Se custodisce ancora asset o conserva accesso a funzioni di minting, regolamento, garanzia o prelievo, continua a essere una superficie d’attacco finanziaria attiva.

Il caso Notional V1 evidenzia alcuni controlli che i team di protocollo dovrebbero verificare insieme:

• usare conversioni di riduzione controllate e rifiutare esplicitamente valori non rappresentabili in sicurezza;
• testare calcoli su debiti con segno, regolamenti e garanzie ai limiti numerici, come 2^128;
• tradurre solvibilità e conservazione del valore in invarianti e testarli lungo sequenze di chiamate multiple;
• verificare se percorsi privilegiati o insoliti possano combinare minting, regolamento e prelievo in un ordine inatteso; e
• limitare chiamanti e flussi operativi quando una funzione non è sicura fuori dal suo contesto previsto.

Lo schema più ampio è ricorrente nella DeFi: un difetto apparentemente piccolo di rappresentazione o autorizzazione può trasformarsi in una perdita totale quando raggiunge un percorso di prelievo che controlla liquidità. La difesa non consiste soltanto nell’audit delle singole funzioni, ma nella verifica che gli invarianti contabili del sistema restino validi in ogni sequenza di chiamate raggiungibile.