Binance Square
Block_Zen
24k Publications

Block_Zen

Compte Square Vérifié+
Crypto is my pulse | charts are my language | Fearless in the bull | patient in the bear | X : Block_Zen
936 Suivis
33.2K+ Abonnés
19.5K+ J’aime
Publications
·
--
#dusk $DUSK @Dusk_Foundation Au début, j’ai trouvé la puissance de règlement côté émetteur de Zedger mal à l’aise. Elle semblait presque à l’opposé de l’hypothèse de self-custody que j’apporte normalement à la crypto. Puis j’ai remarqué la contradiction. DUSK se négocie autour de 0,078 $ aujourd’hui, après s’être approché de 0,0792 $, avec environ 6,1 M$ d’un volume de futures sur 24 h. Pendant ce temps, le détail du protocole qui m’intéresse a peu à voir avec le prix. Zedger a été conçu pour que des titres puissent porter des règles de conformité directement dans leur modèle de transaction : comptes approuvés, plafonds de propriété, dividendes, votes et logique de règlement/rachat. Dusk décrit explicitement des transferts plafonnés où un destinataire ne peut pas dépasser le seuil de propriété configuré. Cela crée une tension étrange. Plus un token représente fidèlement un titre réglementé, moins son comportement de détention sera peut-être « permissionless ». Pour la crypto ordinaire, l’ingérence de l’émetteur ressemble à un échec de la self-custody. Pour les titres, un contrôle sans restriction de la part des détenteurs peut, lui aussi, enfreindre les règles attachées à l’actif. La question intéressante n’est donc pas de savoir si Zedger donne le contrôle aux émetteurs. C’est de savoir si l’ajout de contraintes juridiques à un actif rend nécessaire une forme de contrôle — et si ce contrôle peut rester étroit, vérifiable et prévisible. Je n’ai pas trouvé la frontière exacte de l’action unilatérale de l’émetteur formulée de manière suffisamment cohérente pour trancher cette question. Et honnêtement, c’est la partie que j’étudierais avant que le récit RWA ne devienne trop confortable. @Dusk_Foundation #dusk $DUSK
#dusk $DUSK @Dusk

Au début, j’ai trouvé la puissance de règlement côté émetteur de Zedger mal à l’aise. Elle semblait presque à l’opposé de l’hypothèse de self-custody que j’apporte normalement à la crypto.

Puis j’ai remarqué la contradiction.
DUSK se négocie autour de 0,078 $ aujourd’hui, après s’être approché de 0,0792 $, avec environ 6,1 M$ d’un volume de futures sur 24 h.

Pendant ce temps, le détail du protocole qui m’intéresse a peu à voir avec le prix.

Zedger a été conçu pour que des titres puissent porter des règles de conformité directement dans leur modèle de transaction : comptes approuvés, plafonds de propriété, dividendes, votes et logique de règlement/rachat. Dusk décrit explicitement des transferts plafonnés où un destinataire ne peut pas dépasser le seuil de propriété configuré.

Cela crée une tension étrange.
Plus un token représente fidèlement un titre réglementé, moins son comportement de détention sera peut-être « permissionless ».
Pour la crypto ordinaire, l’ingérence de l’émetteur ressemble à un échec de la self-custody.

Pour les titres, un contrôle sans restriction de la part des détenteurs peut, lui aussi, enfreindre les règles attachées à l’actif.
La question intéressante n’est donc pas de savoir si Zedger donne le contrôle aux émetteurs.
C’est de savoir si l’ajout de contraintes juridiques à un actif rend nécessaire une forme de contrôle — et si ce contrôle peut rester étroit, vérifiable et prévisible.

Je n’ai pas trouvé la frontière exacte de l’action unilatérale de l’émetteur formulée de manière suffisamment cohérente pour trancher cette question.
Et honnêtement, c’est la partie que j’étudierais avant que le récit RWA ne devienne trop confortable.

@Dusk #dusk $DUSK
Vérifié
#dusk $DUSK @Dusk_Foundation J’ai entendu « cette pièce est différente » assez souvent pour me méfier de la formule. Dusk m’a fait regarder deux fois, parce que le marché semble intégrer le récit plus vite que l’infrastructure n’est prouvée. DUSK s’échange autour de 0,077 $ avec environ 9 M$ de volume sur 24 h, après un mouvement nettement haussier cette semaine. C’est là que la contradiction devient intéressante. La chose que Dusk construit vise à réduire l’exposition à l’information, pourtant son token est actuellement réévalué sous l’effet d’une attention publique très visible. Sous ce bruit, Citadel adopte une approche différente de la conformité. Les utilisateurs peuvent prouver qu’ils détiennent un identifiant valide sans publier sur la chaîne les détails personnels sous-jacents ni le numéro de licence exact. Donc la confidentialité n’est pas vraiment la partie inhabituelle. La partie inhabituelle, c’est d’essayer de rendre la preuve de conformité portable. Mais cela soulève une question à laquelle je ne peux pas répondre uniquement à partir de l’architecture : une preuve cryptographiquement valide devient-elle une preuve réglementaire simplement parce qu’elle est techniquement vérifiable ? NPEX et Quantoz donnent plus de substance à la thèse, notamment avec l’intégration EURQ prévue sur Dusk. Mais des partenariats ne sont pas la même chose qu’une demande institutionnelle récurrente. C’est ce que je surveille maintenant. Si le prix peut bouger aussi vite avec le récit, est-ce que l’utilisation réellement encadrée finira par devenir ce qui fait avancer la thèse ? L’écart entre la spéculation du marché et l’adoption de l’infrastructure est ce qui rend DUSK intéressant à mes yeux. @Dusk_Foundation #DUSK $DUSK
#dusk $DUSK @Dusk

J’ai entendu « cette pièce est différente » assez souvent pour me méfier de la formule. Dusk m’a fait regarder deux fois, parce que le marché semble intégrer le récit plus vite que l’infrastructure n’est prouvée.

DUSK s’échange autour de 0,077 $ avec environ 9 M$ de volume sur 24 h, après un mouvement nettement haussier cette semaine.
C’est là que la contradiction devient intéressante.

La chose que Dusk construit vise à réduire l’exposition à l’information, pourtant son token est actuellement réévalué sous l’effet d’une attention publique très visible.
Sous ce bruit, Citadel adopte une approche différente de la conformité. Les utilisateurs peuvent prouver qu’ils détiennent un identifiant valide sans publier sur la chaîne les détails personnels sous-jacents ni le numéro de licence exact.

Donc la confidentialité n’est pas vraiment la partie inhabituelle.
La partie inhabituelle, c’est d’essayer de rendre la preuve de conformité portable.

Mais cela soulève une question à laquelle je ne peux pas répondre uniquement à partir de l’architecture : une preuve cryptographiquement valide devient-elle une preuve réglementaire simplement parce qu’elle est techniquement vérifiable ?

NPEX et Quantoz donnent plus de substance à la thèse, notamment avec l’intégration EURQ prévue sur Dusk. Mais des partenariats ne sont pas la même chose qu’une demande institutionnelle récurrente.

C’est ce que je surveille maintenant.
Si le prix peut bouger aussi vite avec le récit, est-ce que l’utilisation réellement encadrée finira par devenir ce qui fait avancer la thèse ?

L’écart entre la spéculation du marché et l’adoption de l’infrastructure est ce qui rend DUSK intéressant à mes yeux.

@Dusk #DUSK $DUSK
Je pensais que l’effet de levier se résumait toujours à une seule question : jusqu’où une position peut-elle évoluer contre moi avant la liquidation ? En creusant @termmax , cette hypothèse m’a semblé trop simpliste. Le levier basé sur GT fonctionne via le LTV. Si la garantie (collatéral) évolue suffisamment contre la position, la liquidation fait partie des risques. Alpha est différent. Ses positions Long et Short sont des options. Vous payez une prime d’avance, et cette prime définit la perte maximale possible de la position. TermMax décrit cela comme une exposition avec effet de levier sans risque de liquidation. Je ne l’interprète pas comme un « levier sûr ». Je le vois comme une manière différente de définir la baisse (le risque à la baisse). GT laisse la position exposée au LTV et aux mécanismes de liquidation. Alpha fixe la perte maximale au point d’entrée via la prime. Cette distinction a changé la façon dont je perçois le mot « levier ». Le même libellé peut décrire deux structures de risque très différentes. Et le multiplicateur de levier seul ne me dit pas assez. Il me dit la quantité d’exposition que je prends. Mais il ne me dit pas ce qui se passe quand je me trompe. Donc la question qui m’intéresse davantage n’est plus : « De quel levier ai-je le droit d’utiliser ? » C’est : « Où ma baisse est-elle réellement définie ? » Ça me semble être un bien meilleur point de départ. #termmax @termmax
Je pensais que l’effet de levier se résumait toujours à une seule question : jusqu’où une position peut-elle évoluer contre moi avant la liquidation ?
En creusant @TermMax , cette hypothèse m’a semblé trop simpliste.
Le levier basé sur GT fonctionne via le LTV. Si la garantie (collatéral) évolue suffisamment contre la position, la liquidation fait partie des risques.
Alpha est différent.
Ses positions Long et Short sont des options. Vous payez une prime d’avance, et cette prime définit la perte maximale possible de la position. TermMax décrit cela comme une exposition avec effet de levier sans risque de liquidation.
Je ne l’interprète pas comme un « levier sûr ».
Je le vois comme une manière différente de définir la baisse (le risque à la baisse).
GT laisse la position exposée au LTV et aux mécanismes de liquidation.
Alpha fixe la perte maximale au point d’entrée via la prime.
Cette distinction a changé la façon dont je perçois le mot « levier ».
Le même libellé peut décrire deux structures de risque très différentes.
Et le multiplicateur de levier seul ne me dit pas assez.
Il me dit la quantité d’exposition que je prends.
Mais il ne me dit pas ce qui se passe quand je me trompe.
Donc la question qui m’intéresse davantage n’est plus :
« De quel levier ai-je le droit d’utiliser ? »
C’est :
« Où ma baisse est-elle réellement définie ? »
Ça me semble être un bien meilleur point de départ.

#termmax @TermMax
#dusk $DUSK @Dusk_Foundation Je regarde DUSK autour de 0,063 $ ces derniers temps, et le marché continue de le traiter comme un token à petite capitalisation : environ 37 M$ de capitalisation boursière et quelque 2 M$ de volume quotidien. Mais la partie la plus intéressante pour moi n’est pas la taille. C’est la contradiction. CoinGecko classe encore DUSK dans la catégorie « Privacy Blockchain », alors que Dusk construit autour d’actifs régulés, de divulgation sélective et d’une visibilité contrôlée. Cela ressemble à un simple problème de classification, jusqu’à ce que vous regardiez ce que le protocole essaie réellement de faire. Dusk ne semble pas traiter la confidentialité comme « personne ne peut rien voir ». Sa conception ressemble plutôt à : garder, par défaut, les informations financières sensibles invisibles, puis permettre à l’émetteur, au lieu d’exécution, à l’auditeur ou au régulateur de voir les informations spécifiques qu’ils sont autorisés à consulter. Cela crée la contradiction à laquelle je reviens sans cesse. Le protocole essaie de rendre la confidentialité compatible avec la réglementation, alors que l’étiquette « confidentialité » elle-même peut devenir un signal de risque réglementaire. Ainsi, Dusk devra peut-être prouver deux choses en même temps. D’abord, que la divulgation sélective fonctionne réellement pour les marchés régulés. Ensuite, que les bourses et les dépositaires sont prêts à distinguer ce modèle des actifs de confidentialité totalement opaques. La première est un problème technique. La seconde est un problème de classification. Et honnêtement, la seconde m’intrigue davantage. Si le marché voit « privacy blockchain » avant de voir « infrastructure financière régulée », le plus grand avantage en confidentialité de Dusk ne risque-t-il pas de devenir une partie de son problème d’adoption ? @Dusk_Foundation #dusk $DUSK l
#dusk $DUSK @Dusk

Je regarde DUSK autour de 0,063 $ ces derniers temps, et le marché continue de le traiter comme un token à petite capitalisation : environ 37 M$ de capitalisation boursière et quelque 2 M$ de volume quotidien.

Mais la partie la plus intéressante pour moi n’est pas la taille. C’est la contradiction.

CoinGecko classe encore DUSK dans la catégorie « Privacy Blockchain », alors que Dusk construit autour d’actifs régulés, de divulgation sélective et d’une visibilité contrôlée.

Cela ressemble à un simple problème de classification, jusqu’à ce que vous regardiez ce que le protocole essaie réellement de faire.

Dusk ne semble pas traiter la confidentialité comme « personne ne peut rien voir ». Sa conception ressemble plutôt à : garder, par défaut, les informations financières sensibles invisibles, puis permettre à l’émetteur, au lieu d’exécution, à l’auditeur ou au régulateur de voir les informations spécifiques qu’ils sont autorisés à consulter.

Cela crée la contradiction à laquelle je reviens sans cesse.

Le protocole essaie de rendre la confidentialité compatible avec la réglementation, alors que l’étiquette « confidentialité » elle-même peut devenir un signal de risque réglementaire.

Ainsi, Dusk devra peut-être prouver deux choses en même temps.
D’abord, que la divulgation sélective fonctionne réellement pour les marchés régulés.

Ensuite, que les bourses et les dépositaires sont prêts à distinguer ce modèle des actifs de confidentialité totalement opaques.

La première est un problème technique.
La seconde est un problème de classification.
Et honnêtement, la seconde m’intrigue davantage.

Si le marché voit « privacy blockchain » avant de voir « infrastructure financière régulée », le plus grand avantage en confidentialité de Dusk ne risque-t-il pas de devenir une partie de son problème d’adoption ?

@Dusk #dusk $DUSK

l
#dusk $DUSK @Dusk_Foundation Je reviens sans cesse à un étrange hiatus à Dusk : le protocole rend le staking plus facile à connecter aux applications, tandis que le marché semble encore attendre que ces applications créent une vraie demande. Le Hyperstaking permet aux smart contracts de participer au staking. Dans l’ancien modèle, le staking signifiait davantage de charges opérationnelles, notamment le minimum de 1 000 DUSK et l’infrastructure nécessaire pour faire tourner un nœud. Désormais, l’interaction en matière de sécurité peut se faire au niveau du contrat. Et cela compte d’autant plus quand on regarde ce que Dusk construit réellement autour de tout ça : XSC pour les smart contracts confidentiels et les actifs financiers, ainsi qu’un travail autour des titres tokenisés et de l’infrastructure d’oracles. Ainsi, l’architecture évolue vers le fait de permettre aux applications de brancher la sécurité à leur manière. Mais voici la contradiction que je trouve la plus intéressante. Réduire la friction autour du staking devrait rendre le réseau plus facile à utiliser, mais une infrastructure plus simple ne crée pas automatiquement une activité économique. Si les applications financières ne génèrent pas de transactions récurrentes, le Hyperstaking peut améliorer l’architecture sans modifier matériellement l’utilisation du réseau. C’est pourquoi je suis moins intéressé par l’offre de 1 B DUSK ou par une autre métrique de staking prise isolément. Je veux voir si l’activité en direct commence à rattraper la conception : interactions entre contrats, portefeuilles actifs, volume de règlement et usage financier récurrent. Car le vrai test n’est pas de savoir si Dusk a rendu la sécurité plus facile à intégrer. C’est de savoir si les applications ont réellement une raison suffisante d’utiliser cette sécurité. @Dusk_Foundation #dusk $DUSK
#dusk $DUSK @Dusk

Je reviens sans cesse à un étrange hiatus à Dusk : le protocole rend le staking plus facile à connecter aux applications, tandis que le marché semble encore attendre que ces applications créent une vraie demande.

Le Hyperstaking permet aux smart contracts de participer au staking. Dans l’ancien modèle, le staking signifiait davantage de charges opérationnelles, notamment le minimum de 1 000 DUSK et l’infrastructure nécessaire pour faire tourner un nœud. Désormais, l’interaction en matière de sécurité peut se faire au niveau du contrat.

Et cela compte d’autant plus quand on regarde ce que Dusk construit réellement autour de tout ça : XSC pour les smart contracts confidentiels et les actifs financiers, ainsi qu’un travail autour des titres tokenisés et de l’infrastructure d’oracles.

Ainsi, l’architecture évolue vers le fait de permettre aux applications de brancher la sécurité à leur manière.
Mais voici la contradiction que je trouve la plus intéressante.

Réduire la friction autour du staking devrait rendre le réseau plus facile à utiliser, mais une infrastructure plus simple ne crée pas automatiquement une activité économique. Si les applications financières ne génèrent pas de transactions récurrentes, le Hyperstaking peut améliorer l’architecture sans modifier matériellement l’utilisation du réseau.

C’est pourquoi je suis moins intéressé par l’offre de 1 B DUSK ou par une autre métrique de staking prise isolément.
Je veux voir si l’activité en direct commence à rattraper la conception : interactions entre contrats, portefeuilles actifs, volume de règlement et usage financier récurrent.

Car le vrai test n’est pas de savoir si Dusk a rendu la sécurité plus facile à intégrer.
C’est de savoir si les applications ont réellement une raison suffisante d’utiliser cette sécurité.

@Dusk #dusk $DUSK
#termmax @termmax J’avais l’habitude de lire @TermMax via la couche retail, mais les chiffres actuels me font le regarder différemment. Les campagnes TMX, l’XP, les badges, l’effet de levier et Alpha créent une activité visible. TermMax se situe autour de 32,5 M$ de TVL, avec environ 22,1 M$ de prêts actifs et 16,7 K$ de frais sur 30 jours. Ce qui m’a marqué, ce n’est pas la taille. C’est l’écart entre la liquidité et la demande de crédit réelle. Si le retail aide à amorcer la couche de liquidité, la question la plus difficile est de savoir si ce capital continue à trouver un usage productif, plutôt que de simplement s’accumuler au bilan. L’orientation institutionnelle rend cela encore plus intéressant. TermMax est déjà passé à un financement à taux fixe autour de titres tokenisés d’Ondo, tandis que la plateforme de titres tokenisés d’Ondo a franchi 1 Md$ de TVL et 18 Md$ de volume cumulé. Donc l’opportunité de marché semble réelle. Mais il y a une contradiction à laquelle je reviens sans cesse : l’adoption institutionnelle exige une liquidité profonde, tandis que la liquidité profonde a elle-même besoin d’une demande récurrente. Le retail peut aider à créer rapidement le premier volet. Les institutions fourniront peut-être le second, mais elles ont besoin d’un financement prévisible, d’échéances clairement définies et d’une profondeur suffisante pour déployer une taille significative. C’est pourquoi je m’intéresse moins au fait que TermMax fasse simplement grossir son TVL. Je surveille si la liquidité existante commence à tourner plus fréquemment en une demande de crédit durable. Peut-être que le vrai test n’est pas d’attirer davantage de capitaux. C’est de prouver que le capital déjà en place peut continuer à trouver une mission.
#termmax @TermMax

J’avais l’habitude de lire @TermMax via la couche retail, mais les chiffres actuels me font le regarder différemment.

Les campagnes TMX, l’XP, les badges, l’effet de levier et Alpha créent une activité visible. TermMax se situe autour de 32,5 M$ de TVL, avec environ 22,1 M$ de prêts actifs et 16,7 K$ de frais sur 30 jours.

Ce qui m’a marqué, ce n’est pas la taille. C’est l’écart entre la liquidité et la demande de crédit réelle.

Si le retail aide à amorcer la couche de liquidité, la question la plus difficile est de savoir si ce capital continue à trouver un usage productif, plutôt que de simplement s’accumuler au bilan.

L’orientation institutionnelle rend cela encore plus intéressant. TermMax est déjà passé à un financement à taux fixe autour de titres tokenisés d’Ondo, tandis que la plateforme de titres tokenisés d’Ondo a franchi 1 Md$ de TVL et 18 Md$ de volume cumulé.

Donc l’opportunité de marché semble réelle.

Mais il y a une contradiction à laquelle je reviens sans cesse :

l’adoption institutionnelle exige une liquidité profonde, tandis que la liquidité profonde a elle-même besoin d’une demande récurrente.

Le retail peut aider à créer rapidement le premier volet. Les institutions fourniront peut-être le second, mais elles ont besoin d’un financement prévisible, d’échéances clairement définies et d’une profondeur suffisante pour déployer une taille significative.

C’est pourquoi je m’intéresse moins au fait que TermMax fasse simplement grossir son TVL.

Je surveille si la liquidité existante commence à tourner plus fréquemment en une demande de crédit durable.

Peut-être que le vrai test n’est pas d’attirer davantage de capitaux.

C’est de prouver que le capital déjà en place peut continuer à trouver une mission.
#termmax @termmax Je revenais sans cesse aux ordres à fourchette de TermMax parce que, franchement, au début, je pensais que ce n’était qu’une fonctionnalité de carnet d’ordres de plus. Puis j’ai regardé les chiffres actuels et j’ai commencé à voir la conception différemment. TermMax tourne autour de 33 M$ de TVL avec environ 22 M$ en prêts actifs, tandis qu’environ 94 % du TVL reste encore sur Ethereum. Ce qui m’a particulièrement frappé, c’est la façon dont l’ordre à fourchette gère la taille. Un prêteur ne se contente pas de dire : « Je vais prêter à 8 % ». C’est plutôt comme : « Je vais fournir ce montant à 8 %, mais si vous utilisez davantage de mon capital, je veux un taux différent. » Ça ressemble bien plus à la manière dont j’aurais réellement tendance à penser mon propre argent. Je pourrais être parfaitement à l’aise de placer 50 000 $ quelque part, mais 500 000 $ me ferait hésiter. La concentration n’est pas la même. La liquidité que j’abandonne n’est pas la même. Même le coût d’opportunité commence à sembler différent. Au départ, j’ai vu ça comme simplement une meilleure tarification du crédit. Mais il y a un détail que je n’avais pas anticipé. Plus de contrôle, ça veut aussi dire plus de décisions. Vous pouvez façonner l’endroit où se place votre liquidité, mais vous devez aussi être plus délibéré quant à la courbe que vous créez. Et comme la liquidité est encore très concentrée sur Ethereum, je me demande encore si cette précision supplémentaire aide vraiment le capital à mieux se coordonner, ou si elle donne simplement aux utilisateurs plus de réglages à gérer. Peut-être que c’est là le vrai test du crédit programmable. @termmax #termax
#termmax @TermMax

Je revenais sans cesse aux ordres à fourchette de TermMax parce que, franchement, au début, je pensais que ce n’était qu’une fonctionnalité de carnet d’ordres de plus.

Puis j’ai regardé les chiffres actuels et j’ai commencé à voir la conception différemment.
TermMax tourne autour de 33 M$ de TVL avec environ 22 M$ en prêts actifs, tandis qu’environ 94 % du TVL reste encore sur Ethereum.

Ce qui m’a particulièrement frappé, c’est la façon dont l’ordre à fourchette gère la taille.

Un prêteur ne se contente pas de dire : « Je vais prêter à 8 % ».
C’est plutôt comme : « Je vais fournir ce montant à 8 %, mais si vous utilisez davantage de mon capital, je veux un taux différent. »

Ça ressemble bien plus à la manière dont j’aurais réellement tendance à penser mon propre argent.

Je pourrais être parfaitement à l’aise de placer 50 000 $ quelque part, mais 500 000 $ me ferait hésiter. La concentration n’est pas la même. La liquidité que j’abandonne n’est pas la même. Même le coût d’opportunité commence à sembler différent.

Au départ, j’ai vu ça comme simplement une meilleure tarification du crédit.
Mais il y a un détail que je n’avais pas anticipé.
Plus de contrôle, ça veut aussi dire plus de décisions.
Vous pouvez façonner l’endroit où se place votre liquidité, mais vous devez aussi être plus délibéré quant à la courbe que vous créez.

Et comme la liquidité est encore très concentrée sur Ethereum, je me demande encore si cette précision supplémentaire aide vraiment le capital à mieux se coordonner, ou si elle donne simplement aux utilisateurs plus de réglages à gérer.
Peut-être que c’est là le vrai test du crédit programmable.

@TermMax #termax
#dusk $DUSK @Dusk_Foundation Je regardais la configuration de la Citadelle de DUSK et un petit détail me dérangeait : la divulgation sélective réduit les données que vous exposez, mais elle peut rendre l’émetteur du justificatif encore plus important. L’idée elle-même est assez simple. Un utilisateur est vérifié, reçoit une licence, puis peut plus tard prouver des éléments comme un statut accrédité, la suppression des sanctions, ou la juridiction, sans montrer l’ensemble du dossier d’identité. Au début, je me suis dit : d’accord, c’est tout simplement moins de confiance et moins de données partout. Puis j’ai commencé à réfléchir à ce qui se passe derrière ce justificatif. La décision initiale de KYC vient forcément de quelque part. Si ce justificatif est portable, la même décision peut être réutilisée dans différentes interactions au lieu que chaque institution doive recommencer le processus. C’est utile. Mais cela signifie aussi que je m’appuie davantage sur la personne qui l’a émis. Et c’est là que la question du moment a attiré mon attention. Un justificatif peut être valable aujourd’hui et ne pas vouloir dire la même chose plus tard. Les sanctions changent. L’éligibilité change. Les informations de conformité deviennent obsolètes. Donc le compromis que je vois sans cesse est très simple : le vérificateur voit moins, mais l’émetteur compte davantage. Cela rend des éléments comme la révocation, l’actualité et la responsabilité assez importants. Je m’intéresse aussi davantage à savoir si les gens utilisent réellement ces justificatifs de façon répétée que le nombre d’intégrations annoncées. Parce qu’éventuellement, quelqu’un doit faire confiance au justificatif assez pour agir en conséquence. Si ce justificatif s’avère dépassé ou erroné, je me demande encore : qui est réellement responsable ? @Dusk_Foundation #dusk $DUSK Quand un justificatif est erroné ou obsolète, qui doit en être tenu responsable ?
#dusk $DUSK @Dusk

Je regardais la configuration de la Citadelle de DUSK et un petit détail me dérangeait : la divulgation sélective réduit les données que vous exposez, mais elle peut rendre l’émetteur du justificatif encore plus important.

L’idée elle-même est assez simple. Un utilisateur est vérifié, reçoit une licence, puis peut plus tard prouver des éléments comme un statut accrédité, la suppression des sanctions, ou la juridiction, sans montrer l’ensemble du dossier d’identité.

Au début, je me suis dit : d’accord, c’est tout simplement moins de confiance et moins de données partout.

Puis j’ai commencé à réfléchir à ce qui se passe derrière ce justificatif.

La décision initiale de KYC vient forcément de quelque part. Si ce justificatif est portable, la même décision peut être réutilisée dans différentes interactions au lieu que chaque institution doive recommencer le processus.

C’est utile.

Mais cela signifie aussi que je m’appuie davantage sur la personne qui l’a émis.

Et c’est là que la question du moment a attiré mon attention. Un justificatif peut être valable aujourd’hui et ne pas vouloir dire la même chose plus tard. Les sanctions changent. L’éligibilité change. Les informations de conformité deviennent obsolètes.

Donc le compromis que je vois sans cesse est très simple :

le vérificateur voit moins, mais l’émetteur compte davantage.

Cela rend des éléments comme la révocation, l’actualité et la responsabilité assez importants.

Je m’intéresse aussi davantage à savoir si les gens utilisent réellement ces justificatifs de façon répétée que le nombre d’intégrations annoncées.

Parce qu’éventuellement, quelqu’un doit faire confiance au justificatif assez pour agir en conséquence.

Si ce justificatif s’avère dépassé ou erroné, je me demande encore :

qui est réellement responsable ?

@Dusk #dusk $DUSK

Quand un justificatif est erroné ou obsolète, qui doit en être tenu responsable ?
The credential issuer
67%
The verifier
33%
Both equally
0%
3 Votes • Vote fermé
#dusk $DUSK @Dusk_Foundation Je revenais sans cesse à un contraste étrange dans DuskEVM : pour le moment, le marché traite DUSK comme un actif discret à 0,064 $, avec environ 4,1 M$ de volume sur 24 h, tandis que l’architecture rend tranquillement DUSK comme première étape vers l’EVM elle-même. Avant de déployer Solidity, vous bridgez DUSK depuis DuskDS. Il devient l’actif de frais (gas) sur DuskEVM, tandis que DuskDS reste la couche de règlement et de disponibilité des données. Au début, cela m’a semblé n’être qu’un branchement standard de testnet. Puis la contradiction s’est éclairée. DuskEVM est censé paraître familier aux développeurs EVM, mais la première action économique n’a rien d’ethereumien. Vous entrez d’abord via la propre couche de règlement de Dusk. Ainsi, l’histoire de la compatibilité et celle du règlement tirent dans des directions différentes : une exécution familière d’un côté, et une dépendance volontairement native à Dusk en dessous. Et cela pourrait compter davantage que le bridge lui-même. Si, un jour, les développeurs utilisent DuskEVM pour des applications financières sensibles à la confidentialité, la question n’est pas seulement de savoir si l’EVM paraît familier. C’est de savoir si cette connexion sous-jacente à DuskDS fait partie de la raison pour laquelle l’application fonctionne comme elle le fait. Pour l’instant, alors que DUSK s’échange encore autour de six cents, le marché ne semble pas intégrer beaucoup de valeur dans cette distinction. Je ne sais pas si c’est parce que l’architecture est encore précoce, ou parce que la dépendance finalement ne comptera pas autant que je le pense. Quel camp aura raison quand de vraies applications arriveront ? @Dusk_Foundation #dusk $DUSK Qu’est-ce qui compte le plus pour l’adoption à long terme de DuskEVM ?
#dusk $DUSK @Dusk
Je revenais sans cesse à un contraste étrange dans DuskEVM : pour le moment, le marché traite DUSK comme un actif discret à 0,064 $, avec environ 4,1 M$ de volume sur 24 h, tandis que l’architecture rend tranquillement DUSK comme première étape vers l’EVM elle-même.
Avant de déployer Solidity, vous bridgez DUSK depuis DuskDS. Il devient l’actif de frais (gas) sur DuskEVM, tandis que DuskDS reste la couche de règlement et de disponibilité des données.

Au début, cela m’a semblé n’être qu’un branchement standard de testnet.

Puis la contradiction s’est éclairée.
DuskEVM est censé paraître familier aux développeurs EVM, mais la première action économique n’a rien d’ethereumien. Vous entrez d’abord via la propre couche de règlement de Dusk.

Ainsi, l’histoire de la compatibilité et celle du règlement tirent dans des directions différentes : une exécution familière d’un côté, et une dépendance volontairement native à Dusk en dessous.
Et cela pourrait compter davantage que le bridge lui-même.
Si, un jour, les développeurs utilisent DuskEVM pour des applications financières sensibles à la confidentialité, la question n’est pas seulement de savoir si l’EVM paraît familier. C’est de savoir si cette connexion sous-jacente à DuskDS fait partie de la raison pour laquelle l’application fonctionne comme elle le fait.

Pour l’instant, alors que DUSK s’échange encore autour de six cents, le marché ne semble pas intégrer beaucoup de valeur dans cette distinction.

Je ne sais pas si c’est parce que l’architecture est encore précoce, ou parce que la dépendance finalement ne comptera pas autant que je le pense.
Quel camp aura raison quand de vraies applications arriveront ?

@Dusk #dusk $DUSK

Qu’est-ce qui compte le plus pour l’adoption à long terme de DuskEVM ?
EVM compatibility
67%
DuskDS settlement
0%
Privacy-native apps
33%
6 Votes • Vote fermé
Je n’ai cessé de regarder le Double investissement d’@TermMax Alpha, et une contradiction ressortait plus que le Taux annuel (APY). L’interface actuelle annonce des rendements d’environ 50%, mais ce qui m’intéresse davantage, c’est d’où vient réellement ce rendement : votre USDT sert en pratique à financer la liquidité des positions vendeuses (put). Si le prix reste au-dessus de votre prix d’exercice (strike), vous conservez l’USDT et la prime. S’il passe en dessous, l’USDT peut être converti en l’actif au strike que vous avez choisi. Donc, le rendement séduisant s’accompagne d’une condition moins évidente : votre liquidité peut ne pas rester entièrement liquide. Les documents de TermMax indiquent que lorsque les actifs déposés sont déjà empruntés par les acheteurs d’options, le retrait anticipé peut être indisponible jusqu’à l’échéance. Cela change ma façon de voir le produit. Le taux APY ne vous rémunère pas vraiment seulement pour « garer » de l’USDT. On vous compense pour rendre cette liquidité disponible à quelqu’un qui prend l’autre côté de l’option. Et si le marché évolue fortement, cette différence compte. Vous pourriez gagner tout en devenant, simultanément, moins flexible avec le capital. Je me demande si les utilisateurs valoriseront cet arbitrage lorsque le titre « APY » cessera d’être l’attrait principal. La contradiction clé ici, c’est : rendement vs liquidité. Le même mécanisme qui peut rendre le retour intéressant peut aussi rendre le capital moins flexible. @termmax #termmax
Je n’ai cessé de regarder le Double investissement d’@TermMax Alpha, et une contradiction ressortait plus que le Taux annuel (APY).

L’interface actuelle annonce des rendements d’environ 50%, mais ce qui m’intéresse davantage, c’est d’où vient réellement ce rendement : votre USDT sert en pratique à financer la liquidité des positions vendeuses (put).

Si le prix reste au-dessus de votre prix d’exercice (strike), vous conservez l’USDT et la prime. S’il passe en dessous, l’USDT peut être converti en l’actif au strike que vous avez choisi.
Donc, le rendement séduisant s’accompagne d’une condition moins évidente : votre liquidité peut ne pas rester entièrement liquide.

Les documents de TermMax indiquent que lorsque les actifs déposés sont déjà empruntés par les acheteurs d’options, le retrait anticipé peut être indisponible jusqu’à l’échéance.
Cela change ma façon de voir le produit.
Le taux APY ne vous rémunère pas vraiment seulement pour « garer » de l’USDT. On vous compense pour rendre cette liquidité disponible à quelqu’un qui prend l’autre côté de l’option.

Et si le marché évolue fortement, cette différence compte.

Vous pourriez gagner tout en devenant, simultanément, moins flexible avec le capital.
Je me demande si les utilisateurs valoriseront cet arbitrage lorsque le titre « APY » cessera d’être l’attrait principal.

La contradiction clé ici, c’est : rendement vs liquidité. Le même mécanisme qui peut rendre le retour intéressant peut aussi rendre le capital moins flexible.

@TermMax #termmax
#termmax @termmax Je pensais que TermMax résolvait principalement un seul problème : ramener les prêts à taux fixe on-chain. Après avoir passé plus de temps sur la conception, je pense que le problème le plus difficile est ce qui arrive à ce crédit fixe quand la liquidité commence à bouger. C’est là que l’architecture est devenue plus intéressante pour moi. La structure GT place la garantie et la dette dans une seule position, tandis que les limites LTV rendent la limite de risque plus facile à visualiser. Les ordres à plage vont encore plus loin en permettant aux prêteurs d’exprimer comment leur taux requis évolue à mesure que davantage de leur liquidité est utilisée. Cette différence subtile compte. Cela signifie que le marché ne fait pas que faire correspondre du capital à un prix. Il peut commencer à exprimer une relation entre la taille, le taux, la durée et la préférence de liquidité. Mais la flexibilité ne supprime pas le risque. Elle déplace une partie de la complexité ailleurs. Les liquidations dépendent toujours de la liquidité du marché. Les positions fixes ont toujours besoin de sorties crédibles. La gouvernance doit toujours pouvoir modifier des paramètres sans transformer un ajustement local en un événement de risque plus large. C’est aussi pour cela que Smart Unwind a retenu mon attention. Une position fixe n’est utile que dans la mesure où le système est capable de la gérer lorsque les conditions initiales ne semblent plus aussi confortables. Ainsi, je surveille TermMax moins pour le taux mis en avant aujourd’hui, et davantage pour ce qui se passe quand la liquidité devient rare. Le crédit programmable peut-il préserver la certitude des taux fixes sans faire discrètement de la liquidité le prix de cette certitude ? #TermMax @termmax
#termmax @TermMax

Je pensais que TermMax résolvait principalement un seul problème : ramener les prêts à taux fixe on-chain. Après avoir passé plus de temps sur la conception, je pense que le problème le plus difficile est ce qui arrive à ce crédit fixe quand la liquidité commence à bouger.
C’est là que l’architecture est devenue plus intéressante pour moi.
La structure GT place la garantie et la dette dans une seule position, tandis que les limites LTV rendent la limite de risque plus facile à visualiser. Les ordres à plage vont encore plus loin en permettant aux prêteurs d’exprimer comment leur taux requis évolue à mesure que davantage de leur liquidité est utilisée.
Cette différence subtile compte.
Cela signifie que le marché ne fait pas que faire correspondre du capital à un prix. Il peut commencer à exprimer une relation entre la taille, le taux, la durée et la préférence de liquidité.
Mais la flexibilité ne supprime pas le risque. Elle déplace une partie de la complexité ailleurs.
Les liquidations dépendent toujours de la liquidité du marché. Les positions fixes ont toujours besoin de sorties crédibles. La gouvernance doit toujours pouvoir modifier des paramètres sans transformer un ajustement local en un événement de risque plus large.
C’est aussi pour cela que Smart Unwind a retenu mon attention. Une position fixe n’est utile que dans la mesure où le système est capable de la gérer lorsque les conditions initiales ne semblent plus aussi confortables.
Ainsi, je surveille TermMax moins pour le taux mis en avant aujourd’hui, et davantage pour ce qui se passe quand la liquidité devient rare.
Le crédit programmable peut-il préserver la certitude des taux fixes sans faire discrètement de la liquidité le prix de cette certitude ?

#TermMax @TermMax
#dusk $DUSK @Dusk_Foundation Je relisais à nouveau le livre blanc Dusk et une idée ne cessait de me revenir : la confidentialité dans les marchés financiers ne consiste pas vraiment à tout cacher. Il s’agit de dissimuler ce qui ne devrait pas être public, tout en prouvant ce qui doit réellement être vérifié. Cette distinction peut sembler minime, mais je pense que c’est le problème le plus difficile. Une blockchain publique rend la vérification simple, car tout le monde peut voir les mêmes données. Mais la finance réglementée ne fonctionne pas toujours ainsi. Certaines transactions sensibles peuvent nécessiter de la confidentialité, tandis que les règles de propriété, l’éligibilité ou la validité des transactions doivent, elles, rester prouvables. C’est là que @Dusk a retenu mon attention. Phoenix adopte une approche basée sur les UTXO et combine des outils comme les adresses furtives, les nullifiants, les signatures et les preuves à divulgation nulle de connaissance. Ce qui m’intéresse, ce n’est pas seulement que les détails des transactions puissent rester privés. C’est que la vérification ne doit pas nécessairement signifier divulgation. Puis Zedger pousse cette idée plus loin vers des smart contracts confidentiels et des applications financières. Pour moi, c’est cette frontière qui est intéressante : la confidentialité ne devrait pas vouloir dire créer une boîte noire, et la conformité ne devrait pas vouloir dire rendre chaque action financière publique. Le véritable test est de savoir si les régulateurs peuvent accepter une preuve cryptographique comme élément de preuve pertinent, sans avoir besoin de tout voir en dessous. Si cet équilibre fonctionne, c’est une idée bien plus utile que la seule confidentialité. Qu’en pensez-vous : la finance réglementée pourra-t-elle, à terme, faire confiance à la preuve sans exiger une visibilité totale ? @Dusk_Foundation #dusk $DUSK Ce qui compte le plus pour la finance réglementée en chaîne ?
#dusk $DUSK @Dusk

Je relisais à nouveau le livre blanc Dusk et une idée ne cessait de me revenir : la confidentialité dans les marchés financiers ne consiste pas vraiment à tout cacher.

Il s’agit de dissimuler ce qui ne devrait pas être public, tout en prouvant ce qui doit réellement être vérifié.
Cette distinction peut sembler minime, mais je pense que c’est le problème le plus difficile.

Une blockchain publique rend la vérification simple, car tout le monde peut voir les mêmes données. Mais la finance réglementée ne fonctionne pas toujours ainsi. Certaines transactions sensibles peuvent nécessiter de la confidentialité, tandis que les règles de propriété, l’éligibilité ou la validité des transactions doivent, elles, rester prouvables.

C’est là que @Dusk a retenu mon attention.
Phoenix adopte une approche basée sur les UTXO et combine des outils comme les adresses furtives, les nullifiants, les signatures et les preuves à divulgation nulle de connaissance. Ce qui m’intéresse, ce n’est pas seulement que les détails des transactions puissent rester privés.

C’est que la vérification ne doit pas nécessairement signifier divulgation.

Puis Zedger pousse cette idée plus loin vers des smart contracts confidentiels et des applications financières.

Pour moi, c’est cette frontière qui est intéressante : la confidentialité ne devrait pas vouloir dire créer une boîte noire, et la conformité ne devrait pas vouloir dire rendre chaque action financière publique.

Le véritable test est de savoir si les régulateurs peuvent accepter une preuve cryptographique comme élément de preuve pertinent, sans avoir besoin de tout voir en dessous.
Si cet équilibre fonctionne, c’est une idée bien plus utile que la seule confidentialité.

Qu’en pensez-vous : la finance réglementée pourra-t-elle, à terme, faire confiance à la preuve sans exiger une visibilité totale ?

@Dusk #dusk $DUSK

Ce qui compte le plus pour la finance réglementée en chaîne ?
Privacy by default
0%
Full transparency
0%
Verifiable compliance
0%
0 Votes • Vote fermé
#dusk $DUSK Au début, je pensais que DuskEVM était principalement un projet d’onboarding EVM. Puis j’ai regardé le marché et l’architecture ensemble, et la contradiction est devenue beaucoup plus difficile à ignorer. DUSK s’échange autour de la zone des ~$0,07, tandis que le protocole essaie de résoudre un problème qui n’est pas vraiment une question de prix : comment rendre l’activité financière privée sans la rendre impossible à vérifier ? Solidity et Hardhat réduisent la barrière à l’entrée pour les développeurs, mais c’est Hedger qui a retenu mon attention. La partie intéressante n’est pas simplement de cacher les soldes ou les données de transaction. C’est que Dusk essaie de protéger les informations sensibles tout en permettant que certaines affirmations soient prouvées. Mais la confidentialité a un coût. La génération de preuves ZK est suffisamment lourde sur le plan computationnel pour que Dusk sépare le travail du prouveur dans une infrastructure spécialisée, avec des performances qui dépendent fortement de la capacité d’un seul cœur. Et il y a ensuite le pont entre Dusk L1 et DuskEVM. Un retrait n’est pas une action unique : il nécessite une initialisation, une preuve, puis une finalisation sur la L1. Donc la contradiction à laquelle je reviens sans cesse, c’est celle-ci : Plus le flux de travail financier devient privé, plus la machinerie de vérification devient importante. La confidentialité réduit ce que les observateurs peuvent voir. La conformité augmente ce qui doit être prouvable. Peut-être que le problème le plus difficile de DuskEVM n’est pas d’atteindre la confidentialité. C’est d’empêcher que la confidentialité ne devienne une autre forme de complexité. C’est la partie que je continue de surveiller. @Dusk_Foundation #dusk $DUSK
#dusk $DUSK
Au début, je pensais que DuskEVM était principalement un projet d’onboarding EVM. Puis j’ai regardé le marché et l’architecture ensemble, et la contradiction est devenue beaucoup plus difficile à ignorer.

DUSK s’échange autour de la zone des ~$0,07, tandis que le protocole essaie de résoudre un problème qui n’est pas vraiment une question de prix : comment rendre l’activité financière privée sans la rendre impossible à vérifier ?

Solidity et Hardhat réduisent la barrière à l’entrée pour les développeurs, mais c’est Hedger qui a retenu mon attention.
La partie intéressante n’est pas simplement de cacher les soldes ou les données de transaction. C’est que Dusk essaie de protéger les informations sensibles tout en permettant que certaines affirmations soient prouvées.
Mais la confidentialité a un coût.

La génération de preuves ZK est suffisamment lourde sur le plan computationnel pour que Dusk sépare le travail du prouveur dans une infrastructure spécialisée, avec des performances qui dépendent fortement de la capacité d’un seul cœur.
Et il y a ensuite le pont entre Dusk L1 et DuskEVM. Un retrait n’est pas une action unique : il nécessite une initialisation, une preuve, puis une finalisation sur la L1.
Donc la contradiction à laquelle je reviens sans cesse, c’est celle-ci :
Plus le flux de travail financier devient privé, plus la machinerie de vérification devient importante.

La confidentialité réduit ce que les observateurs peuvent voir.
La conformité augmente ce qui doit être prouvable.

Peut-être que le problème le plus difficile de DuskEVM n’est pas d’atteindre la confidentialité.

C’est d’empêcher que la confidentialité ne devienne une autre forme de complexité.
C’est la partie que je continue de surveiller.

@Dusk #dusk $DUSK
#dusk $DUSK Je reviens sans cesse à une contradiction chez @Dusk : plus la confidentialité devient utile pour les institutions, plus la visibilité contrôlée devient précieuse. DUSK s’élève autour de 0,0648 $, en hausse de 6,75 %, mais le mouvement du prix n’est pas vraiment la partie qui m’intéresse. Ce qui a attiré mon attention, c’est l’architecture autour des transactions confidentielles, XSC, et de la divulgation sélective. L’idée n’est pas simplement de masquer les informations financières. Il s’agit de permettre à différents participants d’accéder à différentes couches de ces informations, lorsque la situation l’exige. Un investisseur n’a peut-être besoin que d’une preuve d’éligibilité. Un émetteur peut avoir besoin de davantage de contexte. Un auditeur ou un régulateur pourrait exiger des dossiers plus approfondis. Le marché au sens large peut n’avoir besoin de presque rien. Cela transforme la confidentialité d’un problème de dissimulation en un problème d’allocation d’accès. Et c’est là que la contradiction devient intéressante. Plus la divulgation programmable s’améliore, plus la couche de permissions devient importante aussi. Qui définit ces règles ? Qui peut les modifier ? Qui décide quand une exception est légitime ? Car un système peut protéger des informations sensibles tout en concentrant encore le pouvoir sur la personne (ou l’entité) qui est autorisée à les voir. C’est la limite que je trouve plus intéressante que la blockchain privée. Dusk teste peut-être si les marchés financiers peuvent bénéficier de confidentialité sans perdre la vérifiabilité. Mais le test le plus difficile pourrait être de savoir si la visibilité programmable reste neutre ou finit par devenir progressivement un contrôle programmable. C’est ce que je surveille au-delà du graphique des prix. @Dusk_Foundation #dusk $DUSK
#dusk $DUSK
Je reviens sans cesse à une contradiction chez @Dusk : plus la confidentialité devient utile pour les institutions, plus la visibilité contrôlée devient précieuse.

DUSK s’élève autour de 0,0648 $, en hausse de 6,75 %, mais le mouvement du prix n’est pas vraiment la partie qui m’intéresse.

Ce qui a attiré mon attention, c’est l’architecture autour des transactions confidentielles, XSC, et de la divulgation sélective. L’idée n’est pas simplement de masquer les informations financières. Il s’agit de permettre à différents participants d’accéder à différentes couches de ces informations, lorsque la situation l’exige.

Un investisseur n’a peut-être besoin que d’une preuve d’éligibilité.
Un émetteur peut avoir besoin de davantage de contexte.
Un auditeur ou un régulateur pourrait exiger des dossiers plus approfondis.

Le marché au sens large peut n’avoir besoin de presque rien.
Cela transforme la confidentialité d’un problème de dissimulation en un problème d’allocation d’accès.
Et c’est là que la contradiction devient intéressante.

Plus la divulgation programmable s’améliore, plus la couche de permissions devient importante aussi.
Qui définit ces règles ?
Qui peut les modifier ?
Qui décide quand une exception est légitime ?

Car un système peut protéger des informations sensibles tout en concentrant encore le pouvoir sur la personne (ou l’entité) qui est autorisée à les voir.
C’est la limite que je trouve plus intéressante que la blockchain privée.

Dusk teste peut-être si les marchés financiers peuvent bénéficier de confidentialité sans perdre la vérifiabilité.

Mais le test le plus difficile pourrait être de savoir si la visibilité programmable reste neutre ou finit par devenir progressivement un contrôle programmable.
C’est ce que je surveille au-delà du graphique des prix.

@Dusk #dusk $DUSK
#dusk $DUSK Je pensais auparavant que la résistance à Sybil consistait à empêcher les identités fausses. Après avoir creusé le design de mise en jeu (staking) de Dusk, je commence à penser que le problème le plus difficile est plutôt l’évaluation du coût de l’influence. Le minimum de 1 000 DUSK n’est que la première couche. Ce qui a attiré mon attention, c’est que la nouvelle mise n’est pas activée immédiatement. Dusk utilise des epochs de 2 160 blocs, avec une activation qui tombe après la prochaine borne de période (boundary), soit environ 6 à 12 heures selon le moment où la mise arrive. Cela crée un compromis étrange. Un attaquant peut obtenir du capital, mais ne peut pas le transformer instantanément en poids de consensus. Pourtant, la même friction s’applique au capital honnête. La sécurité se renforce en partie parce que le système oblige tout le monde à attendre. Ensuite, j’ai regardé le volet incitations. Dusk prévoit d’émettre 500 M de DUSK sur 36 ans pour financer les récompenses de staking. Cela signifie que la sécurité n’est pas seulement une propriété technique ; elle dépend du fait que les validateurs continuent de trouver que l’économie vaut l’effort du capital et de l’exploitation. Donc je m’intéresse moins, à présent, au nombre d’identités que quelqu’un peut créer. Je m’intéresse davantage au coût que représente le fait de rendre ces identités pertinentes. Peut-être que la résistance à Sybil ne vise pas vraiment à empêcher les identités factices. Peut-être qu’elle vise à rendre l’influence coûteuse, lente et traçable. Une meilleure façon de penser la sécurité du staking serait-elle celle-là ? @Dusk_Foundation #dusk $DUSK Qu’est-ce qui compte le plus pour la résistance à Sybil ?
#dusk $DUSK

Je pensais auparavant que la résistance à Sybil consistait à empêcher les identités fausses. Après avoir creusé le design de mise en jeu (staking) de Dusk, je commence à penser que le problème le plus difficile est plutôt l’évaluation du coût de l’influence.

Le minimum de 1 000 DUSK n’est que la première couche. Ce qui a attiré mon attention, c’est que la nouvelle mise n’est pas activée immédiatement. Dusk utilise des epochs de 2 160 blocs, avec une activation qui tombe après la prochaine borne de période (boundary), soit environ 6 à 12 heures selon le moment où la mise arrive.

Cela crée un compromis étrange.
Un attaquant peut obtenir du capital, mais ne peut pas le transformer instantanément en poids de consensus. Pourtant, la même friction s’applique au capital honnête. La sécurité se renforce en partie parce que le système oblige tout le monde à attendre.

Ensuite, j’ai regardé le volet incitations. Dusk prévoit d’émettre 500 M de DUSK sur 36 ans pour financer les récompenses de staking. Cela signifie que la sécurité n’est pas seulement une propriété technique ; elle dépend du fait que les validateurs continuent de trouver que l’économie vaut l’effort du capital et de l’exploitation.

Donc je m’intéresse moins, à présent, au nombre d’identités que quelqu’un peut créer.
Je m’intéresse davantage au coût que représente le fait de rendre ces identités pertinentes.

Peut-être que la résistance à Sybil ne vise pas vraiment à empêcher les identités factices.

Peut-être qu’elle vise à rendre l’influence coûteuse, lente et traçable.

Une meilleure façon de penser la sécurité du staking serait-elle celle-là ?

@Dusk #dusk $DUSK

Qu’est-ce qui compte le plus pour la résistance à Sybil ?
Making influence expensive
34%
Delaying new stake
33%
Both together
33%
3 Votes • Vote fermé
#dusk $DUSK Je reviens sans cesse à une contradiction chez @Dusk : le système essaie de révéler moins, mais la finance réglementée pourrait en réalité exiger davantage de choses à pouvoir prouver. Citadel 2 et XSC font très clairement cette distinction. Vous pouvez prouver votre éligibilité sans exposer l’identité derrière l’attestation, tandis que l’activité financière peut rester confidentielle sans supprimer les exigences de conformité ou d’audit. L’objectif n’est donc pas vraiment de « tout cacher ». C’est plutôt : prouver l’affirmation, tout en retenant les données inutiles. Ce qui rend tout cela plus intéressant, c’est la partie sécurité. AEGIS a remédié à 39 constats, dont 7 classés comme critiques, portant sur l’exécution, l’intégrité des frais et l’authentification par consensus. Dusk affirme qu’aucune preuve d’exploitation n’a été trouvée. Cela m’a donné une manière légèrement différente de regarder la confidentialité. Réduire la divulgation ne réduit pas le nombre d’hypothèses sous-jacentes au système. Au contraire, cela rend les limites de vérification sous-jacentes encore plus importantes. Et le marché semble toujours minuscule par rapport à cette ambition. Alors je me demande si le vrai défi de Dusk n’est pas de prouver que les données financières peuvent rester privées. Il s’agit de prouver que des informations moins visibles peuvent encore produire assez de vérité vérifiable pour que les institutions fassent confiance au système. De quelle quantité de données faut-il réellement qu’elle soit publique avant que la transparence ne commence à devenir une exposition inutile ? @Dusk_Foundation #dusk $DUSK
#dusk $DUSK
Je reviens sans cesse à une contradiction chez @Dusk : le système essaie de révéler moins, mais la finance réglementée pourrait en réalité exiger davantage de choses à pouvoir prouver.

Citadel 2 et XSC font très clairement cette distinction. Vous pouvez prouver votre éligibilité sans exposer l’identité derrière l’attestation, tandis que l’activité financière peut rester confidentielle sans supprimer les exigences de conformité ou d’audit.

L’objectif n’est donc pas vraiment de « tout cacher ».
C’est plutôt : prouver l’affirmation, tout en retenant les données inutiles.

Ce qui rend tout cela plus intéressant, c’est la partie sécurité.
AEGIS a remédié à 39 constats, dont 7 classés comme critiques, portant sur l’exécution, l’intégrité des frais et l’authentification par consensus. Dusk affirme qu’aucune preuve d’exploitation n’a été trouvée.

Cela m’a donné une manière légèrement différente de regarder la confidentialité.
Réduire la divulgation ne réduit pas le nombre d’hypothèses sous-jacentes au système. Au contraire, cela rend les limites de vérification sous-jacentes encore plus importantes.
Et le marché semble toujours minuscule par rapport à cette ambition.
Alors je me demande si le vrai défi de Dusk n’est pas de prouver que les données financières peuvent rester privées.
Il s’agit de prouver que des informations moins visibles peuvent encore produire assez de vérité vérifiable pour que les institutions fassent confiance au système.
De quelle quantité de données faut-il réellement qu’elle soit publique avant que la transparence ne commence à devenir une exposition inutile ?

@Dusk #dusk $DUSK
Je pensais autrefois que la sécurité de Babylon commençait une fois que le BTC était verrouillé sur Bitcoin. Puis j’ai passé un certain temps à suivre comment un coffre-fort passe réellement de sa création au règlement, et cette hypothèse a commencé à changer. Bitcoin constitue le dernier point de contrôle. Mais avant que quoi que ce soit n’atteigne Bitcoin, les signatures doivent être recueillies, les conditions doivent être remplies, et différents participants doivent se coordonner. Il s’est déjà passé énormément de choses avant même qu’une transaction ne soit prête à être réglée. Cela m’a amené à envisager la sécurité autrement. La plupart d’entre nous évaluons la sécurité en nous demandant si des fonds peuvent être volés après le règlement. Je commence à penser qu’une autre question compte aussi : quelle quantité d’incertitude un protocole peut-il éliminer avant même que le règlement n’ait lieu ? L’événement de sécurité le plus fort pourrait être celui que nous ne voyons jamais en chaîne. Une signature manquante, une tentative de coordination échouée ou une condition qui n’est pas remplie ne laisse généralement aucune trace visible, car la transaction n’a jamais lieu. La réussite ressemble souvent à un simple “rien ne s’est passé”. C’est pourquoi je ne pense pas que Bitcoin et Babylon résolvent le même problème. Bitcoin rend l’historique finalisé extrêmement difficile à modifier. Babylon tente de s’assurer que seul un historique correctement validé arrive jusque-là. J’aime ce design. Ce qui me laisse encore curieux, c’est la façon dont il se comporte lorsque les choses cessent de se dérouler comme prévu. Si les opérateurs sont retardés ou que la coordination commence à se dégrader, ces garde-fous tiennent-ils encore ? C’est probablement là que le vrai test commence. @babylonlabs_io #baby $BABY
Je pensais autrefois que la sécurité de Babylon commençait une fois que le BTC était verrouillé sur Bitcoin.

Puis j’ai passé un certain temps à suivre comment un coffre-fort passe réellement de sa création au règlement, et cette hypothèse a commencé à changer.

Bitcoin constitue le dernier point de contrôle. Mais avant que quoi que ce soit n’atteigne Bitcoin, les signatures doivent être recueillies, les conditions doivent être remplies, et différents participants doivent se coordonner. Il s’est déjà passé énormément de choses avant même qu’une transaction ne soit prête à être réglée.

Cela m’a amené à envisager la sécurité autrement.
La plupart d’entre nous évaluons la sécurité en nous demandant si des fonds peuvent être volés après le règlement. Je commence à penser qu’une autre question compte aussi : quelle quantité d’incertitude un protocole peut-il éliminer avant même que le règlement n’ait lieu ?

L’événement de sécurité le plus fort pourrait être celui que nous ne voyons jamais en chaîne.

Une signature manquante, une tentative de coordination échouée ou une condition qui n’est pas remplie ne laisse généralement aucune trace visible, car la transaction n’a jamais lieu. La réussite ressemble souvent à un simple “rien ne s’est passé”.

C’est pourquoi je ne pense pas que Bitcoin et Babylon résolvent le même problème. Bitcoin rend l’historique finalisé extrêmement difficile à modifier. Babylon tente de s’assurer que seul un historique correctement validé arrive jusque-là.

J’aime ce design. Ce qui me laisse encore curieux, c’est la façon dont il se comporte lorsque les choses cessent de se dérouler comme prévu. Si les opérateurs sont retardés ou que la coordination commence à se dégrader, ces garde-fous tiennent-ils encore ? C’est probablement là que le vrai test commence.

@BabylonLabs_io #baby $BABY
Je suis retourné chez @BabylonLabs_io aujourd’hui en m’attendant à ce que le plus grand chiffre soit le plus important. Ce n’était pas le cas. Le tableau de bord indique 56 853 BTC mis en jeu dans les coffres de Babylon, soit environ 5,6 Md$ sécurisés nativement, sans BTC enveloppé ni ponts. C’est le chiffre dont tout le monde parle. Mais en creusant l’architecture d’emprunt, j’ai réalisé que ce n’est qu’une partie du système qui est mesurée. Au départ, je me suis dit que davantage de Bitcoin dans les coffres signifiait naturellement plus de capacité d’emprunt. Non. Plus de BTC renforce les garanties. Ce qui ne crée pas de liquidité. Chaque prêt dépend toujours d’un pool distinct de capitaux fournis par les prêteurs, régi par les paramètres de risque du Hub. Le coffre prouve que votre position est sûre. Le Hub détermine s’il y a réellement de l’argent à prêter. Cela a complètement changé la façon dont je regardais le tableau de bord. Babylon peut attirer bien davantage en Bitcoin, tandis que la capacité d’emprunt augmente beaucoup plus lentement si la liquidité côté prêteurs ne suit pas. La couche de garanties et la couche de liquidité ne se développent pas ensemble. Je pense même que c’est une conception intelligente. Un Hub de liquidité partagé est bien plus efficace en capital que de forcer chaque application Bitcoin à construire son propre marché de prêt fragmenté. Mais l’efficacité du capital introduit une dépendance qui peut facilement passer inaperçue. Le Protocole peut continuer à battre de nouveaux records de TVL pendant que les utilisateurs se disputent toujours le même pool d’actifs empruntables. Ce n’est pas une contradiction. C’est un rappel que la TVL mesure les garanties, pas le crédit. Peut-être avons-nous décrit BTCFi de la mauvaise manière. Le défi n’est pas simplement de libérer le Bitcoin. Il s’agit de coordonner suffisamment de liquidité pour rendre ces garanties économiquement utiles. Peut-être que BTCFi n’a pas un problème de scaling du Bitcoin. Peut-être qu’il a un problème de coordination de la liquidité. C’est le critère que je vais surveiller : non seulement la quantité de Bitcoin qui entre dans les coffres, mais aussi si la couche de liquidité croît assez vite pour garder les garanties productives. @babylonlabs_io #baby $BABY Quel est le vrai goulot d’étranglement pour BTCFi ?
Je suis retourné chez @BabylonLabs_io aujourd’hui en m’attendant à ce que le plus grand chiffre soit le plus important.

Ce n’était pas le cas.

Le tableau de bord indique 56 853 BTC mis en jeu dans les coffres de Babylon, soit environ 5,6 Md$ sécurisés nativement, sans BTC enveloppé ni ponts.

C’est le chiffre dont tout le monde parle.

Mais en creusant l’architecture d’emprunt, j’ai réalisé que ce n’est qu’une partie du système qui est mesurée.

Au départ, je me suis dit que davantage de Bitcoin dans les coffres signifiait naturellement plus de capacité d’emprunt.

Non.

Plus de BTC renforce les garanties.

Ce qui ne crée pas de liquidité.

Chaque prêt dépend toujours d’un pool distinct de capitaux fournis par les prêteurs, régi par les paramètres de risque du Hub. Le coffre prouve que votre position est sûre. Le Hub détermine s’il y a réellement de l’argent à prêter.

Cela a complètement changé la façon dont je regardais le tableau de bord.

Babylon peut attirer bien davantage en Bitcoin, tandis que la capacité d’emprunt augmente beaucoup plus lentement si la liquidité côté prêteurs ne suit pas.

La couche de garanties et la couche de liquidité ne se développent pas ensemble.

Je pense même que c’est une conception intelligente.

Un Hub de liquidité partagé est bien plus efficace en capital que de forcer chaque application Bitcoin à construire son propre marché de prêt fragmenté.

Mais l’efficacité du capital introduit une dépendance qui peut facilement passer inaperçue.

Le Protocole peut continuer à battre de nouveaux records de TVL pendant que les utilisateurs se disputent toujours le même pool d’actifs empruntables.

Ce n’est pas une contradiction.

C’est un rappel que la TVL mesure les garanties, pas le crédit.

Peut-être avons-nous décrit BTCFi de la mauvaise manière.

Le défi n’est pas simplement de libérer le Bitcoin.

Il s’agit de coordonner suffisamment de liquidité pour rendre ces garanties économiquement utiles.

Peut-être que BTCFi n’a pas un problème de scaling du Bitcoin. Peut-être qu’il a un problème de coordination de la liquidité.

C’est le critère que je vais surveiller : non seulement la quantité de Bitcoin qui entre dans les coffres, mais aussi si la couche de liquidité croît assez vite pour garder les garanties productives.

@BabylonLabs_io #baby $BABY

Quel est le vrai goulot d’étranglement pour BTCFi ?
More BTC collateral
100%
More lender liquidity
0%
Risk parameters
0%
1 Votes • Vote fermé
Je pensais que la partie la plus difficile pour faire entrer Bitcoin dans DeFi consistait à construire un meilleur pont. Après avoir passé du temps à lire l’article sur les Vaults sans confiance de Babylon, ma perspective a changé. Ce qui m’a marqué, ce n’était pas une autre façon de déplacer le BTC entre les chaînes : c’était l’idée de garder le Bitcoin soumis à ses propres règles tout en permettant aux applications externes de prouver qu’elles ont rempli des conditions spécifiques. Cela m’a semblé plus concret que l’habituel récit crypto du « déplacer les actifs partout ». Au lieu de demander aux utilisateurs de faire confiance à un dépositaire ou à un actif tokenisé, la conception cherche à faire de la preuve cryptographique l’élément central. Cela m’a rappelé que, parfois, la plus grande innovation ne consiste pas à ajouter plus de flexibilité : elle consiste à réduire la quantité de confiance nécessaire. Cela dit, il me reste des questions. La complexité liée aux preuves ZK, à BitVM3 et à l’infrastructure hors chaîne peut-elle rester invisible pour les utilisateurs du quotidien ? Et les développeurs vont-ils adopter des vaults spécifiques aux applications si cela implique de renoncer à une partie de la composabilité ? Pour moi, la leçon la plus importante n’était pas liée à une nouvelle fonctionnalité. C’était la prise de conscience que l’avenir du Bitcoin dans DeFi pourrait dépendre moins du fait de faire changer le Bitcoin, et davantage de celui de faire en sorte que les applications s’adaptent au Bitcoin. Plus je lis, plus je me rends compte que l’apprentissage en crypto ne consiste pas à se forger des opinions plus tranchées : il s’agit d’être prêt à remplacer les hypothèses anciennes par de meilleures. @babylonlabs_io #baby $BABY Quelle est la plus grande innovation de Babylon ?
Je pensais que la partie la plus difficile pour faire entrer Bitcoin dans DeFi consistait à construire un meilleur pont.

Après avoir passé du temps à lire l’article sur les Vaults sans confiance de Babylon, ma perspective a changé. Ce qui m’a marqué, ce n’était pas une autre façon de déplacer le BTC entre les chaînes : c’était l’idée de garder le Bitcoin soumis à ses propres règles tout en permettant aux applications externes de prouver qu’elles ont rempli des conditions spécifiques.

Cela m’a semblé plus concret que l’habituel récit crypto du « déplacer les actifs partout ». Au lieu de demander aux utilisateurs de faire confiance à un dépositaire ou à un actif tokenisé, la conception cherche à faire de la preuve cryptographique l’élément central. Cela m’a rappelé que, parfois, la plus grande innovation ne consiste pas à ajouter plus de flexibilité : elle consiste à réduire la quantité de confiance nécessaire.

Cela dit, il me reste des questions. La complexité liée aux preuves ZK, à BitVM3 et à l’infrastructure hors chaîne peut-elle rester invisible pour les utilisateurs du quotidien ? Et les développeurs vont-ils adopter des vaults spécifiques aux applications si cela implique de renoncer à une partie de la composabilité ?

Pour moi, la leçon la plus importante n’était pas liée à une nouvelle fonctionnalité. C’était la prise de conscience que l’avenir du Bitcoin dans DeFi pourrait dépendre moins du fait de faire changer le Bitcoin, et davantage de celui de faire en sorte que les applications s’adaptent au Bitcoin.

Plus je lis, plus je me rends compte que l’apprentissage en crypto ne consiste pas à se forger des opinions plus tranchées : il s’agit d’être prêt à remplacer les hypothèses anciennes par de meilleures.

@BabylonLabs_io #baby $BABY

Quelle est la plus grande innovation de Babylon ?
Native BTC
67%
Less trust, more proofs
0%
Apps adapt to Bitcoin
33%
3 Votes • Vote fermé
Je m’attendais à ce que la plus grande histoire soit celle de XPLA devenant un réseau Bitcoin surpuissant. Après avoir lu davantage, j’ai compris que ce n’était pas le point qui est resté avec moi. Ce qui a retenu mon attention, c’est le problème que le projet tente de résoudre. Beaucoup de blockchains sont vraiment douées pour attirer des développeurs, des utilisateurs et de nouvelles applications. Construire une solide économie de sécurité est beaucoup plus difficile, et cela arrive généralement bien plus tard, parce que c’est coûteux. Babylon m’a fait envisager ce compromis différemment. Au lieu que chaque écosystème essaie de bâtir sa sécurité économique à partir de zéro, Bitcoin peut aider à la fournir tout en restant productif. Cela ne signifie pas que la sécurité est « externalisée » entièrement. La gouvernance, la sécurité des applications et les opérations quotidiennes continuent d’appartenir au réseau lui-même. Pour moi, c’est là que se trouve le changement le plus intéressant. Peut-être que l’avenir n’est pas que chaque chaîne essaie d’être la plus sécurisée par elle-même. Peut-être que tout se joue dans le partage de la sécurité économique, tout en laissant à chaque écosystème la possibilité de se concentrer sur ce qui le rend réellement unique. Bien sûr, ce n’est pas sans risque. Une infrastructure partagée implique aussi de nouvelles hypothèses concernant le jalonnement, les validateurs et la coordination. Chaque conception comporte des compromis. C’est pourquoi je pense que des partenariats comme celui-ci comptent. Ils nous montrent où l’industrie expérimente la suite, pas seulement qui s’intègre à qui. Je me demande si les autres le voient de la même manière. Assiste-t-on à l’évolution de la sécurité blockchain, ou déplace-t-on simplement la confiance ailleurs ? @babylonlabs_io #baby $BABY $HOME $KAITO Quel est l’impact le plus important de la sécurité adossée à Bitcoin ?
Je m’attendais à ce que la plus grande histoire soit celle de XPLA devenant un réseau Bitcoin surpuissant. Après avoir lu davantage, j’ai compris que ce n’était pas le point qui est resté avec moi.

Ce qui a retenu mon attention, c’est le problème que le projet tente de résoudre.

Beaucoup de blockchains sont vraiment douées pour attirer des développeurs, des utilisateurs et de nouvelles applications. Construire une solide économie de sécurité est beaucoup plus difficile, et cela arrive généralement bien plus tard, parce que c’est coûteux.
Babylon m’a fait envisager ce compromis différemment.

Au lieu que chaque écosystème essaie de bâtir sa sécurité économique à partir de zéro, Bitcoin peut aider à la fournir tout en restant productif. Cela ne signifie pas que la sécurité est « externalisée » entièrement. La gouvernance, la sécurité des applications et les opérations quotidiennes continuent d’appartenir au réseau lui-même.

Pour moi, c’est là que se trouve le changement le plus intéressant.
Peut-être que l’avenir n’est pas que chaque chaîne essaie d’être la plus sécurisée par elle-même. Peut-être que tout se joue dans le partage de la sécurité économique, tout en laissant à chaque écosystème la possibilité de se concentrer sur ce qui le rend réellement unique.
Bien sûr, ce n’est pas sans risque. Une infrastructure partagée implique aussi de nouvelles hypothèses concernant le jalonnement, les validateurs et la coordination. Chaque conception comporte des compromis.

C’est pourquoi je pense que des partenariats comme celui-ci comptent. Ils nous montrent où l’industrie expérimente la suite, pas seulement qui s’intègre à qui.
Je me demande si les autres le voient de la même manière. Assiste-t-on à l’évolution de la sécurité blockchain, ou déplace-t-on simplement la confiance ailleurs ?

@BabylonLabs_io #baby $BABY

$HOME $KAITO

Quel est l’impact le plus important de la sécurité adossée à Bitcoin ?
Stronger blockchain security
71%
Better capital efficiency
29%
More trust assumptions
0%
7 Votes • Vote fermé
Connectez-vous pour découvrir plus de contenu
Rejoignez la communauté mondiale des adeptes de cryptomonnaies sur Binance Square
⚡️ Suviez les dernières informations importantes sur les cryptomonnaies.
💬 Jugé digne de confiance par la plus grande plateforme d’échange de cryptomonnaies au monde.
👍 Découvrez les connaissances que partagent les créateurs vérifiés.
Adresse e-mail/Nº de téléphone
Plan du site
Préférences de cookies
CGU de la plateforme