CryptoDeon

Je n’ai cessé de réfléchir au débat actuel sur la gouvernance de Babylon… mais en partant de la mauvaise direction.

Le débat évident, c’est de savoir si les récompenses BSN devraient être distribuées aux détenteurs de BABY ou bien converties via une vente aux enchères sur chaîne, puis brûlées.

Cela compte.

Mais je pense que la question la plus intéressante est de savoir quel type d’attentes un protocole crée, une fois que les gens se sont habitués à un flux de récompense.

Une récompense n’est pas seulement un transfert économique.

Avec le temps, elle fait partie du comportement des utilisateurs.

Si les participants s’attendent à ce que chaque nouvelle source de valeur arrive sous forme de distribution directe, les décisions futures de gouvernance deviennent de plus en plus difficiles, car modifier cette attente commence à ressembler à une action visant à retirer quelque chose.

D’un autre côté, faire transiter la valeur par un mécanisme de brûlage ne récompense pas immédiatement les participants. À la place, cela change la dynamique d’offre à long terme du jeton. Cela peut bénéficier le réseau d’une manière différente, mais cela oblige aussi les utilisateurs à penser au-delà de la prochaine distribution.

Aucune des deux approches n’est évidemment la bonne.

L’une privilégie des incitations visibles.

L’autre privilégie des incitations structurelles.

C’est pourquoi je ne pense pas que cette proposition concerne vraiment les récompenses BSN.

Il s’agit de décider si Babylon veut que sa gouvernance optimise les attentes des participants… ou le comportement économique à long terme.

Ce n’est pas toujours la même chose.

#baby $BABY @BabylonLabs_io

Aujourd’hui, j’ai examiné la répartition du volume de Babylon sous un angle différent — pas seulement le ratio, mais ce qui se passe quand un nouvel approvisionnement y fait face.

Pour l’instant, $BABY runs représente environ 11,45 M$ de volume sur des plateformes centralisées, contre 2,95 M$ sur les DEX, ce qui place l’exécution décentralisée à environ 21% du volume total. Cet écart n’est pas nouveau. Ce qui change, c’est le calendrier.

Le 10 août, Babylon débloquera 136,11 M de tokens BABY d’une valeur d’environ 1,43 M$, soit 1,2% de l’offre totale. En pourcentage, c’est faible. Mais rapporté à la liquidité on-chain réelle, l’histoire est différente — 1,43 M$ est proche de la moitié de ce qui transite actuellement par les DEX en une seule journée.

Un bref contexte pour ceux qui découvrent : le volume CEX s’échange sur des plateformes comme Binance ou OKX, où l’exchange détient les fonds et fait le rapprochement des ordres en interne. Le volume DEX s’échange et se règle on-chain via des smart contracts, sans dépositaire. Quand le volume des DEX est faible par rapport à celui des CEX, la découverte des prix dépend encore largement des plateformes centralisées — plutôt que des rails sans confiance sur lesquels la thèse du token est construite.

Donc le vrai test n’est pas de savoir si Babylon peut absorber 1,2% de l’offre. C’est de savoir si les pools décentralisés peuvent l’absorber par leurs propres moyens, ou s’ils ont besoin des carnets d’ordres CEX pour maintenir les prix dans la ligne. Si les pools DEX s’appuient sur l’arbitrage CEX pour rester équilibrés, le déblocage passe quand même par la couche centralisée — mais indirectement.

Je surveille la profondeur des DEX dans les jours qui suivent le 10 août, pas la bougie de prix.

#baby $BABY @BabylonLabs_io

J’ai tiré les vrais chiffres de la gouvernance au lieu de parler dans l’abstrait — voici une nouvelle coupe, un point d’entrée différent que « les dépôts comme barrière » :

La partie de $BABY governance qui mérite d’être démêlée n’est pas le dépôt, c’est ce qui se passe quand on ne fait rien.

Le dépôt standard d’une proposition est de 50 000 BABY, et la voie accélérée nécessite 200 000 BABY pour un vote à peu près le jour même, au lieu de la fenêtre habituelle de trois jours. Au prix d’aujourd’hui, ~0,01269 $, cela représente environ 635 $ pour le standard et 2 540 $ pour l’accéléré — ce n’est pas le mur plutocratique que ça a l’air d’être sur le papier, plutôt une taxe de dépôt modérée qui s’est surtout réduite pendant que le token refroidissait par rapport à ses sommets. Le quorum est de 33,4 % de l’offre mise en jeu, et le seuil d’approbation de 50 %.

Mais voici le mécanisme qui détermine en réalité la plupart des résultats : si vous détenez du BABY et ne votez pas, le vote de votre validateur est hérité automatiquement en votre nom. Votez d’abord et c’est le vôtre. Restez silencieux et votre voix devient simplement ce que votre validateur a déjà décidé. Le guide officiel de la gouvernance de Babylon le souligne directement : il indique aux participants de voter sur tout précisément, pour qu’ils ne se contentent pas de suivre par défaut l’opinion de leur validateur.

Donc la vraie question n’est pas « est-ce que les petits détenteurs peuvent se permettre de proposer des choses ». C’est plutôt combien d’entre eux se rendent compte que leur silence est déjà un vote, émis par quelqu’un d’autre, dès qu’ils ne se présentent pas. La proposition avec combustion déflationniste qui a été adoptée l’an dernier est un bon cas de test : ça vaut le coup de vérifier quel était le taux de participation réel des stakers par rapport aux votes hérités des validateurs, plutôt que de se contenter de demander directement au compte.

Avez-vous des chiffres de participation ventilés entre « staker a voté directement » et « hérité du validateur » pour les propositions passées, ou bien cette répartition n’est-elle pas quelque chose que l’explorateur affiche actuellement du tout ?

#baby $BABY @BabylonLabs_io

Le mempool de Bitcoin se situe à l’heure actuelle autour de 179 Mo, avec des frais qui restent proches de 1 sat/vByte, à peu près aussi calme que le réseau puisse l’être. J’ai vérifié ce chiffre en m’attendant à ce qu’il soit sans importance pour $BABY . Il ne l’est pas.

Chaque point de contrôle que Babylon publie pour ancrer l’état d’une chaîne PoS sur Bitcoin passe par une vraie transaction Bitcoin, une écriture OP_RETURN soumise par un Vigilante Submitter, payant le tarif en vigueur à ce moment-là. L’espace des blocs Bitcoin ne sait ni ne s’en soucie si la transaction provient de Babylon plutôt qu’un lot de retraits d’une bourse ou d’une émission d’Ordinals. C’est une seule vente aux enchères partagée pour environ 4 millions d’unités de poids toutes les dix minutes, et tout le monde enchérit dans la même file.

C’est le point facile à manquer en lisant les documents de Babylon isolément. En 2023, lorsque la vague des Ordinals et des inscriptions BRC-20 a déferlé, les frais médians sont passés d’environ 5 sat/vB à 100 puis à 300 sat/vB pendant des mois, uniquement à cause d’une activité NFT sans rapport qui entrait en concurrence pour le même espace. Les Runes ont fait quelque chose de similaire en 2024, poussant les frais à plus de 1 000 sat/vB au pic. Tout cela n’avait rien à voir avec le fait que des chaînes PoS aient besoin de la sécurité de Bitcoin. Les coûts des checkpoints de Babylon auraient quand même été frappés aussi durement que ceux de tout le monde.

Ainsi, la dépense opérationnelle de Babylon pour la chose qu’elle vend réellement, à savoir la sécurité ancrée dans Bitcoin, n’est pas déterminée par l’usage propre de Babylon. Elle est fixée par tout ce qui d’autre se dispute l’espace des blocs Bitcoin cette semaine-là : les émissions de memecoins, les consolidations d’échanges, la congestion déclenchée par le halving—aucun de ces éléments n’est quelque chose que Babylon peut prédire ou contrôler.

À garder en tête la prochaine fois que l’on présente les coûts des checkpoints comme une métrique de Babylon. La moitié de ce chiffre n’a jamais été, à la base, du ressort de Babylon.

$BABY #baby @BabylonLabs_io

J’ai supposé que chaque transaction sur une chaîne sécurisée par Babylon héritait automatiquement de la finalité finale de Bitcoin dès sa confirmation. En lisant le design réel, ce n’est pas comme ça que ça marche, et l’écart entre la finalité rapide et lente est précisément la partie que la plupart des explications passent sous silence.

Babylon fait tourner deux vitesses en parallèle. Les transactions normales obtiennent une finalité rapide : elles sont confirmées instantanément via le consensus PoS propre à la chaîne, le même modèle de consensus social que chaque chaîne Cosmos utilise déjà. La sécurité au niveau de Bitcoin n’entre en jeu que pour la finalité lente : un client attend que le point de contrôle de la transaction soit suffisamment enfoui par des blocs sur Bitcoin, environ quelques heures, parfois plus proche d’un cycle complet d’epoch, avant de la considérer comme réellement irréversible.

Voici la version simple. Attendre des heures pour une confirmation Bitcoin annule l’intérêt d’une chaîne rapide, donc presque personne ne le fait pour les activités du quotidien. Cela signifie que le volume de transactions mis en avant comme « sécurisé par Bitcoin » tourne, pour l’essentiel, sur le même consensus rapide et socialement approuvé dont Babylon a été construit pour s’éloigner. L’horodatage Bitcoin existe, il est là en option, mais il est facultatif, et il faut que quelque chose ait suffisamment de valeur pour qu’une personne choisisse d’attendre.

Donc la vraie amélioration de sécurité n’est pas systématique : elle est sélective, par conception. Les transferts à forte valeur, les contestations de points de contrôle, tout ce qui mérite d’attendre : ceux-là reçoivent la garantie réelle de Bitcoin. L’activité routinière non, parce que personne n’est prêt, en pratique, à échanger la vitesse contre cela.

Il est utile de savoir dans quel niveau atterrissent réellement vos propres transactions, avant de supposer que l’étiquette couvre tout.

$BABY #baby @BabylonLabs_io

Babylon se vend avec une phrase : pas d’enrobage, pas de pontage, pleine auto-conservation. Je le croyais entièrement jusqu’à ce que je vérifie par où passe la majeure partie du volume réel de BTC mis en jeu.

Une grande part d’entre elle ne se met même pas en jeu nativement. Elle transite par LBTC de Lombard, un jeton de staking liquide, un ERC-20 qui s’échange à travers Ethereum, Solana et d’autres chaînes, adossé 1:1 à du BTC que Lombard met en jeu dans Babylon pour le compte de l’utilisateur. En termes simples : vous déposez du Bitcoin, Lombard le met en jeu, et vous obtenez un jeton de reconnaissance (IOU) négociable au lieu de détenir directement du BTC mis en jeu. Cet IOU est exactement le type d’enrobage que tout le discours de Babylon visait à éviter.

Voici pourquoi les gens y ont quand même recours, et c’est une raison tout à fait raisonnable. Le désenvoûtage (unstaking) natif via Babylon nécessite environ une période de 7 jours pour l’attente de désengagement. La conversion de LBTC en BTC natif peut prendre jusqu’à 10 jours une fois qu’on ajoute le propre cycle de rééquilibrage de Lombard. Ainsi, LBTC existe précisément pour offrir de la liquidité et de l’accès DeFi, échangeable sur plus de 70 plateformes, tandis que le BTC sous-jacent reste bloqué pendant le même délai d’attente de désengagement. La conservation du Bitcoin réel qui le garantit est assurée par ce que Lombard appelle un Security Consortium (consortium de sécurité), des nœuds institutionnels comme Galaxy, Wintermute et OKX qui émettent et rachètent conjointement le jeton.

Il y a donc désormais deux modèles de confiance différents superposés, tous deux portant la même étiquette de « staking de Bitcoin ». Le staking natif via Babylon est la version sans confiance, auto-conservée, sur laquelle le protocole a été conçu. Chercher une exposition via LBTC revient à faire confiance à un consortium d’institutions nommées pour gérer correctement la conservation et le rachat, ce qui représente un risque réellement différent de celui que l’architecture de Babylon affirme supprimer.

Ce sur quoi je veille surtout, c’est de savoir si une exposition enveloppée comme LBTC continue de prendre l’avantage sur le staking natif et direct, car cela signifierait que la base de sécurité du monde réel se regroupe discrètement autour d’un petit nombre de membres du consortium, même lorsque le protocole de base lui-même reste exactement aussi sans confiance que promis.

$BABY #baby @BabylonLabs_io

Le chiffre de rendement qui apparaît sur les tableaux de bord de staking pour BABY se situe autour de 15 à 20 % par an. J’ai presque pris cela comme une preuve que Bitcoin Secured Networks versait de l’argent réel pour la sécurité de Bitcoin. Ensuite, j’ai retracé d’où vient réellement ce rendement, et ce n’est pas ça.

BABY a un taux d’inflation annuel de 8 %, réparti à parts égales : 4 % sont émis pour les stakers de BTC, et 4 % pour les stakers de BABY. C’est la couche de financement de base qui alimente presque tout le rendement annoncé pour le moment. À part, il existe une enchère de récompenses où les BSN qui s’intègrent réellement peuvent diriger une part de leurs propres récompenses vers le réseau, et où BABY fait l’objet d’une offre et est ensuite brûlé. Mais le flux de cette enchère reste encore faible comparé au socle de l’inflation, car la majeure partie de l’écosystème en est encore à Babylon Genesis lui-même : un seul BSN, pas encore un marché de réseaux payants.

Voici la version simple de pourquoi cette distinction compte. Le rendement financé par l’inflation n’est pas une preuve que quelqu’un accorde de la valeur à la sécurité qu’on vend. C’est simplement que de nouveaux tokens sont émis et remis à ceux qui ont verrouillé d’abord le BTC ou BABY. La vraie demande ne se manifeste que dans cette enchère séparée et le mécanisme de brûlage, lorsque des chaînes externes mettent réellement de la valeur sur la table pour une sécurité adossée à Bitcoin, plutôt que Babylon ne paie ses propres stakers pour qu’ils se manifestent.

À l’heure actuelle, Babylon détient près de 57 000 BTC mis en staking, qui valaient autrefois plus de 5,6 milliards de dollars au pic du TVL, ce qui ressemble à une validation écrasante. Mais le TVL mesure la quantité de BTC qui a été verrouillée, pas combien une chaîne PoS est prête à payer pour louer cette sécurité. Ce sont des questions différentes, avec des réponses différentes.

Ce qui m’intéresse réellement, c’est de savoir si, du côté de l’enchère et du brûlage, cela commence un jour à avoir un poids réel face à la subvention de 8 %, à mesure que davantage de réseaux passent en ligne ; ou si le rendement continue simplement d’être une chose que Babylon finance pour lui-même.

#baby $BABY @BabylonLabs_io

L’ampleur de la pénalité de slashing pour la double signature sur Babylon est de 0,1% du BTC misé. Quand j’ai lu ce chiffre pour la première fois, il m’a semblé rassurant : petit, contenu, gérable. Puis j’ai compris comment fonctionne réellement le multi-staking, et ce nombre n’a plus raconté toute l’histoire.

La phase 3 de Babylon permet à un dépôt de 1 BTC de sécuriser simultanément plusieurs réseaux Bitcoin Secured, et pas seulement Babylon Genesis. Un unique fournisseur de finalité conserve un ensemble de clés de signature pré-enregistrées et peut signer des checkpoints sur plusieurs BSN en utilisant la même mise sous-jacente. Voilà l’essentiel : un seul verrou, plusieurs réseaux, plus de sources de rendement pour un seul dépôt, au lieu de fractionner le BTC sur des positions distinctes.

Voici ce que ce chiffre de 0,1% ne capture pas. Il s’agit d’un montant par événement de slashing, et non d’un pourcentage de la mise. Si un fournisseur de finalité se comporte mal et se fait prendre sur un réseau, c’est une seule coupure de 0,1%. Mais si, en utilisant la même mise partagée, ce même fournisseur sécurise aussi trois ou quatre autres BSN en même temps, l’honnêteté et la disponibilité de cet unique opérateur deviennent alors un facteur déterminant pour l’ensemble, simultanément. C’est exactement la même question structurelle que le modèle de restaking d’EigenLayer a dû traiter sur Ethereum : un collatéral réutilisé signifie qu’une ligne de défaillance d’un service peut s’étendre plus loin que le service où la panne a eu lieu.

Donc le risque n’est pas vraiment le pourcentage de slashing. C’est la corrélation. Un miseur de BTC ne parie plus seulement sur l’honnêteté d’un unique fournisseur de finalité : il parie aussi sur le fait que ce fournisseur reste honnête et en ligne sur chaque réseau touché par sa clé, simultanément, dans un environnement où se disputent environ 250 fournisseurs de finalité, tous en concurrence pour cette confiance.

Condition que je surveille : si les BSN qui s’enregistrent via le multi-staking commencent à divulguer le chevauchement de fournisseurs de finalité partagés comme les protocoles de prêt divulguent le risque de collatéral partagé, ou si cette corrélation reste invisible jusqu’à ce qu’un mauvais opérateur la rende évidente, de la manière la plus difficile.

$BABY #baby @BabylonLabs_io

Il y a une phrase dans la documentation de Babylon qui, discrètement, annule le mot que tout le monde utilise pour désigner son action de hachage : « trustless ». J’avais supposé qu’EOTS faisait tout le travail seul : la math détecte un double-signataire, la punition survient, aucun comité n’est nécessaire. En lisant les conditions de dépense réelles, j’ai changé d’avis.

Le script Bitcoin ne peut pas exprimer nativement « si ce fournisseur de finalité double-signe, alors écimez sa mise ». Ainsi, Babylon construit le chemin de punition d’une manière différente. Au moment du staking, vos fonds se verrouillent dans un UTXO qui exige des signatures de vous et d’un quorum du comité du covenant, recueillies à l’avance. Si, plus tard, le fournisseur de finalité double-signe, la math d’EOTS fait fuiter sa clé privée, et cette clé divulguée fournit la signature finale que le multisig préconstruit attendait déjà.

Donc la partie élégante, celle où la math rattrape automatiquement les mauvais acteurs, est bien réelle, mais ce n’est que la dernière pièce d’une structure, pas l’ensemble de la structure. Les signatures du comité doivent exister avant qu’une quelconque mauvaise conduite ne se produise, sinon il n’y a tout simplement aucun chemin punissable. La « trustlessness » n’apparaît qu’à la fin. Tout le reste avant cela dépend du fait que ce comité est présent, honnête et en ligne au moment du staking.

Ce qui redéfinit ce qui vaut réellement la peine d’être surveillé. Ce n’est pas de savoir si la cryptographie fonctionne — cette partie est solide. Il s’agit plutôt de savoir si le comité du covenant reste décentralisé et disponible pendant que Babylon s’étend à travers davantage de réseaux sécurisés par Bitcoin, car si cette couche s’amincit, le chemin de slashing ne échoue pas bruyamment : il cesse simplement d’exister pour tout nouveau staking avant que quiconque ne vérifie.

Que la composition du comité et sa disponibilité commencent à être scrutées avec la même attention que la TVL et les chiffres du staking, ou qu’elles restent la condition préalable invisible dont personne ne se soucie jusqu’à ce qu’il soit trop tard.

$BABY #baby @BabylonLabs_io

Quelque chose concernant le déblocage du 10 juillet ne collait pas quand j’ai réellement pris le temps de regarder les chiffres, alors j’ai cessé de faire des suppositions et je suis allé vérifier.

BABY ne fait pas de déblocages « cliff-and-dump » comme beaucoup de tokens. L’équipe, les conseillers et les premiers investisseurs débloquent 1/36e de leur allocation chaque mois, jusqu’en avril 2029 : un écoulement linéaire lent, plutôt qu’une seule date effrayante sur un calendrier. Le 10 juillet n’était pas un événement spécial : c’était juste un autre des trente-six mois identiques. Sur environ 3,99 milliards de tokens déjà en circulation, cette libération a ajouté une portion prévisible et connue ; rien qu’une personne ayant une courbe d’acquisition (« vesting ») ne pouvait pas voir venir il y a un an.

Voici la partie qui compte vraiment, et elle est facile à interpréter à l’envers. Un déblocage planifié et linéaire n’est pas un choc d’offre : il est déjà intégré dans les prix par toute personne attentive, parce que le marché connaît l’exacte mécanique depuis que le calendrier a été publié. Ce qui fait bouger le prix n’est pas le déblocage lui-même, mais plutôt si la nouvelle demande, l’afflux de plus de BTC vers le staking et TBV, et davantage d’intégrations comme le récent accord Gomining, progressent plus vite que ce flux mensuel régulier de nouvelles entrées de liquidité (float) vers les bourses.

La vraie question n’était donc jamais « combien de déblocages ce mois-ci ». C’est de savoir si, côté protocole : BTC sécurisé, coffres ouverts, utilisation réelle — la croissance est suffisamment rapide pour absorber trente-six mois supplémentaires du même écoulement, sans que quiconque ne le remarque comme une pression.

Condition que je suis : si la croissance des BTC dans les coffres reste au-dessus du rythme mensuel des déblocages sur les prochains « cliffs », ou si le flux finit par dépasser la demande en silence, comme le font souvent les fuites lentes.

$BABY #baby #BinanceSquareFamily @BabylonLabs_io

Je jouais avec l’idée de déverrouiller seulement une partie de mon BTC depuis un Trustless Bitcoin Vault, comme on ferait un retrait partiel d’un compte d’épargne, et je me suis heurté à un mur que je n’avais pas anticipé. Le TBV ne permet pas les retraits partiels. C’est un coffre en entier : tout entre, tout sort. Une seule pièce, pas plusieurs.

Au début, j’ai pensé que c’était une limitation UX, presque une conception paresseuse. Mais en y réfléchissant davantage, je crois que c’est l’inverse. Prouver un rachat partiel vers Bitcoin, sans fork et sans nouveaux opcodes, revient à prouver une fraction d’un événement en utilisant une logique de script qui n’a jamais été construite pour exprimer les fractions de façon propre. Le rachat de tout le coffre contourne complètement ce problème. Un dépôt, un état, une preuve claire. La simplicité n’est pas une fonctionnalité manquante : c’est ce qui maintient la vérification honnête sur une chaîne qui refuse de se plier à vos besoins.

Voici la partie facile à manquer si vous êtes nouveau : chaque conception de DeFi native au Bitcoin doit choisir entre flexibilité et prouvabilité, et bien souvent on ne peut pas avoir les deux. Babylon a choisi la prouvabilité. Ce compromis explique, en silence, pourquoi ils détiennent plus de 56 000 BTC dans des coffres de staking et ont récemment fait entrer un soutien tout neuf de la part d’a16z cette année ; les institutions ne courent pas après la flexibilité, elles cherchent du prouvable.

Ce qui me revient sans cesse, c’est la question de savoir si ce compromis passe à l’échelle. Le rachat de tout le coffre est simple quand les coffres sont petits et personnels. C’est beaucoup moins propre lorsque des intégrations, comme le récent accord de Gomining, commencent à faire transiter un millier de BTC à la fois via la même porte de sortie tout-ou-rien.

Condition que je surveille : est-ce que les intégrations à grande échelle s’adaptent au rachat de tout le coffre tel quel, ou est-ce qu’elles se fragmentent discrètement en de nombreux coffres plus petits juste pour retrouver un comportement de retrait partiel, en passant par la porte de côté.

$BABY #baby @BabylonLabs_io

J’ai d’abord remarqué quelque chose d’étrange en regardant une guilde farmer — des dizaines de joueurs qui cultivent des ressources pendant des heures, fabriquent des objets sans arrêt, et $BABY barely n’a pratiquement pas bougé. Ce n’est que lorsqu’une personne a réellement frappé ou réglé un objet on-chain que le token a commencé à réagir.

C’est là que j’ai compris : $BABY ne valorise pas l’activité. Il valorise le moment où l’effort cesse d’être invisible et devient permanent. L’agriculture, l’artisanat, le grind — tout cela vit off-chain, non valorisé, non enregistré par le marché. La demande ne se manifeste qu’au moment de la conversion, la seule étape où le temps d’un joueur est “daté” dans quelque chose que la chaîne doit reconnaître.

Ce qui signifie qu’un jeu peut paraître totalement vivant — serveurs complets, craft constant, guildes actives — pendant que la demande du token se vide discrètement, parce que les joueurs ont appris à retarder ou à éviter cette dernière étape. L’activité continue d’apparaître en surface longtemps après que ce que $BABY valorise réellement a cessé de se produire en dessous.

À surveiller : si la fréquence des conversions reste stable à mesure que la base de joueurs grandit, ou si la croissance en joueurs ne se traduit pas par une croissance à cet unique instant.

#baby #BinanceSquare @BabylonLabs_io

Je fixais à nouveau l’écran du plan Multiplier ce matin, mais cette fois je ne regardais pas les rendements. Je regardais ce que le report fait réellement au token lui-même, pas seulement à mon allocation.

Voici la partie qui a retenu mon attention. Toute personne qui choisit un report de 4 ou 8 mois ne fait pas que mettre ses propres tokens de côté pour un multiplicateur plus élevé plus tard. Elle retire aussi cette offre de la circulation dès le TGE, au moment où GRVT fait ses débuts sur le marché spot et vise des inscriptions sur des CEX de niveau 1. Moins d’offre en circulation au lancement signifie généralement une pression de vente initiale plus faible et une fenêtre de découverte des prix plus nette.

Ainsi, le multiplicateur n’est pas seulement une récompense pour la patience. C’est aussi une compensation pour absorber une mission dont l’échange tire profit — maintenir l’offre hors du marché pendant la période la plus fragile de la découverte des prix, juste après le lancement.

Cela change un peu la manière de voir la décision. Ne pas attendre et réclamer immédiatement, ce n’est pas seulement « une certitude maintenant », comme je le pensais auparavant. C’est aussi contribuer à la pression de vente exacte à laquelle l’action des prix au début du TGE est la plus sensible. Le report n’est pas seulement « peut-être un chiffre plus élevé plus tard » : il soutient discrètement les conditions qui pourraient rendre ce chiffre plus élevé possible dès le départ.

L’inscription est ouverte jusqu’au 27 juillet 2026, 00:00 UTC, les choix sont définitifs, et le pool de report se trouve dans la part fixe de 18 % de la Saison 2 sur l’offre de 1B.

Le fait que cela se déroule réellement comme prévu dépend de la proportion de l’offre enregistrée qui finit par choisir le report plutôt qu’une demande immédiate, car un taux de report faible ne changerait pas grand-chose à la vue d’ensemble de la pression de vente.

#grvt #BinanceSquare @grvt_io

La question sur laquelle je suis resté assis n’avait rien à voir avec la technologie. Elle concernait la responsabilité.

@NewtonProtocol peut vérifier qu’un agent a respecté ses règles. La preuve cryptographique est réelle : chaque évaluation de politique laisse une trace, chaque action effectuée dans les autorisations définies est attestable. C’est réellement plus que ce que la plupart des automatisations en DeFi proposent aujourd’hui.

Mais voici le point. L’exécution vérifiable et le jugement vérifiable sont deux problèmes différents. Newton résout soigneusement le premier. Le second dépend encore, pour l’essentiel, de la personne qui a rédigé les règles.

En termes simples : si un gestionnaire de coffre fixe une limite de dépenses qui s’avère trop souple, ou définit un déclencheur de rééquilibrage qui avait du sens dans des marchés calmes mais pas dans des marchés volatils, Newton applique correctement ces règles. La politique s’exécute, la preuve est produite, la transaction se règle. Tout a fonctionné comme prévu. Le résultat pourrait toutefois rester mauvais.

Ce n’est pas exactement une faille de l’architecture. Aucune couche d’exécution ne peut améliorer le jugement humain. Mais cela soulève une question que le protocole n’a pas encore entièrement résolue : quand une politique est correcte mais que les règles qui la sous-tendent étaient erronées, où se situe la responsabilité ? Chez l’opérateur qui l’a configurée ? Le développeur qui a publié le modèle ? L’utilisateur qui l’a activée sans avoir lu en détail ce qu’il a approuvé ?

La finance traditionnelle résout cela via la licence, l’obligation fiduciaire et la réglementation. La crypto le résout via une documentation que personne ne lit et des conditions générales qui se déchargent de tout.

Newton se trouve au milieu de ce manque, pour l’instant. La couche d’exécution est en cours de construction avec soin. La couche de responsabilité autour de qui conçoit les règles, qui les audite et qui répond lorsqu’elles échouent — cette partie relève encore, pour l’essentiel, de l’aspiration.

Le fait que cela soit résolu au fil du temps importera probablement plus que n’importe quelle étape technique de la feuille de route.

$NEWT @NewtonProtocol #Newt

Je relisais ce matin les mécanismes réels du Multiplier Plan sur le centre d’aide de GRVT, en passant au-delà du discours marketing, et quelque chose s’est déclenché que je n’avais pas envisagé auparavant.

L’allocation de la saison 2 est fixée à 18% de l’offre totale de 1 milliard de GRVT. L’allocation totale pour la communauté et les airdrops est plafonnée à 28%. Ce n’est pas un chiffre qui bouge : il est fixé avant même que quiconque ne s’inscrive.

Alors, quand le Multiplier Plan propose jusqu’à 4x votre allocation en différant, d’où vient réellement cette taille supplémentaire ? Elle ne peut pas provenir de nouveaux tokens : l’offre est fixe et il n’y a aucune émission supplémentaire. Elle doit donc venir du même pool que tout le monde utilise.

Cela signifie que le plan ne récompense pas vraiment la patience avec une nouvelle valeur. Il redistribue une part fixe. Chaque personne qui obtient un multiplicateur plus élevé en attendant, en réalité, réduit ce qui reste pour le pool par rapport à celles et ceux qui revendiquent immédiatement. C’est un partage à somme nulle présenté comme un bonus de fidélité.

L’inscription est ouverte maintenant jusqu’au 27 juillet 2026, 00:00 UTC, et le choix est définitif une fois fait. Personne ne sait encore quelle fraction des participants choisira le multiplicateur plutôt que la revendication immédiate, et c’est exactement ce ratio qui détermine si le fait de différer valait le coup.

Si la plupart des gens se précipitent pour revendiquer tout de suite, les quelques personnes qui ont différé obtiennent une part disproportionnée. Si la plupart des gens différèrent, le multiplicateur se dilue contre lui-même et le « bonus » se réduit vers le néant.

Je suis curieux de savoir dans quel sens penchent réellement les chiffres d’inscription une fois la fenêtre fermée.

#grvt #BinanceSquare @grvt_io

J’ai passé une partie de la journée à essayer de mettre en difficulté la mise en place de l’agent de langage naturel de Newton — pas de façon malveillante, juste en réfléchissant à ce qui se passe quand un langage anglais simple rencontre un code précis.

L’expérience est vraiment fluide. Vous saisissez quelque chose comme « rééquilibrer mon portefeuille si un seul actif dépasse 30 % » et le système le transforme en une politique exécutable réelle, avec des zkPermissions attachées. Pas de Solidity. Pas de fichiers de configuration. L’écart entre l’intention et l’exécution me paraît plus faible que tout ce que j’ai utilisé auparavant dans la DeFi.

Puis j’ai commencé à poser les questions de suivi évidentes, et la fluidité s’est vite compliquée.

30 % de quoi exactement ? La valeur actuelle du portefeuille au moment où le déclenchement se produit ? La valeur au moment où l’autorisation a été créée ? Le dépôt initial ? Ces trois interprétations produisent des déclenchements de rééquilibrage différents sur un marché volatile, parfois de façon radicalement différente. « N’importe quel seul actif » — est-ce que cela inclut les positions mises en jeu ? Les jetons de pools de liquidité ? Les versions enveloppées du même actif détenues dans différents protocoles ?

Le protocole ne vous comprend pas de travers. C’est le problème. Il vous comprend précisément et exécute exactement ce que dit la version analysée de votre instruction, ce qui n’est peut-être pas ce que vous vouliez dire quand vous l’avez tapée dans une phrase normale.

Newton rend l’exécution des politiques fiable. Il ne rend pas la rédaction des politiques fiable. Ce sont deux problèmes différents, et le second ne se résout pas avec une meilleure infrastructure — il se résout avec de meilleurs réglages par défaut, des prévisualisations d’interprétation plus claires, et probablement avec quelques cas limites douloureux qui apprennent à l’écosystème ce que « rééquilibrer » doit préciser exactement avant de pouvoir être automatisé sans risque.

Je préfère voir la couche de langage naturel m’afficher la politique analysée en termes simples avant de confirmer, plutôt que de découvrir un décalage d’interprétation trois semaines plus tard quand l’agent a fait exactement ce que j’ai dit et rien de ce que je voulais

$NEWT @NewtonProtocol #Newt

Je suis retourné relire la formule exacte que GRVT utilise pour le haircut, car j’ai réalisé que la discussion précédente que j’avais vue ne la décrivait jamais clairement.

C’est le Déficit du Fonds d’Assurance divisé par les Capitaux Propres Totaux des Clients. Ce dénominateur, c’est lui qui a changé la façon dont je voyais les choses.

Cela signifie que le haircut n’est pas une pénalité fixe liée à la taille du manque. C’est un pourcentage qui évolue selon la quantité de capital client total qui se trouve sur la plateforme à cet instant précis. Même déficit, plus de fonds propres totaux sur la plateforme, et la taxe de retrait diminue automatiquement. Même déficit, moins de fonds propres totaux, et la charge frappe plus durement.

Ainsi, la croissance agit discrètement comme un amortisseur. Une base d’utilisateurs plus large ne fait pas seulement paraître le système plus sain sur un tableau de bord : elle dilue mathématiquement le fardeau qu’un seul utilisateur procédant à un retrait supporte pendant un événement de déficit. Ce qui signifie aussi que l’inverse est vrai : un déficit survenant pendant une période plus calme, avec moins de fonds garés sur la plateforme, entraîne un haircut plus sévère pour exactement le même manque en dollars.

Ce n’est pas exactement un défaut : c’est simplement une propriété que personne ne met en avant. La taille de la perte que vous absorbez personnellement dépend moins de la cause du déficit et davantage de la quantité de capital sans lien qui se trouvait sur GRVT le jour où vous aviez besoin de sortir.

Que ce soit une fonction de stabilisation ou un risque de synchronisation caché dépend probablement de la vitesse à laquelle les Capitaux Propres Totaux des Clients peuvent eux-mêmes se contracter pendant le même épisode de stress qui a créé le déficit, en premier lieu.

#grvt #BinanceSquare @grvt_io