Tard dans la nuit, impossible de dormir. Je réuni quelques vieux amis qui ont longtemps roulé leur bosse dans Web3 pour repasser la situation et analyser le paysage de l’industrie du moment. On s’est aspergé le visage d’eau froide, puis on est restés longtemps à réfléchir devant un écran vide. Finalement, on a clarifié la question ultime qui tourmente l’industrie depuis longtemps : le Newton Mainnet Beta, lancé par le Newton Protocol, comble précisément quel maillon vital manquant dans l’infrastructure on-chain ? Et surtout, pourquoi cette lacune, il y a de ça plus de dix ans, n’a-t-elle jamais été traitée sérieusement par tout le secteur ?
Aujourd’hui, on ne va pas parler en termes obscurs. On va simplement apporter une chaise, comme dans le vieux coin, autour d’une bière, pour discuter tranquillement : avec des mots simples, on va tout démonter et l’expliquer clairement.
1. Dans un parfait plan du Web3, il y a en fait toujours une “zone aveugle invisible”
Reprenons d’abord et repassons en revue l’infrastructure Web3 actuelle. Honnêtement, à première vue, elle semble déjà extrêmement parfaite — même trop parfaite, au point de ne laisser aucune épine à enlever :
1. La couche d’exécution a des smart contracts : transformer toute la logique métier en code immuable, décentralisé, vérifiable, que n’importe qui peut auditer à tout moment — et réaliser vraiment “le code, c’est la loi”.
2. La couche de données a des oracles décentralisés : injecter en continu et de façon fiable des données du monde réel hors chaîne (par ex. prix des tokens, météo, événements réels) dans les smart contracts on-chain.
3. La couche d’extension a des réseaux Layer 2 : abaisser les frais de Gas élevés, pour rendre possible le trading haute fréquence et des applications à grande échelle.
4. La couche sécurité a des mécanismes de double/multiple staking lourds comme EigenLayer : permettent de réemprunter et réutiliser la précieuse sécurité économique, ce qui abaisse le seuil de démarrage des nouvelles chaînes.
Avec ce combo, si on le remet dans le contexte d’il y a cinq ans, aucun acteur du Web3 n’oserait même l’imaginer. Mais au moment où tout le monde pensait que la construction de l’infrastructure était enfin terminée et qu’on se mettait à fond à “pousser l’application layer”, la réalité nous a giflés très fort.
Il y a un problème central, tout en bas, le plus déterminant, que même dans ce récit grandiose, on n’arrive pourtant pas à résoudre avec une infrastructure décentralisée correspondante. Cette zone aveugle, c’est : la “vérification native de conformité on-chain”.
À ce stade, quelqu’un pourrait objecter : “Qui a dit que DeFi ne fait pas attention à la conformité ? Les grands protocoles ne l’ont-ils pas toujours fait ?”
Oui, il faut quand même dire les choses honnêtement : ces années, l’industrie DeFi n’a pas totalement “fermé les yeux” sur la conformité.
Sur son interface front-end, Uniswap a bloqué de manière précise les adresses malveillantes sous sanctions.
Circle, en tant que géant, s’est aussi à plusieurs reprises conformé aux exigences de l’OFAC (Office of Foreign Assets Control, Bureau de contrôle des avoirs étrangers des États-Unis), et a rapidement gelé certains comptes USDC ciblés.
Au sein d’Aave, il existe tout un ensemble de cadres stricts de contrôle des risques et de processus de gouvernance des paramètres, qui refusent l’entrée de flux de capitaux à haut risque.
Des sociétés d’analyse on-chain comme Chainalysis et TRM Labs fournissent des services extrêmement fins de marquage d’adresses, de suivi et d’évaluation des risques.
Au cours des dernières années, ces mécanismes ont effectivement permis le bon fonctionnement de l’ensemble de l’industrie Web3. Ils ne sont pas de simples apparences : ils ont une valeur concrète. Mais attention : il y a une différence de logique de fond, extrêmement mortelle, cachée derrière tout cela.
2. Ne vous faites pas avoir : aujourd’hui, la conformité n’est qu’un “outil de patch”, pas une “infrastructure”
Une fois que vous avez clarifié toutes les méthodes de conformité mentionnées ci-dessus, vous vous sentirez soudain refroidis. Car toutes ces solutions relèvent de la couche “outil”, aucune n’est une solution de la couche “infrastructure” !
La différence entre outil et infrastructure n’est absolument pas un détail technique sans importance : c’est un monde d’écart au niveau de la structure de confiance.
Le résultat des outils, c’est “pour les humains” :
Un logiciel de surveillance hors chaîne produit un long rapport de risques, et l’équipe de conformité le lit au bureau. Ensuite, l’humain prend une décision selon l’expérience, puis passe à l’action manuellement. Dans cette longue chaîne, chaque étape nécessite une intervention humaine, chaque étape implique un délai, et surtout : chaque étape peut être contournée. La couche d’exécution des smart contracts de base ne sait même pas, et ne se soucie pas du tout, de ce que vous avez vérifié hors chaîne.
Le résultat de l’infrastructure, c’est “les prérequis que la couche d’exécution doit respecter” :
C’est un peu comme les smart contracts eux-mêmes : le code s’exécute directement dans l’EVM, sans qu’aucune personne ne doive décider “est-ce que ce code doit s’exécuter aujourd’hui ou non”. Les oracles, c’est pareil : les données sont injectées directement dans le contrat, sans vérification humaine, pour savoir si ce prix est bon. Le mécanisme lui-même garantit la confiance et l’irréversibilité.
En une phrase : vous ne pourrez jamais contourner l’infrastructure, mais vous pouvez toujours contourner les outils.
Prenons une analogie très concrète : supposons qu’une grande institution financière traditionnelle veuille participer à un produit de tokenisation des bons du Trésor on-chain (RWA). Selon la réglementation, elle doit vérifier l’identité éligible des investisseurs (KYC), confirmer que l’origine des fonds est propre, et aussi s’assurer que les opérations respectent les limites de taux de conformité.
Dans le cadre technique actuel, comment tout le monde s’y prend ?
1. L’utilisateur fait le KYC sur l’interface front-end ;
2. Vérification du contexte en dehors de la chaîne ;
3. Les administrateurs de contrat examinent manuellement en arrière-plan ;
4. Autorisation finale manuelle pour libérer la transaction.
Vous avez repéré le problème ? Tout ce flux est fragmenté, manuel, et ne produit aucune preuve cryptographique vérifiable on-chain. Si un hacker, ou un investisseur malin, contourne votre page web front-end et appelle directement, via du code, le smart contract de la couche inférieure, alors toutes les vérifications de conformité que vous aviez configurées dans le front-end s’annulent instantanément !
Ce n’est pas parce que Chainalysis ou un outil de conformité quelconque n’est pas assez bon : c’est parce que, dans l’ensemble de l’écosystème Web3, il n’y a jamais eu de couche d’infrastructure de conformité qui soit à la fois “exécution avant le règlement”, “fonctionnement décentralisé”, et capable de produire des preuves cryptographiques.
Ce siège, si crucial, est resté vide pendant quinze ans. Et Newton Protocol, avec Newton Mainnet Beta, vise précisément ce siège vide.
3. Comment Newton Mainnet Beta casse réellement les verrous “sans faire semblant” ?
En plaçant Newton Mainnet Beta dans ce cadre d’observation, tout devient incroyablement clair : il doit mettre fin totalement à l’ère de la “conformité manuelle”, et transformer la vérification de conformité en un élément d’infrastructure on-chain. En le mettant au même niveau que les smart contracts et les oracles, il devient une “porte anti-vol” obligatoire, que tout actif on-chain doit franchir avant le règlement.
Pour que tout le monde comprenne, nous avons décomposé le fonctionnement interne de Newton Mainnet Beta en quatre étapes extrêmement “hardcore” et pourtant très élégantes :
1. Capture de l’intention et modularisation de la stratégie (langage Rego + IPFS)
Lorsqu’une application ou un utilisateur soumet une transaction, cette transaction ne va pas directement se jeter dans la couche de règlement du réseau public. Au lieu de cela, elle envoie d’abord son intention d’opération au réseau d’opérateurs décentralisé de Newton (Operator Network). Sur Newton, les règles de conformité ne sont plus une pile de tableaux manuels et désordonnés : elles sont écrites dans le langage Rego, extrêmement rigoureux, sous forme de modules dynamiques composables. Ces modules de conformité existent sur IPFS grâce à la technologie d’adressage par contenu. Cela signifie que n’importe quel protocole on-chain (qu’il s’agisse de prêt, d’un DEX ou de RWA) peut appeler ces modules comme des blocs de construction, sans avoir à reconstruire toute la logique de conformité depuis zéro.
2. Bac à sable de sécurité et liaison en temps réel avec des données faisant autorité (plugins WASM)
Après avoir reçu l’intention, le réseau de l’opérateur fait immédiatement appel aux données en temps réel les plus faisant autorité. Newton a déjà connecté tous les “gros pontes” de l’écosystème : Chainalysis et Hexagate fournissent les listes de sanctions et les données de risque liées aux hackers les plus récentes ; RedStone alimente des données de prix précises ; Credora fournit une évaluation de la crédibilité on-chain. Le plus impressionnant, c’est que ces flux de données sensibles fonctionnent tous sous forme de plugins WASM, dans un bac à sable de sécurité totalement isolé. Toute force extérieure ne peut pas falsifier ce processus d’évaluation, garantissant ainsi des données absolument natives et pures.
3. Liaison cryptographique et interception avant le règlement (signature agrégée BLS)
Une fois l’évaluation terminée dans le bac à sable, le réseau Newton produit un résultat clair (acceptation ou rejet). Ce résultat est transformé en une preuve cryptographique lourde de sens — une signature agrégée BLS. Cette preuve est directement publiée on-chain et solidement liée à l’opération concernée. Avant l’exécution et le règlement finaux, le smart contract cible de la couche inférieure impose une vérification de cette preuve BLS. S’il n’y a pas de preuve, ou si la preuve indique que la conformité n’est pas validée, le smart contract refuse directement d’exécuter. C’est cela, le véritable “contrôle avant le règlement” : même en contournant le front-end, le hacker ne peut rien y faire, car les contrats de la couche inférieure ne reconnaissent que la preuve cryptographique de Newton.
4. Sécurité économique et mécanismes de pénalisation (EigenLayer + défi ZK)
Alors, comment garantir que le réseau d’opérateurs décentralisé de Newton ne commettra pas de mal et ne laissera pas tout passer en vert sans contrôle ? Newton introduit directement le réseau d’indexation économique (economic staking) d’EigenLayer. Les opérateurs doivent engager une somme considérable d’argent réel. Dès qu’un opérateur fournit une preuve erronée ou une preuve fabriquée pour contourner la conformité, n’importe qui dans le réseau peut lancer un défi via un mécanisme ZK (preuves à connaissance zéro) pour dénoncer publiquement. Une fois la malveillance prouvée, les actifs mis en jeu par l’opérateur malveillant sont instantanément confisqués (Slash). Ce modèle de confiance est entièrement isomorphe aux smart contracts de couche de base d’Ethereum et aux oracles décentralisés : il ne dépend d’aucune personne “bonne” unique, mais seulement des mathématiques, de la cryptographie et d’une sanction économique impitoyable.
4. Le bon moment, le bon endroit : l’intersection parfaite entre la tempête réglementaire et l’évolution technologique
En parlant de ça, certains se demandent peut-être : “Pourquoi personne n’est sorti faire cette infrastructure ces premières années, et pourquoi justement maintenant ?”
Il faut alors parler du “moment opportun” au niveau macro. Dans le passé, Web3 était à l’époque des geeks en mode croissance sauvage : tout le monde prenait la conformité de haut. Mais aujourd’hui, l’environnement global de régulation internationale a complètement changé de fond en comble :
Aux États-Unis, le GENIUS Act est désormais officiellement en place. Il exige clairement que les émetteurs de stablecoins disposent d’une capacité de contrôle de conformité “exécutable et intervenable à l’avance”, plutôt que de se contenter de patchs après coup.
Le plan MiCA de l’Europe met en place un cadre complet de régulation des crypto-actifs couvrant l’ensemble de l’Europe.
Le GAFI (Groupe d’action financière) fait avancer avec fermeté, à l’échelle mondiale, l’application du Travel Rule (règle relative aux transferts de fonds).
Vous voyez, ce que les autorités de régulation veulent aujourd’hui, c’est exactement ce que Newton a discrètement mis en place au niveau technique : exécuter avant le règlement, fournir des preuves cryptographiquement vérifiables, et conserver des journaux d’audit immuables et infalsifiables.
Dans l’histoire de l’industrie, l’orientation macro des régulations et l’orientation technologique de base de Web3 ont, pour la première fois, pointé aussi précisément vers le même point de coordonnées. C’est aussi la raison profonde pour laquelle le lancement de Newton Mainnet Beta a attiré autant d’attention des “anciens” de l’industrie.
5. La logique d’accumulation de valeur liée à $NEWT : outil VS infrastructure
Enfin, comme point de chute pour nos discussions en privé, parlons quand même des jetons et de la logique de valeur. Il faut comprendre que la logique d’accumulation de richesse entre les projets d’infrastructure et les projets d’outils est radicalement différente.
Le modèle “outil” est “à la séance/paiement à l’usage” : combien de personnes l’utilisent aujourd’hui, autant de frais ils peuvent gagner ; sa courbe de valeur est linéaire, et il est difficile de créer un impact explosif à l’échelle d’une nouvelle ère.
Les projets d’infrastructure misent sur une “efficacité de réseau” terrifiante et une “douves/citadelles” d’écosystème.
À l’heure actuelle, nous pouvons surveiller de près deux indicateurs clés :
1. Le nombre réel de protocoles qui s’intègrent à la couche de conformité de Newton.
2. L’ampleur réelle des actifs que ces protocoles gèrent.
Si, dans les prochains mois, de grandes institutions financières traditionnelles — ou des émetteurs de stablecoins reconnus par la réglementation — terminent une véritable intégration métier sur Newton Mainnet Beta, alors pas besoin de plus : cela signifie que le volant d’inertie (flywheel) de l’infrastructure s’est bel et bien verrouillé on-chain. À ce moment-là, ce sera le moment d’or pour être “optimiste à fond” et suivre avec détermination. D’ici là, il faut rester très attentif, observer le plus finement possible et garder une position de base (core holding) pour ressentir la densité d’information la plus à la pointe du secteur : c’est la stratégie la plus sûre.
Il aura fallu quinze ans à toute l’infrastructure on-chain pour construire entièrement, et de bout en bout, la couche d’exécution et la couche de données. Quant à la couche de conformité — ce “boulot manuel” entretenu jusqu’ici par des humains et des outils grossiers — elle est enfin en train d’être normalisée “hardcore” par Newton Mainnet Beta, via du code pur et de la cryptographie.
Est-ce qu’on peut mener cette voie jusqu’au bout, complètement ? Ce n’est pas seulement un problème technique : c’est la bataille clé pour savoir si tout Web3 peut accueillir l’entrée de dizaines de milliers de milliards d’actifs financiers traditionnels.
Les frères, dans vos opérations quotidiennes on-chain ou dans le développement de projets, est-ce que vous avez vraiment ressenti ce besoin urgent d’une “infrastructure de conformité native on-chain” ? Si vous deviez gérer au quotidien des questions aussi délicates de conformité et de frontières de sécurité, comment est-ce que vous vous y prenez habituellement ? Commentez ici, parlons-en tous ensemble et échangeons en profondeur !
(Cet article est une mission de plateforme et ne constitue aucun conseil en investissement.)
