Notional Finance V1 : comment une dette de 2^128 a pu être comptabilisée à zéro

L’incident signalé chez Notional Finance ne ressemble pas à un simple défaut de collatéral. La faiblesse présumée est un décalage dans la comptabilité : une dette fCash massive aurait été créée à la frontière 2^128, puis ramenée à zéro lorsque le protocole l’a convertie en uint128 pour calculer le collatéral disponible. À ce stade crucial, la dette n’étant plus prise en compte, le compte pouvait paraître solvable et retirer des actifs auxquels il n’aurait normalement pas dû avoir accès. 416

Cette reconstitution repose sur des observations on-chain et des rapports de chercheurs en sécurité, et non sur un post-mortem publié par le protocole. Cette nuance est essentielle : les mouvements de fonds sont visibles sur la blockchain, mais la séquence exacte des appels, l’ampleur complète de l’impact et l’état des correctifs n’avaient pas été confirmés dans les informations disponibles. 34

Le défaut comptable : une dette évaluée à zéro

Dans Notional V1, les obligations de paiement futures étaient représentées par des fCash. Selon l’alerte publique de CertiK, l’attaquant aurait utilisé deux appels à mintfCashPair() afin de créer un passif de -2^128. Lors de l’évaluation du collatéral disponible, une conversion non sécurisée en uint128 aurait tronqué cette valeur à 0. 16

Concrètement, le scénario décrit par les chercheurs est le suivant :

1. Créer une position fCash négative extrême. L’attaquant aurait généré une dette exactement à la taille où sa réduction dans un entier non signé de 128 bits pouvait effacer sa représentation. 416
2. Déclencher l’évaluation du collatéral. La comptabilité de l’escrow aurait converti ce passif via un downcast non sécurisé vers uint128.
3. Faire disparaître la dette lors du contrôle. Au lieu de refléter une obligation négative gigantesque, le calcul l’aurait traitée comme nulle. 46
4. Franchir la barrière de retrait. La dette étant absente du calcul du collatéral disponible, le compte pouvait sembler remplir les conditions requises pour retirer les stablecoins liquides de l’escrow. 46

Il est donc plus juste de parler d’une défaillance de conversion réductrice et d’invariant comptable que d’un vague « dépassement d’entier ». L’effet critique rapporté est qu’un passif négatif est devenu nul dans le chemin d’évaluation censé empêcher un retrait insuffisamment collatéralisé. 416

Les actifs qui auraient été retirés

Les données on-chain rapportées font état d’environ 69 257 DAI et 1 650 824 USDC, soit approximativement 1,728 million de dollars. Les actifs auraient ensuite été échangés contre environ 689,2 ETH, puis déposés dans Tornado Cash. 215

Le contrat identifié dans les rapports est l’escrow Notional Finance à l’adresse 0x9abd0b8868546105F6F48298eaDC1D9c82f7f683. Une source évoque une transaction de préparation, envoyée depuis une adresse se terminant par Ce38, le 3 septembre 2026 à 23 h 58 min 47 s UTC, puis une transaction de retrait environ trois minutes plus tard, au début du 4 septembre. 1723

Les enquêteurs ont publiquement associé deux adresses Ethereum aux transferts :

• 0xC954…De69
• 0xDaCC…Ce38

Ces étiquettes correspondent à une association établie dans le cadre d’une enquête on-chain ; elles n’identifient pas une personne, une organisation ni le détenteur final des portefeuilles. 11

Pourquoi le passage par l’ETH a compliqué la récupération

La conversion rapportée des DAI et USDC en ETH a changé les perspectives de récupération. Les transferts de stablecoins étaient directement traçables sur Ethereum, tandis que l’échange a réparti la valeur sous forme d’ETH. Les dépôts signalés dans Tornado Cash ont ensuite ajouté une couche de confidentialité destinée à obscurcir l’origine, la destination et les contreparties des transactions. 229

Cela ne rend pas l’analyse blockchain impossible et ne prouve pas qui contrôlerait un éventuel retrait ultérieur. En revanche, le suivi direct, actif par actif, entre l’escrow exploité et un bénéficiaire ultérieur devient nettement moins simple une fois les fonds passés par un mélangeur. 29

Ce qui restait inconnu

Au moment des publications citées, Notional n’avait pas communiqué publiquement sur l’incident. Plusieurs questions importantes restaient donc ouvertes :

• la cause technique définitive et l’enchaînement complet des appels ayant permis l’exploit ;
• le fait de savoir si les transactions rapportées couvraient tous les contrats, comptes et actifs affectés ;
• la perte finale après les échanges, frais et éventuels transferts ultérieurs ;
• les possibilités de suspension, de mise à jour, d’indemnisation ou de récupération ;
• l’identité de l’attaquant et la question de savoir si les portefeuilles étiquetés étaient les seuls sous contrôle commun. 3411

La cause rapportée doit donc être considérée comme une reconstitution préliminaire solide, et non comme le substitut d’un audit post-incident ou d’un rapport officiel.

La leçon de sécurité pour les protocoles DeFi historiques

Un contrat ancien n’est pas peu risqué parce qu’il n’est plus au centre de la feuille de route d’un produit. Dès lors qu’il détient encore des actifs ou conserve un rôle dans la création, le règlement, le collatéral ou les retraits, il reste une surface d’attaque financière active.

Pour les équipes de protocoles, le cas Notional V1 souligne plusieurs contrôles à vérifier ensemble :

• employer des conversions réductrices vérifiées et rejeter explicitement les valeurs non représentables sans risque ;
• tester les calculs de dette signée, de règlement et de collatéral aux limites numériques, notamment autour de 2^128 ;
• formaliser les règles de solvabilité et de conservation sous forme d’invariants, puis les tester sur des séquences de plusieurs appels ;
• examiner si des chemins d’appel inhabituels ou privilégiés peuvent combiner création, règlement et retrait dans un ordre imprévu ;
• limiter les appelants et les parcours d’exécution lorsque certaines fonctions ne sont sûres que dans leur contexte prévu.

Le schéma est récurrent dans la DeFi : une faiblesse apparemment réduite dans la représentation d’une valeur ou l’autorisation peut se transformer en perte totale dès qu’elle atteint un mécanisme de retrait détenant des actifs liquides. La défense ne consiste pas seulement à auditer les fonctions une à une, mais à démontrer que les invariants comptables tiennent sur toute séquence d’appels accessible.