Crypto _Mars

Il y a eu un moment où je croyais vraiment que si nous pouvions simplement voir les problèmes assez clairement et assez rapidement, nous finirions par devenir bons pour les gérer. Je me souviens avoir fixé des tableaux de bord pendant des dépegs et des liquidations, en les actualisant comme s’ils pouvaient changer ce qui était déjà en train de se produire. Les données étaient là. Les avertissements clignotaient. Et pourtant, l’argent a bougé quand même.
Cette expérience est restée gravée en moi. Avec le temps, j’ai commencé à remarquer un schéma qui semblait plus grand que n’importe quel échec isolé. Dans la crypto, nous sommes devenus incroyablement doués pour construire des systèmes capables de nous montrer quand quelque chose allait mal. Mais nous n’avons jamais vraiment construit de systèmes capables de l’empêcher de se produire dès le départ. La plupart de ce que l’on appelle gestion du risque est en réalité de l’observation du risque : nous regardons, nous alertons, nous en discutons, puis nous essayons de nettoyer après coup.

For as long as I can remember, compliance has been treated like the villain in crypto.
It's the KYC form that interrupts you. The withdrawal that suddenly gets paused. The extra verification step that makes everything feel slower than it should. Somewhere along the way, we started treating compliance as the opposite of good user experience. Fast, permissionless, frictionless—that was the goal. Compliance was simply the price institutions wanted everyone else to pay.
But I don't think that's the real problem.
The issue was never that compliance existed. The issue was when it happened.
In traditional finance, a transaction often goes through first, and only later does someone decide whether it should have happened. Logs are reviewed. Documents are requested. A compliance team investigates after the fact. By then, the money has already moved, or worse, the transaction gets frozen without anyone understanding why.
That's why compliance feels frustrating. Not because checking rules is inherently slow, but because the people involved are always reacting to something that has already happened. Users are left wondering why their funds are pending. Institutions don't immediately know whether a counterparty meets their policies. Regulators are forced to reconstruct events instead of observing them as they unfold.
Maybe what we've been calling a compliance problem is really a visibility problem.
Now imagine something different.
Instead of adding compliance after execution, what if the rules became part of the transaction itself? A wallet is screened before settlement. A transfer limit is checked while the transaction is being processed. Every decision—approve, delay, or reject—is made in the same moment the transaction is executed.
That's the direction Newton Protocol is exploring.
What I find interesting isn't that the protocol can enforce rules. Plenty of systems can do that. What's different is that every policy check leaves behind a cryptographic receipt showing which rule was evaluated and what the outcome was. If a transaction is delayed, there is evidence explaining why. If it passes, there is proof that the required checks actually happened.
It reminds me less of a compliance department and more of tracking a package. You don't just hear that your order is "being processed." You can see every checkpoint along the way.
Privacy doesn't have to disappear either.
This is where zero-knowledge proofs become much more interesting than people often give them credit for. A protocol can prove that a rule was satisfied without revealing the personal information behind it. The network verifies the outcome without exposing the data itself.
That's an important shift.
We often talk about privacy and transparency as if they're competing goals, but cryptography increasingly suggests they don't have to be. Sometimes the most transparent system isn't the one that reveals everything. It's the one that can prove it followed the rules without exposing what never needed to be public in the first place.
This conversation is becoming increasingly relevant beyond crypto circles. Policymakers are beginning to ask whether digital financial systems can enforce identity and compliance requirements without sacrificing user privacy. That question is no longer theoretical. It's gradually becoming a requirement for bringing larger pools of institutional capital on-chain.
If that's where the industry is heading, then maybe the biggest user experience improvement won't be shaving another second off transaction speed.
Maybe it will be something much simpler.
Knowing why your transaction is pending.
Knowing why it was approved.
And being able to verify those answers yourself instead of trusting someone else's word.
Perhaps that's the point where compliance stops feeling like a barrier and starts feeling like part of the interface itself.
So maybe the better question isn't, "How do we make compliance less annoying?"
Maybe it's this:
What if the best user experience isn't one that asks you to trust the system—but one that lets you verify it for yourself?
$NEWT #Newt @NewtonProtocol
Do you think compliance and speed are really competing priorities, or can better infrastructure make both possible?

Puis-je être honnête une seconde ? Quand la plupart des projets disent avoir « de la confidentialité », j’ai appris à me méfier un peu. Pas parce que l’intention est mauvaise, mais parce que ce mot sert trop souvent à masquer un problème que la plupart des équipes n’ont en réalité pas résolu.
Voici le point que personne n’a envie d’admettre à voix haute : si vos données sont chiffrées et que vous devez les vérifier par rapport à une règle, comme une limite de dépenses, une liste de sanctions, etc., alors quelqu’un doit les déchiffrer d’abord. Il n’y a pas de moyen d’y échapper. Vous ne pouvez tout simplement pas effectuer un contrôle sur des données que vous ne pouvez pas lire.

Ne me comprenez pas mal, j’adore les agents IA intelligents, mais je ne les adore pas assez.Ne me comprenez pas mal, j’adore les agents IA intelligents, mais je ne les adore pas assez.
La semaine dernière, j’ai vu un agent d’arbitrage vider complètement son pool de collatéral en moins de 10 secondes, à cause d’une croyance selon laquelle l’oracle de prix alimentant le système était corrompu. Mais, après dix secondes, oui, après dix secondes, des mois de rendement capitalisé sont effacés. Ce n’était pas parce que l’intelligence artificielle était inintelligente. Le modèle était un réseau neuronal extrêmement complexe, capable de traiter des milliers de points de données par seconde. Non, parce que l’agent n’avait aucun contrôle sur les clés du portefeuille, ni aucune désincitation à commettre une erreur. Ce type avait un cerveau extrêmement rapide, mais sa cage était en papier. Notre communauté est fascinée par les bots depuis des années, et par l’idée de les rendre plus intelligents et plus indépendants. Cependant, je pense que c’est une distraction périlleuse pour nous alors que nous commençons 2026. L’agent IA non contraint, avec la clé privée, n’est pas une révolution dans le monde de la finance on-chain. C’est une bombe à retardement dans la poche financière de n’importe qui peut envoyer une requête qui la déclenche, ou un bot de front-running rusé.

J’ai vu un développeur transpirer à grosses gouttes dans sa chemise pendant une mise à niveau du mainnet en direct la semaine dernière, et ce n’était pas dû à une faille active. Il était simplement terrorisé par le slot zéro. Cela m’a fait réaliser à quel point nos systèmes immuables deviennent fragiles dès l’instant où l’on essaie de les modifier.
La DeFi regorge de protocoles qui détiennent des millions de dollars et qui ne peuvent pas simplement s’arrêter, effacer l’ardoise et recommencer. Ils doivent s’améliorer tout en restant en fonctionnement, c’est pourquoi le protocole Newton a suscité autant d’intérêt. Il propose un moyen d’intégrer une autorisation de pré-transaction directement dans un contrat existant via une mise à niveau par proxy. À première vue, c’est le rêve d’un développeur. Vous héritez de NewtonPolicyClient, connectez votre ancien contrat au moteur de politique, et soudain vous disposez de contrôles de risque dignes d’une institution. Mais en regardant de plus près, vous comprenez que les pièges les plus dangereux ne se trouvent pas dans la logique métier elle-même. Ils sont dissimulés dans les emplacements mémoire silencieux de la Machine Virtuelle Ethereum.

Hier, je regardais un contrat intelligent vider un compte sur un explorateur de blocs, et cela m’a laissé une question simple : que se passe-t-il quand la transaction est valide, mais que l’intention n’aurait jamais dû être approuvée à la base ?
Cette tension est facile à manquer dans la crypto. Les blockchains sont très douées pour le règlement. Elles sont moins bonnes en matière d’autorisation. Dans les paiements traditionnels, l’autorisation intervient avant que l’argent ne circule. En DeFi, les transactions signées vont souvent directement à l’exécution, ce qui signifie que le système peut faire exactement ce qui a été demandé, même lorsque ce qui a été demandé était dangereux.

Le protocole Newton est intéressant parce qu’il pose une question que beaucoup de projets DeFi cherchent à éviter : que se passe-t-il lorsque l’exécution « sans confiance » dépend encore d’entrées de confiance ?
D’après les propres documents de Newton, sa version bêta sur le mainnet est en ligne sur Base et Ethereum, et l’évaluation de la politique a lieu avant le règlement grâce à des opérateurs EigenLayer, des politiques basées sur Rego, des définitions de politiques stockées sur IPFS et une attestation BLS. Le protocole prend aussi en charge des ensembles d’oracles de données tels que Chainalysis, vaults.fyi, RedStone, Credora et Webacy. Techniquement, il s’agit donc d’un élément d’infrastructure sérieux. Mais, sur le plan philosophique, c’est aussi un changement : une partie de la confiance passe du code onchain pur vers la qualité, la fraîcheur et la gouvernance des sources de données hors chaîne.