Ce que j’ai appris, c’est qu’il ne faut pas trop vite faire confiance à chaque nouvelle histoire de cryptographie.

Le marché, en l’espace de quelques semaines, parvient presque à emballer n’importe quoi sous la forme d’une « action à faire immédiatement ». Les agents d’IA sont le dernier exemple. Tout le monde parle de vitesse, d’automatisation et d’exécution. Mais le problème plus discret — et plus difficile — est le suivant : avant que l’argent ne bouge réellement, qu’est-ce qui peut empêcher l’agent de commettre une erreur coûteuse ?

#newt $NEWT @NewtonProtocol

C’est justement ici que Newton $NEWT a attiré mon attention.

D’après la documentation officielle, Newton essaie de jouer le rôle d’une « couche de vérification de stratégie » pour les transactions on-chain. Une façon simple de le comprendre : imagine-le comme un comptoir de sécurité dans un bâtiment. L’agent se voit peut-être accorder des autorisations d’exécution, mais chaque action doit encore être validée par les règles à l’entrée.

Mais le vrai problème s’est révélé ensuite.

Qui vérifie « le vérificateur » ?

La conception de Newton s’appuie sur des intentions de transaction, des politiques basées sur Rego, des données hors chaîne et un réseau décentralisé d’opérateurs. Les opérateurs évaluent cette intention, signent le résultat au moyen d’attestations avec BLS, et la couche d’agrégation vérifie que le quorum est atteint avant que le contrat intelligent ne valide l’autorisation sur la chaîne.

Cela semble utile, notamment pour les wallets d’agents, les règles de conformité, les plafonds de dépenses et les contrôles anti-fraude.

Cependant, je ne l’ai pas encore considéré comme une infrastructure résolue. La stratégie peut être mal écrite. Les opérateurs ont besoin de fiabilité. Les développeurs peuvent aussi éviter ces mécanismes pour réduire les frictions supplémentaires.

Ensuite, je veux examiner plus en profondeur le modèle opérationnel de Newton et évaluer si ce système peut rester digne de confiance une fois mis à l’échelle.