À deux heures du matin, j’ai fini de configurer, dans le SDK VaultKit de Newton, la première stratégie : déclencher automatiquement une liquidation quand le ratio de collatéral passe sous 110%. Poussé vers l’environnement de test, j’ai lancé quelques transactions de simulation, tout fonctionnait correctement. Mais avant d’éteindre l’ordinateur, par un mauvais concours de circonstances, j’ai jeté un coup d’œil au tableau des paramètres de la stratégie, juste pour voir d’où venaient exactement les données de prix.
Et là, plus aucune somnolence.
RedStone. Un seul RedStone.
Le jugement en temps réel de tout le moteur de politiques Newton est entièrement accroché à une seule chaîne d’oracle : RedStone. Pas de sauvegarde avec Chainlink, pas de validation croisée avec Pyth, pas de source de données secondaire pour confirmer deux fois. Une seule ligne, reliée à toute la logique de liquidation d’un coffre.
Admettons que le point de départ de Newton est effectivement le bon. Lors du lancement du réseau principal en bêta le 23 juin 2026, Newton a également sorti le VaultKit SDK, permettant aux développeurs de définir des règles telles que des limites de dépenses, les exigences de collatéral, et les contrôles du contrepartiste. RedStone et Credora, en tant que partenaires de données de lancement, ont été intégrés. RedStone dit lui-même : « Une politique n’est forte que dans la mesure des données qu’elle vérifie ». Cette remarque est juste : la force de la stratégie dépend de la qualité des données qu’elle lit. Mais le problème, c’est que lorsque la stratégie ne lit qu’une seule source de données, la fiabilité de cette donnée devient le maillon décisif de l’ensemble du système.
Dans le rapport de KuCoin, c’est formulé très clairement : « Le risque à surveiller est la concentration. Si le moteur de politiques de Newton dépend excessivement des données de prix fournies par RedStone, toute interruption d’un oracle peut entraîner le gel des transactions sur la plateforme. » Le rapport de BingX mentionne aussi le même risque : « Dès que l’approvisionnement en données d’un oracle est interrompu, cela peut déclencher un effet domino de gels de transactions au niveau de la plateforme. »
RedStone couvre actuellement plus de 100 blockchains et affirme n’avoir « jusqu’à présent jamais connu d’événement de mauvais prix ». Mais « ne s’être jamais produit jusqu’à présent » ne veut pas dire « ne se produira jamais ». Pannes de l’oracle, sources de données contaminées, retards dans l’alimentation des prix : ces scénarios se répètent maintes fois dans l’histoire de DeFi. Dans le moteur de stratégie de Newton, il n’existe aucun plan de sauvegarde.
Ce qui me met le plus mal à l’aise, c’est une autre chose : dans l’environnement d’exécution TEE de Newton, après avoir lu les données de marché de RedStone et effectué les calculs hors chaîne, il ne génère qu’une preuve ZK sous forme simplifiée soumise à la chaîne. Les données originales complètes ne sont pas stockées sur la chaîne.
Qu’est-ce que cela implique ?
Si un jour, une stratégie d’automatisation exécute par erreur des actions à cause d’anomalies dans les données de prix, entraînant des pertes pour les utilisateurs, vous ne pourrez pas retrouver sur la chaîne l’ensemble des données originales complètes. Vous ne verrez que cette preuve simplifiée : elle vous dit que « le processus de calcul est correct », mais elle ne vous dit pas si « les données en entrée elles-mêmes sont problématiques ».
Est-ce que c’est l’oracle qui a alimenté un mauvais prix, ou bien un nœud TEE qui a falsifié les données, ou encore une erreur (bug) dans la logique du contrat ? Les utilisateurs n’auront jamais la possibilité de vérifier intégralement en toute transparence sur la chaîne. Et dans le livre blanc de Newton, je n’ai pas vu de conception détaillée portant sur des contrôles multiples avec plusieurs oracles.
Le marché a déjà donné sa réponse. NEWT est passé du sommet historique de juillet 2025 à environ 0,717 dollar vers juillet 2026, jusqu’à environ 0,05 dollar : une baisse de plus de 93 %. Sa capitalisation n’est qu’environ 10,18 millions de dollars. Pour un projet qui s’affiche avec un effet de projecteur de 90 millions de dollars de financement, ce chiffre, lui, est d’un calme inquiétant.
Lorsqu’une stratégie de trading automatisé d’un protocole dépend entièrement d’une seule source de données d’oracle pour être déclenchée, et que la chaîne ne permet même pas de vérifier l’ensemble des données originales en intégralité — alors, que signifie exactement « automatisation vérifiable » : vérifie-t-elle quoi ?
Ce qui précède ne sont que des opinions personnelles et ne constitue pas un conseil en investissement. N’hésitez pas à en discuter dans la section commentaires et à partager votre point de vue.