Avant, Newton parlait davantage d’Agent, d’exécution automatisée, de TEE, de ZK, et de la façon de faire faire aux machines les opérations on-chain pour les utilisateurs. Après le lancement de Mainnet Beta le 23 juin, le centre de gravité du projet s’est clairement resserré : il s’agit d’abord de se concentrer sur les DeFi Vault, en insérant la couche d’autorisation entre l’intention de transaction et le règlement final.
Ce changement me semble très pragmatique.
Parce que, dans la finance on-chain, ce qui manque aujourd’hui ne se limite pas vraiment à ajouter une stratégie de rendement en plus. L’argent est déjà passé on-chain, mais les règles de gestion des risques restent dans des PDF, des tableaux internes, des groupes Telegram et dans la tête des administrateurs. Quand le marché est stable, tout le monde peut encore faire semblant que le processus fonctionne. Mais si la tendance s’inverse brutalement, le robot continue à rééquilibrer, les administrateurs n’ont pas le temps de retirer les autorisations, le système d’alerte se met à envoyer des messages en rafale… au final, c’est quand même la transaction qui se concrétise d’abord, puis le rapport de risque arrive après coup.
Ce que Newton veut résoudre, c’est ce décalage entre les périodes.
D’après la divulgation officielle, au cours de l’année passée, le TVL des curated DeFi vault a augmenté de plus de 350 %. La Mainnet Beta est actuellement déployée sur Ethereum et Base, et propose des implémentations pour des scénarios de Vault comme ceux d’Euler ; en parallèle, elle s’appuie sur des services de données et de risques tels que RedStone, Credora, Chainalysis, vaults.fyi et Webacy. Récemment, Newton a aussi mis à jour sa collaboration avec RedStone : elle enchaîne les données de prix, les scores de risque et l’exécution des stratégies en amont des transactions…
Un curator de Vault prépare à transférer davantage de fonds vers un certain marché. Dans un Vault ordinaire, cette action dépend généralement des permissions d’administrateur : tant que la signature est valide et que le contrat l’autorise, la transaction s’exécute. Newton ajoute une vérification en amont : encapsuler d’abord le contenu complet de la transaction en Intent, puis le confier à l’opérateur pour évaluation via la Rego Policy. La stratégie peut vérifier si la position sur un marché unique dépasse 40 %, si le prix de la garantie est anormal, si l’oracle est dévié, si une adresse est entrée dans une liste de sanctions, puis générer une preuve d’autorisation ou de refus.
Après validation, Shield ne fait ensuite que rediriger l’appel vers le Vault sous-jacent.
Ce qu’il y a de plus précieux dans cette conception, c’est que la preuve est liée à une transaction précise. Le signataire, le contrat cible, le montant, le calldata, l’ID de chaîne et la signature de fonction seront tous inscrits dans l’Intent. Une fois qu’un administrateur obtient une autorisation, il ne peut ni remplacer furtivement les paramètres, ni réutiliser une autorisation de transaction en la transposant sur une autre transaction. L’ID de tâche ne peut être consommé qu’une fois, la preuve a aussi une période de validité, et l’ID de chaîne est revérifié lors de l’exécution. Cette structure est bien plus solide que “une IA qui gère ta trésorerie à ta place”.
Difficile de prouver si une IA choisit les bons marchés ; de même, comment prouver avec certitude si une action de gestion a dépassé des limites préétablies alors qu’elle pourrait être strictement vérifiée. Newton découpe le problème complexe en une question de décision plus petite : cette transaction est-elle conforme à la stratégie publiée auparavant ?
Mais si je continue à regarder, la contradiction la plus critique du projet apparaît aussi.
Newton insiste : les règles peuvent être exécutées automatiquement, mais les règles elles-mêmes ne deviennent pas automatiquement correctes.
Le plafond de concentration du Vault est fixé à 40 % ou 70 % ? À partir de quel niveau de score de risque faut-il arrêter le rééquilibrage ? À quel écart de l’oracle faut-il considérer que c’est anormal ? Combien de temps sans mise à jour des données faut-il pour refuser la transaction ? Au final, tous ces paramètres sont décidés par le curator ou le configurateur de la stratégie. Newton peut garantir que le système exécute selon les règles, mais il ne peut pas aider les propriétaires de fonds à juger si les règles sont suffisamment strictes.
Le code ne fait que protéger la porte ; où se trouve la porte, c’est encore aux humains de le décider.
C’est particulièrement important. Une stratégie écrite de manière très permissive peut aussi obtenir une belle preuve on-chain grâce à Newton. Chaque transaction est enregistrée, chaque autorisation est signée, chaque vérification peut être retrouvée dans Explorer ; pourtant, le Vault peut toujours porter un risque très agressif. La vérifiabilité on-chain résout la question de “l’exécution conforme au règlement”, mais ne résout pas naturellement celle de “le règlement est-il bon”.
Même après mise à jour des paramètres de stratégie, les transactions futures utiliseront les nouveaux paramètres, tandis que les anciennes preuves conserveront l’historique dans leur état d’origine. Techniquement, c’est très cohérent ; côté utilisateur, cela crée pourtant un nouveau coût de compréhension : lorsque je dépose des fonds, les règles que je vois sont-elles toujours les mêmes engagements de risque que celles utilisées par le curator lorsqu’il les a mises à jour ?
La documentation de Newton indique que les déposants peuvent consulter les policy params on-chain, décoder les modules de stratégie, et vérifier les sources de données utilisées par les modules. En théorie, c’est extrêmement transparent. Dans la réalité, est-ce que les utilisateurs ordinaires peuvent comprendre le manifest, le WASM CID, PolicyConfig et chacun des modules d’oracle ? C’est une autre affaire. Le fait que ce soit public on-chain ne veut pas dire que l’utilisateur comprend : ce vieux problème subsiste au niveau de la couche d’autorisation, mais avec des noms de fichiers plus “professionnels”…
Newton lui-même insiste encore et encore : la force de la stratégie dépend des données de base. Désormais, la Policy peut appeler les informations de prix de RedStone, les notations de risque de Credora, le filtrage des adresses de Chainalysis, les indicateurs de santé des Vaults de vaults.fyi et les signaux de risque de Webacy.
Ces collaborations ont du poids. RedStone divulgue qu’elle couvre plus de 1 000 actifs et plus de 100 chaînes. Newton mentionne aussi récemment dans sa publication conjointe que Credora a déjà couvert les notations de Spark Savings, et fournit des évaluations de risque pour un grand nombre de Vaults Morpho. Mais si des données externes sont en retard, si l’API est indisponible, si le modèle de notation est déformé, ou si l’oracle utilise une définition qui ne correspond pas à la liquidité réelle, Newton exécutera très fidèlement une entrée problématique.
Bonne nouvelle : VaultKit a par défaut fail closed. Si le Gateway est indisponible, si les opérateurs n’atteignent pas le nombre légal, si la stratégie ne peut pas être évaluée, si la preuve expire ou si la vérification on-chain échoue, Shield ne transmettra pas plus loin les opérations d’administration. Quand le système rencontre une incertitude, il s’arrête d’abord ; c’est beaucoup plus fiable que “les données ne sont pas revenues, on continue avec le dernier résultat”.
Dans un marché très volatil, arrêter un mauvais rééquilibrage peut sauver la vie, mais bloquer aussi un retrait nécessaire peut, tout aussi bien, amplifier la perte. Le système de gestion des risques redoute surtout deux choses : ne pas bloquer quand il faut, et ne pas pouvoir laisser passer quand il faut. Aujourd’hui, Newton a fait par défaut le choix de la première option ; l’orientation “sécurité d’abord” est très claire. Cependant, une fois que le Vault fonctionne réellement, les délais de réponse des opérateurs, la stabilité du Gateway, le taux de disponibilité des fournisseurs de données, et les retards de génération des preuves passeront d’indicateurs techniques à des risques financiers.
Il y a aussi un détail facilement emporté par le discours marketing.
Le principal que protège VaultKit, ce sont les actions d’administration du curator : réallocation des fonds, ajustement des plafonds, activation des marchés et modification des frais. Les dépôts et retraits des utilisateurs ordinaires ne passent pas par Shield. Il encadre la façon dont les droits d’administration sont utilisés, sans placer une “assurance universelle” sur l’ensemble du Vault. Les vulnérabilités du protocole de base, le désancrage des actifs, l’évaporation de liquidité du marché, et le choix par l’utilisateur de produits erronés : tous ces risques existent encore. Le clin d’œil : le mécanisme de contournement.
VaultKit affirme que lorsque la stratégie rejette, la transaction ne s’exécute pas, et qu’à défaut de consensus des opérateurs, la transaction ne s’exécute pas non plus. En même temps, le système conserve le bypass différé initié par le owner. Ce contournement doit être publiquement mis en file d’attente, passer par un temps d’attente prédéfini, et laisser un événement on-chain ; l’administrateur ne peut pas appuyer discrètement sur un bouton “skip” quand la stratégie ne lui convient pas.
Un système sans sortie d’urgence peut, dans des cas extrêmes, immobiliser les fonds ; un système contournable à tout moment fait de toutes les stratégies de simples décorations web. Une échappatoire différée, publique et observable expose au moins le pouvoir de l’administrateur à un temps et à des traces on-chain.
Mais il faut continuer à poser les questions : la période d’attente, concrètement, dure combien de temps ? Qui contrôle owner ? C’est un compte unique, une multi-signature, ou une gouvernance institutionnelle ? Pendant l’attente, les déposants peuvent-ils recevoir à temps les alertes ? Le front-end affichera-t-il clairement que bypass est en file d’attente ? Les Vault qui ont exécuté un bypass conserveront-ils un marquage de risque permanent ?
Ces éléments déterminent si bypass est une issue de secours, ou au contraire une “porte dérobée” aménagée avec plus de soin.
Ce qui mérite encore plus d’attention, c’est que les clauses juridiques de VaultKit définissent très clairement les limites de responsabilité. Magic ne garantit pas que la Policy reconnaîtra forcément les adresses sanctionnées, les transactions dangereuses ou les comportements non conformes ; ne garantit pas non plus que Gateway sera continuellement disponible, ni que les données tierces seront exactes et en temps voulu. La configuration de Shield, les paramètres de stratégie, les tests en environnement de production et les conséquences générées après l’utilisation de bypass sont principalement assumés par le déployeur et le curator. La promesse technique de wton devient caduque.
Cela montre que la Mainnet Beta fournit actuellement un ensemble d’outils d’autorisation vérifiables, et qu’elle n’est pas encore devenue une société d’assurance qui endosse à la place des institutions la responsabilité de la gestion des risques. Newton peut prouver que les opérateurs appliquent un certain ensemble de règles à une entrée donnée, mais il ne peut pas garantir que l’entrée restera toujours vraie, que les règles resteront toujours raisonnables, ni que les déployeurs resteront toujours prudents.
Il y a aussi un point dans le livre blanc que je vais continuer à surveiller.
L’état de maturité décrit par Newton correspond à plusieurs opérateurs indépendants qui exécutent chacun la même stratégie ; une fois le seuil de pondération de mise atteint, ils génèrent une signature agrégée BLS. Un résultat erroné peut être contesté pendant la période de litige. Les challengers pointent le problème via une preuve de fraude à connaissance zéro. Les opérateurs malveillants ou négligents encourent alors le slashing.
Mais l’officialité, lorsqu’elle explique la Mainnet Beta, utilise une formulation très prudente : après le retrait de la Beta, de nombreux opérateurs évalueront indépendamment la même proposition. Le niveau de décentralisation de la phase précédente, le nombre d’opérateurs, la répartition des mises, si les challengers sont réellement ouverts, et si le slashing a bien été entièrement activé, doivent être vérifiés séparément. Le projet a déjà commencé à exécuter des règles sur de vrais fonds, mais le modèle de sécurité complet dans le livre blanc ne sera peut-être pas entièrement dans sa forme finale.
C’est précisément la partie la plus intéressante de la Mainnet Beta.
Je ne vais donc pas me contenter de regarder combien de partenaires Newton a “branchés”, ni donner d’emblée une note parfaite à la sécurité simplement parce que la liste inclut Chainalysis, RedStone, EigenLayer, Succinct et Euler. Je veux plutôt voir plusieurs jeux de données concrètes : combien d’Intent réels traités au total sur le mainnet, quel est le taux de rejet des stratégies, quel est le délai moyen de génération des preuves, quel est le nombre réel d’opérateurs et la concentration de la mise, combien de fois un échec “fail closed” a été déclenché quand les sources de données étaient anormales, y a-t-il eu des Vault qui ont démarré avec bypass, et est-ce que les mécanismes de challenge et de slashing ont déjà eu des cas réels.
Un rapport de résultats d’un protocole d’autorisation ne devrait pas seulement compter combien de transactions ont été acceptées. Qu’a-t-il bloqué, pourquoi l’a-t-il bloqué, combien de fois a-t-il bloqué à tort, comment a-t-on récupéré en cas de panne du système : ces données sont plus importantes.
Quant à $NEWT, la Mainnet Beta actuelle remet aussi sur la table le problème de la capture de valeur du token. Dans la conception officielle initiale, NEWT assure la sécurité du staking, les frais du protocole, l’enregistrement du modèle et les fonctions de gouvernance. À l’avenir, les opérateurs et les délégants obtiendront un retour via les activités du protocole et les récompenses du réseau. L’offre totale est fixe à 1 milliard de tokens ; l’offre en circulation initiale est de 215 millions. Les récompenses réseau du début représentent 8,5 % de l’offre totale : l’objectif est d’abord d’activer la sécurité via des incitations de la fondation, puis de passer progressivement à de vrais frais de protocole. Après la croissance des activités d’autorisation Vault, où les frais seront-ils réellement perçus ? À quel niveau faut-il détenir ou payer NEWT ? Comment se répartissent la sécurité ré-stakée d’EigenLayer et la sécurité du staking de NEWT lui-même ? Quelle part des revenus des opérateurs vient d’une utilisation réelle, et quelle part vient encore de subventions ?
Le protocole commence à exécuter de vraies Policies : c’est un jalon plus significatif que des campagnes de points. Mais passer de “la technique fonctionne” à “la formation d’une demande stable par les tokens” implique encore trois postes à faire : l’échelle d’utilisation, la méthode de facturation et le budget de sécurité.
J’ai une attitude plutôt positive envers Newton Protocol Mainnet Beta, et je garderai un œil sur sa structure de permissions.
Newton a identifié un manque bien réel dans la finance on-chain : le règlement est déjà très automatisé, mais l’autorisation et la gestion des risques reposent encore sur des processus manuels. Il place les règles avant que la transaction n’ait lieu, lie l’action de l’administrateur à un Intent précis, puis conserve à chaque décision un enregistrement vérifiable. Cette approche est bien plus intéressante que d’empiler simplement un agrégateur de rendements.
Mais la couche d’autorisation ne peut pas créer la confiance de nulle part.
Il ne fait que démanteler les relations de confiance qui étaient auparavant cachées au sein des institutions, pour montrer à chacun qui définit les règles, qui fournit les données, qui signe le résultat, qui peut contourner en cas d’anomalie, et qui assume la responsabilité après que quelque chose tourne mal.
Si ces questions peuvent être rendues visibles, alors Newton peut dire qu’il a fait le premier pas.
La prochaine preuve que le projet devra apporter, c’est que ces permissions sont réellement suffisamment dispersées, que les stratégies sont réellement examinées par des humains, que les anomalies de données sont réellement traitées à temps, et que l’information publique on-chain est réellement compréhensible par les propriétaires de capitaux ordinaires.
Sinon, on pourrait obtenir un résultat assez froid : chaque transaction dispose d’une preuve complète, chaque signature peut être vérifiée, et le système suit strictement le règlement… sauf que ledit règlement n’est pas bien rédigé.