Nexiz Crypto
537 Publications
Nexiz Crypto
Ouvert au trading
Trade fréquemment
5.1 an(s)
149 Suivis
130 Abonnés
364 J’aime
Publications
Portefeuille
Tous
Citations
PINNED
Je lisais les documents des nœuds de Dusk tard dans la nuit, à moitié en étant attentif. J’ai presque sauté toute la section sur le nœud d’archive.
Je me suis dit que c’était ennuyeux. Une simple boîte de stockage pour d’anciens blocs. Rien de captivant.
Puis une seule ligne m’a arrêté.
Un nœud d’archive peut aussi mettre en jeu des fonds et participer au consensus. Le même nœud, un travail en plus.
Attendez… quoi ? Je pensais que les nœuds d’archive restaient simplement en arrière-plan, tranquillement. J’ai continué à lire, en espérant davantage de détails. Puis j’ai vu que les docs disent aussi que ce n’est pas vraiment recommandé. Ça m’a déconcerté une seconde. Pourquoi mentionner quelque chose que vous ne voulez pas vraiment que les gens fassent ?
Puis tout s’est éclairci.
Ce n’est pas une règle. C’est plutôt une étiquette d’avertissement. Le nœud peut faire les deux tâches, mais les faire en même temps, c’est demander beaucoup à une seule machine. Imaginez un bibliothécaire à qui on a aussi demandé de surveiller le bâtiment toute la nuit. C’est techniquement possible. Probablement épuisant. Ce petit détail a changé ma façon de voir ces nœuds. Ce n’est pas parce qu’une capacité existe qu’elle doit forcément être utilisée. Parfois, la chose la plus honnête dans une documentation, ce n’est pas la fonctionnalité. C’est la note discrète qui vous dit de faire attention.
Ça me fait me demander combien d’opérateurs de nœuds lisent cette ligne et la… ignorent.
#dusk $DUSK @Dusk
Je me suis dit que c’était ennuyeux. Une simple boîte de stockage pour d’anciens blocs. Rien de captivant.
Puis une seule ligne m’a arrêté.
Un nœud d’archive peut aussi mettre en jeu des fonds et participer au consensus. Le même nœud, un travail en plus.
Attendez… quoi ? Je pensais que les nœuds d’archive restaient simplement en arrière-plan, tranquillement. J’ai continué à lire, en espérant davantage de détails. Puis j’ai vu que les docs disent aussi que ce n’est pas vraiment recommandé. Ça m’a déconcerté une seconde. Pourquoi mentionner quelque chose que vous ne voulez pas vraiment que les gens fassent ?
Puis tout s’est éclairci.
Ce n’est pas une règle. C’est plutôt une étiquette d’avertissement. Le nœud peut faire les deux tâches, mais les faire en même temps, c’est demander beaucoup à une seule machine. Imaginez un bibliothécaire à qui on a aussi demandé de surveiller le bâtiment toute la nuit. C’est techniquement possible. Probablement épuisant. Ce petit détail a changé ma façon de voir ces nœuds. Ce n’est pas parce qu’une capacité existe qu’elle doit forcément être utilisée. Parfois, la chose la plus honnête dans une documentation, ce n’est pas la fonctionnalité. C’est la note discrète qui vous dit de faire attention.
Ça me fait me demander combien d’opérateurs de nœuds lisent cette ligne et la… ignorent.
#dusk $DUSK @Dusk
Je parcourais la documentation de TermMax pour comprendre ce que signifiait réellement le « Fixed-Rate Token » (token à taux fixe), et je me suis dit que le taux lui-même devait être verrouillé par le protocole, fixé une fois qu’un marché s’ouvre. Cette hypothèse n’a pas tenu jusqu’à la première page sur la tokenisation.
La documentation décrit le FT comme une obligation zéro-coupon : elle s’engage à verser 1 token de dette à l’échéance, mais s’échange avec une décote avant cette date. Donc la partie « fixed » (fixe) n’est pas un nombre verrouillé, c’est la destination : un seul token de dette, garanti à l’échéance. Ce qu’un prêteur gagne réellement dépend de la décote à laquelle il achète, décote qui est déterminée par la fourchette (range order) dans laquelle il finit par être exécuté. C’est à ce moment-là que j’ai compris.
Ce qui m’a surpris, c’est la condition de parité qui fonctionne en dessous : 1 FT plus 1 XT égale 1 token de dette, valable à tout instant, pas seulement à la date de règlement. XT n’est pas un actif « à côté », posé de l’autre côté de l’équation : c’est l’autre moitié de la même formule, et il devient sans valeur dès l’instant où le FT peut être racheté à maturité. Le compromis, c’est que la tarification évolue quand le temps restant jusqu’à l’échéance diminue : le taux effectif change à chaque transaction au lieu de rester statique. Cela semble intentionnel, pour laisser le marché découvrir le taux plutôt que de le dicter d’avance.
Je me demande à quel point cette décote suit réellement le temps restant quand les marchés deviennent plus fins à l’approche de l’échéance. #termmax @TermMax
La documentation décrit le FT comme une obligation zéro-coupon : elle s’engage à verser 1 token de dette à l’échéance, mais s’échange avec une décote avant cette date. Donc la partie « fixed » (fixe) n’est pas un nombre verrouillé, c’est la destination : un seul token de dette, garanti à l’échéance. Ce qu’un prêteur gagne réellement dépend de la décote à laquelle il achète, décote qui est déterminée par la fourchette (range order) dans laquelle il finit par être exécuté. C’est à ce moment-là que j’ai compris.
Ce qui m’a surpris, c’est la condition de parité qui fonctionne en dessous : 1 FT plus 1 XT égale 1 token de dette, valable à tout instant, pas seulement à la date de règlement. XT n’est pas un actif « à côté », posé de l’autre côté de l’équation : c’est l’autre moitié de la même formule, et il devient sans valeur dès l’instant où le FT peut être racheté à maturité. Le compromis, c’est que la tarification évolue quand le temps restant jusqu’à l’échéance diminue : le taux effectif change à chaque transaction au lieu de rester statique. Cela semble intentionnel, pour laisser le marché découvrir le taux plutôt que de le dicter d’avance.
Je me demande à quel point cette décote suit réellement le temps restant quand les marchés deviennent plus fins à l’approche de l’échéance. #termmax @TermMax
Partiellement vrai
J’ai supposé que chaque blockchain fonctionnait fondamentalement de la même façon en coulisses. Les transactions sont soumises, elles font la file, tout le monde peut voir cette file avant que quoi que ce soit ne soit confirmé. Je n’ai jamais vraiment remis cela en question. Puis j’ai lu quelque chose dans la documentation de Dusk qui m’a fait m’arrêter. DuskEVM n’a tout simplement pas cette file d’attente visible. Les transactions passent directement, sans rien de public qui montre ce qui va se produire avant que cela n’arrive. C’est à ce moment-là que ça a fait tilt. Sur la plupart des chaînes, le fait de laisser tout le monde voir les transactions en attente est considéré comme normal, voire bénéfique, en termes de transparence. Mais cela signifie aussi que quiconque surveille de près peut voir un échange arriver et agir en premier. Pour les transferts du quotidien, cela ne change presque rien. Pour des activités financières réglementées, c’est un risque réel. Donc ce n’est pas vraiment un raccourci technique. On dirait plutôt un choix délibéré : de la transparence échangée contre de la protection. Car les institutions financières se soucient moins de regarder la file et davantage du fait que leur activité ne soit pas exposée avant que tout ne soit réglé. Ce à quoi je reviens sans cesse, c’est la façon dont cela change ce que « la confidentialité » signifie ici. Il ne s’agit pas de tout cacher. Il s’agit de ne pas diffuser l’intention avant qu’une transaction ne soit réelle. Est-ce que des institutions financières feraient réellement plus confiance à un système si elles ne pouvaient pas voir les transactions arriver, ou est-ce que cela ne fait que déplacer le problème de confiance ailleurs ? #dusk $DUSK @Dusk
Voir la traduction
I was reading through Dusk's page on the NPEX partnership, and one detail caught my attention: a mention of a "DLT-TSS" license. I hadn't come across that term in a blockchain context before, so I assumed it was internal Dusk terminology.
After checking the official page, it turned out to be an actual regulatory category, a DLT Trading and Settlement System license, one of the newer designations under EU pilot regime rules for market infrastructure running on distributed ledger tech.
What surprised me was comparing that page against Dusk's earlier NPEX announcement. The original 2023 release described NPEX simply as an MTF-licensed exchange. The more recent "Regulatory Edge" page lists a fuller stack: MTF, Broker, ECSP, and the forthcoming DLT-TSS. That's a noticeable shift in scope between two official materials from the same source, not a contradiction, but a sign the partnership's regulatory coverage expanded over time rather than being fixed from day one.
The cautious read here is that Dusk isn't claiming its own license, it's inheriting NPEX's existing regulatory standing across the stack. That's a trade-off by design: it ties Dusk's compliance story to NPEX's licensing progress instead of a standalone framework.
Which raises a real question: once DLT-TSS is finalized, does that change what kinds of assets can settle on Dusk, or mainly formalize what NPEX already does?
#dusk $DUSK @Dusk
After checking the official page, it turned out to be an actual regulatory category, a DLT Trading and Settlement System license, one of the newer designations under EU pilot regime rules for market infrastructure running on distributed ledger tech.
What surprised me was comparing that page against Dusk's earlier NPEX announcement. The original 2023 release described NPEX simply as an MTF-licensed exchange. The more recent "Regulatory Edge" page lists a fuller stack: MTF, Broker, ECSP, and the forthcoming DLT-TSS. That's a noticeable shift in scope between two official materials from the same source, not a contradiction, but a sign the partnership's regulatory coverage expanded over time rather than being fixed from day one.
The cautious read here is that Dusk isn't claiming its own license, it's inheriting NPEX's existing regulatory standing across the stack. That's a trade-off by design: it ties Dusk's compliance story to NPEX's licensing progress instead of a standalone framework.
Which raises a real question: once DLT-TSS is finalized, does that change what kinds of assets can settle on Dusk, or mainly formalize what NPEX already does?
#dusk $DUSK @Dusk
Voir la traduction
I was reading through some updates on Dusk Network and one detail caught my attention: they're building something called Hedger, described as a privacy module for their upcoming EVM layer.
My first assumption was that this just meant "private transactions," the same pitch most privacy chains make. After checking the official docs, it turned out to be more specific than that. Hedger uses homomorphic encryption alongside zero-knowledge proofs, but the goal isn't just hiding data, it's making that hidden data reviewable when required. That's when it clicked. Regulated finance doesn't actually need total secrecy. It needs privacy that can be selectively opened up for auditors or regulators without exposing everything to the public chain. What surprised me was how this reframes the whole "privacy vs transparency" debate. Instead of picking one, DuskEVM seems built around toggling between them depending on who's asking and why.
There's a trade-off here worth noting. Supporting confidential Solidity-style workflows means more computational overhead than a standard EVM chain, since proofs and encrypted state checks aren't free. That's likely the cost of designing for institutions rather than pure throughput.
Still, it raises a genuine question: as more real-world assets move onchain, will "selective transparency" become the actual industry standard, rather than an edge case?
#dusk $DUSK @Dusk
My first assumption was that this just meant "private transactions," the same pitch most privacy chains make. After checking the official docs, it turned out to be more specific than that. Hedger uses homomorphic encryption alongside zero-knowledge proofs, but the goal isn't just hiding data, it's making that hidden data reviewable when required. That's when it clicked. Regulated finance doesn't actually need total secrecy. It needs privacy that can be selectively opened up for auditors or regulators without exposing everything to the public chain. What surprised me was how this reframes the whole "privacy vs transparency" debate. Instead of picking one, DuskEVM seems built around toggling between them depending on who's asking and why.
There's a trade-off here worth noting. Supporting confidential Solidity-style workflows means more computational overhead than a standard EVM chain, since proofs and encrypted state checks aren't free. That's likely the cost of designing for institutions rather than pure throughput.
Still, it raises a genuine question: as more real-world assets move onchain, will "selective transparency" become the actual industry standard, rather than an edge case?
#dusk $DUSK @Dusk
J’ai supposé que NPEX apportait des actifs sur Dusk via une migration de jetons simple.
Ce n’est pas ça.
NPEX est déjà une bourse néerlandaise réglementée, autorisée en tant qu’MTF et courtier.
Ce qui se passe réellement : Chainlink CCIP devient la couche d’interopérabilité pour les actifs que NPEX émet sur DuskEVM. DataLink apporte les données d’échange onchain. Data Streams gère les flux de marché.
À aucun moment, la licence de NPEX n’est remplacée ni contournée.
Les actifs restent rattachés à la situation réglementaire existante de NPEX pendant toute la durée. Le rôle de Chainlink consiste simplement à permettre à ces données réglementées de circuler entre les chaînes sans rompre la conformité.
Un détail a retenu mon attention. Les 300 M+ EUR souvent cités ne correspondent pas à un nouvel apport de capitaux entrant dans la crypto. Il s’agit d’un AUM réglementé existant qui est représenté onchain, tout en restant régi par la même licence qu’auparavant.
La tokenisation sous une licence existante compte-t-elle comme l’arrivée de la TradFi onchain, ou plutôt comme la fourniture à la TradFi d’une nouvelle interface ? #dusk $DUSK @Dusk
Ce n’est pas ça.
NPEX est déjà une bourse néerlandaise réglementée, autorisée en tant qu’MTF et courtier.
Ce qui se passe réellement : Chainlink CCIP devient la couche d’interopérabilité pour les actifs que NPEX émet sur DuskEVM. DataLink apporte les données d’échange onchain. Data Streams gère les flux de marché.
À aucun moment, la licence de NPEX n’est remplacée ni contournée.
Les actifs restent rattachés à la situation réglementaire existante de NPEX pendant toute la durée. Le rôle de Chainlink consiste simplement à permettre à ces données réglementées de circuler entre les chaînes sans rompre la conformité.
Un détail a retenu mon attention. Les 300 M+ EUR souvent cités ne correspondent pas à un nouvel apport de capitaux entrant dans la crypto. Il s’agit d’un AUM réglementé existant qui est représenté onchain, tout en restant régi par la même licence qu’auparavant.
La tokenisation sous une licence existante compte-t-elle comme l’arrivée de la TradFi onchain, ou plutôt comme la fourniture à la TradFi d’une nouvelle interface ? #dusk $DUSK @Dusk
Je parcourais le forum de gouvernance d’Aave et j’ai remarqué quelque chose de bizarre : WBTC revenait sans cesse dans les propositions d’« augmentation du supply cap », mois après mois. Je me suis dit qu’un actif blue-chip comme le wrapped Bitcoin aurait simplement une capacité illimitée pour être déposé et emprunté.
Cette hypothèse ne s’est pas confirmée.
Après avoir consulté les publications réelles du Risk Steward d’Aave, j’ai trouvé que le supply cap de WBTC sur Aave V3 Core était à environ 97% d’utilisation en juin, ce qui a poussé LlamaRisk à recommander de le relever de 31,800 à 38,200 WBTC. Quelques semaines plus tôt, la même limite avait été abaissée de 39,000 à 31,800.
Ce qui m’a surpris, c’est l’aller-retour. Ce n’est pas un chiffre figé, défini une fois pour toutes : il est ajusté presque en continu en fonction de la profondeur de liquidité et du comportement observé des utilisateurs. C’est là que j’ai compris : les supply caps ne sont pas là pour limiter la popularité, ce sont des coupe-circuits. Si trop de WBTC s’accumule par rapport à la liquidité disponible on-chain, un bug d’oracle ou une ruée de liquidations pourrait dépasser ce que le marché peut réellement absorber.
En plafonnant l’offre, on borne ce risque même quand la demande est forte. L’arbitrage est réel, toutefois. Quand le cap est atteint, les détenteurs de WBTC qui veulent emprunter sur leur collatéral doivent simplement attendre que la gouvernance agisse.
Ça me fait me demander combien de personnes supposent que « capacité pleine » signifie qu’il y a un problème, alors que cela peut juste vouloir dire que le système est prudent volontairement.
#baby $BABY @BabylonLabs_io
Cette hypothèse ne s’est pas confirmée.
Après avoir consulté les publications réelles du Risk Steward d’Aave, j’ai trouvé que le supply cap de WBTC sur Aave V3 Core était à environ 97% d’utilisation en juin, ce qui a poussé LlamaRisk à recommander de le relever de 31,800 à 38,200 WBTC. Quelques semaines plus tôt, la même limite avait été abaissée de 39,000 à 31,800.
Ce qui m’a surpris, c’est l’aller-retour. Ce n’est pas un chiffre figé, défini une fois pour toutes : il est ajusté presque en continu en fonction de la profondeur de liquidité et du comportement observé des utilisateurs. C’est là que j’ai compris : les supply caps ne sont pas là pour limiter la popularité, ce sont des coupe-circuits. Si trop de WBTC s’accumule par rapport à la liquidité disponible on-chain, un bug d’oracle ou une ruée de liquidations pourrait dépasser ce que le marché peut réellement absorber.
En plafonnant l’offre, on borne ce risque même quand la demande est forte. L’arbitrage est réel, toutefois. Quand le cap est atteint, les détenteurs de WBTC qui veulent emprunter sur leur collatéral doivent simplement attendre que la gouvernance agisse.
Ça me fait me demander combien de personnes supposent que « capacité pleine » signifie qu’il y a un problème, alors que cela peut juste vouloir dire que le système est prudent volontairement.
#baby $BABY @BabylonLabs_io
Je faisais défiler la page des statistiques d’Aave et j’ai remarqué que le WBTC a atteint un sommet historique sur V4.
Ma première hypothèse était simple. La demande de levier devait augmenter.
Mais ça ne collait pas complètement. Si la demande d’emprunt le pilotait, les taux devraient aussi grimper.
Alors j’ai vérifié l’app d’Aave plutôt que de supposer.
Au final, les détenteurs de WBTC, cbBTC, WETH et wstETH peuvent actuellement emprunter de l’USDC à environ -0,2%.
Négatif. On vous paie pour contracter le prêt.
C’est à ce moment-là que ça a fait tilt.
Le pic de supply n’est pas seulement une question de conviction envers Bitcoin. Une partie vient de l’arbitrage des taux qui attire le capital de manière presque mécanique.
C’est d’ailleurs pour ça que la proposition <t-2/> @BabylonLabs_io d’Aave a aussi attiré mon attention.
Elle vise à permettre aux prêts natifs en BTC de revenir directement, sans besoin d’envelopper côté dépôt. Mais les liquidations passent encore par WBTC, car Bitcoin ne peut pas confirmer assez vite pour un règlement en temps réel.
Ainsi, même un marché « BTC natif » dépend de WBTC au moment le plus crucial.
Pourquoi construire tout ça avec des taux subventionnés et des solutions de repli enveloppées.
La conception « hub-and-spoke » de Aave V4 permet à chaque marché de définir ses propres incitations tout en partageant la liquidité depuis un hub commun. Cela permet à Aave d’amorcer la profondeur dans de nouveaux marchés, y compris Babylon, au lieu d’attendre une demande organique.
Le compromis, c’est que le « supply record » devient plus difficile à interpréter à première vue.
Une partie relève de la conviction. Une autre, c’est simplement le meilleur taux.
Quand un marché de prêt atteint un sommet historique, comment fait-on d’habitude la différence ?
#baby $BABY
Ma première hypothèse était simple. La demande de levier devait augmenter.
Mais ça ne collait pas complètement. Si la demande d’emprunt le pilotait, les taux devraient aussi grimper.
Alors j’ai vérifié l’app d’Aave plutôt que de supposer.
Au final, les détenteurs de WBTC, cbBTC, WETH et wstETH peuvent actuellement emprunter de l’USDC à environ -0,2%.
Négatif. On vous paie pour contracter le prêt.
C’est à ce moment-là que ça a fait tilt.
Le pic de supply n’est pas seulement une question de conviction envers Bitcoin. Une partie vient de l’arbitrage des taux qui attire le capital de manière presque mécanique.
C’est d’ailleurs pour ça que la proposition <t-2/> @BabylonLabs_io d’Aave a aussi attiré mon attention.
Elle vise à permettre aux prêts natifs en BTC de revenir directement, sans besoin d’envelopper côté dépôt. Mais les liquidations passent encore par WBTC, car Bitcoin ne peut pas confirmer assez vite pour un règlement en temps réel.
Ainsi, même un marché « BTC natif » dépend de WBTC au moment le plus crucial.
Pourquoi construire tout ça avec des taux subventionnés et des solutions de repli enveloppées.
La conception « hub-and-spoke » de Aave V4 permet à chaque marché de définir ses propres incitations tout en partageant la liquidité depuis un hub commun. Cela permet à Aave d’amorcer la profondeur dans de nouveaux marchés, y compris Babylon, au lieu d’attendre une demande organique.
Le compromis, c’est que le « supply record » devient plus difficile à interpréter à première vue.
Une partie relève de la conviction. Une autre, c’est simplement le meilleur taux.
Quand un marché de prêt atteint un sommet historique, comment fait-on d’habitude la différence ?
#baby $BABY
J’ai supposé que le prêt natif de BTC sur la proposition Aave @BabylonLabs_io signifiait que WBTC était hors du tableau.
En fait, ce n’est pas le cas.
J’ai vérifié le temp check sur le forum de gouvernance d’Aave pour m’en assurer.
Les dépôts verrouillent bien directement le BTC natif sur Bitcoin. Mais les liquidations n’y touchent pas du tout.
Lorsqu’une position est liquidée, un liquidateur échange le vault contre du WBTC avec une petite prime. C’est cela qui règle la dette sur Ethereum. Le remboursement réel en Bitcoin intervient séparément, ensuite.
C’est là que j’ai compris.
La séparation existe parce que Bitcoin ne peut pas confirmer assez vite pour qu’une liquidation ait lieu en temps réel. WBTC permet un règlement instantané sur Ethereum, tandis que le déblocage plus lent, une fois le BTC vérifié, se fait selon son propre calendrier.
Donc le vrai compromis n’est pas « BTC natif vs BTC wrapped ».
C’est le fait que le BTC natif garantit le prêt, mais que WBTC porte encore le moment qui compte le plus : la liquidation.
La proposition est encore à un stade précoce : elle se situe au stade du temp check, avant que les audits et les paramètres de risque ne soient finalisés.
Ça me fait me demander comment le marché va valoriser cette courte fenêtre où BTC et WBTC doivent se faire confiance. #baby $BABY
En fait, ce n’est pas le cas.
J’ai vérifié le temp check sur le forum de gouvernance d’Aave pour m’en assurer.
Les dépôts verrouillent bien directement le BTC natif sur Bitcoin. Mais les liquidations n’y touchent pas du tout.
Lorsqu’une position est liquidée, un liquidateur échange le vault contre du WBTC avec une petite prime. C’est cela qui règle la dette sur Ethereum. Le remboursement réel en Bitcoin intervient séparément, ensuite.
C’est là que j’ai compris.
La séparation existe parce que Bitcoin ne peut pas confirmer assez vite pour qu’une liquidation ait lieu en temps réel. WBTC permet un règlement instantané sur Ethereum, tandis que le déblocage plus lent, une fois le BTC vérifié, se fait selon son propre calendrier.
Donc le vrai compromis n’est pas « BTC natif vs BTC wrapped ».
C’est le fait que le BTC natif garantit le prêt, mais que WBTC porte encore le moment qui compte le plus : la liquidation.
La proposition est encore à un stade précoce : elle se situe au stade du temp check, avant que les audits et les paramètres de risque ne soient finalisés.
Ça me fait me demander comment le marché va valoriser cette courte fenêtre où BTC et WBTC doivent se faire confiance. #baby $BABY
Vérifié
Je pensais que les récompenses de co-staking nécessitaient une taille de mise minimale pour que vous voyiez un réel avantage. C’est ainsi que fonctionnent la plupart des systèmes de récompenses échelonnées.
Après avoir consulté le guide officiel de co-staking de Babylon, j’ai découvert que cette hypothèse était fausse. La documentation indique explicitement que le poids de co-staking peut être une valeur décimale quelconque, et qu’il n’est pas nécessaire de miser au moins 1 BTC ou 20 000 BABY pour obtenir des récompenses. Elle aborde directement cela comme un mythe : toute quantité de BTC et de BABY permet de gagner des récompenses de façon proportionnelle, sans seuil minimum intégré dans la formule.
Ce qui m’a surpris, c’est à quel point le mécanisme de liaison est strict malgré cette flexibilité. Les récompenses sont calculées à l’aide d’une formule pondérée qui tient compte à la fois de vos mises en BTC et en BABY ensemble, plutôt que de les traiter comme deux flux de récompenses distincts. Il y a aussi une exigence précise que la plupart des gens manqueraient. Si votre adresse de mise en BTC et votre adresse de mise en BABY sont différentes, vous obtenez zéro récompense de co-staking, donc les deux délégations doivent utiliser exactement la même adresse BABY. Ce n’est pas un bug : c’est ainsi que le protocole attribue le poids à un seul participant entre deux types d’actifs différents. Le compromis est logique : des récompenses proportionnelles maintiennent le système ouvert à tout détenteur, mais la règle de correspondance d’adresse garantit une attribution propre.
Pourtant, cela soulève une vraie question : combien de stakers en BTC sur Babylon renoncent involontairement à des récompenses à cause d’une simple divergence d’adresse ?
#baby $BABY @BabylonLabs_io
Après avoir consulté le guide officiel de co-staking de Babylon, j’ai découvert que cette hypothèse était fausse. La documentation indique explicitement que le poids de co-staking peut être une valeur décimale quelconque, et qu’il n’est pas nécessaire de miser au moins 1 BTC ou 20 000 BABY pour obtenir des récompenses. Elle aborde directement cela comme un mythe : toute quantité de BTC et de BABY permet de gagner des récompenses de façon proportionnelle, sans seuil minimum intégré dans la formule.
Ce qui m’a surpris, c’est à quel point le mécanisme de liaison est strict malgré cette flexibilité. Les récompenses sont calculées à l’aide d’une formule pondérée qui tient compte à la fois de vos mises en BTC et en BABY ensemble, plutôt que de les traiter comme deux flux de récompenses distincts. Il y a aussi une exigence précise que la plupart des gens manqueraient. Si votre adresse de mise en BTC et votre adresse de mise en BABY sont différentes, vous obtenez zéro récompense de co-staking, donc les deux délégations doivent utiliser exactement la même adresse BABY. Ce n’est pas un bug : c’est ainsi que le protocole attribue le poids à un seul participant entre deux types d’actifs différents. Le compromis est logique : des récompenses proportionnelles maintiennent le système ouvert à tout détenteur, mais la règle de correspondance d’adresse garantit une attribution propre.
Pourtant, cela soulève une vraie question : combien de stakers en BTC sur Babylon renoncent involontairement à des récompenses à cause d’une simple divergence d’adresse ?
#baby $BABY @BabylonLabs_io
Vérifié
Je cherchais des calendriers de déblocage de jetons la semaine dernière, et le nom de Babylon revenait sans cesse, alors je me suis plongé dedans.
Ma première hypothèse était l’histoire habituelle : des tokens de l’équipe qui se déversent sur le grand public. Mais les chiffres ne collaient pas tout à fait. L’offre en circulation de BABY se situe autour de 4 milliards sur un total proche de 10 milliards, soit environ 37% débloqués, avec un token qui s’échange autour de 0,011–0,013 $ et une capitalisation boursière dans une fourchette de 45–50 M$. Je suis donc allé consulter la documentation pour vérifier le calendrier réel. C’est là que j’ai compris : Babylon n’utilise pas un modèle unique « cliff-and-dump » (grosse coupure puis déversement). Les premiers investisseurs, l’équipe et les conseillers partagent tous la même structure — un cliff d’un an, puis 35 autres libérations mensuelles de 1/36 chacune, s’étalant de mai 2026 jusqu’à avril 2029. Ce qui m’a surpris, c’est à quel point cette répartition est délibérée. Un écoulement linéaire sur trois ans signifie qu’aucun mois unique ne noie le marché. Le compromis, c’est que la dilution ne s’arrête jamais vraiment : c’est un impôt lent et régulier sur le prix, plutôt qu’un choc unique. Il y a aussi une deuxième couche : BABY affiche une inflation annuelle de 5,5% pour les récompenses de staking, partiellement compensée par la combustion de tokens via les enchères de récompense BSN. Donc l’offre ne se contente pas de se débloquer : elle est aussi créée (mintée) et partiellement brûlée en même temps. Ça me fait me demander : est-ce qu’un drip (déblocage progressif) long et prévisible change réellement le comportement des investisseurs davantage qu’un gros cliff ?
#baby $BABY @BabylonLabs_io
Ma première hypothèse était l’histoire habituelle : des tokens de l’équipe qui se déversent sur le grand public. Mais les chiffres ne collaient pas tout à fait. L’offre en circulation de BABY se situe autour de 4 milliards sur un total proche de 10 milliards, soit environ 37% débloqués, avec un token qui s’échange autour de 0,011–0,013 $ et une capitalisation boursière dans une fourchette de 45–50 M$. Je suis donc allé consulter la documentation pour vérifier le calendrier réel. C’est là que j’ai compris : Babylon n’utilise pas un modèle unique « cliff-and-dump » (grosse coupure puis déversement). Les premiers investisseurs, l’équipe et les conseillers partagent tous la même structure — un cliff d’un an, puis 35 autres libérations mensuelles de 1/36 chacune, s’étalant de mai 2026 jusqu’à avril 2029. Ce qui m’a surpris, c’est à quel point cette répartition est délibérée. Un écoulement linéaire sur trois ans signifie qu’aucun mois unique ne noie le marché. Le compromis, c’est que la dilution ne s’arrête jamais vraiment : c’est un impôt lent et régulier sur le prix, plutôt qu’un choc unique. Il y a aussi une deuxième couche : BABY affiche une inflation annuelle de 5,5% pour les récompenses de staking, partiellement compensée par la combustion de tokens via les enchères de récompense BSN. Donc l’offre ne se contente pas de se débloquer : elle est aussi créée (mintée) et partiellement brûlée en même temps. Ça me fait me demander : est-ce qu’un drip (déblocage progressif) long et prévisible change réellement le comportement des investisseurs davantage qu’un gros cliff ?
#baby $BABY @BabylonLabs_io
Vérifié
Je lisais les chiffres récents de Babylon et un détail a attiré mon attention : le protocole vient de franchir environ 56 000 BTC mis en jeu, quelque part au nord de 5 milliards de dollars de valeur, sans qu’aucun token enveloppé ne soit impliqué. J’ai vu pas mal de projets “Bitcoin DeFi” annoncer des chiffres similaires, donc je me suis dit que c’était simplement un autre wrapper custodial avec un marketing plus efficace.
Cette hypothèse n’a pas résisté cinq minutes face à la documentation.
Le modèle de mise en jeu de Babylon conserve le BTC verrouillé directement sur la blockchain Bitcoin, grâce à des scripts à échéance plutôt que de déplacer des fonds n’importe où. Il n’y a ni pont, ni actif synthétique qui se substitue à votre BTC. Ce qui m’a surpris, c’est à quel point une grande partie du modèle de sécurité repose sur les limites de la programmation côté Bitcoin plutôt que sur des smart contracts. Au lieu de cela, Babylon utilise des transactions pré-signées et des règles de type covenant qui ne s’activent que si un validateur se comporte mal.
C’est là que le vrai compromis m’a sauté aux yeux. Comme Bitcoin ne peut pas “slash” (réduire/penaliser) nativement la mise d’un validateur comme une chaîne EVM peut le faire, Babylon intègre des conditions de slashing dans le processus de désengagement. C’est ingénieux, mais cela signifie aussi que votre BTC reste temporairement illiquide pendant la phase de désengagement, car la garantie de sécurité dépend de cette fenêtre temporelle.
Il y a aussi le design plus récent de mise en jeu multiple, où le même BTC peut sécuriser plusieurs réseaux proof-of-stake à la fois. Plus de rendement, mais aussi plus de validateurs dont le comportement peut avoir une incidence sur votre mise. L’utilisation efficace du capital versus l’exposition concentrée ressemble davantage à la vraie tension : pas une faille, mais un pari assumé.
Je reviens toujours à une question : à mesure que davantage de chaînes se connectent au même pool de Bitcoin mis en jeu, la sécurité partagée évolue-t-elle de façon fluide, ou redistribue-t-elle discrètement le risque au lieu de l’éliminer ?
#baby $BABY @BabylonLabs_io
Cette hypothèse n’a pas résisté cinq minutes face à la documentation.
Le modèle de mise en jeu de Babylon conserve le BTC verrouillé directement sur la blockchain Bitcoin, grâce à des scripts à échéance plutôt que de déplacer des fonds n’importe où. Il n’y a ni pont, ni actif synthétique qui se substitue à votre BTC. Ce qui m’a surpris, c’est à quel point une grande partie du modèle de sécurité repose sur les limites de la programmation côté Bitcoin plutôt que sur des smart contracts. Au lieu de cela, Babylon utilise des transactions pré-signées et des règles de type covenant qui ne s’activent que si un validateur se comporte mal.
C’est là que le vrai compromis m’a sauté aux yeux. Comme Bitcoin ne peut pas “slash” (réduire/penaliser) nativement la mise d’un validateur comme une chaîne EVM peut le faire, Babylon intègre des conditions de slashing dans le processus de désengagement. C’est ingénieux, mais cela signifie aussi que votre BTC reste temporairement illiquide pendant la phase de désengagement, car la garantie de sécurité dépend de cette fenêtre temporelle.
Il y a aussi le design plus récent de mise en jeu multiple, où le même BTC peut sécuriser plusieurs réseaux proof-of-stake à la fois. Plus de rendement, mais aussi plus de validateurs dont le comportement peut avoir une incidence sur votre mise. L’utilisation efficace du capital versus l’exposition concentrée ressemble davantage à la vraie tension : pas une faille, mais un pari assumé.
Je reviens toujours à une question : à mesure que davantage de chaînes se connectent au même pool de Bitcoin mis en jeu, la sécurité partagée évolue-t-elle de façon fluide, ou redistribue-t-elle discrètement le risque au lieu de l’éliminer ?
#baby $BABY @BabylonLabs_io
J’ai supposé que le comité de la clause pouvait geler le Bitcoin d’un staker s’il le voulait. Il ne peut pas déplacer un seul satoshi sans la propre signature du staker.
Chaque sortie de staking sur Babylon a trois façons de la dépenser : le retrait, le désengagement (unbonding) et la slashing. Le comité de la clause cosigne les trois.
Mais cosigner n’est pas la même chose que contrôler. La clé du staker est requise dans chaque voie sauf pour slasher un fournisseur de finalité malveillant. Sans cela, la signature du comité ne sert à rien.
Donc, le comité peut approuver une demande de désengagement. Il peut appliquer le délai (timelock) et le pourcentage de slashing. Ce qu’il ne peut pas faire, en revanche, c’est rediriger les fonds, accélérer la sortie, ou slasher un staker honnête — parce qu’il ne détient jamais la clé unique qui rend l’une de ces voies dépensables.
Un groupe qui doit cosigner chaque transaction paraît puissant de l’extérieur. Regardez de plus près : ce n’est qu’un vérificateur de règles, sans aucun moyen de contourner les règles qu’il vérifie.
#baby $BABY @BabylonLabs_io
Chaque sortie de staking sur Babylon a trois façons de la dépenser : le retrait, le désengagement (unbonding) et la slashing. Le comité de la clause cosigne les trois.
Mais cosigner n’est pas la même chose que contrôler. La clé du staker est requise dans chaque voie sauf pour slasher un fournisseur de finalité malveillant. Sans cela, la signature du comité ne sert à rien.
Donc, le comité peut approuver une demande de désengagement. Il peut appliquer le délai (timelock) et le pourcentage de slashing. Ce qu’il ne peut pas faire, en revanche, c’est rediriger les fonds, accélérer la sortie, ou slasher un staker honnête — parce qu’il ne détient jamais la clé unique qui rend l’une de ces voies dépensables.
Un groupe qui doit cosigner chaque transaction paraît puissant de l’extérieur. Regardez de plus près : ce n’est qu’un vérificateur de règles, sans aucun moyen de contourner les règles qu’il vérifie.
#baby $BABY @BabylonLabs_io
Je lisais la mise à jour du testnet TBV, en la parcourant à moitié — peg-in ramené à trois heures, frais divisés par trois. Progrès solides.
Puis une ligne m’a arrêté : les plans de pause de Babylon pour faire un pont entre leur propre jeton BABY et Ethereum, en invoquant des préoccupations de sécurité liées aux ponts.
Bizarre, pour un protocole qui affirme : « nous avons résolu le problème des ponts ».
Mais ce n’est pas une contradiction : c’est une nuance. Un pont normal émet un jeton enveloppé par confiance — si on casse la logique, quelqu’un émet à partir de rien. TBV ne déplace jamais lui-même le BTC. Il déplace une revendication cryptographiquement contrainte à son sujet, appliquée par le script et des preuves, et non par la parole d’un validateur.
Donc l’équipe fait confiance à ce modèle avec le Bitcoin réel de clients. Juste pas encore avec leur propre jeton.
C’est plus honnête que ce que la plupart des lancements admettent. Mais cela laisse la question la plus difficile en suspens : que « l’état vérifiable sur Ethereum » est encore, fonctionnellement, une représentation vivant sur une deuxième chaîne — la même forme qu’un pont produit, avec une confiance différente en dessous.
Si c’est assez sûr pour le vrai BTC, pourquoi pas BABY — et si ce n’est pas le cas, que dit ce manque d’écart sur le niveau de confiance qu’ils lui accordent réellement à grande échelle ?
#baby $BABY @BabylonLabs_io
Puis une ligne m’a arrêté : les plans de pause de Babylon pour faire un pont entre leur propre jeton BABY et Ethereum, en invoquant des préoccupations de sécurité liées aux ponts.
Bizarre, pour un protocole qui affirme : « nous avons résolu le problème des ponts ».
Mais ce n’est pas une contradiction : c’est une nuance. Un pont normal émet un jeton enveloppé par confiance — si on casse la logique, quelqu’un émet à partir de rien. TBV ne déplace jamais lui-même le BTC. Il déplace une revendication cryptographiquement contrainte à son sujet, appliquée par le script et des preuves, et non par la parole d’un validateur.
Donc l’équipe fait confiance à ce modèle avec le Bitcoin réel de clients. Juste pas encore avec leur propre jeton.
C’est plus honnête que ce que la plupart des lancements admettent. Mais cela laisse la question la plus difficile en suspens : que « l’état vérifiable sur Ethereum » est encore, fonctionnellement, une représentation vivant sur une deuxième chaîne — la même forme qu’un pont produit, avec une confiance différente en dessous.
Si c’est assez sûr pour le vrai BTC, pourquoi pas BABY — et si ce n’est pas le cas, que dit ce manque d’écart sur le niveau de confiance qu’ils lui accordent réellement à grande échelle ?
#baby $BABY @BabylonLabs_io
Je décrivais l’intégration d’Aave de Babylon à un ami, et j’ai dit — sans réfléchir — « pas de wrapping, jamais. »
Il m’a posé une seule question : si le BTC ne quitte jamais Bitcoin, comment Aave — qui vit sur Ethereum — le voit-il réellement ? Je n’avais pas de vraie réponse. Alors je suis retourné à la proposition elle-même, au lieu des résumés que tout le monde partage.
J’ai supposé que j’y trouverais quelque chose de malin, du genre qu’Aave traverse les chaînes pour lire le Bitcoin directement.
Ce n’est pas ce que j’ai trouvé. J’ai trouvé un token. Le design de Babylon crée quelque chose appelé vaultBTC sur Ethereum, destiné à servir de substitut au BTC verrouillé sur Bitcoin.
Ça m’a stoppé net une seconde. Un token qui se substitue à un actif verrouillé sur une autre chaîne, c’est une forme que j’ai déjà vue maintes fois. Mon premier réflexe a été : est-ce que ce n’est pas juste du wrapping avec un nom plus sympa ?
Puis j’ai regardé de plus près ce qui sert réellement de garantie à ce token.
La plupart des actifs “wraps” vous obligent à faire confiance à quelqu’un — un custodian, un pont — pour garantir que le véritable actif est bien là où il prétend être.
vaultBTC cherche à remplacer cette confiance par une preuve. Le vault utilise des conditions pré-signées sur Bitcoin lui-même ; la légitimité du token vient donc de la cryptographie plutôt que de la parole de quelqu’un. C’est là que j’ai compris. La vraie question n’a jamais été « wrapped ou non wrapped ».
C’est « représentation de confiance ou représentation prouvée ». Les deux nécessitent encore quelque chose d’existant sur l’autre chaîne. Mais l’une des deux vous demande de croire une personne, alors que l’autre s’appuie sur les mathématiques.
Quand j’ai vu les choses ainsi, « pas de wrapping » a cessé de ressembler à une affirmation et a commencé à ressembler à une simplification — vraie dans l’esprit, mais en omettant le détail qui compte vraiment. Ce que je ne sais toujours pas, c’est dans quelle mesure cette preuve résiste à la pression. Des marchés calmes, c’est facile. Une liquidation en retard, ou un désaccord sur le fait que le vault correspond vraiment à ce que vaultBTC affirme : c’est là que « prouvé » et « de confiance » montreraient une différence.
Je me demande encore si ce moment a déjà eu lieu quelque part, et si ça n’a tout simplement pas été assez bruyant pour qu’on le remarque.
Est-ce que quelqu’un ici a déjà vu vaultBTC être réellement testé de cette façon ?
#baby $BABY @BabylonLabs_io
Il m’a posé une seule question : si le BTC ne quitte jamais Bitcoin, comment Aave — qui vit sur Ethereum — le voit-il réellement ? Je n’avais pas de vraie réponse. Alors je suis retourné à la proposition elle-même, au lieu des résumés que tout le monde partage.
J’ai supposé que j’y trouverais quelque chose de malin, du genre qu’Aave traverse les chaînes pour lire le Bitcoin directement.
Ce n’est pas ce que j’ai trouvé. J’ai trouvé un token. Le design de Babylon crée quelque chose appelé vaultBTC sur Ethereum, destiné à servir de substitut au BTC verrouillé sur Bitcoin.
Ça m’a stoppé net une seconde. Un token qui se substitue à un actif verrouillé sur une autre chaîne, c’est une forme que j’ai déjà vue maintes fois. Mon premier réflexe a été : est-ce que ce n’est pas juste du wrapping avec un nom plus sympa ?
Puis j’ai regardé de plus près ce qui sert réellement de garantie à ce token.
La plupart des actifs “wraps” vous obligent à faire confiance à quelqu’un — un custodian, un pont — pour garantir que le véritable actif est bien là où il prétend être.
vaultBTC cherche à remplacer cette confiance par une preuve. Le vault utilise des conditions pré-signées sur Bitcoin lui-même ; la légitimité du token vient donc de la cryptographie plutôt que de la parole de quelqu’un. C’est là que j’ai compris. La vraie question n’a jamais été « wrapped ou non wrapped ».
C’est « représentation de confiance ou représentation prouvée ». Les deux nécessitent encore quelque chose d’existant sur l’autre chaîne. Mais l’une des deux vous demande de croire une personne, alors que l’autre s’appuie sur les mathématiques.
Quand j’ai vu les choses ainsi, « pas de wrapping » a cessé de ressembler à une affirmation et a commencé à ressembler à une simplification — vraie dans l’esprit, mais en omettant le détail qui compte vraiment. Ce que je ne sais toujours pas, c’est dans quelle mesure cette preuve résiste à la pression. Des marchés calmes, c’est facile. Une liquidation en retard, ou un désaccord sur le fait que le vault correspond vraiment à ce que vaultBTC affirme : c’est là que « prouvé » et « de confiance » montreraient une différence.
Je me demande encore si ce moment a déjà eu lieu quelque part, et si ça n’a tout simplement pas été assez bruyant pour qu’on le remarque.
Est-ce que quelqu’un ici a déjà vu vaultBTC être réellement testé de cette façon ?
#baby $BABY @BabylonLabs_io
Partiellement vrai
Je lisais la configuration de checkpointing de Babylon et il y a un détail qui m’a pris un moment pour comprendre pleinement.
La plupart des chaînes Cosmos utilisent une période de désunbonding de 21 jours comme filet de sécurité principal. C’est ainsi qu’elles se protègent contre quelqu’un qui essaierait de réécrire l’histoire. Mais Babylon ne pouvait pas vraiment conserver ça une fois qu’elle a commencé à s’ancrer à Bitcoin, car désormais elle dépend du timing de Bitcoin plutôt que de celui de Cosmos. Du coup, au lieu de ça, ils ont construit un module d’« epoching » (périodisation). Des blocs sont regroupés dans des fenêtres fixes, et chaque fenêtre est checkpointée sur Bitcoin comme un lot unique. D’après ce que j’ai vu sur testnet, les epochs durent environ une heure, en regroupant quelques centaines de blocs à chaque fois.
Au début, ça m’a juste semblé être un détail interne, pas quelque chose qui mérite qu’on s’y attarde. Mais en réalité, ça change beaucoup la façon dont la chaîne se comporte. Les changements de validateurs ne peuvent plus simplement se produire quand bon leur semble. Les nouveaux validateurs, les sorties, les redélégations, tout ça doit attendre que la frontière d’epoch arrive. La logique de désunbonding a aussi dû être repensée : on s’est éloigné des minuteries habituelles de Cosmos pour quelque chose de construit autour de la façon dont Bitcoin confirme les choses.
En contrepartie, Babylon obtient quelque chose qui est réellement difficile à reproduire ailleurs. La réécriture de l’histoire n’est plus un problème de consensus social : cela devient un problème d’attaque contre Bitcoin, ce qui est bien plus exigeant pour quiconque voudrait le faire. Ce que je remarque constamment, c’est que la finalité ici ne fonctionne pas avec une seule horloge. Il y a le côté Cosmos qui avance à son propre rythme, et le côté Bitcoin qui suit un tempo plus lent, distinct. Donc quand les gens disent que Babylon emprunte la sécurité de Bitcoin, il y a un coût mécanique concret derrière, pas juste une affirmation joliment formulée. Je ne pense pas que ce soit un patch ajouté plus tard : ça ressemble à quelque chose intégré dès le départ. J’essaie encore de déterminer à quel point ce couplage compte concrètement, mais c’est un de ces choix de conception faciles à manquer si on ne regarde pas attentivement.
@BabylonLabs_io $BABY #BABY
La plupart des chaînes Cosmos utilisent une période de désunbonding de 21 jours comme filet de sécurité principal. C’est ainsi qu’elles se protègent contre quelqu’un qui essaierait de réécrire l’histoire. Mais Babylon ne pouvait pas vraiment conserver ça une fois qu’elle a commencé à s’ancrer à Bitcoin, car désormais elle dépend du timing de Bitcoin plutôt que de celui de Cosmos. Du coup, au lieu de ça, ils ont construit un module d’« epoching » (périodisation). Des blocs sont regroupés dans des fenêtres fixes, et chaque fenêtre est checkpointée sur Bitcoin comme un lot unique. D’après ce que j’ai vu sur testnet, les epochs durent environ une heure, en regroupant quelques centaines de blocs à chaque fois.
Au début, ça m’a juste semblé être un détail interne, pas quelque chose qui mérite qu’on s’y attarde. Mais en réalité, ça change beaucoup la façon dont la chaîne se comporte. Les changements de validateurs ne peuvent plus simplement se produire quand bon leur semble. Les nouveaux validateurs, les sorties, les redélégations, tout ça doit attendre que la frontière d’epoch arrive. La logique de désunbonding a aussi dû être repensée : on s’est éloigné des minuteries habituelles de Cosmos pour quelque chose de construit autour de la façon dont Bitcoin confirme les choses.
En contrepartie, Babylon obtient quelque chose qui est réellement difficile à reproduire ailleurs. La réécriture de l’histoire n’est plus un problème de consensus social : cela devient un problème d’attaque contre Bitcoin, ce qui est bien plus exigeant pour quiconque voudrait le faire. Ce que je remarque constamment, c’est que la finalité ici ne fonctionne pas avec une seule horloge. Il y a le côté Cosmos qui avance à son propre rythme, et le côté Bitcoin qui suit un tempo plus lent, distinct. Donc quand les gens disent que Babylon emprunte la sécurité de Bitcoin, il y a un coût mécanique concret derrière, pas juste une affirmation joliment formulée. Je ne pense pas que ce soit un patch ajouté plus tard : ça ressemble à quelque chose intégré dès le départ. J’essaie encore de déterminer à quel point ce couplage compte concrètement, mais c’est un de ces choix de conception faciles à manquer si on ne regarde pas attentivement.
@BabylonLabs_io $BABY #BABY
J’ai continué à lire « slashing » dans la documentation de Babylon en supposant que cela fonctionnait comme sur Ethereum. Ce n’est pas le cas, et la différence est la partie intéressante.
Sur Ethereum, un validateur est pénalisé pour deux choses : l’équivoque (signer des blocs contradictoires) et les fuites d’inactivité (rester hors ligne pendant un défaut de vivacité). Les deux vous coûtent de l’argent. Babylon ne procède au slashing que pour la première. Si un fournisseur de finalité signe en double, sa clé est exposée et le BTC qui est derrière est brûlé. S’ils passent simplement dans l’ombre, cessent de voter ou refusent de finaliser des blocs, il ne se passe rien à la mise. Ils sont mis en prison (jail). Les délégateurs gardent chaque satoshi. On dirait un détail d’implémentation mineur. Ce n’est pas le cas. Cela signifie que la « sécurité Bitcoin » qu’un BSN achète ne se défend que contre une attaque très spécifique et délibérée : quelqu’un qui signe deux blocs contradictoires et incendie sa propre mise pour le faire. Cela ne fait rien contre un ensemble de validateurs qui arrête simplement de produire des blocs, ou censure de façon sélective des transactions, ou traîne les pieds pendant un moment conflictuel.
Ce sont, à bien des égards, des menaces plus réalistes auxquelles une jeune chaîne PoS est réellement confrontée.
Donc, quand un BSN dit qu’il est « sécurisé par des milliards de Bitcoin », ce qui est effectivement mis en jeu derrière cette affirmation est une promesse plus étroite que ce que le chiffre laisse entendre. Le capital est réel. La garantie de sécurité est réelle. La garantie de vivacité, la chose qui rend une chaîne résistante à la censure et vivante en période de tension, n’est soutenue par aucun slashing.
Si Bitcoin ne peut pas être slashed pour le silence, combien vaut réellement ce silence pour les chaînes qui le louent ?
#baby $BABY @BabylonLabs_io
Sur Ethereum, un validateur est pénalisé pour deux choses : l’équivoque (signer des blocs contradictoires) et les fuites d’inactivité (rester hors ligne pendant un défaut de vivacité). Les deux vous coûtent de l’argent. Babylon ne procède au slashing que pour la première. Si un fournisseur de finalité signe en double, sa clé est exposée et le BTC qui est derrière est brûlé. S’ils passent simplement dans l’ombre, cessent de voter ou refusent de finaliser des blocs, il ne se passe rien à la mise. Ils sont mis en prison (jail). Les délégateurs gardent chaque satoshi. On dirait un détail d’implémentation mineur. Ce n’est pas le cas. Cela signifie que la « sécurité Bitcoin » qu’un BSN achète ne se défend que contre une attaque très spécifique et délibérée : quelqu’un qui signe deux blocs contradictoires et incendie sa propre mise pour le faire. Cela ne fait rien contre un ensemble de validateurs qui arrête simplement de produire des blocs, ou censure de façon sélective des transactions, ou traîne les pieds pendant un moment conflictuel.
Ce sont, à bien des égards, des menaces plus réalistes auxquelles une jeune chaîne PoS est réellement confrontée.
Donc, quand un BSN dit qu’il est « sécurisé par des milliards de Bitcoin », ce qui est effectivement mis en jeu derrière cette affirmation est une promesse plus étroite que ce que le chiffre laisse entendre. Le capital est réel. La garantie de sécurité est réelle. La garantie de vivacité, la chose qui rend une chaîne résistante à la censure et vivante en période de tension, n’est soutenue par aucun slashing.
Si Bitcoin ne peut pas être slashed pour le silence, combien vaut réellement ce silence pour les chaînes qui le louent ?
#baby $BABY @BabylonLabs_io
Vérifié
3M$ ne représente pas grand-chose pour une fondation qui soutient un protocole sécurisant 10G$+ en BTC. Mais le fait que cela ait bougé mérite d’être noté.
Après l’exploit du Kelp DAO, qui a déstabilisé les marchés rsETH et s’est propagé à Aave fin avril 2026, la Babylon Foundation a engagé 3M$ pour l’effort de relance DeFi — 2M$ vers Aave v3, 1M$ vers Aave v4. Babylon n’était pas le protocole qui a été exploité. Les utilisateurs de TBV n’étaient pas en danger. Les coffres ont continué de fonctionner exactement comme prévu.
L’allocation en v4 mérite qu’on s’y attarde. Il s’agit des mêmes $AAVE version Trustless Bitcoin Vaults qui sont en cours de construction pour être utilisés comme route vers laquelle achemine l’emprunt adossé à des BTC. Babylon n’a pas simplement fait un don à un partenaire en difficulté — elle a injecté des fonds spécifiquement dans la couche applicative dont sa feuille de route dépend pour rester solvable et crédible.
La plupart des diligences raisonnables sur TBV portent sur la cryptographie : preuves de peg-in, conditions des coffres, absence de dépositaire dans la boucle. Rien de tout cela ne couvre ce qui se passe lorsque le marché de prêt dans lequel vous vous branchez est touché par l’exploit de quelqu’un d’autre. C’est une question de comportement d’une fondation, pas de conception d’un protocole, et elle n’apparaît pas dans un livre blanc.
Babylon y a répondu en avril, avant que la plupart des gens ne le suivent comme un signal. Si le BTC doit servir de collatéral en $AAVE v4 via TBV, ces 3M$ constituent un point de données plus utile que tout ce qu’on trouve dans le testnet.
#baby $BABY @BabylonLabs_io
Après l’exploit du Kelp DAO, qui a déstabilisé les marchés rsETH et s’est propagé à Aave fin avril 2026, la Babylon Foundation a engagé 3M$ pour l’effort de relance DeFi — 2M$ vers Aave v3, 1M$ vers Aave v4. Babylon n’était pas le protocole qui a été exploité. Les utilisateurs de TBV n’étaient pas en danger. Les coffres ont continué de fonctionner exactement comme prévu.
L’allocation en v4 mérite qu’on s’y attarde. Il s’agit des mêmes $AAVE version Trustless Bitcoin Vaults qui sont en cours de construction pour être utilisés comme route vers laquelle achemine l’emprunt adossé à des BTC. Babylon n’a pas simplement fait un don à un partenaire en difficulté — elle a injecté des fonds spécifiquement dans la couche applicative dont sa feuille de route dépend pour rester solvable et crédible.
La plupart des diligences raisonnables sur TBV portent sur la cryptographie : preuves de peg-in, conditions des coffres, absence de dépositaire dans la boucle. Rien de tout cela ne couvre ce qui se passe lorsque le marché de prêt dans lequel vous vous branchez est touché par l’exploit de quelqu’un d’autre. C’est une question de comportement d’une fondation, pas de conception d’un protocole, et elle n’apparaît pas dans un livre blanc.
Babylon y a répondu en avril, avant que la plupart des gens ne le suivent comme un signal. Si le BTC doit servir de collatéral en $AAVE v4 via TBV, ces 3M$ constituent un point de données plus utile que tout ce qu’on trouve dans le testnet.
#baby $BABY @BabylonLabs_io
L’évolution du prix du BTC paraît plutôt ennuyeuse pour l’instant. Mais le flux d’ordres en dessous ne l’est pas.
Bitcoin est coincé dans la fourchette 64K$-67K$ depuis quelques semaines, encore en forte baisse par rapport au sommet à 126K$ d’octobre. Rien de spectaculaire à première vue. Pourtant, des données de CryptoQuant de cette semaine montrent quelque chose qui mérite d’être observé. Les portefeuilles qui détiennent 1 000 à 10 000 BTC viennent d’enregistrer leur plus forte accumulation sur 60 jours depuis la mi-juin : environ 66 700 BTC achetés.
Pendant ce temps, les détenteurs de “niveau intermédiaire”, dans la tranche 100-1 000 BTC, ont déchargé environ 77 800 BTC sur la même période. Des gros portefeuilles achètent, les moyens vendent en face. Maintenant, associez cela à quelque chose dont presque personne ne parle. L’Indice de Prime Bitcoin de Coinbase — essentiellement un indicateur de la pression d’achat aux États-Unis — est négatif depuis 60 jours d’affilée. La plus longue série jamais enregistrée. La demande institutionnelle qui a porté le rallye de 2024 s’est pratiquement tue, même pendant que les baleines continuent d’ajouter.
Accumuler sans “offre” institutionnelle derrière, c’est une situation étrange pour un marché. Ce n’est pas automatiquement haussier et ce n’est pas automatiquement non plus un piège. Historiquement, ce type de configuration se résout soit par un squeeze sur l’offre, soit par une stagnation pendant un moment. La Fed se réunit les 28-29 juillet. Ça devrait probablement l’orienter dans un sens ou dans l’autre.
Je me demande si quelqu’un d’autre regarde cet indice de prime, ou si j’en fais trop avec ça. #BitcoinReclaims65K $BTC
Bitcoin est coincé dans la fourchette 64K$-67K$ depuis quelques semaines, encore en forte baisse par rapport au sommet à 126K$ d’octobre. Rien de spectaculaire à première vue. Pourtant, des données de CryptoQuant de cette semaine montrent quelque chose qui mérite d’être observé. Les portefeuilles qui détiennent 1 000 à 10 000 BTC viennent d’enregistrer leur plus forte accumulation sur 60 jours depuis la mi-juin : environ 66 700 BTC achetés.
Pendant ce temps, les détenteurs de “niveau intermédiaire”, dans la tranche 100-1 000 BTC, ont déchargé environ 77 800 BTC sur la même période. Des gros portefeuilles achètent, les moyens vendent en face. Maintenant, associez cela à quelque chose dont presque personne ne parle. L’Indice de Prime Bitcoin de Coinbase — essentiellement un indicateur de la pression d’achat aux États-Unis — est négatif depuis 60 jours d’affilée. La plus longue série jamais enregistrée. La demande institutionnelle qui a porté le rallye de 2024 s’est pratiquement tue, même pendant que les baleines continuent d’ajouter.
Accumuler sans “offre” institutionnelle derrière, c’est une situation étrange pour un marché. Ce n’est pas automatiquement haussier et ce n’est pas automatiquement non plus un piège. Historiquement, ce type de configuration se résout soit par un squeeze sur l’offre, soit par une stagnation pendant un moment. La Fed se réunit les 28-29 juillet. Ça devrait probablement l’orienter dans un sens ou dans l’autre.
Je me demande si quelqu’un d’autre regarde cet indice de prime, ou si j’en fais trop avec ça. #BitcoinReclaims65K $BTC
Une dernière prédiction. Un dernier coup de sifflet. ⚽🔥 Que mon pronostic gagne ou perde, c’est une expérience incroyable de suivre chaque match. Bonne chance à tous ceux qui font leur dernier choix—terminons le Football Challenge en force ! 🍀⚽ #BinancePickAndWin #BinancePickAndWin
Connectez-vous pour découvrir plus de contenu