ITS ME ANJAN_0

#dusk $DUSK @Dusk L’enchère la plus intéressante de Dusk ne concerne peut-être pas la confidentialité.

Elle pourrait plutôt porter sur la possibilité pour un actif réglementé de devenir un produit financier programmable, et pas seulement une représentation tokenisée.

Cette distinction compte.

Dusk construit la pile autour de l’ensemble du cycle de vie de l’actif : éligibilité, restrictions de transfert, divulgation sélective, émission, négociation et règlement. Son architecture actuelle sépare le règlement/la disponibilité des données de l’exécution EVM et de la confidentialité native, tout en conservant DUSK comme actif commun à l’échelle de toute la pile.

Et il existe déjà un ancrage concret dans le monde réel : Dusk indique que son pipeline institutionnel inclut plus de 300 M€ d’émissions confirmées, tandis que plus de 210 M de DUSK sont mis en jeu pour sécuriser le réseau.

Mais c’est là, je pense, que la question la plus difficile commence.

Davantage d’activité financière se traduit-elle réellement par une demande économique accrue pour DUSK ?

DUSK est requis pour le gaz et le jalonnement, mais le propre Economic Protocol de Dusk a été conçu explicitement pour que des contrats intelligents puissent payer le gaz à la place des utilisateurs. Cela rend l’adoption institutionnelle plus facile—mais cela affaiblit aussi l’hypothèse selon laquelle chaque nouvel investisseur ou détenteur d’actifs doit forcément exiger directement DUSK.

Je n’exprimerais donc pas la thèse ainsi :

« 300 M€ de RWA → demande de DUSK ».

La thèse la plus intéressante est plutôt :

Dusk peut-il rendre des actifs réglementés suffisamment programmables, composables et actifs on-chain pour que l’infrastructure elle-même devienne une source significative d’activité économique récurrente ?

La tokenisation prouve très peu par elle-même.

Les marchés programmables constituent le véritable test.

#dusk $DUSK @Dusk Le plus je regarde Dusk, moins je pense que l’histoire RWA soit simplement une question de mise d’actifs en chaîne.

La partie la plus difficile, c’est ce qui se passe après l’émission.

Un actif réglementé doit toujours répondre à l’éligibilité des investisseurs, aux transferts contrôlés, à la confidentialité, à la divulgation et au règlement.

La plupart des blockchains peuvent gérer des éléments de tout cela.

Dusk s’efforce d’assembler ces éléments autour du même flux de travail d’actifs.

C’est là que DuskEVM devient, à mes yeux, plus intéressant.

Il ne s’agit pas uniquement d’apporter des applications Solidity sur une autre chaîne. Dusk positionne l’exécution EVM à côté de son parcours natif de confidentialité et de son règlement déterministe, afin que les applications financières puissent conserver un développement familier tout en utilisant la confidentialité et la conformité au niveau de l’infrastructure.

Et cela change ma façon de voir la narration autour des RWA.

L’actif de valeur n’est peut-être pas le jeton lui-même.

Il s’agit peut-être de l’infrastructure qui décide qui peut y accéder, ce que chacun peut en faire, les informations qu’il doit divulguer et la manière dont la transaction se règle finalement.

Si Dusk peut rendre ces contraintes programmables au lieu de les ajouter après coup, alors il ne s’agit pas seulement de tokeniser des actifs réglementés.

L’objectif est d’intégrer les règles relatives à ces actifs directement dans l’infrastructure du marché.

Cela ressemble à l’expérience Dusk la plus importante à suivre.

#dusk $DUSK @Dusk J’ai continué à revenir à un détail dans Dusk qui a l’air presque trop simple.

Un jeton se trouve sous une pile étonnamment compliquée.

DuskDS gère le règlement et l’irréversibilité. DuskEVM donne aux développeurs l’environnement EVM. DuskVM gère la confidentialité native et l’exécution ZK.

Pourtant, les trois utilisent finalement DUSK.

Cela a changé la façon dont je pense au modèle de jetons de Dusk.

La question évidente est de savoir si les actifs tokenisés généreront une activité suffisante pour avoir de l’importance.

Je pense qu’il y a une question plus intéressante :

Que se passe-t-il lorsque le même flux financier commence à circuler entre différents environnements d’exécution ?

Une institution peut émettre un actif via une couche, utiliser des outils EVM pour une application, faire transiter la valeur via la couche de règlement, puis n’utiliser l’infrastructure de confidentialité que pour certaines transactions.

L’actif reste le même.

L’application reste la même.

Mais l’environnement d’exécution peut changer.

Et DUSK demeure l’unité économique commune en dessous.

Cela signifie que Dusk n’a peut-être pas besoin que chaque RWA « achète DUSK » directement, d’une façon évidente.

Le point le plus important pourrait plutôt être de savoir si Dusk peut faire en sorte que ses différents environnements d’exécution donnent l’impression d’être un seul et même système financier.

S’il y parvient, le fossé (moat) intéressant ne serait peut-être pas la confidentialité.

Il se pourrait que les développeurs puissent choisir différentes façons de construire, tandis que la couche économique sous-jacente converge vers le même jeton.

C’est une thèse de jeton beaucoup plus intéressante pour moi que de simplement compter combien d’actifs Dusk tokenisera finalement.

#dusk $DUSK @Dusk J’avais l’habitude de penser que le plus gros pari de Dusk consistait simplement à mettre la confidentialité sur une blockchain conçue pour la finance réglementée.

Après avoir creusé plus en profondeur, je ne suis pas sûr que ce soit la bonne façon de le voir.

Ce qui a attiré mon attention, c’est l’architecture.

DuskDS gère le règlement et la disponibilité des données. DuskEVM offre aux développeurs l’environnement Ethereum familier. DuskVM est l’endroit où les applications peuvent exploiter la confidentialité plus approfondie de Dusk ainsi que ses capacités ZK. En d’autres termes, la confidentialité n’est plus seulement « ce que la chaîne est ». Elle peut dépendre de l’endroit où l’application choisit d’exécuter.

Cela crée un compromis intéressant.

La compatibilité avec EVM facilite la construction de Dusk, mais plus l’activité se déplace vers l’environnement EVM familier, plus la frontière entre la compatibilité et la confidentialité native devient importante.

Dusk affirme qu’il peut aussi apporter de la confidentialité aux applications EVM, y compris via Hedger, de sorte que cette limitation pourrait finir par devenir moins problématique.

Mais cela me laisse avec une question que je n’ai pas vue suffisamment discutée :

Le fossé de Dusk tient-il réellement à la confidentialité elle-même, ou bien à la capacité de faire fonctionner ensemble la confidentialité, la conformité et le règlement, sans forcer les développeurs à renoncer à la compatibilité EVM ?

Ce sont deux fossés très différents.

$SYN La résistance tient, le SYN pourrait retomber. C’est le moment de se positionner à la baisse. Configuration de Short.

Entrée : 0,112 - 0,115
TP : 0,108 - 0,104 - 0,100 - 0,097
SL : 0,119

Le SYN montre un rejet de la résistance. Est-ce que vous vous attendez à un autre mouvement à la baisse à partir d’ici ?

#dusk $DUSK @Dusk J’ai commencé à me pencher sur Dusk parce que l’histoire liée à la confidentialité avait du sens.

Puis les chiffres m’ont fait faire une pause.

Dusk affirme disposer de plus de 300 M€ d’émissions institutionnelles et de plus de 210 M de DUSK mis en jeu, tandis que le token est toujours autour d’une capitalisation boursière d’environ 30 à 36 M$ avec un volume de transactions quotidiennes d’environ 1,7 M$.

Cet écart est intéressant.

La conclusion évidente, c’est que « le marché n’a pas encore découvert Dusk ».

Je ne suis pas convaincu que ce soit la bonne conclusion.

Plus je me suis plongé dans l’architecture, plus j’ai remarqué que Dusk cherche à devenir quelque chose de plus grand qu’un simple L1 axé sur la confidentialité : règlement/settlement, conformité, identité, transferts confidentiels, exécution EVM, et éventuellement un véritable flux de trading réglementé.

Du coup, la question qui me reste est différente :

Si la vraie valeur va se retrouver dans des actifs réglementés et dans l’infrastructure financière, quelle part de cette valeur doit réellement transiter par DUSK ?

Le réseau peut être utile sans que le token devienne proportionnellement plus précieux.

Et, pour moi, c’est une question bien plus intéressante que de savoir si Dusk a une technologie de confidentialité de qualité.

#dusk $DUSK J’ai commencé à m’intéresser à Dusk parce que l’histoire de la confidentialité + de la finance réglementée avait du sens.

Ensuite, j’ai vérifié où se situe réellement l’offre de DUSK.

Cela a changé mon point de vue.

L’explorateur de réseau indique une offre totale d’environ 571 M de DUSK, mais environ 211 M sont mis en jeu et encore 355 M se trouvent dans des soldes liés aux ponts. Il reste donc moins de 5 M comme offre liquide d’après ce cliché.

En même temps, la chaîne ne traite toujours qu’environ 174 transactions par jour, avec seulement 8 appels de contrats dans le même cliché sur 24 h.

Cela soulève une question à laquelle je ne m’attendais pas.

Si Dusk réussit à devenir une infrastructure pour des actifs réglementés, ce succès crée-t-il réellement une demande proportionnelle pour le DUSK ?

Ou bien l’activité financière peut-elle croître tandis que le jeton reste surtout un carburant de sécurité/de règlement, dont l’importance économique est davantage déterminée par le jalonnement et la structure de l’offre que par la valeur des actifs qui circulent sur le réseau ?

La technologie n’est pas ce qui m’a fait faire une pause.

C’est la relation entre l’ambition du réseau et le rôle économique réel du jeton.@Dusk

$PORTAL La résistance se maintient près de 0,0195 $, PORTAL pourrait rechuter. Le setup en short semble prometteur ici.

Entrée : 0,0188 $ - 0,0195 $
TP : 0,0175 $ - 0,0160 $ - 0,0150 $ - 0,0142 $
SL : 0,0203 $

$ZEC n’est pas encore haussier — il attend une confirmation.
Le prix se situe entre le support et une zone de décision majeure.
Configuration longu e: cassure et retest à partir de $520+
TP1 : $550
TP2 : $580
TP3 : $620
SL : en dessous de $490
Mais voici le point que je surveille de près :
Si ZEC perd $490, la configuration haussière s’affaiblit et $469–$480 devient la prochaine zone à surveiller.
Donc le vrai trade n’est pas « acheter parce que $ZEC semble fort ».
C’est : quel camp obtient la confirmation en premier — les acheteurs au-dessus de la résistance ou les vendeurs sous le support ?
Cette réponse pourrait définir le prochain grand mouvement de ZEC.
Ce n’est pas un conseil financier. Gérez votre risque de façon autonome.
Que se passe-t-il ensuite ?

#dusk $DUSK Je me suis mis à examiner Dusk comme une chaîne de confidentialité pour les actifs réglementés.

Puis j’ai remarqué quelque chose de plus intéressant : Dusk construit en réalité deux manières différentes de s’intégrer au réseau.

DuskEVM rend l’environnement familier pour les applications existantes, tandis que la pile native est celle où la confidentialité, l’exécution ZK et les contrôles au niveau des actifs deviennent partie intégrante de l’infrastructure.

Cela ressemble à de la flexibilité.

Mais cela soulève aussi une question que je n’avais pas anticipée.

Si le chemin le plus simple pour les développeurs est la voie EVM familière, qu’est-ce qui fait que les applications finissent par choisir l’architecture native de confidentialité de Dusk plutôt que de se contenter de considérer Dusk comme une simple couche de règlement supplémentaire ?

Peut-être que le problème le plus difficile de Dusk n’est pas de prouver que la finance confidentielle fonctionne.

C’est de rendre la voie de confidentialité native économiquement plus difficile à ignorer.
@Dusk

J’ai remarqué qu’au bout d’un moment, beaucoup de projets blockchain finissent par se ressembler.

#dusk $DUSK Je me suis d’abord mis à considérer Dusk comme un problème de confidentialité.
Puis l’architecture m’a amené à remettre en question cette façon de cadrer les choses.
Dusk construit une infrastructure financière réglementée où la confidentialité n’est qu’un aspect de l’équation. L’exigence la plus difficile consiste à décider qui a le droit de voir, de déplacer ou de récupérer un actif tout en conservant la possibilité de vérifier le système.
Cela change le rôle de la blockchain.
La partie intéressante n’est pas de savoir si Dusk peut masquer des transactions. La question est de savoir si les institutions accorderont réellement assez de valeur à des restrictions programmables pour transférer une infrastructure de marché réelle vers un réseau public.
Dusk renvoie déjà vers NPEX, des plateformes réglementées, 300 M€+ d’émissions confirmées et 210 M+ de DUSK mis en jeu. Mais le token, lui, capture encore principalement l’ancienne boucle de valeur des L1 : le gaz et le staking.
Du coup, j’en reviens à une question :
Si la chose la plus précieuse que Dusk construit est une infrastructure de marché réglementée, quelle part de cette valeur doit finalement transiter par DUSK ?
@Dusk

J’ai remarqué que beaucoup de projets blockchain finissent par se ressembler au fil du temps.

#baby $BABY Je suis entré à Babylone en supposant que la plus grande question de long terme serait de savoir si Bitcoin peut sécuriser des réseaux PoS à grande échelle.

En fouillant dans l’architecture, je me suis finalement mis à penser à tout autre chose.

À mesure que davantage de BTC est mis en jeu, le budget de sécurité du protocole peut augmenter sans que la demande pour BABY elle-même ait nécessairement à croître. Le réseau bénéficie de davantage de Bitcoin qui le sécurisent, tandis que la captation de valeur de l’actif de gouvernance dépend d’incitations entièrement différentes. C’est un découpage économique inhabituel.

Ce n’est pas forcément une faiblesse. Ce pourrait même être la façon la plus claire d’éviter de forcer Bitcoin à jouer un rôle de gouvernance pour lequel il n’a jamais été conçu.

Mais cela m’a laissé avec une question que je ne m’attendais pas à me poser :

Si l’actif qui fournit la sécurité et l’actif qui capte la valeur de gouvernance suivent des trajectoires économiques de plus en plus distinctes, d’où vient alors l’alignement à long terme du protocole ?
@BabylonLabs_io

#baby $BABY Je ne m’attendais pas à voir le plus petit nombre affiché à l’écran devenir le plus intéressant.
Environ 56k BTC sont stockés dans le système de coffre-fort de Babylon, mais mes yeux n’arrêtaient pas de revenir sur la couche de gouvernance. L’histoire de la sécurité est déjà bien comprise. Ce dont on parle beaucoup trop peu, en revanche, c’est à quel point il semble y avoir peu de recouvrement entre les personnes qui profitent des coffres et celles dont on attend qu’elles façonnent l’avenir.
Plus je cartographiais le flux, plus cela me semblait étrange. Les déposants se soucient du fait que le Bitcoin reste natif. Les emprunteurs se soucient de l’efficacité du capital. Les applications se soucient d’intégrer la liquidité en BTC. Aucune de ces décisions ne nécessite qu’une personne s’implique profondément dans la gouvernance.
Cela m’a fait me demander si Babylon sépare discrètement deux choses que nous avons pris l’habitude de voir ensemble : l’utilisation du protocole et la participation à la gouvernance.
La plupart des réseaux espèrent que les utilisateurs actifs deviendront, au fil du temps, des gouverneurs actifs. Babylon ne pousse pas clairement ce comportement. Il semble à l’aise de laisser l’utilité grandir indépendamment de la demande en gouvernance.
Si ce schéma se poursuit, la réussite ne se traduira pas automatiquement par une participation plus large à la gouvernance. Elle pourrait simplement concentrer la coordination entre moins de mains, tandis que l’adoption continue de s’étendre.
Je n’arrive pas à décider s’il s’agit d’une force négligée ou d’un manque d’incitation qui ne devient visible qu’à grande échelle.
@BabylonLabs_io

#baby $BABY Au début, je pensais que le problème le plus difficile de Babylon était de convaincre les détenteurs de Bitcoin de miser (staking) sans renoncer à la garde. Plus je regardais longtemps, moins cette hypothèse me semblait convaincante. La garde en self-custody est importante, mais elle ressemble davantage à une condition d’entrée qu’à la contrainte définissante du protocole.

Ce qui m’a surtout attiré ailleurs, c’est la séparation entre l’origine du poids économique et l’endroit où il est réellement consommé. Bitcoin reste inchangé, mais son signal de sécurité est continuellement interprété par des systèmes PoS externes fonctionnant avec des hypothèses très différentes. Cette couche de traduction paraît plus déterminante que le mécanisme de staking lui-même.

J’ai commencé à me demander si Babylon crée progressivement un nouveau marché de coordination plutôt qu’un simple marché de staking. Chaque chaîne consommatrice supplémentaire hérite de la sécurité adossée à Bitcoin, mais devient aussi dépendante de l’interprétation par Babylon de la finalité de Bitcoin, de la datation (timestamping) et des conditions de slashing. La sécurité ne vit plus entièrement sur Bitcoin, ni entièrement sur la chaîne de destination. Elle s’accumule dans les règles qui les relient.

Cela m’a amené à questionner les incitations des validateurs. Si plusieurs écosystèmes finissent par se disputer le même pool de sécurité adossée à Bitcoin, la ressource rare n’est peut-être plus le BTC lui-même, mais une allocation fiable de cette sécurité entre des réseaux concurrents. Peut-être que le capital reste décentralisé tandis que la coordination de la sécurité devient de plus en plus centralisée.

À terme, le protocole pourrait être moins centré sur le fait de rendre Bitcoin productif que sur la détermination de qui a le droit d’emprunter la crédibilité de Bitcoin, dans quelles conditions, et avec quelles garanties économiques.

Si cette couche de coordination devient la véritable source de levier, où se situe réellement la décentralisation sur le long terme ?
@BabylonLabs_io

#baby $BABY Au début, je pensais que le problème le plus difficile de Babylon était de convaincre les détenteurs de Bitcoin de miser sans renoncer à la garde. Plus j’y regardais, moins cette hypothèse me paraissait convaincante. La garde en propre est importante, mais elle ressemble davantage à une condition d’entrée qu’à la contrainte déterminante du protocole.

Ce qui attirait sans cesse mon attention ailleurs, c’était la séparation entre l’endroit d’où provient le poids économique et l’endroit où il est effectivement consommé. Le Bitcoin reste inchangé, pourtant son signal de sécurité est continuellement interprété par des systèmes externes de preuve d’enjeu (PoS) qui fonctionnent avec des hypothèses très différentes. Cette couche de traduction semble plus déterminante que le mécanisme de mise lui-même.

Je me suis alors demandé si Babylon crée progressivement un nouveau marché de coordination plutôt qu’un simple marché de mise. Chaque chaîne consommatrice supplémentaire hérite de la sécurité adossée à Bitcoin, mais devient aussi dépendante de l’interprétation par Babylon de la finalité du Bitcoin, de l’horodatage et des conditions de slashing. La sécurité ne vit plus entièrement sur le Bitcoin, ni entièrement sur la chaîne de destination. Elle s’accumule dans les règles qui les relient.

Cela m’a amené à questionner les incitations des validateurs. Si plusieurs écosystèmes finissent par se disputer le même bassin de sécurité adossée à Bitcoin, la ressource rare n’est peut-être plus le BTC lui-même, mais une allocation fiable de cette sécurité entre des réseaux concurrents. Le capital resterait décentralisé, tandis que la coordination de la sécurité deviendrait de plus en plus centralisée.

À terme, le protocole sera peut-être moins question de rendre le Bitcoin productif que de déterminer qui obtient d’emprunter la crédibilité du Bitcoin, dans quelles conditions, et avec quelles garanties économiques.

Si cette couche de coordination devient la véritable source de levier, où se situe réellement la décentralisation sur le long terme ?
@BabylonLabs_io

#baby $BABY Au début, j’ai supposé que la contrainte principale de Babylon serait de convaincre les détenteurs de Bitcoin de staker sans renoncer à la garde. Plus je regardais, moins cette question me semblait importante. La garde personnelle résout un problème, mais elle modifie aussi l’endroit où la confiance s’accumule discrètement.

Je constatais de plus en plus que le Bitcoin lui-même ne devient jamais programmable. À la place, le signal économique produit par Bitcoin est exporté vers des systèmes PoS externes. Cela crée une séparation inhabituelle: l’actif qui fournit la sécurité et la chaîne qui consomme cette sécurité évoluent selon des processus de gouvernance totalement différents.

Cela m’a amené à me demander qui s’adapte en premier quand les incitations dérivent. Bitcoin change à peine, tandis que les écosystèmes PoS ajustent en permanence les règles des validateurs, les émissions et les conditions de slashing. La source de sécurité est volontairement stable, mais la demande de sécurité reste extrêmement dynamique.

Un autre schéma est apparu autour de la concurrence entre validateurs. Si la sécurité adossée à Bitcoin devient largement disponible, le staking pourrait devenir moins une question d’attraction de capitaux natifs et davantage celle d’attirer les fournisseurs externes de sécurité les plus solides. Peut-être que, progressivement, la différenciation des validateurs s’éloigne de la simple détention de tokens pour se tourner vers la réputation, la qualité de l’infrastructure et l’intégration avec des marchés de sécurité partagée.

Ce qui m’a le plus surpris, c’est que Babylon ne ferait peut-être pas qu’augmenter l’utilité du Bitcoin. Elle pourrait réduire progressivement l’importance stratégique de la liquidité de staking native au sein des écosystèmes interconnectés, en changeant la manière dont les nouveaux réseaux PoS amorcent la sécurité économique dès le départ.

Peut-être que l’effet à long terme n’est pas plus de staking, mais une redistribution de l’endroit où les prix de la sécurité sont découverts.

Si cela se produit, la gouvernance perd-elle finalement son influence sur la sécurité, ou est-ce que la sécurité commence à façonner la gouvernance à la place ?
@BabylonLabs_io

#baby $BABY Je suis entré à Babylone en pensant que sa plus grande contrainte serait de convaincre les détenteurs de Bitcoin de miser.
Je ne pense pas que ce soit le problème le plus difficile.
Le protocole part du principe que le Bitcoin peut rester économiquement prudent tout en devenant économiquement utile ailleurs. C’est une hypothèse beaucoup plus étrange qu’elle n’en a l’air.
Le Bitcoin a passé des années à récompenser l’inactivité. La pièce la plus sûre était souvent celle qui ne bougeait jamais.
Babylone ne change pas vraiment cette règle. Il change ce que peut signifier « ne rien faire ».
Une position BTC verrouillée ne « participe » pas soudainement parce qu’elle se déplace entre écosystèmes. Elle participe parce qu’un autre réseau est prêt à fonder ses hypothèses de sécurité sur la crédibilité du Bitcoin.
Cela ressemble à une inversion.
Au lieu que le Bitcoin s’adapte aux réseaux PoS, ce sont les réseaux PoS qui commencent à s’adapter au Bitcoin.
Si cela continue, le Bitcoin pourrait cesser d’être perçu comme un simple actif au sein d’une infrastructure multi-chaînes.
Il pourrait progressivement devenir une infrastructure lui-même.
Il y a une différence importante entre exporter de la liquidité et exporter de la crédibilité.
Babylone semble bien plus intéressé par la seconde.
Peut-être que c’est le changement plus discret qui se produit ici.
Si le Bitcoin finit par devenir la référence de sécurité autour de laquelle les autres réseaux s’organisent, continuera-t-on à le décrire comme un « inter-chaînes »... ou faudra-t-il repenser l’interopérabilité d’une toute autre manière?
@BabylonLabs_io

#baby $BABY Au début, j’ai supposé que la sécurité de Babylon provenait presque entièrement du Bitcoin.
En lisant plus en profondeur, l’explication m’a semblé de moins en moins complète.
Le Bitcoin apporte le poids économique, mais le protocole dépend encore de quelque chose de beaucoup plus petit, qui est rarement discuté : la constance opérationnelle.
Un fournisseur de finalité n’apparaît pas simplement avec du BTC. Il doit continuer à produire une aléatoire valide, éviter les signatures contradictoires, préserver l’état local de signature et survivre aux redémarrages sans rompre cette historique. Le protocole construit même des garde-fous dédiés contre le slashing autour de ces risques opérationnels.
Cela a changé la façon dont j’ai envisagé la conception.
La partie coûteuse de la sécurité est déléguée à Bitcoin. La partie fragile est reportée dans le logiciel.
Peut-être est-ce intentionnel.
Plutôt que de prétendre que les humains ne commettent jamais d’erreurs, Babylon semble partir du principe qu’ils en feront—et essaie de réduire les dégâts avant que ces erreurs ne deviennent des échecs de consensus.
Cela m’a amené à me demander si l’innovation réelle du protocole n’est pas, en fait, le staking sur Bitcoin.
Peut-être s’agit-il de l’idée que la sécurité économique et la sécurité opérationnelle devraient être traitées comme deux problèmes d’ingénierie distincts, plutôt que comme un seul.
Si c’est vrai, qu’est-ce qui, au final, limite la sécurité de Babylon dans le temps—la quantité de BTC qui le sécurise, ou la qualité des opérateurs qui le font fonctionner ?
@BabylonLabs_io