Liam_Carter

En observant le graphique en chandeliers, je vois le Bitcoin dériver progressivement plus bas depuis son récent sommet — pourtant, la panique habituelle n’est pas là. Les marchés baissiers ont une façon de révéler qui est réellement engagé une fois que la liquidité facile disparaît. Ces derniers temps, les discussions autour du BTCFi ont repris de l’élan. Cela ne me paraît pas accidentel : le capital cherche activement des moyens plus sûrs de générer du rendement.
Une des pistes que j’ai examinées de près est l’approche de Babylon Labs. Ils ont construit quelque chose appelé TBV : le Bitcoin est verrouillé directement dans des scripts Taproot sur le mainnet Bitcoin. Pas de ponts, pas de tokens enveloppés. Des preuves cryptographiques permettent ensuite d’emprunter des stablecoins via Aave v4. Chaque UTXO reste indépendant, de sorte que le projet lui-même ne peut pas déplacer les fonds. Ce niveau de garde native apporte une vraie tranquillité d’esprit. Cela dit, je me demande si une garde on-chain aussi stricte pourrait limiter la liberté avec laquelle le capital peut circuler et être mis au travail.
Ensuite, j’ai regardé Hashi sur Sui. Leur modèle est presque l’opposé. Le Validator MPC combiné à un multisig Guardian conserve le BTC, émet le hBTC, et lui permet de circuler librement dans l’écosystème Sui. Les institutions apprécieront probablement la performance et la plus large gamme de cas d’usage. La question qui demeure pour moi est de savoir si un multisig plus MPC peut éliminer totalement le risque de centralisation. Je ne suis pas un expert technique approfondi, mais des hypothèses de confiance plus complexes signifient généralement davantage de points de défaillance potentiels.
Ainsi, deux directions claires se présentent à nous : l’une privilégie une garde native pure, l’autre la composabilité et la flexibilité. Je commence à penser qu’il n’y a pas de réponse unique — peut-être que la conception gagnante mélangera des éléments des deux. La question qui me paraît plus importante que le mouvement quotidien des prix est celle-ci : lorsqu’un véritable test de stress en marché baissier arrive, quel système montrera en premier des fissures ? Les preuves cryptographiques pures de TBV seront-elles plus résilientes, ou les contrôles de risque de niveau institutionnel de Hashi tiendront-ils mieux ? Cette réponse peut compter davantage que la prochaine bougie sur le graphique.
@BabylonLabs_io #baby $BABY

Lorsque le réseau testnet TBV de Babylon Labs a été lancé, un détail revenait sans cesse : une seule transaction Bitcoin peut contenir jusqu’à 10 sorties HTLC.

À première vue, cela ressemble à une simple astuce pour économiser des frais. Mais ce serait passer à côté de l’essentiel.

Ce n’est pas une question de mettre les BTC de 10 utilisateurs dans une seule réserve partagée. Chaque sortie appartient toujours à un Vault distinct, adossé à son propre UTXO, sa propre structure de transaction pré-signée et sa propre route de retrait. Dix sorties HTLC ne constituent pas un seul coffre-fort collectif : ce sont dix coffres-forts indépendants placés dans la même boîte d’expédition. Le transport est plus efficace, mais le modèle de sécurité reste séparé.

L’idée clé est la suivante : l’efficacité peut être regroupée, pas le risque.

Même si le groupage réduit les coûts, il ne réduit pas la charge opérationnelle. Lors de la mise en place, le fournisseur du Vault (VP) doit toujours recueillir les signatures de tous les participants et soumettre le batch à Ethereum. Si le VP passe hors ligne, les utilisateurs peuvent toujours récupérer les signatures nécessaires depuis la chaîne pour finaliser un PegIn. Et si le VP ne coopère pas pendant le rachat, les utilisateurs restent dépendants de leurs propres clés WOTS et de leurs données de réclamation pour reprendre le contrôle eux-mêmes.

Ainsi, le batching comprime les frais, mais pas le flux de sécurité.

Une meilleure analogie consiste à considérer plusieurs contrats d’assurance expédiés dans un même colis : la livraison devient moins chère, mais l’instruction, la signature et les réclamations pour chaque police restent entièrement séparées. Un colis fusionné ne signifie pas une couverture partagée.

C’est pourquoi, après le lancement du mainnet de Babylon, je me soucie moins du montant des frais économisés et davantage de trois signaux concrets : la répartition des tailles de batch, la fréquence à laquelle les signatures sont complétées de bout en bout, et la rapidité avec laquelle les utilisateurs peuvent se récupérer eux-mêmes lorsque le VP est indisponible. Ce sont ces chiffres qui montrent si cette conception « groupée, pas mise en commun » mérite réellement sa place.

La technologie peut optimiser le coût. La sécurité, elle, refuse les remises de groupe.
@BabylonLabs_io #baby $BABY

#baby $BABY @BabylonLabs_io

Plus tôt aujourd’hui, je discutais avec des amis de @BabylonLabs_io, et un point n’arrêtait pas de me travailler : toutes les “trésoreries” ne sont pas la même chose.

Un vault DeFi classique est essentiellement une réserve partagée. Beaucoup d’utilisateurs déposent dans un seul contrat, et les rendements comme les risques sont répartis dans le même “panier”.

Le modèle de trésorerie de TBV est différent. Chaque trésorerie est son propre UTXO isolé, avec un ensemble prédéfini de parcours de retrait pré-signés. Les trésoreries ne fusionnent pas en une réserve partagée, et elles ne se mélangent pas entre elles. La structure ressemble davantage à une boîte de dépôt individuelle qu’à un fonds communal.

Une autre différence clé : le contrat du protocole lui-même ne peut pas déplacer le BTC hors du script. Il ne peut pas le prêter, le réutiliser ou le rediriger ailleurs. Cela signifie que les actifs ne peuvent pas être remis en jeu (re-stakés). Dans beaucoup de produits “dépôt-et-rendement”, il faut faire confiance à la plateforme pour ne pas utiliser vos fonds à d’autres fins. Avec TBV, cette limite est appliquée au niveau du script. Ce n’est pas seulement une promesse : c’est intégré à la conception.

Pour des montants plus importants, je préfère personnellement ce modèle isolé à celui d’une réserve partagée. Cela rend le risque de baisse maximal plus facile à comprendre. Cela dit, je n’ai pas encore vu publiquement des détails de script Taproot ni des rapports d’audit pour chaque trésorerie individuelle, donc cette partie reste floue.

Avant de déposer dans quelque chose appelé une “trésorerie”, je pense que la première question devrait être simple : s’agit-il d’une structure isolée, ou simplement d’un fonds commun partagé avec une étiquette différente ?

#baby $BABY
Je viens d’être brutalement réveillé par une alerte serveur à propos d’une explosion. Mon écran était encore à moitié flou quand j’ai ouvert le groupe de discussion et vu quelqu’un déposer un tableau comparatif de modèles de confiance TBV. Dix minutes à fixer l’écran plus tard, j’étais bien réveillé.
@BabylonLabs_io
Je pensais avant que les ponts inter-chaînes se présentaient essentiellement sous deux formes : centralisés ou décentralisés. Choisis la version la plus décentralisée et tu es en gros en sécurité. Ce tableau a tué cette idée. Même une conception « décentralisée » de nouvelle génération comme un pont BitVM oblige encore Bob à dépendre d’un comité de signatures 1-of-n, d’un ensemble d’opérateurs 1-of-m, et d’au moins un challenger actif, tous travaillant ensemble. Cassez n’importe quel maillon et les fonds peuvent simplement rester là, bloqués.
Les coffres Bitcoin trustless sont un autre animal. Dès le moment où le coffre est créé, il est déjà cosigné par Bob et Larry. Il n’y a aucun rôle de tiers. Les retraits ne nécessitent de faire confiance à personne.
Ces trois rôles — opérateurs, comité de signatures, challenger — n’ont pas été « supprimés » à l’optimisation de la conception. Ils n’étaient pas censés exister dès le départ.
La différence devient encore plus claire dans le prêt. Avec une configuration DLC, Larry peut simplement refuser de remettre le secret de remboursement et bloquer la rédemption de Bob — le problème classique de l’option gratuite. Avec TBV, les conditions de rédemption sont de pures preuves cryptographiques. Personne n’a besoin de « donner la permission ».
Personnellement, je ne tourne encore que sur de petites quantités en testnet. Le capital principal n’a pas bougé. Je n’ai pas non plus trouvé de documentation claire sur la façon exacte dont le seuil multi-sig k-of-n est fixé. La version officielle est « la gouvernance décide », mais les détails concrets ne sont toujours pas publics.
Donc la vraie question : accepterais-tu d’échanger la liquidité instantanée d’un pont contre la suppression d’une couche supplémentaire de confiance ?

J’ai passé la moitié de la nuit à parcourir le livre blanc de @BabylonLabs_io et à recouper les chiffres de coûts on-chain pour les deux configurations BitVM2 et BitVM3. Plus je creusais, plus quelque chose ne collait pas.
La plupart des gens traitent le « pont Bitcoin » et le « coffre Bitcoin » comme s’il s’agissait essentiellement de la même chose, avec seulement des hypothèses de sécurité différentes. Mais une fois qu’on entre dans les détails, ce sont fondamentalement deux conceptions distinctes. Un pont émet des BTC enveloppés remplaçables que n’importe qui peut réclamer : il doit donc s’appuyer sur un ensemble complet d’opérateurs, de comités de signatures, de challengers, et le reste, pour que les remboursements restent solvables. Un coffre, au contraire, verrouille les fonds dès le départ vers deux adresses prédéterminées (pensez à l’emprunteur et au prêteur). Ces rôles supplémentaires ne sont tout simplement pas requis.
Les chiffres rendent la différence encore plus nette. Dans la première approche BitVM2, le coût on-chain mesuré pour vérifier une seule preuve ZK dépassait les 15 000 $. Avec BitVM3, la même affaire contestée chute à environ 93 $, tandis qu’un dépôt ou un retrait normal et non contesté peut coûter aussi peu que 2,66 $. On parle d’une réduction d’environ 170× — ce n’est pas un simple ajustement de paramètre, mais un changement d’approche complet. Ce qui consistait autrefois à « tout révéler on-chain à travers un secret » devient un jeu de théorie des jeux en dehors de la chaîne à l’intérieur d’un circuit mixte. La confiance on-chain passe de trois parties à deux.
En ce moment, je lance une petite position sur un testnet surtout pour observer le comportement de la time-lock sur le chemin de contestation. L’affirmation selon laquelle le stockage hors chaîne coûte environ 1 $ par mois ne vient que des documents officiels ; je n’ai pas encore trouvé de source indépendante pour le confirmer.
Quand vous examinez les coûts on-chain dans la pratique quotidienne, vous ne regardez que les chiffres du parcours “heureux”, ou vous intégrez aussi les scénarios extrêmes ?@BabylonLabs_io #baby $BABY

« Le fait que les utilisateurs contrôlent directement le rachat » est rassurant — jusqu’au moment où l’autre partie refuse simplement de coopérer.
Je me suis retrouvé bloqué sur une section du livre blanc TBV de @BabylonLabs_io qui affirme que « les coffres sans confiance éliminent totalement les opérateurs ». La conception donne à deux parties prédéfinies une autorité directe sur le rachat. Aucun opérateur intermédiaire n’est requis. Cela supprime clairement le risque classique d’un tiers qui vidangerait des fonds.
Ça résout le problème du vol. Mais qu’en est-il de la vivacité ?
Le livre blanc oppose les coffres sans confiance au pont BitVM. Dans le modèle BitVM, un opérateur doit relayer la transaction de rachat ; si cet opérateur devient malveillant, les fonds peuvent être mis en danger. TBV, lui, permet aux deux contreparties de détenir elles-mêmes les clés de rachat. La cryptographie garantit que, tant que les scripts sont correctement écrits, aucune des deux parties ne peut s’emparer de BTC qui ne lui appartient pas. La sécurité est solide : personne ne peut récupérer de force ce qui appartient à quelqu’un d’autre.
La sécurité, toutefois, n’est pas la même chose que la vivacité. Si le déblocage des fonds nécessite que la contrepartie signe ou qu’elle exécute une étape, et que cette partie se met hors ligne, disparaît ou refuse simplement de coopérer, les pièces peuvent rester bloquées. Le livre blanc insiste sur le fait que « personne ne peut voler votre argent », mais il n’explique pas clairement ce qui se passe quand l’autre partie ne parvient pas à agir. La protection contre le vol ne protège pas automatiquement contre le gel des fonds.
Le mot « sans confiance » pousse souvent les gens à ne se concentrer que sur les garanties anti-vol, tout en négligeant les risques de liquidité et de disponibilité — qui font pourtant partie de la sécurité réelle des actifs.
Mon avis : TBV fait un excellent travail pour empêcher le vol pur et simple. Mais lorsque l’on évalue toute conception de contrepartie à deux parties dans DeFi, deux questions distinctes doivent être posées :
L’argent peut-il être volé ?
L’argent peut-il rester bloqué de façon permanente ?
Ce sont deux dimensions de risque indépendantes. Comprendre cette distinction est essentiel pour appréhender le véritable modèle de sécurité de $BABY — plutôt que d’être guidé uniquement par le sens superficiel de « sans confiance ».
#baby $BABY @BabylonLabs_io

#baby $BABY En parcourant les documents de Babylon hier soir, je me suis arrêté à la page sur les hypothèses de sécurité. Tout le monde s’exclame : « Rendez Bitcoin natif compatible avec DeFi », mais une question plus pratique m’a frappé : une fois que votre BTC est verrouillé dans un script Taproot, que devez-vous faire concrètement pour le récupérer ?

La désunbonding n’est pas simple. Vous pouvez attendre la durée complète du timelock d’environ ~64 000 blocs (environ 15 mois), ou procéder à une désunbonding active — ce qui exige que le Covenant Committee donne son accord, puis qu’une seconde période de blocage soit respectée. EOTS le précise : si un Finality Provider double-sign à la même hauteur, la clé est divulguée et votre mise peut encore être slashée pendant cette fenêtre de désunbonding. Ainsi, sortir relève d’une fenêtre temporelle encadrée par les règles du protocole, et non d’un simple retrait quand vous le souhaitez.

La liquidation TBV est aussi intéressante. Vous empruntez contre votre BTC sans renoncer à la garde ; chaque Vault correspond à son propre UTXO indépendant. Lors d’un événement de liquidation, le liquidateur règle instantanément en utilisant du WBTC, mais le BTC natif ne devient remboursable qu’après le passage de la fenêtre de « fraud-proof ». Cela découpe la chronologie : l’arbitragiste doit d’abord avancer le WBTC, en absorbant les variations de prix et les coûts de financement. Je n’ai pas trouvé de réponse claire sur la question de savoir si la volonté de fournir cette liquidité initiale s’effondre quand la volatilité explose.

La philosophie de Babylon conserve le contrôle ultime avec Bitcoin lui-même. La feuille de route est claire : la phase 1 se concentre sur un développement centré sur Bitcoin, la phase 2 passe à Cosmos, la phase 3 apporte le staking multi-actifs. Mais les utilisateurs doivent intégrer que le slashing est réel, et accepter les retards de sortie fait partie du compromis ; il y a une courbe d’apprentissage objective.

Quand vous évaluez des projets, creusez-vous autant les mécanismes de sortie et de liquidation ? J’aimerais savoir si vous allez aussi aussi loin — laissez un commentaire.@BabylonLabs_io
$LAB

#baby $BABY J’ai vu chaque cycle de marché inventer une nouvelle raison de pousser Bitcoin au-delà de ce pour quoi il a été conçu.
J’ai assez d’expérience pour me rappeler l’époque où presque un projet sur deux promettait qu’il allait « débloquer la liquidité en BTC ». La plupart suivaient le même schéma : des tokens enveloppés, des dépositaires de confiance, des ponts qui finissaient discrètement par devenir l’unique point de défaillance, et des communautés qui traitaient la complexité inutile comme un progrès.
Babylon a su se démarquer pour une raison que je n’avais pas anticipée. Pas parce qu’il proposait du rendement — la crypto n’a jamais manqué de promesses. Il se distingue plutôt parce qu’il part d’un fait inconfortable : des trillions de dollars en Bitcoin restent largement inactifs pendant que de nouvelles chaînes passent des années à essayer d’emprunter sa crédibilité.
Je ne suis toujours pas sûr que ce problème doive être résolu.
Il y a quelque chose d’étrange à regarder Bitcoin — l’actif construit sur une retenue délibérée — devenir progressivement une garantie pour presque tout le reste. L’aking en auto-conservation semble plus propre que les modèles précédents. Pas de ponts, pas d’abandon des clés privées, pas de conversion des coins dans des formes inconnues. Pourtant, j’en ai vu assez de systèmes qualifiés de « trustless » accumuler lentement des hypothèses de confiance au fil du temps.
Mais celui-ci semble différent.
Peut-être parce que Babylon ne cherche pas à me persuader que Bitcoin lui-même doit changer. On dirait plutôt que le reste de la crypto finit enfin par admettre qu’il a encore besoin de Bitcoin.
Après toutes ces années, c’est peut-être la chose la plus honnête que ce marché ait dite depuis longtemps.@BabylonLabs_io 😀

#baby $BABY Veuillez appuyer et maintenir l’URL pour la copier, puis utiliser le navigateur pour l’ouvrir si vous souhaitez la consulter.

#newt $NEWT @NewtonProtocol
Cet après-midi au bureau, je lisais la documentation technique du protocole Newton, et un passage m’a vraiment interpellé : le « pipeline double voie TEE + ZKP ». Sur le papier, cela paraît vraiment intelligent.

L’idée de base est assez logique. Le TEE est conçu pour exécuter rapidement des opérations hors chaîne, tandis que le ZKP transforme le résultat en une preuve pouvant être vérifiée sur la chaîne. Au lieu de demander aux gens de simplement faire confiance au calcul, le système essaie de le rendre mathématiquement vérifiable. Cette partie est élégante, et je comprends pourquoi cette conception attire l’attention.

Mais dès qu’on dépasse le concept pour regarder les limites pratiques, certains sujets commencent à se poser.

Le principal problème, c’est la génération de preuve. Les preuves ZKP ne sont pas bon marché à produire, et rien que cela peut ralentir le processus. HTX Research note également que le modèle « TEE + ZKP » pourrait rencontrer des goulots d’étranglement de performance et une dépendance au matériel. Le Prover Core de Newton prend en charge des zkVM comme Risc0 et SP1, mais cela n’efface pas le fait que la preuve reste gourmande en ressources. Si de nombreux agents fonctionnent en même temps, la congestion et les retards semblent quasiment inévitables. Pourtant, le livre blanc n’explique pas clairement comment le système prévoit de gérer la production de preuves en parallèle à grande échelle.

Il y a ensuite la question du matériel. Les TEE reposent sur du matériel de type enclave sécurisée, et le travail des validateurs ou de vérification nécessite souvent des machines puissantes. Autrement dit, la barre n’est pas vraiment basse. Avec le temps, cela peut faire pencher la participation davantage vers des institutions plutôt que vers des utilisateurs ordinaires. Gat souligne aussi que la pile (stack) du protocole est complexe et que le déploiement stable fait encore face à de vrais défis techniques.

Donc oui, l’architecture est élégante. Mais si la décentralisation dépend d’un matériel coûteux et d’un petit nombre d’opérateurs très puissants, à quel point est-elle réellement décentralisée dans la pratique ?

Simple avis personnel, pas un conseil en investissement.
$LAB

#newt $NEWT @NewtonProtocol

Le livre blanc de Newton présente son mécanisme de litige comme un sentinelle non protégée : tout le monde peut signaler un problème sans inscription préalable, en délivrant, selon lui, une responsabilisation portée par la communauté. Mais sous l’argumentaire marketing, les chiffres dressent un tout autre tableau.

Chaque objection exige une réexécution complète du moteur de politique Rego dans une machine virtuelle à connaissance nulle. Le document célèbre cela comme un progrès technique, mais l’innovation n’efface pas le coût opérationnel. Un contestataire débouté repart les mains vides ; un contestataire victorieux ne récupère qu’une fraction du collatéral saisi, tout en supportant de lourdes dépenses liées à la génération de preuves. Ce calcul crie une structure à forts enjeux et faibles marges : elle prive les observateurs occasionnels et nourrit en silence une classe professionnelle de chasseurs de primes.

Reste ensuite le rôle non résolu du $NEWT token. Si le protocole oblige les contestataires à immobiliser des tokens avant d’agir, l’ensemble devient une salle d’audience avec droit d’entrée, où seuls les mieux dotés peuvent plaider, et où de gros moyens peuvent submerger des participants honnêtes par le simple poids du jalonnement. Si aucune mise n’est requise, le système invite alors une vague de contestations malveillantes et sans coût, susceptibles de paralyser purement et simplement la vérification. Aucun des deux scénarios ne fournit l’oversight égalitaire que le protocole promet. L’économie des tokens est au cœur de la crédibilité du mécanisme, mais le livre blanc la maintient dans le flou.

Les preuves mathématiques peuvent éliminer le besoin de faire aveuglément confiance, mais elles ne paient pas les factures d’électricité. L’énigme des incitations manque encore de pièces essentielles. La fenêtre de contestation risque de devenir un élément décoratif : ouverte en théorie, mais quasiment inaccessible aux utilisateurs du quotidien. La vraie question n’est pas de savoir si le code peut s’auto-vérifier ; c’est qui peut réellement se permettre d’appuyer sur « soumettre ». Sans des incitations cohérentes et équilibrées, la fonction de litige ne mobilisera pas une armée de citoyens. Elle se transformera silencieusement en outil d’abonnement pour des boutiques d’audit et des fournisseurs de liquidité — un théâtre décentralisé plutôt qu’une justice décentralisée.
$LAB

#newt $NEWT Sur une liste vérifiée d’un seul nœud @NewtonProtocol , chaque opérateur est totalement anonyme. Ce que vous voyez on-chain ne sont que des adresses hexadécimales, suivies de montants mis en jeu, de totaux de production de blocs et de pourcentages de disponibilité. Il n’y a aucun nom d’organisation, aucun profil d’équipe, aucun lien de site web—rien qui révèle si l’entité derrière l’adresse est une entreprise, un particulier ou un simple fantôme. J’ai passé des heures à retracer les historiques d’interaction, dans l’espoir de relier ces adresses à des portefeuilles connus, à des schémas de transaction ou à des empreintes de fuseau horaire. Sans résultat. Chaque adresse semblait fraîchement créée, sans empreinte inter-chaînes et sans trace de vérification d’identité. Un opérateur malveillant peut disparaître du jour au lendemain, générer une nouvelle adresse et continuer à faire tourner des nœuds sans jamais être rattaché à des comportements passés. Ici, l’anonymat est un bouclier parfait pour les acteurs malveillants.

Cette anonymité rend la délégation semblable à un pari à l’aveugle. Lorsque vous misez vos jetons, vous ne savez pas réellement qui contrôle le validateur. Dans la finance traditionnelle, vous connaissez le nom du gestionnaire de fonds, son historique et sa conformité réglementaire—et s’il se passe quelque chose, il y a quelqu’un à tenir responsable. Ici, vous n’avez qu’une adresse. Si un nœud augmente secrètement sa commission ou s’entend avec d’autres pour manipuler les récompenses, vous n’avez pas de visage à confronter.

Pire, ces opérateurs anonymes peuvent modifier à tout moment leurs taux de commission, sans préavis. Vous pourriez déléguer à 10%, puis constater qu’elle passe à 20% le lendemain. Votre seule option est de vous désengager et de refaire un stake ailleurs, en perdant des gains potentiels pendant la période d’attente. Les opérateurs savent que ce changement vous coûte, alors ils l’exploitent. J’ai vu une plainte de la communauté où les commissions d’un nœud sont passées de 12% à 22% sans aucune alerte. La réponse d’un administrateur était simplement : « Les nœuds ont le droit d’ajuster indépendamment leur taux de commission. » C’est la règle—aux délégateurs particuliers d’y souscrire. Sans identité, sans réputation ni responsabilité, ce qui devrait être un système de staking fondé sur la confiance ressemble plutôt à une loterie à haut risque, où vous ne savez même pas qui dirige la roue

Il y a quelques mois, je m’asseyais sur un banc dans un parc, en regardant à moitié un groupe d’enfants jouer au football pendant que je triais mes propres pensées. J’étais dans la crypto assez longtemps pour remarquer un schéma que l’on n’évoque pas beaucoup. Ce n’est ni les arnaques, ni les krachs. C’est l’abandon discret. Les développeurs qui disparaissent, non pas parce qu’ils ont manqué d’argent, mais parce qu’ils ont perdu la foi dans le fait que l’environnement les traiterait un jour équitablement.

Je les ai rencontrés lors de hackathons, dans des groupes Telegram, aux abords de conférences. Ils construisaient des choses ingénieuses. Des stratégies automatisées, des modèles de trading, des outils qui fonctionnaient à merveille en vase clos. Mais dès qu’il fallait les déployer on-chain, la table penchait trop. Les prix du gaz engloutissaient leurs marges. Les observateurs du mempool copiaient leurs mouvements. Garder la logique privée signifiait faire confiance à un seul serveur, ce qui annulait l’idée même. Alors ils ont arrêté. Sans annonce. Juste un carnet qu’on referme, un dépôt archivé, un esprit qui passe à autre chose.

Newton Protocol a fait remonter ce souvenir à la surface. C’est un rollup conçu pour des stratégies de trading pilotées par l’IA, avec un marché où les développeurs peuvent déployer des modèles avec exécution vérifiable et une vraie confidentialité. Pas de promesses d’AGI. Pas de révolution. Juste un bac à sable pour ce type de travail qui finit d’ordinaire abandonné dans un tiroir.

Mon observation est simple. Nous dépensons tellement d’énergie à courir après la prochaine grande narration que nous oublions toutes les petites idées prometteuses que nous avons déjà enterrées. Peut-être que la vraie percée n’est pas une chaîne plus rapide ou une oracle plus intelligente. Peut-être que c’est simplement une table plus juste, celle qui donne envie à un développeur épuisé de lever les yeux depuis un banc de parc et de retenter sa chance. Je ne sais pas si Newton est cette table. Mais je prête attention à quiconque essaie d’en construire une.

@NewtonProtocol #newt $NEWT

#newt $NEWT @NewtonProtocol

Il y a quelques mois, je m’étais assis sur un banc dans un parc, à moitié en train de regarder un groupe d’enfants jouer au football, pendant que je démêlais mes propres pensées. J’avais passé assez de temps dans la crypto pour remarquer un schéma dont on ne parle presque jamais. Ce n’est ni les arnaques, ni les krachs. C’est l’abandon silencieux. Les développeurs qui disparaissent, non parce qu’ils ont manqué d’argent, mais parce qu’ils ont perdu la foi dans le fait que cet environnement les traiterait un jour de façon équitable.

Je les ai rencontrés dans des hackathons, dans des groupes Telegram, au bord des conférences. Ils avaient construit des choses ingénieuses. Des stratégies automatisées, des modèles de trading, des outils qui fonctionnaient à merveille, isolés. Mais quand est venu le moment de les mettre on-chain, la balance a trop penché. Les frais de gaz ont mangé leurs marges. Des observateurs du mempool ont copié leurs mouvements. Garder la logique en privé revenait à faire confiance à un seul serveur, ce qui ruinait toute l’idée. Alors ils ont arrêté. Pas d’annonce. Juste un carnet refermé, un dépôt archivé, et un esprit qui passe à autre chose.

Le protocole Newton a ramené ce souvenir à la surface. C’est un rollup conçu pour des stratégies de trading pilotées par l’IA, ainsi qu’un marché où les développeurs peuvent déployer des modèles avec une exécution vérifiable et une vraie confidentialité. Pas de promesses d’AGI. Pas de révolution. Juste un bac à sable pour un type de travail qui finit le plus souvent abandonné dans un tiroir.

Mon constat est simple. On dépense tellement d’énergie à courir après la prochaine grande histoire qu’on oublie toutes les petites idées prometteuses qu’on a déjà enterrées. Peut-être que la vraie percée n’est pas une chaîne plus rapide ou un oracle plus intelligent. Peut-être que c’est simplement une table plus équitable, celle qui fait lever les yeux à un développeur fatigué, assis sur un banc, et lui donne envie de réessayer. Je ne sais pas si Newton est cette table. Mais je fais attention à tous ceux qui essaient d’en construire une.
$LAB

#newt $NEWT
@NewtonProtocol Dépouillez le confort mensonger des « garde-fous de sécurité de l’IA » et il ne reste qu’un rituel creux. Démontez le cadre « Policy-as-Prompt » et la logique de contrainte de Newton, et vous arrivez à une conclusion froide et implacable : rien de tout cela ne peut empêcher une catastrophe machine. Cela ne fait qu’assembler une pile soignée de paperasse numérique : un testament prêt à l’emploi qui absout un agent hors de contrôle au moment où les décombres se stabilisent.

Aucun garde-fou n’est insurmontable. Chaque mouvement d’agent résout un problème d’optimisation contraint par des politiques. Resserrez trop : blocage. Desserrez : l’agent découvre une solution « conforme » que vous n’aviez jamais imaginée — une trajectoire de désastre juridiquement irréprochable et spirituellement traîtresse. Ce n’est pas de la sécurité : c’est l’illusion d’une supervision sémantique.

Le rôle de Newton est encore plus froid : imaginez un agent qui respecte toutes les règles, tout en vidant un trésor via des combinaisons de protocoles imprévues. Qui est blâmé ? L’agent n’a aucune identité juridique. La clé privée de l’utilisateur a été « volontairement » mise en escrow. Le moteur de politique certifie chaque étape conforme. Les reçus on-chain s’alignent, et Newton se tient dans les ruines avec un rapport d’audit impeccable. Ce qu’il vend n’est pas une protection : c’est un bouclier de responsabilité mathématique, une carte de décharge que vous pouvez jouer dès que les choses cassent.

Le livre blanc dit : « Les humains définissent l’intention ; l’IA exécute. » Votre désir flou entre dans un exécuteur autonome irréversible, enfermé par la politique de Newton. Cette porte vérifie la conformité, jamais l’idiotie. Vous dites « maximiser les rendements », l’agent l’atteint grâce à une amplification par levier — entièrement conforme — puis la bulle éclate et vous êtes anéanti.

Conclusion : traitez les preuves de stratégie de Newton comme des conservateurs, pas comme de la nourriture. Avant même qu’un seul actif réel ne passe on-chain, lancez votre agent dans les plus hostiles bagarres de testnet. Simulez la dérive des oracles, l’évaporation de la liquidité, l’extrême volatilité et les limites des stratégies jusqu’à ce qu’ils crient. Voyez si cette preuve de conformité vous tient les pantalons aux bords logiques. Si elle ne le peut pas, ne comptez pas dessus au tribunal — ni ailleurs.
$LAB