Sijan18

#dusk $DUSK @Dusk Je me suis intéressé à la manière dont Citadel gère l’argument « une KYC, vérifiez partout ». L’idée semble simple : vérifier une fois, puis permettre aux institutions de consulter vos informations d’identification sans recommencer tout le processus. Mais « partout » fait un travail intéressant.
Lorsque vous demandez une licence à un License Provider (fournisseur de licences), vous envoyez une adresse furtive — une adresse unique, générée spécifiquement pour ce LP. Le LP signe la licence, la lie à cette adresse et la frappe sous forme de NFT. Vous pouvez ensuite prouver à un Service Provider que vous détenez une licence valide, sans révéler les données d’identité sous-jacentes.
La partie intéressante arrive quand vous utilisez différents LP. Si NPEX délivre une première attestation et qu’une autre bourse en délivre une seconde, ces licences utilisent des adresses furtives distinctes et produisent des preuves séparées, impossibles à relier entre elles. Aucun fil d’identité commun ne les relie.
Au départ, j’ai supposé que « une KYC pour partout » signifiait une seule identité vérifiée que les institutions pourraient recouper. Citadel semble au contraire adopter presque l’approche inverse : vérifier une fois par LP, puis prouver que vous détenez la preuve, sans révéler que vous êtes la même personne que celle vue ailleurs.
Cela me rappelle l’argent liquide par rapport à une carte de crédit. Une carte utilisable partout crée une trace. Utiliser du cash dans différents magasins rend chaque transaction plus difficile à relier — mais chaque magasin vous voit aussi comme un inconnu, même si vous y êtes déjà allé.
Cet arbitrage a du sens du point de vue de la confidentialité. Si les bourses pouvaient corréler la même personne vérifiée entre des plateformes concurrentes, une seule base de données client compromise pourrait révéler ses activités ailleurs.
Mais je me demande encore si les institutions réglementées préféreront réellement ce modèle de confidentialité par fragmentation, ou si, à terme, elles exigeront une identité unique qu’elles pourront auditer sur l’ensemble de leur base de clients.

#dusk $DUSK #dusk $DUSK @Dusk Je me suis mis à chercher pourquoi Dusk ne cesse de ramener les PME, en m’attendant à une nouvelle histoire du type « les RWA représentent un énorme marché ». Mais je me suis retrouvé bloqué sur quelque chose de beaucoup plus simple : que se passe-t-il quand quelqu’un détient une partie d’une entreprise privée et veut réellement la vendre ?
Pour une entreprise cotée en bourse, vous avez une bourse, des courtiers, des acheteurs, une infrastructure de règlement — toute la machine existe déjà. Pour une petite entreprise privée, le marché secondaire peut, en gros, être… rien du tout. Vous pouvez détenir les actions, mais trouver un acheteur et finaliser le transfert de manière conforme peut être un problème totalement différent.
Cela a fait « cliquer » pour moi l’angle PME de Dusk, mais d’une autre façon.
Le point intéressant n’est pas seulement de mettre les fonds propres onchain. Il s’agit de faire travailler ensemble des investisseurs vérifiés, des règles d’éligibilité, des restrictions de transfert et le règlement, afin qu’un transfert conforme puisse réellement avoir lieu sans devoir reconstruire manuellement tout le processus à chaque fois.
Ça m’a rappelé le fait de mettre une maison en vente dans une ville où il n’y a pas de vrais agents immobiliers, pas de site d’annonces et pas de paperasse standard. Rendre la maison numérique ne crée pas le marché. Il faut d’abord l’infrastructure qui permet aux acheteurs et aux vendeurs de se rencontrer et de transiger.
Et c’est aussi, je pense, là que l’histoire devient plus difficile.
Dusk peut rendre une action de PME transférable. Il peut rendre la conformité autour de ce transfert programmable. Mais il ne peut pas, par magie, créer la demande. Si personne ne veut acheter les actions, le règlement instantané ne résout pas le problème de liquidité.
Alors je commence à voir la thèse « PME » moins comme « tokeniser plus d’entreprises » et davantage comme « rendre possible un marché secondaire là où l’infrastructure traditionnelle n’était pas assez rentable pour en construire un ».
Ça ressemble à une question bien plus vaste.
Si ça fonctionne réellement, quelles PME seront débloquées en premier — des entreprises avec des employés qui attendent de vendre leurs actions, des entreprises familiales établies, ou des entreprises privées à croissance rapide dont les investisseurs veulent une sortie ?
#Dusk

#dusk $DUSK J’ai vérifié aujourd’hui l’état de ma transaction sur l’explorateur de testnet DuskEVM, en m’attendant aux deux états habituels — en attente (pending) ou confirmé (confirmed). J’en ai trouvé quatre.

Il s’avère que Dusk ne considère pas la confirmation comme un instant unique. Un bloc passe d’abord à Accepted — il a franchi les trois étapes de consensus de la ronde en cours. Puis Confirmed — ensuite, des blocs s’appuient dessus. Puis Stable — suffisamment enfoui pour qu’on puisse le réverser soit improbable, mais pas impossible. Le quatrième état, Final, est le seul qui le verrouille réellement grâce à une garantie cryptographique : il ne peut jamais être inversé, quoi qu’il arrive après.

Ça m’a rappelé une décision de justice. « Decided » n’est pas la même chose que « non susceptible d’appel ». Un juge peut rendre une décision aujourd’hui et elle peut encore être infirmée en appel pendant des semaines. Ce n’est qu’une fois que chaque délai d’appel est expiré que la décision devient réellement finale — tout ce qui vient avant n’est qu’une opinion forte, avec une échéance attachée.

Ce qui m’a frappé, c’est que la plupart des chaînes que j’ai utilisées traitent la confirmation comme binaire : faite ou pas faite. Dusk la divise en quatre garanties distinctes, chacune plus forte que la précédente, parce qu’un règlement encadré ne peut pas se permettre de traiter « probablement permanent » comme « garanti permanent » — l’écart entre Stable et Final est exactement la ligne de démarcation entre ce qui suffit pour la plupart des gens et ce qui suffit à un régulateur.

Alors, chaque intégration doit-elle attendre Final à chaque fois, ou Stable est-il en fait suffisant pour tout ce qui n’est pas la dernière étape d’un règlement réel ?

@Dusk $DUSK #dusk

#dusk $DUSK @Dusk J’ai essayé aujourd’hui de m’inscrire sur la page d’attente de Dusk Trade, m’attendant au rituel habituel — télécharger une pièce d’identité, un selfie, puis attendre qu’un humain vérifie. Ce n’est pas comme ça que c’est construit.

En fait, Dusk gère l’éligibilité via quelque chose appelé Citadel. Un fournisseur de licence vous vérifie une fois, hors chaîne (off-chain), puis vous remet une crédentiale privée. Ensuite, vous ne remettez plus jamais votre pièce d’identité à qui que ce soit : vous générez une preuve à divulgation nulle de connaissance (zero-knowledge) indiquant que vous détenez une crédentiale valide, sans révéler laquelle, votre portefeuille (wallet) ou les détails derrière. La chaîne ne voit que la preuve qui a été validée.

Voici le point qui m’a fait réfléchir à deux fois : Citadel ne décide pas si vous êtes admis quelque part. Elle ne fait que prouver que la crédentiale est réelle. Chaque lieu choisit encore quels fournisseurs de licence il accepte et ce qu’il souhaite. Ce n’est pas une faille qu’ils auraient manquée — un MTF néerlandais et un broker allemand ne fonctionnent pas avec les mêmes règles ; une seule liste blanche universelle on-chain ne pourrait jamais satisfaire les deux. Détacher « prouver qu’elle est valide » de « qui l’accepte » permet à une même crédentiale de fonctionner dans plusieurs lieux quand, légalement, ils ne peuvent pas s’accorder sur une norme unique.

Ça m’a fait penser à flasher un bracelet qui prouve que vous êtes assez âgé pour entrer, sans jamais remettre votre pièce d’identité à l’entrée — sauf que, dans la rue, chaque lieu applique une loi sur l’âge différente, et le bracelet ne prouve que le fait, jamais leur règle locale.

Alors, est-ce que ça rend réellement plus facile le passage entre des lieux réglementés avec une seule crédentiale, ou bien est-ce que ça signifie simplement que chaque lieu reconstruit discrètement son propre dispositif de contrôle derrière les coulisses, et que « permissionless » finit par n’être qu’une simple approximation dans la manière dont la conformité fonctionne vraiment ici ?

Cette semaine, j’ai continué de comparer côte à côte les deux systèmes de confidentialité de Dusk, et une différence a presque échappé à mon attention — jusqu’à ce qu’elle ne m’échappe plus.

La couche de confidentialité d’origine de Dusk, Zedger, a été conçue sur un modèle UTXO — le même type de modèle que celui qui permet aux outils de confidentialité de type Bitcoin de masquer l’identité de qui effectue réellement des transactions. Hedger, le nouvel moteur de confidentialité pour DuskEVM, ne fonctionne pas de cette manière. Il s’appuie sur un modèle de compte, car c’est ce qui le rend compatible avec les portefeuilles et outils Ethereum « standards ». Le chiffrement homomorphe et les preuves à divulgation nulle garantissent que les montants et les soldes restent entièrement chiffrés de bout en bout. Mais le compte lui-même — l’adresse qui envoie et qui reçoit — demeure visible. Hedger masque ce qui a bougé. Il ne masque pas qui l’a fait.

On dirait un relevé bancaire avec chaque montant en dollars masqué, mais votre nom reste clairement imprimé en haut. Une vraie confidentialité sur les chiffres. Aucune sur l’identité qui leur est associée.

Ce n’est pas un « bug » qu’ils cachent — c’est le compromis réel du fait de passer à une compatibilité EVM plutôt qu’à un modèle basé sur UTXO. L’anonymat total et la compatibilité totale avec les portefeuilles et outils existants d’Ethereum ne viennent pas ensemble « en pack ». Dusk a choisi, intentionnellement, la compatibilité et une confidentialité vérifiable plutôt que l’anonymat, parce que les institutions réglementées doivent de toute façon pouvoir prouver leur identité.

Du coup, pour le public réel que Dusk vise — des fonds réglementés, des courtiers agréés — cacher l’identité est-elle quelque chose qu’ils voudraient, ou vaut-il mieux avoir des montants confidentiels avec une responsabilité visible ?

@Dusk $DUSK #dusk

#dusk $DUSK

Aujourd’hui, j’ai relié certains DUSK à DuskEVM et j’ai continué à rafraîchir le tracker comme si ça allait changer quelque chose. Ma transaction s’est affichée comme « incluse » presque tout de suite. Puis elle est restée là pendant un moment avant que l’on ne dise finalement « réglée ». J’ai supposé que ce décalage était juste un lag de l’interface.

Mais non. DuskEVM fonctionne sur un cycle de rollup : un sequencer inclut votre transaction dans un bloc L2 rapidement, mais ce n’est pas la même étape que le règlement. Un batcher distinct doit publier ces données sur DuskDS — la propre couche de consensus et de disponibilité des données de Dusk — et ce n’est qu’une fois que les engagements d’état et les preuves de faute font le lien avec cette couche que quelque chose est réellement réglé. « Incluse » et « réglée » sont deux promesses différentes, faites par deux parties différentes de la pile.

J’avais l’impression d’un colis affichant « en cours de livraison » dès qu’il quitte l’entrepôt, bien avant qu’il ne soit réellement sur votre pas de porte. Les deux sont vrais. Mais ce n’est pas la même affirmation.

Ce qui ressort, c’est que vous ne devez pas le deviner à partir du temps écoulé. Déplacer de la valeur entre DuskEVM et le Dusk L1 implique de vérifier l’état réel via le protocole ou le portefeuille, pas de supposer qu’assez de minutes se sont écoulées. Pour quelque chose censé transporter des actifs financiers réglementés, ce n’est pas un détail mineur — un fonds ne peut pas se régler sur une supposition.

Du coup, cette conception en deux étapes devient-elle un argument de vente quand des institutions commencent réellement à s’appuyer dessus, ou bien est-ce juste un obstacle UX sur lequel les utilisateurs réguliers rebondissent avant de comprendre pourquoi c’est construit comme ça ?

@Dusk $DUSK #dusk

#dusk $DUSK

J’ai clôturé mon prêt sur le réseau de test TBV hier soir, en m’attendant à devoir obtenir quelque chose en retour de la part du prêteur avant que mon BTC ne bouge — une libération, une confirmation, n’importe quoi. Rien n’est venu. Mon retrait a simplement été traité à partir de ma propre preuve de remboursement.

En fait, ce n’est pas un raccourci propre au testnet. D’autres conceptions de prêts en Bitcoin donnent réellement au prêteur un levier à cet endroit : si le remboursement dépend du prêteur qui révèle un secret, le prêteur peut tout simplement refuser, et la pièce de l’emprunteur reste bloquée même après paiement intégral. TBV évite complètement cette étape : le remboursement produit une preuve que je fournis moi-même, et la libération du coffre ne dépend que de cette preuve. Personne de l’autre côté n’a besoin de faire quoi que ce soit, ni d’accepter quoi que ce soit, pour que je récupère mon BTC.

J’avais l’impression de régler un prêt automobile et de recevoir le titre envoyé automatiquement dès que le paiement est validé, au lieu d’attendre que le concessionnaire ait envie de le signer et de le transférer.

Ce qui m’a fait “tilt”, c’est que ce n’est pas vraiment une question de rapidité. C’est une question d’éliminer le moment unique où une contrepartie pourrait simplement… ne pas agir. Dans ces systèmes, la plupart de la confiance ne s’effondre pas à cause d’un vol : elle s’effondre parce que quelqu’un refuse discrètement de faire sa part exactement au moment où cela compte.

Alors, si une conception a encore besoin que l’autre partie fasse un geste avant que vous récupériez vos fonds, est-ce vraiment sans confiance, ou juste sans confiance jusqu’à ce que quelqu’un décide de ne pas coopérer ?

@BabylonLabs_io $BABY #baby $HEI $BLESS

J’ai remarqué une ligne de frais sur mon peg-in de testnet que je n’avais pas vraiment remarquée auparavant — payé en BTC, pas en BABY. J’ai cherché où ce BTC allait réellement, et la réponse n’était même pas dans l’application.

Il ne reste pas dans une trésorerie. Le design l’achemine vers une vente aux enchères automatisée on-chain : les enchérisseurs paient des BABY pour obtenir le BTC, et les BABY qu’ils dépensent sont brûlés directement. Pas de trésorerie, pas de multisig, pas d’appel discrétionnaire de la part de quelqu’un.

J’avais l’impression d’un péage qui ne garde pas les pièces qu’il collecte — il les convertit immédiatement en brûlant une autre devise, automatiquement, sans qu’un opérateur décide de ce qui arrive au tiroir-caisse.

Ce qui ressort, c’est que cela relie l’offre de BABY directement à l’utilisation des vaults, et non au staking ou à la participation à la gouvernance. Plus de BTC qui circule via les vaults signifie plus de BTC à mettre aux enchères, ce qui veut dire plus de BABY brûlés à chaque cycle. La rareté du token devient une fonction de la quantité de TBV réellement utilisée, et non d’un calendrier d’émission fixe.

Ça vaut le coup d’être clair sur cette partie — ce n’est pas encore en live sur le testnet : c’est toujours en attente d’approbation par la gouvernance avant que cela ne fonctionne vraiment.

Alors, le fait d’acheminer les frais d’utilisation vers une vente aux enchères de burn va-t-il créer une vraie pression déflationniste une fois que le volume sera réel, ou l’adoption en phase initiale est-elle trop faible pour que quiconque sache si l’enchère sera un jour suffisamment importante pour avoir un impact ?

@BabylonLabs_io $BABY #baby $CYS $HEI

J’ai choisi un fournisseur de coffre via un menu déroulant pendant un peg-in, sans trop y penser — j’avais l’impression de choisir un réseau, pas une contrepartie.

Puis je suis tombé sur l’écran d’examen du retrait et j’ai vu une ligne : commission du VP, prélevée sur mon BTC au moment du rachat. J’ai vérifié la documentation ensuite. Ce taux n’est pas fixé au moment du rachat — il est figé dès que le coffre est créé, directement « intégré » dans les transactions de paiement pré-signées du graphe de transactions du coffre. Pas de renégociation ensuite, pas de tour de manèges une fois qu’on est dans le coffre. Celui que j’ai choisi dans ce menu déroulant a une part fixe de mon BTC avant même que j’aie emprunté quoi que ce soit.

J’avais l’impression de moins choisir une banque que de signer un bail où le loyer de la cinquième année était déjà notarié le jour un.

Le protocole appelle ça trustless (sans confiance) parce que personne ne peut déplacer les fonds en dehors des parcours préautorisé — sur ce point, c’est réel. Mais cela signifie aussi que le prix de ma sortie a été fixé par une décision en quatre secondes dans un menu déroulant avant que je comprenne vraiment ce que je choisissais. « Trustless » veut dire que les conditions ne peuvent pas être modifiées plus tard. Ça ne veut pas dire qu’elles ont été choisies avec soin la première fois.

Donc, est-ce que le fournisseur de coffre, vous l’évaluez comme un validateur — taux de commission, disponibilité, réputation — avant même d’effectuer le peg-in ? Ou bien, pour la plupart des gens, le choix est essentiellement aléatoire, et ces frais ne deviennent vraiment concrets pour eux que le jour où ils essaient de retirer ?

@BabylonLabs_io $BABY #baby $VIC $SKYAI

J’ai déposé sur le testnet TBV en m’attendant à ce que le vault passe en ligne dès que ma transaction a été confirmée. Ce n’est pas arrivé. Il y a eu une attente que je n’avais pas prévue, et comprendre pourquoi a changé ma façon de penser l’ensemble du flux.

Un peg-in n’est pas « en ligne » après une seule confirmation Bitcoin. TBV a besoin d’un certain nombre de confirmations empilées au-dessus avant que le vault soit considéré comme réglé, car une seule confirmation peut encore être réorganisée hors de la chaîne (reorg). Sur un dépôt EVM, un bloc final est quasiment final. Sur Bitcoin, un bloc est une revendication, pas un règlement — la vraie garantie n’apparaît qu’à quelques blocs plus tard, car l’annuler reviendrait à réécrire une vraie preuve de travail (proof-of-work).

Ça m’a rappelé un virement bancaire qui affiche « en attente » dans votre appli avant d’être réellement réglé. Le montant apparaît immédiatement à l’écran, mais la banque ne vous laisse pas toucher les fonds tant qu’elle n’est pas sûre que le côté de l’émetteur ne peut plus encore les rejeter.

Ce qui m’a surpris, c’est que TBV ne peut pas contourner ça comme le ferait un dépositaire (custodian). Un dépositaire se contente de dire « faites-moi confiance, c’est dedans » et passe à la suite. TBV n’a personne à qui dire ça : il doit attendre que Bitcoin règle effectivement la revendication, parce que tout l’intérêt est de ne pas avoir besoin de la parole de quelqu’un.

Donc l’attente liée aux confirmations n’est pas une aspérité UX qu’on optimise plus tard. C’est le coût de l’abandon d’un dépositaire qui absorberait normalement cette incertitude à votre place et vous dirait que tout va bien.

Ça me fait me demander combien de personnes qui testent s’attendent à ce que la vitesse des dépôts finisse par correspondre à une application DeFi « normale », plutôt que de réaliser que cette attente est en fait la partie sans confiance (trustless) qui fonctionne correctement, et non un bug en attente d’être corrigé.

@BabylonLabs_io $BABY #baby $BLESS $TAKE #Babylon

J’ai essayé de transférer mon BTC de test d’un parcours de prêt vers une autre application après l’avoir verrouillé dans TBV, en pensant que c’était un simple rééquilibrage normal. Impossible de le faire. Le coffre refuse de libérer.

En fait, ce n’est pas un manque de disponibilité sur le réseau de test : c’est codé comme ça. Verrouiller du BTC via l’intégration Aave émet du vaultBTC — et le vaultBTC est un jeton soumis à des restrictions de transfert. Il ne peut pas être listé ni échangé sur une bourse quelconque, et il ne peut interagir qu’avec les propres contrats intelligents d’Aave. Ce n’est pas un réglage de permissions qu’on pourrait assouplir plus tard. Le jeton lui-même a été conçu pour être incapable d’aller ailleurs.

J’avais l’impression de louer un box de stockage via le système de clés d’un seul établissement. On ne peut pas faire découper une clé de rechange et laisser un deuxième entrepôt, dans l’autre partie de la ville, revendiquer une partie de ce qu’il y a dedans. Tout ce qui se trouve dans ce box appartient à cet unique établissement tant que vous ne fermez pas complètement le compte.

Ça s’explique quand on le compare à ce qu’est réellement le Wrapped BTC. Wrapped BTC est un jeton liquide : il est listé sur des bourses, il circule entre des protocoles, parce que ce n’est qu’un solde dans un registre sans restrictions attachées. vaultBTC a été construit délibérément sans cette propriété. La flexibilité n’a jamais été une fonctionnalité de l’actif sous-jacent. Le wrapping ne fait que l’ajouter, et TBV le retire volontairement.

Le compromis n’est donc pas, en théorie, liquidité contre absence de confiance : c’est plutôt quelque chose de très précis. Un jeton conçu pour ne pouvoir être échangé partout sauf dans la seule application pour laquelle il a été émis, en échange d’un BTC qui n’a jamais quitté Bitcoin à la base.

Je me demande combien de personnes dimensionnent une position TBV en supposant qu’elles peuvent faire circuler vaultBTC comme n’importe quel autre jeton DeFi, avant de se rendre compte en amont qu’il n’a jamais été construit pour être déplacé.

@BabylonLabs_io $BABY #baby $IDOL $UAI #Babylon

J’ai clôturé une position de test sur TBV hier soir, en m’attendant à une étape de vérification des preuves avant que tout ne passe. J’ai attendu un peu. Rien ne s’est affiché. C’était en fait la partie intéressante.

J’avais supposé que chaque retrait devait utiliser du Bitcoin pour vérifier sur le moment une preuve à connaissance nulle complète — c’est toute la promesse : une vérification sans confiance. Mais en voyant ma propre demande rester là, je me suis rendu compte que la preuve n’avait en fait jamais été publiée. Ma clôture s’est déroulée sur ce que le protocole appelle le « happy path » — vous déclarez, vous attendez, personne ne conteste, c’est terminé. La partie coûteuse, la vérification on-chain du circuit brouillé, ne se déclenche que si quelqu’un le conteste.

Ça m’a fait penser à la phrase « dites-le maintenant ou gardez le silence à jamais » à un mariage : le silence n’est pas une preuve que rien ne va mal, c’est juste que personne n’a fait objection à temps.

J’ai vérifié les chiffres ensuite : l’ancienne version de ce système de preuves, BitVM2, coûtait plus de 15 000 $ pour publier une preuve contestée sur Bitcoin. BitVM3 a réduit cela à 93 $ pour un véritable litige, environ 2,66 $ pour le happy path que je viens de suivre. Ma clôture m’a pratiquement coûté rien, précisément parce que la partie coûteuse est restée inutilisée.

Et c’est ça, le point qui m’a empêché d’arrêter d’y penser : ma demande n’avait pas été prouvée sûre, elle n’avait juste pas été contestée. Personne ne surveillait assez attentivement sur le testnet pour prendre la peine de contester quoi que ce soit.

Donc : sur testnet, avec rien de réel en jeu, est-ce que quelqu’un joue vraiment ce rôle de chien de garde, ou bien tout ce modèle de sécurité reste-t-il non testé jusqu’à ce que mainnet donne à quelqu’un une vraie raison de vérifier ?

@BabylonLabs_io $BABY #baby $1000RATS $KOMA #Babylon

Je viens de clôturer mon trade Perpétuel XPTUSDT sur Binance Futures. Chaque trade est une opportunité d’apprentissage. Cette position s’est terminée par une petite perte, mais une gestion des risques disciplinée et l’analyse de mes entrées sont plus importantes que de chercher des profits rapides. Rester patient, suivre ma stratégie et s’améliorer en continu m’aidera à devenir un meilleur trader au fil du temps. 📈💪 #ShareMyTradFi

J’ai suivi le flux réel du testnet TBV au lieu d’en lire simplement le fonctionnement, et je me suis retrouvé bloqué à une étape à laquelle je ne m’attendais pas : juste après le dépôt, l’application n’ouvre pas une seule voûte (vault). Elle recommande d’en créer deux : une voûte « sacrificielle », dimensionnée pour couvrir tout ce que le protocole s’attend à saisir en premier, et une voûte « protégée » qui contient le reste. La voûte sacrificielle est liquidée en premier, dans cet ordre, avant que la voûte protégée ne soit jamais touchée.

Ce n’est pas comme je supposais que la liquidation fonctionnait ici. Sur un marché Aave normal, la liquidation ne fait que consommer une tranche de votre position en collatéral unique, proportionnellement.

Ça m’a rappelé le fait de préparer un vol avec un bagage que vous êtes pleinement prêt à perdre. Vous ne répartissez pas vos objets de valeur de façon égale dans deux valises en espérant que tout se passe bien. Vous mettez ce que vous pouvez vous permettre de perdre dans celui qui part en soute, et vous gardez ce qui compte vraiment sur vous. TBV vous fait faire ça avec du BTC avant même d’avoir emprunté quoi que ce soit : vous décidez à l’avance ce qui est « expendable », de sorte que si quelque chose tourne mal, seul le « bagage en soute » soit pris.

Voici la partie qui m’a surpris : avec les paramètres actuels du testnet, la voûte sacrificielle est en fait la plus grande des deux, pas la plus petite. Le protocole ne vous demande pas de risquer un montant de jetons dès le départ — il vous demande de mettre un poids réel derrière le leurre (décoy).

Ça devient logique une fois qu’on réfléchit au « pourquoi ». Débloquer (unwinding) le BTC sur Bitcoin n’est pas instantané, contrairement à un appel de liquidation sur un EVM — il n’y a pas de façon propre de déboucler partiellement une voûte partagée au milieu d’une crise. Deux voûtes distinctes signifient que le protocole s’en va avec la plus petite, sans problème de liquidation partielle à gérer, et sans devoir se battre avec des délais de confirmation en plein milieu de la liquidation.

On dirait moins une gestion du risque et plus un séquençage du risque, décidé par le déposant plutôt que par le protocole.

Je me demande combien de personnes vont réellement dimensionner délibérément cette voûte sacrificielle, plutôt que d’accepter le split par défaut de l’application et de découvrir ce à quoi elles se sont engagées pendant leur première liquidation — est-ce un manque côté UX, ou est-ce que forcer la décision dès le départ est justement le but ?

@BabylonLabs_io $BABY #baby $KOMA $AKE

Je me demandais pourquoi Babylon a divisé cela en deux protocoles distincts au lieu de construire un seul système. En fait, le volet de l’horodatage est la partie dont presque personne ne parle.

Le staking verrouille du BTC. L’horodatage est la partie qui rend le désengagement rapide. Babylon regroupe environ 300 blocs en un seul point de contrôle par epoch, puis publie ce point de contrôle sur Bitcoin. Une fois qu’il est sur Bitcoin, le réécrire revient à attaquer Bitcoin lui-même — pas seulement le propre ensemble de validateurs de Babylon.

J’y pense comme à un courrier recommandé. Chacun peut prétendre qu’une lettre est arrivée un certain jour, mais le tampon du bureau de poste est la chose que personne ne peut contester a posteriori. Babylon n’invente pas un nouveau système de preuve — il fait simplement marcher tous les 300 blocs jusqu’au seul employé dont le tampon personne ne peut contrefaire.

C’est la raison réelle pour laquelle le désengagement est passé des 21 jours habituels de gel PoS à quelques heures. La plupart des chaînes ont besoin de cette fenêtre parce qu’elles s’appuient sur le consensus social pour détecter un validateur qui se désengage, puis elles forcent discrètement un ancien état de chaîne — une attaque par portée étendue. Babylon n’a pas besoin de cette couche sociale. Le tampon est la preuve.

Le prix est autour de 0,0116 $ aujourd’hui, en baisse sur la semaine, avec une capitalisation boursière proche de 44–46 M$. Rien de tout cela ne change, ne serait-ce qu’un peu, les calculs des points de contrôle — la sécurité que produit ce système n’est pas “évaluée” en BABY : elle dépend du coût qu’il faudrait pour falsifier ce tampon.

Pourtant, il y a encore un point qui continue de tourner : la propre chaîne de Babylon est l’employé qui transporte les lettres jusqu’au bureau de poste. Si ce trajet se bloque ou est censuré, la promesse de désengagement sur deux jours tient-elle, ou est-ce qu’elle devient tranquillement soumise au même problème de consensus social que ce système était justement censé éliminer ?

@BabylonLabs_io $BABY #baby $COTI $UAI

Quelle est la plus grande innovation dans la conception de Babylon ?

J’ai raté une fenêtre de récompense de co-staking le mois dernier de six heures. Je ne savais même pas que ça existait jusqu’à ce que la date limite soit déjà dépassée : j’ai juste vu un paiement plus faible que prévu et je me suis mis à chercher.

Voici ce que j’ai trouvé : les Finality Providers de Babylon ne peuvent pas faire tourner leurs clés. Une fois qu’un FP enregistre sa clé EOTS et sa clé Genesis, cette identité est permanente : impossible de remplacer une clé compromise comme on le ferait sur la plupart des réseaux de validateurs. C’est directement lié au mécanisme de slashing : si un provider double-signe, l’EOTS peut révéler le matériel de clé nécessaire pour le sanctionner. L’identité permanente rend cette menace réelle.

Je pensais que la rotation des clés était juste une bonne pratique opérationnelle standard partout. Ici, c’est l’inverse : le protocole a délibérément supprimé cette flexibilité afin que la responsabilité ne puisse pas être discrètement réinitialisée.

Cela signifie que pour un FP, le vrai risque n’est pas la cryptographie : c’est de survivre pendant des années à des pannes matérielles, des changements de personnel et des migrations d’infrastructure sans jamais toucher à cette seule clé.

Confieriez-vous la délégation à un provider qui fonctionne pendant des années avec une clé permanente unique, ou ce type de configuration vous pousse-t-il plutôt à exiger d’abord une preuve de leur plan de sauvegarde opérationnelle ?

@BabylonLabs_io $BABY #baby $BULLA $ON
La plupart des validateurs : font tourner les clés lorsqu’elles sont compromises. Les FP de Babylon : bloqués avec une seule clé, pour toujours. Quelle approche vous inspire le plus confiance ?

J’ai remarqué quelque chose d’étrange en jouant à un jeu en ligne.

Deux joueurs ont démarré avec les mêmes ressources.
Même règles.
Même opportunité.

Mais au bout d’un moment, l’un d’eux était toujours en avance.

Pas parce qu’il avait plus.

Mais parce qu’il bougeait en premier… à chaque fois.

Ils voyaient des opportunités plus tôt.
Ils réagissaient plus vite.
Ils se positionnaient avant même que les autres ne comprennent ce qui se passait.

Le jeu était équitable.

Mais les résultats ne l’étaient pas.

Ça m’a marqué en regardant Babylon.

Je pensais autrefois que des systèmes comme celui-ci étaient surtout faits pour la sécurité.

Si Bitcoin sécurise la couche de base,
si tout est vérifiable,
si personne ne peut tricher…

alors le système est équitable.

Mais maintenant, je n’en suis plus si sûr.

Parce que Babylon répartit les rôles d’une manière facile à manquer.

BTC fournit le poids.
Mais la coordination—via des prestataires de finalité et une participation inter-chaînes—détermine comment ce poids est réellement utilisé.

Ce qui signifie :

Tout le monde ne joue pas au même jeu.

Certains participants réagissent au système.

D’autres le façonnent en temps réel.

Et avec le temps, cette différence s’amplifie.

Pas parce que les règles sont enfreintes.

Mais parce que le timing et la coordination deviennent un avantage.

Donc la question n’est pas seulement :

« Le système est-il sans confiance ? »

Il se pourrait que ce soit :

« Qui a constamment la possibilité d’agir en premier dans ce système ? »

Parce que si le même groupe continue de voir, de réagir et de se positionner plus tôt que tout le monde…

alors le système peut rester entièrement sans permission—

et pourtant concentrer l’avantage.

Je ne pense pas que ce soit un défaut.

Mais ça change la façon dont je le vois.

Babylon n’étend pas seulement l’utilité de Bitcoin.

Il crée un système où
la sécurité est partagée… mais où l’avantage ne l’est peut-être pas.

Et j’essaie encore de comprendre comment cela se manifeste pendant que davantage de valeur y circule.

@BabylonLabs_io
#baby $BABY #Babylon #baby $BABY

#baby $BABY
Nous avons généralement tendance à considérer la flexibilité comme une force.
Plus d’options.
Plus d’adaptabilité.
Plus de façons de réagir.
Mais en examinant les conceptions de coffres Bitcoin utilisées par , cela m’a fait remettre cela en question.
Et si la flexibilité était en réalité l’endroit où les systèmes sont exploités ?
Au lieu de décider quoi faire après que les fonds sont bloqués…
L’approche de Babylon définit les résultats avant que quoi que ce soit ne se produise.
Pas un seul chemin.
Une carte complète des issues possibles.
Au début, cela semble restrictif.
Mais ensuite, on réalise :
Personne ne peut improviser plus tard.
Personne ne peut « ajuster » les conditions en cours de processus.
Aucun changement de règles silencieux.
Cette rigidité élimine une catégorie entière de risques.
Ce n’est pas une tentative d’être dynamique.
C’est une tentative d’être définitif.
Et c’est une philosophie de conception très différente de celle de la plupart des plateformes de smart contracts.
Maintenant, je me demande :
À mesure que les systèmes deviennent plus complexes, la flexibilité augmente-t-elle en fait le risque plutôt que de le réduire ?
Car si chaque action possible est connue à l’avance…
il ne reste plus rien à manipuler.
#baby $BABY @BabylonLabs_io

J’étais à un clic de le refaire.

Il y a quelques nuits, j’ai sorti mon portefeuille, j’ai regardé mon BTC et je me suis dit : « Je devrais probablement le faire travailler. »

Aucune émotion. Pas d’urgence.

Juste une habitude.

Mon cerveau avait déjà les étapes prêtes : l’envelopper → le transférer → le déposer.

Je l’ai déjà fait. Ça marche.

Alors j’ai avancé…
…et puis je me suis arrêté juste avant de confirmer.

Pas parce que j’avais peur de perdre des fonds.

Mais parce que quelque chose semblait bizarre, d’une façon que je n’arrivais pas à expliquer.

Ce n’était pas le risque.
C’était la sensation que tout était automatique.

Comme si je ne prenais plus de décision — juste en suivant un processus que j’avais répété assez de fois pour cesser de me poser des questions.

Et c’est précisément ça qui m’a dérangé.
À partir de quand « utiliser Bitcoin » a-t-il commencé par l’éloigner de Bitcoin ?

À partir de quand est-ce devenu normal ?

Cette question est restée avec moi plus longtemps que la transaction n’aurait dû.

Et c’est exactement pour ça que les Trustless Bitcoin Vaults ont attiré mon attention.

Pas parce qu’ils promettent un rendement. Pas parce que c’est une autre couche de prêt.

Mais parce qu’ils remettent en question cette première étape.

Et si le fait que Bitcoin devienne utile n’avait jamais nécessité de le quitter en premier lieu ?

Et si on avait simplement accepté cette voie parce que c’était la seule disponible à ce moment-là ?

Je ne sais pas si TBV résout entièrement le problème pour l’instant.

Mais je sais une chose —

Le moment où tu t’arrêtes juste avant de cliquer sur « confirmer »… et que tu réalises que tu ne sais plus réellement pourquoi tu fais quelque chose…

c’est généralement là que le changement commence.

@BabylonLabs_io
$BABY #baby #Babylon i

#baby $BABY

Je pense que la crypto a pris l’habitude de résoudre le compromis d’hier plutôt que de se demander pourquoi ce compromis existait.
Prenons Bitcoin.
Pendant des années, si vous vouliez mettre du BTC au travail, la conversation commençait généralement par modifier quelque chose.
L’envelopper. Le relier. Le déposer quelque part. Ajouter une autre couche.
Personne ne remettait plus en question la première étape.
C’est devenu normal.
C’est précisément ce que je trouve intéressant dans les Trustless Bitcoin Vaults.
Ils ne commencent pas par se demander : « Comment peut-on déplacer du Bitcoin ? »
Ils commencent par se demander : « Et si le fait de déplacer du Bitcoin n’avait jamais été le bon point de départ ? »
Ces questions se ressemblent.
Je ne pense pas qu’elles le soient.
L’une suppose que le compromis est inévitable.
L’autre remet en question la nécessité même du compromis, dès le départ.
C’est une philosophie de conception très différente.
Peut-être que, dans des années, les gens ne se souviendront plus de TBV parce qu’il a introduit un autre produit d’emprunt.
Peut-être qu’ils s’en souviendront parce qu’il a, discrètement, modifié la première question que les développeurs se posent lorsqu’ils construisent avec Bitcoin.
@BabylonLabs_io
$BABY #baby #Babylon