Minh Nhat Builder

Plus j’en apprends sur Dusk et le staking, plus je trouve que cette partie est importante, au-delà même de l’histoire de la confidentialité. À l’heure actuelle, pour staker il faut au minimum 1.000 DUSK, et il faut environ 1 à 2 epochs pour que tout soit activé. Le protocole prévoit d’émettre 500M DUSK sur 36 ans, avec une réduction de l’émission de 50% tous les 4 ans
Au début, je n’avais presque pas fait attention à ces chiffres. Mais plus je regarde la manière dont tout est agencé, plus je trouve ça intéressant. @Dusk ne protège pas seulement le consensus : on le retrouve aussi dans le staking, le gas et le règlement quand l’écosystème $DUSK se développe
Par rapport à la mise à jour du whitepaper de novembre 2024, l’architecture actuelle de Dusk a changé de façon notable. À l’époque, Moonlight et Phoenix s’occupaient encore des transactions publiques et de la confidentialité dans la finance régulée.
En juin 2025, Dusk est passé à trois volets : DuskDS pour le règlement et la disponibilité des données, DuskEVM pour les applications EVM, et DuskVM pour les applications qui nécessitent de la confidentialité.
Je me dis que le staking pourrait prendre une autre signification à mesure que Dusk entre dans une phase avec davantage d’activités concrètes. Quand EVM et VM commenceront à avoir des utilisateurs, un token pourra être utilisé simultanément à plusieurs niveaux du réseau.
Bien sûr, pour l’instant, je ne fais que formuler cette hypothèse.
Je prête aussi une attention particulière à la Stake Abstraction, car elle ouvre la possibilité aux contrats de gérer le staking eux-mêmes, ce qui pourrait soutenir des modèles comme des staking pools ou des stratégies d’exploitation automatisées directement sur le réseau.
Cependant, je ne sais pas encore dans quelle mesure l’activité de #dusk reflète réellement un besoin d’utilisation. Une partie relève-t-elle d’applications, et une autre seulement de staking et d’infrastructure ? Il manque encore des données suffisantes pour distinguer clairement.
Si vous avez des données on-chain plus détaillées, je serais très heureux de les consulter afin de les confronter à ce que j’observe et de mieux comprendre à quoi l’activité réelle sur le réseau correspond.

J’ai passé un peu de temps à parcourir la section 6 des documents techniques de @Dusk et j’en suis ressorti avec plus de questions que de réponses.

Étrangement, je pense que c’est bon signe.

Ce qui a attiré mon attention n’était pas seulement la PVM ou le modèle d’exécution basé sur le WASM. C’était la mesure dans laquelle le comportement central du réseau de Dusk semble être transféré dans des contrats.

Transfer gère $DUSK transferts, les frais de validation et d’exécution. Stake gère les DUSK bloqués, l’état du jalonnement et les retraits. Des éléments à venir comme Zedger et Clock poussent encore plus de logique dans des contrats.

Cela m’a amené à remettre en question une hypothèse.

Au départ, j’ai surtout envisagé la PVM comme un moyen léger et modulaire d’exécuter des contrats intelligents. Mais la question plus profonde n’est peut-être pas de savoir à quel point la VM les exécute de manière “propre”.

C’est plutôt qui contrôle les contrats dont le réseau dépend de plus en plus.

Si un contrat important devient un goulot d’étranglement en matière de sécurité, comment est-il mis à jour ou remplacé ?

Qui a réellement l’autorité de le modifier ?

Et dans la pratique, à quel point ce contrôle est décentralisé ?

Ces questions comptent davantage pour moi maintenant que le simple fait de savoir que #Dusk dispose d’une VM basée sur le WASM.

La partie intéressante de l’architecture tient peut-être moins à ce que les contrats peuvent faire qu’à ce qui se passe lorsque le réseau commence à dépendre d’eux pour un comportement critique.

Ma prochaine étape consiste à creuser davantage pour comprendre comment ces contrats système, présents dès la genèse et à venir, sont gouvernés, mis à niveau et sécurisés.

J’ai le sentiment que c’est là que ma compréhension actuelle de Dusk confirmera ses bases — ou changera assez fortement.
$TMX $XRP #KazakhstanCutsOilOutputForecastTo96MTons #JapanNoAdditionalOilReserveReleaseInSepOct #SamsungSKHynixLeveragedETFsPostFirstMonthlyOutflow #ThailandToExpandSECDigitalAssetProbePowers

Toute la matinée d’hier, j’ai presque passé tout mon temps à bidouiller le nouveau testnet DuskEVM de @Dusk au lieu de faire quelque chose d’utile.

Le testnet est lancé depuis le 10/8, et ce qui est le plus souvent mentionné en ce moment, c’est « la prise en charge de Solidity et de Hardhat ». C’est évidemment plutôt bien, mais pour être honnête, ce n’est pas ça qui m’a fait m’arrêter en scrollant.

Ce qui a le plus retenu mon attention, c’est la façon dont #dusk gère le settlement. Le contrat s’exécute sur DuskEVM et le sequencer s’occupe de l’exécution, mais le batcher envoie les données de transaction à DuskDS sous forme de blobs. Ensuite, le proposer inscrit le state commitment. En termes simples : l’exécution se fait sur DuskEVM, tandis que la finalité est ancrée sur la couche de base. Le gas est payé avec $DUSK , mais il faut bridge le DUSK de DuskDS vers l’avant avant de déployer.

Cette idée tourne en boucle dans ma tête. Pour commencer à écrire du Solidity sur DuskEVM, le développeur a dû faire passer du DUSK réel via le bridge. Pour moi, ce détail rend l’expérience du réseau beaucoup plus concrète, au lieu d’exister uniquement sur le papier.

Je viens de jeter un œil à l’explorer du testnet et j’ai vu que le contrat y était déjà apparu il y a quelques jours. Un nouveau réseau qui fonctionne depuis à peine six jours et qui a déjà autant d’activité, ce n’est pas rien, à mon avis.

Je n’ai pas encore arrêté de creuser pour voir si ce modèle settlement-anchoring jouera un rôle important dans la manière dont des actifs comme NPEX fonctionneront plus tard sur l’EVM, ou si je ne fais que regarder un motif familier d’OP Stack et lui attribuer trop de sens.

Pour l’instant, je penche du côté de la première hypothèse, mais je ne suis pas encore assez sûr pour conclure.

Je me demande s’il y a déjà quelqu’un qui a déployé un contrat sur DuskEVM, ou si tout le monde s’arrête encore à l’étape de la lecture des docs comme moi ?
$UAI $MarsCoin #BitcoinRises23.6%Weekly #TinFed #TheoDõiFOMC

@Dusk @Dusk $DUSK #dusk
Je pensais autrefois que la confidentialité sur une blockchain signifiait accepter moins de transparence.

Si vous vouliez de la confidentialité, vous deviez renoncer à la visibilité.
Si vous vouliez de la conformité, vous deviez accepter que tout devienne public.

Puis j’ai creusé le modèle de transactions de @Dusk , et un détail m’a fait m’arrêter.

Ce qui a attiré mon attention n’était pas le récit sur la confidentialité en soi, mais la façon dont Moonlight et Phoenix fonctionnent ensemble.

Moonlight peut fournir de la transparence pour la conformité, tandis que Phoenix utilise la ZK pour protéger des données sensibles comme les soldes et les montants des transactions.

Au début, j’y ai vu un autre mécanisme de confidentialité.

Mais plus j’y regardais, plus je me rendais compte que l’idée réelle consiste à séparer la vérifiabilité de la visibilité.

Une institution peut prouver ce dont les régulateurs ont besoin pour vérifier sans exposer l’ensemble de sa situation financière ni sa stratégie de trading au marché.

Cela me pousse à repenser l’approche de #Dusk .

Peut-être que l’avenir de la blockchain institutionnelle n’est ni une transparence totale ni une anonymisation totale, mais une confidentialité contrôlée.

Je me pose encore cette question :

Si la confidentialité devient vérifiable sans être entièrement visible, est-ce le pont qui amène les institutions dans la crypto - ou un compromis de la vision originale, permissionless, de la crypto ?

$DUSK

Lors de mes débuts dans la compréhension du DeFi à taux fixe, je trouvais les taux d’intérêt assez simples à appréhender : s’ils sont élevés, c’est attrayant ; s’ils sont faibles, ça mérite moins l’attention. Mais lorsque le RWA apparaît dans le rôle d’actif de garantie, je commence à voir les choses sous un nouvel angle. À ce moment-là, les taux reflètent aussi, en partie, la manière dont le marché valorise les actifs situés derrière le prêt.

Ce qui m’a le plus captivé dans @TermMax , c’est la façon dont chaque marché peut établir son propre niveau de taux de prêt. Lorsque le RWA est utilisé comme garantie et associé à une échéance fixe, la liquidité, la qualité de l’actif, et même les variations peuvent créer des écarts. Si ces données sont suffisamment nombreuses au fil du temps, @TermMax peut permettre de construire une base de mesure du crédit onchain, plutôt que de se limiter à être un simple endroit qui génère de l’APY.

Je veux aussi examiner une autre chose : est-ce que les utilisateurs restent réellement ? Un reward élevé ne veut pas forcément dire qu’il y a une demande durable. Je vais observer si les lenders continuent de fournir des fonds, si le taux s’auto-équilibre lorsque les incitations diminuent, et si l’emprunteur revient sur plusieurs échéances. Une liquidité faible peut aussi rendre le taux plus attrayant qu’en réalité, surtout lorsque l’essentiel des transactions provient d’un petit groupe.

J’aurai une vision plus favorable de @TermMax si l’activité de prêt conserve un rythme cohérent : les taux refléteront alors correctement les caractéristiques de chaque type d’actif de garantie, et la liquidité sera répartie de manière régulière sur différents terms. À l’inverse, si le récit prend davantage de place que ce qui se passe réellement, je garderai une attitude prudente.

Pour moi, une courbe de taux “belle” ne suffit pas. Je veux remonter à la source pour comprendre d’où provient réellement l’argent.
#termmax $XRP $BLESS $BTW #SamsungToAnnounceNewShareholderReturnPlanFriday #BitcoinBestWeekSinceMarch2023 #TinFed #SpotGoldHitsHighestSinceMay15

Auparavant, j’imaginais la conversion de FT assez simple et directe : un prêt est remboursé, le détenteur de FT reçoit un token de dette, puis la transaction se termine. Je pensais que ce serait un simple règlement à l’échéance.

Mais la documentation de @TermMax propose un mécanisme de traitement lorsque le prêt n’est pas remboursé comme prévu. Si, à la fin de la liquidation window, la dette reste encore en place ou n’a été traitée que partiellement, la livraison physique se déclenche automatiquement. Ces actifs sont gérés immédiatement dans le cadre du mécanisme de conversion ; il n’y a aucune étape supplémentaire à effectuer par l’utilisateur.

Le point notable est que le détenteur de FT peut recevoir différents types d’actifs par rapport au cas où le prêt est entièrement remboursé. À ce moment-là, le pool peut inclure à la fois le token de dette et le token d’actif restant en garantie. La part de l’actif est répartie par @TermMax selon la proportion de FT que chaque personne détient par rapport à l’offre totale de FT.

Autrement dit, le ratio de conversion 1:1 entre FT et token de dette ne reflète que le scénario où tout se déroule comme prévu. S’il y a un problème dans le traitement du prêt, le détenteur de FT recevra la valeur correspondante provenant du pool, et le nombre d’actifs reçus peut varier selon le résultat du traitement effectué avant la date d’échéance.

Cela m’amène à m’interroger sur un autre point : avant la date d’échéance, le détenteur de FT peut-il savoir assez clairement quelle part de sa valeur est liée au token de dette et quelle part provient du token de collatéral ? 🧐
#termmax $XRP $COLLECT $ON
#GrayscaleFilesToListZcashTrustOnNYSEArca #TinFed #USJoblessClaimsFallTo206000 #WalmartFalls7%

#binancep2pantoan @Binance Vietnam
Avant, je n’étais généralement vigilant(e) qu’aux ordres qui semblaient être retardés ou ne pas aboutir au paiement. Après un certain temps d’observation, j’ai pourtant remarqué une autre situation qui peut facilement faire baisser la garde des utilisateurs : en cours de route, l’autre partie finit soudainement par proposer de nouvelles informations de réception de fonds, en changeant de compte de paiement. La raison qu’ils donnent est souvent difficile à considérer comme anormale sur le moment, par exemple : le compte précédent aurait eu un problème. Mais ce qui m’a frappé, c’est que les données de la commande ne restent plus identiques. J’ai examiné la commande d’origine pour déterminer : qui est le partenaire, quel est le montant de la transaction, et par quel moyen les fonds ont été envoyés.

À première vue, cela semble plutôt logique, mais un simple message demandant de changer de compte suffit à rendre tout beaucoup plus difficile à vérifier. Pour moi, le point important, c’est que cela m’oblige à m’arrêter et à revoir depuis le début la transaction : le montant et la manière de paiement.

À mon avis, la meilleure façon de procéder n’est pas de soupçonner immédiatement l’autre partie, mais de recontrôler les informations modifiées avant de continuer. Binance conseille aussi aux utilisateurs de choisir un mode de paiement accepté et de vérifier pour s’assurer que les informations du compte correspondent aux exigences de la transaction. Mais cela ne vaut la peine que si les nouvelles données sont toujours compatibles avec la commande initiale et que je peux les confirmer. Si je ne suis pas sûr(e), je privilégie l’arrêt de la transaction et j’utilise Appeal si la situation nécessite un traitement plus approfondi.

Je me demande encore à quel moment un changement n’est qu’un simple désagrément, et à quel moment il devient un signal d’alerte. Peut-être que c’est un point auquel je devrais continuer à faire attention lors des prochaines transactions
$XRP $COLLECT $ON #TinFed #GrayscaleFilesToListZcashTrustOnNYSEArca #WalmartFalls7%

$DUSK @Dusk
Un jour, j’ai entendu une amie raconter le transfert d’argent entre deux comptes ouverts dans des lieux différents. Elle pensait qu’il suffisait d’effectuer une opération sur un compte pour que l’autre reçoive automatiquement quelque chose de similaire. Mais lorsqu’il a fallu redonner l’argent, le processus a de nouveau ajouté une étape de vérification au niveau du site de transaction initial.

Cette histoire m’a fait penser à la manière dont @Dusk đ a été transféré à l’aller-retour entre Dusk L1 et DuskEVM Testnet.

J’avais d’abord pensé que les deux sens fonctionneraient de façon similaire : envoyer depuis Dusk L1 ferait apparaître DUSK dans le portefeuille DuskEVM lié. Mais le sens du retrait est tout à fait différent. La commande démarre sur DuskEVM, puis il faut revenir sur @Dusk L1 pour prouver le retrait et finaliser. Ainsi, en plus des frais du point de départ, l’utilisateur doit également supporter deux frais supplémentaires sur L1.

Ce qui m’a semblé particulièrement notable, ce n’est pas le nombre d’étapes, mais la logique qui se cache derrière. Un retrait ne peut être poursuivi que lorsque l’état du réseau a été mis à jour, que la preuve satisfait les conditions nécessaires et que les étapes de vérification associées sont terminées. C’est pourquoi, la recommandation de #dusk conseille aux utilisateurs de consulter directement l’état sur Web Wallet, plutôt que de se fier uniquement au temps d’attente.

Je veux encore savoir si ces deux étapes renforcent réellement la solidité de l’achèvement d’une transaction, ou si elles contraignent involontairement davantage les utilisateurs à dépendre des vérifications de progression et à gérer chaque étape eux-mêmes.
$XRP $ON #GrayscaleFilesToListZcashTrustOnNYSEArca #TinFed #USJoblessClaimsFallTo206000 #WalmartFalls7%

#termmax @TermMax
Je me suis encore et encore demandé si le levier doit forcément aller de pair avec la liquidation, et avec TermMax Alpha Options, la réponse semble plus nuancée que dans la plupart des approches.

Il ne s’agit pas de réduire le levier pour éviter la liquidation. C’est une opportunité de vérifier si une prime fixe peut réellement transformer le downside en une perte effectivement plafonnée.

Ce que je peux vraiment vérifier, ce sont le montant de la prime à payer, le payoff en position long/short, et la perte maximale de la position. Je peux aussi examiner le mécanisme selon lequel le déposant reçoit la prime afin de fournir de la liquidité, car c’est vraiment un test pour voir si ce modèle peut répartir le risque entre les deux parties, et pas seulement rendre l’effet de levier « plus sûr » en apparence.

Ce que je ne sais pas, c’est comment le système se comportera en cas de fortes variations et avec une liquidité réelle plutôt que dans un environnement contrôlé. La question est de savoir si le downside limité en théorie procure effectivement une meilleure expérience de gestion du risque lorsque le marché devient volatil.

Je suis en train de suivre si les utilisateurs choisissent réellement de payer une prime en échange d’une perte maximale clairement définie.
$DOS $ACE $HEMI
#CryptoRally #FOMCWatch

#binancep2pantoan @Binance Vietnam
Quand une transaction P2P dure assez longtemps avec une même personne, la familiarité peut parfois nous faire baisser notre vigilance.

Au départ, ce n’étaient que quelques Orders, puis 5 Orders, 10 Orders… Tout s’est bien passé : paiements rapides, échanges sans difficulté et aucun incident. Peu à peu… la méfiance initiale a laissé place à un sentiment de sécurité. Puis un jour, le Merchant a proposé : « La prochaine fois, on échange via Telegram ou Zalo, là-bas je pourrai vous donner un meilleur prix, bien mieux que d’ici. »

Honnêtement, je comprends pourquoi beaucoup de gens seraient facilement tentés d’accepter. Après avoir suffisamment échangé, les précédentes fois se sont toujours bien déroulées, et cette fois le prix semble plus avantageux. Mais je me le répète toujours : faire confiance à quelqu’un, c’est une chose ; garantir la sécurité de la transaction actuelle, c’en est une autre.

Chaque Order P2P sur Binance contient des informations sur l’Order, les méthodes de paiement, l’Order ID, le Order Chat, l’historique, l’Appeal et l’Escrow. Quand on sort la transaction de la plateforme, la couche de protection associée à l’Order n’est plus là. La familiarité peut parfois nous faire oublier les règles : passer sur Zalo, Telegram, ignorer l’étape de vérification, voire faire un Release plus tôt juste parce qu’avant, il n’y avait jamais eu de problème. Ainsi, même si le Merchant a beaucoup échangé avec moi, je maintiens mes règles : la transaction doit toujours rester dans l’Order, et chaque paiement doit être vérifié à nouveau.

Un bon historique ne veut pas dire que la transaction actuelle n’a pas besoin d’être vérifiée.

Et quand je vends, je ne me fie qu’au solde réel affiché dans l’application bancaire avant de Release. Pas de Zalo, pas de Telegram, pas de capture d’écran.

Je me fie à l’historique, mais je ne relâche pas ma vigilance pour la transaction actuelle. Parce qu’en P2P, un incident ne vient parfois pas de la suspicion, mais du moment où l’on perd sa vigilance.
$DOS $ACE #TheoDõiFOMC

Je veux souvent comprendre comment un réseau est construit avant de m’intéresser aux tokens ou à l’écosystème. Chez Dusk Network, ce qui attire d’abord mon attention, c’est l’architecture, clairement orientée vers la confidentialité dans les applications financières.

Au départ, j’ai abordé la « privacy blockchain » de Dusk d’une manière assez simple. Je me disais que l’essentiel était simplement de ne pas divulguer les données de transaction, mais plus je lisais la documentation, plus je voyais que le champ d’application est beaucoup plus large : des smart contracts confidentiels jusqu’à la norme Confidential Security Contract (XSC).

En réalisant cela, j’ai commencé à voir Dusk sous un autre angle.

Pour moi, la question intéressante ne se limite pas à « dans quelle mesure la blockchain peut-elle sécuriser les données ? », mais plutôt à savoir comment créer des applications financières capables de garder secrète une partie des informations, tout en permettant au système en arrière-plan d’exécuter les règles nécessaires.

Je pense que c’est précisément le problème central auquel Dusk s’attaque, en jouant le rôle d’une Layer-1.

Je veux approfondir ma compréhension de la façon dont le XSC traite des problématiques financières à plusieurs niveaux. Quelles données sont autorisées à être visibles uniquement par certains acteurs, lesquelles doivent encore être prouvées à tous, et comment la frontière entre ces deux catégories sera gérée ?

Je n’ai pas encore le sentiment d’avoir vu l’ensemble du tableau de cette architecture. C’est pourquoi, plutôt que de conclure trop vite, je souhaite continuer à lire et à vérifier davantage. @Dusk #dusk $DUSK $ACE $DOS #CryptoRally #FOMCWatch #UAESaysItDetectedTwoIranianBallisticMissiles #ToyotaFinanceLaunchesTokenizedBondForRetail

#termmax @TermMax
Je reviens une dernière fois aux documents de TermMax, cette fois en me concentrant sur la façon dont le “fixed-rate” change réellement l’emprunt et le lending dans DeFi.

Au début, ce qui a attiré mon attention, c’était simplement la possibilité d’emprunter ou de prêter avec un taux fixé à l’avance. Mais en creusant davantage, je me suis laissé happer par tout ce qui se passe en coulisses derrière ce mécanisme.

Je me suis mis à me demander comment TermMax parvient à garder un taux suffisamment stable alors que le marché change en permanence. Si la liquidité se fragmente soudainement, quelles répercussions cela aura sur les positions ? Et lorsque des options coexistent au sein du système, comment le protocole fait-il pour éviter que les risques ne s’additionnent les uns aux autres ?

Puis j’ai commencé à regarder la gouvernance sous un autre angle.

Un protocole peut déléguer à l’échelle technique, mais le pouvoir de décision réel peut tout de même être concentré dans un petit groupe. Je n’ai pas encore assez de données pour déterminer comment TermMax répartit ce pouvoir, donc pour l’instant cette partie reste une grande inconnue.

Je veux aussi examiner plus attentivement la couche sécurité. Un smart contract peut contenir des bugs, mais ce n’est pas toute l’histoire. Les pressions venant du marché, de l’oracle, de la liquidité et de la liquidation peuvent chacune créer un type de risque distinct.

Plus je lis, moins je vois TermMax comme un simple “fixed-rate DeFi”. Je commence plutôt à m’intéresser à la mesure dans laquelle la blockchain peut offrir un niveau de stabilité et de prévisibilité pour les produits financiers.

Selon vous, quelle est la pièce la plus importante dans l’infrastructure de TermMax ?
$EDEN $ACE $DOS #CryptoRally #FOMCWatch #UAESaysItDetectedTwoIranianBallisticMissiles #ToyotaFinanceLaunchesTokenizedBondForRetail

#binancep2pantoan @Binance Vietnam
Le acheteur que je connaissais autrefois est devenu un étranger.

Lors des transactions précédentes avec cet acheteur, tout s’était bien passé, alors ce matin, j’ai été plus négligent que d’habitude. Jusqu’au moment où j’ai vérifié le paiement reçu : je me suis rendu compte qu’il provenait d’une banque totalement différente de celles des fois précédentes. Le nouveau compte, bien que le nom de l’expéditeur soit le même, ne m’avait pas été annoncé à l’avance.

Je me suis arrêté et j’ai demandé directement dans le chat avant de continuer. Finalement, ce n’était pas si compliqué : ils avaient ajouté un compte bancaire et l’utilisaient parfois. Mais si je n’avais pas posé la question, j’aurais très facilement ignoré ce détail, simplement parce que j’étais habitué à traiter avec eux.

C’est à ce moment-là que j’ai compris : reconnaître un visage ne veut pas dire que c’est vérifié.

Comme à chaque fois, j’ai ouvert moi-même l’application bancaire pour confirmer le paiement au lieu de me fier à une capture d’écran, même s’il s’agissait d’un acheteur qui avait déjà effectué de nombreuses transactions. Peut-être qu’ils n’ont jamais fabriqué de preuves. Mais pour moi, une transaction ne peut pas reposer sur deux mots : « peut-être ».

Une historique de transactions parfaitement fluide rend tellement facile de baisser sa garde, alors que les vérifications initiales ne sont pas là pour donner un sentiment de confiance, mais plutôt pour conserver une trace des transactions quand on en a besoin. C’est pourquoi, après chaque transaction, comme d’habitude, je conserve l’Order ID ainsi que l’intégralité du chat.
$EDEN $ACE $KII #VIXFallsTo2026Low #DollarHits3MonthLow

@Dusk $DUSK #dusk
Toute la journée, je n’ai cessé de tomber sur STOX en revoyant @Dusk . Maintenant, il a changé de nom et s’appelle @Dusk Trade. Il y a un point dans ce projet qui me retient : Dusk Trade a annoncé son plan visant à rapprocher le marché privé des PME d’ici le 15/8

Staking : Plus de 30 % du total des jetons sont actuellement en staking, tandis que l’APR tourne autour de 27 %.

Accès : Le mécanisme de selective disclosure permet de vérifier l’adresse ou l’éligibilité sans divulguer l’identité. La démarche en matière de privacy est assez intéressante, mais la portée de la participation est encore, pour l’instant, limitée à certains partenaires et à certains groupes d’actifs.

#dusk Trade : À l’heure actuelle, les utilisateurs ne peuvent que s’inscrire sur liste d’attente ; la plateforme n’est pas encore ouverte à tout le monde.

Ce point me semble plutôt intéressant.

La privacy pourrait ne pas nécessiter d’intermédiaire, mais la participation au marché doit quand même passer par une étape de validation.

J’ai essayé de staker un peu pour vérifier. Mais staker des tokens ne signifie pas pouvoir trader. D’un côté il y a un élément lié à la privacy, de l’autre un élément lié à l’éligibilité. Je ne suis pas particulièrement intéressé par l’idée de mettre l’accent sur le ZK ici. Ce qui m’importe, c’est de savoir qui aura des places pour la phase initiale, et quelles exigences ils doivent remplir.

Quelqu’un a-t-il déjà obtenu l’accès à la participation après être passé sur la waitlist ?

Si on devait n’en choisir qu’un seul, selon toi, où devrait $DUSK Trade faire la différence en premier : la couverture des utilisateurs, le niveau de sécurité, le nombre d’actifs ou les barrières à l’entrée ?
#CryptoRally #FOMCWatch

#termmax @TermMax Avant d’examiner en profondeur ce sujet, je pensais toujours que la TGE était le moment le plus important pour évaluer un token.

À ce moment-là, je n’avais jamais vraiment vérifié si le protocole disposait déjà d’un produit et d’une activité réelle avant l’apparition du token.

J’ai donc décidé de revenir en arrière et de rechercher soigneusement $TMX avant la date de TGE du 25/08/2026.

Le résultat était plus nuancé que je ne l’avais prévu.

Il y avait un point qui correspondait à ce que je pensais : la valorisation initiale de TMX dépendrait encore fortement de la cotation et du récit au moment de la TGE.

Mais ce qui m’a surpris, c’est que TermMax avait construit le protocole avant l’apparition du token. L’infrastructure à taux fixe, le déploiement multi-chaînes et les principales intégrations DeFi étaient déjà en place avant la TGE.

Au lieu que la TGE soit le moment où un projet commence à créer de la valeur, les données ont montré que TermMax avait déjà pris de l’ampleur : plus de 90 M$ de TVL d’après les chiffres de l’équipe, plus de 1,5 M de portefeuilles enregistrés et plus de 90 K de DAU.

Le vrai problème n’est pas la TGE.

Il s’agit de savoir si TMX peut transformer la véritable activité du protocole en utilité durable et en captation de frais.

D’un point de vue technique, TMX dispose d’une offre totale fixe de 1 milliard de tokens, d’une circulation initiale d’environ 20 %, et l’équipe comme les investisseurs ont un cliff de 12 mois. L’utilité est liée à la gouvernance, au staking et aux frais du protocole.

Si les utilisateurs ne viennent que pour farmer XP, AP, MP avant la TGE puis partent, la TVL et l’activité pourraient diminuer.

Mais si les utilisateurs continuent d’utiliser des produits à taux fixe, la génération de frais et la rétention pourraient devenir la base de la valeur à long terme de TMX.

Cela change complètement la façon dont nous devrions regarder la TGE de TermMax.

En y repensant, j’ai réalisé que j’abordais ce problème en partant de l’hypothèse que la tokenomics et la TGE étaient au centre, plutôt que de vérifier les données en premier.

Le processus de recherche ne m’a pas amené à penser que tout était parfaitement bien ou que tout était faux.

Il m’a seulement fait comprendre que le problème était plus nuancé que je ne l’avais imaginé.

Par conséquent, ma perspective sur TMX a aussi changé.

Je veux encore voir TermMax prouver la génération de frais et la rétention des utilisateurs après la TGE
$ACE $GPS $PORTAL

#binancep2pantoan Avant d’examiner attentivement ce problème, je pensais toujours que si la contrepartie avait un bon taux d’achèvement et un historique de trading solide, je pouvais me sentir davantage rassuré lorsque je traitais une transaction P2P.

À ce moment-là, je n’avais jamais vraiment vérifié le montant que je recevais avant de libérer la somme lorsqu’il y avait une petite différence. J’ai donc décidé de vérifier quelque chose de très basique : si le montant qui entrait réellement sur le compte correspondait au montant de l’ordre.

Le résultat s’est avéré plus nuancé que ce que j’attendais.

Il y avait un point qui confirmait ce que je pensais : le taux d’achèvement de la contrepartie et le nombre d’ordres restaient utiles pour évaluer un trader.

Mais ce qui m’a surpris, c’est que ces informations ne pouvaient pas remplacer la vérification du montant réellement reçu.

Le véritable problème n’était pas de savoir si l’acheteur était fiable ou s’il insistait parce qu’il était « pressé ».

Il s’agissait plutôt de savoir si l’argent était réellement suffisant ou non.

Si le montant était encore insuffisant, alors, quelle que soit la réputation de la contrepartie, je ne devais toujours pas libérer la somme tant que le montant restant n’avait pas été transféré intégralement.

En repensant à cela, j’ai compris que j’avais abordé cette question en me basant sur la réputation de la contrepartie et la notification de paiement, au lieu de vérifier d’abord le montant réel.

Peut-être que j’aurais dû vérifier plus tôt mon solde bancaire, plutôt que de supposer qu’une notification de paiement signifiait déjà que l’argent était suffisant.

Cela m’a seulement fait réaliser plus clairement que le vrai problème est le suivant : si l’argent n’est pas assez, ne libérez pas.

Se presser ne veut pas dire être dans l’erreur. Mais il vaut toujours la peine de recompter deux fois.@Binance Vietnam $ACE $GPS $PORTAL
#IsraelStrikesLebanonKillsHezbollahCommander #CardanoSplitsDijkstraUpgradeIntoTwoPhases #SECCancelsCryptoRulemakingMeeting #CMESeptemberHikeOddsFallTo30.6%

J’ai parcouru le tableau de distribution des récompenses de Dusk et les conditions de combustion des tokens m’ont surpris. Le générateur de blocs reçoit 70 % des récompenses de chaque bloc directement, auxquels s’ajoute jusqu’à 10 % supplémentaires liés à quelque chose appelé certificate credits. Toute partie de ces 10 % additionnels qui n’est pas requise sera brûlée plutôt que redistribuée.

Les documents ne définissent jamais réellement ce qui est considéré comme un credit. J’ai vérifié plusieurs fois en pensant avoir peut-être manqué une page liée, mais cette section se contente de l’évoquer et de continuer.

Ce manque de clarté m’a davantage préoccupé que ce qu’il n’aurait probablement dû. Un mécanisme de combustion lié à un indicateur de participation non défini diffère des mécanismes de combustion programmés, ou déclenchés par l’administration, que la plupart des projets évoquent. Le reste de la répartition est relativement simple. 10 % pour le fonds de développement, 5 % pour la validation, 5 % pour la ratification.

L’émission fonctionne selon une courbe programmée qui décroît sur 36 ans : elle est divisée par deux après chaque période de quatre ans, et est limitée à 500 millions de nouveaux DUSK émis à partir d’un approvisionnement initial de 500 millions. Par rapport à cette courbe, toute quantité brûlée par bloc semble négligeable.

Cependant, sur des milliers de blocs présentant un taux de complétion certificate incohérent, cela ne paraît plus insignifiant. Rien ici ne change la manière dont je me positionne. Cela change seulement ce que je suis en train de suivre dans les données de récompense actuelles.
@Dusk $DUSK #dusk $KII $DOS
#IsraelStrikesLebanonKillsHezbollahCommander #CardanoSplitsDijkstraUpgradeIntoTwoPhases #SECCancelsCryptoRulemakingMeeting #CMESeptemberHikeOddsFallTo30.6%

#binancep2pantoan @Binance Vietnam
Avant de l’examiner attentivement, je pensais toujours que Binance P2P était principalement protégé par un Escrow : la crypto est bloquée, les deux parties échangent et, en cas de problème, il existe un recours (Appeal).

À cette époque, je n’avais jamais vraiment vérifié ce qui se passe lorsqu’une transaction entre dans un litige. J’ai décidé de revenir en arrière et de découvrir ce qui rend réellement une transaction P2P sûre.

Le résultat n’était pas aussi simple que je le pensais à l’époque.

L’Escrow est bien une couche de protection importante. Mais ce qui m’a surpris, c’est que l’Escrow ne peut pas raconter l’histoire de ce qui s’est réellement passé entre deux personnes.

En cas de désaccord, le problème n’est plus uniquement technique. Il devient une question de vérité et de preuves.

Au lieu de voir le P2P uniquement comme un marché doté d’un Escrow, j’ai commencé à le voir comme un système de coordination.

L’Escrow conserve les actifs.
Le chat conserve le contexte.
Le recours (Appeal) fait vivre le processus.
Les preuves aident à déterminer la vérité.

Le sujet n’est pas seulement le nombre de couches de protection que Binance a, mais aussi si les utilisateurs restent à l’intérieur de ces couches.

S’ils quittent le Chat interne, passent sur Telegram ou Zalo, se fient à une capture d’écran plutôt que de vérifier le compte bancaire, ou se hâtent de libérer les fonds, les utilisateurs eux-mêmes s’extraient de l’infrastructure conçue pour les protéger.

En y repensant, j’ai réalisé que j’avais pensé « Escrow = sécurité », au lieu d’observer l’ensemble du processus.

La sécurité en P2P est une combinaison de technologie, de preuves, de processus et de discipline de l’utilisateur.

Une bonne infrastructure n’est pas quelque chose qui rend chaque transaction simple.

C’est plutôt quelque chose qui vous aide à comprendre ce qui s’est réellement passé lorsque la transaction n’est plus simple.
$KII $AIO $MarsCoin
#LMECopperStocksFall42DaysLongestSince2014 #SP500TopsRecord7800 #USToPressNationsToPickUSOrChinaAICoalition #SP500EarningsBeatExpectations

Il y a une chose à laquelle je reviens sans cesse lorsque j’explore @Dusk : savoir si la conformité doit vraiment être sacrifiée au profit de la confidentialité, et une grande partie de la logique de conception tient à la manière dont Citadel 2 sépare « prouver qu’il a bien été vérifié » de « révéler la personne derrière ». Le flux commence avec le fournisseur de licence qui vérifie l’utilisateur hors chaîne et signe les attributs nécessaires. Ensuite, l’utilisateur crée une preuve à divulgation nulle (zero-knowledge proof) afin de prouver qu’il possède une licence valide, signée et enregistrée en chaîne ; c’est la partie que je trouve la plus intéressante.

La preuve se déroule par cryptographie, sans révéler la clé du portefeuille, les attributs ni la licence spécifique, et c’est là que la question de la confidentialité est véritablement mise à l’épreuve. La politique du service existe toujours en arrière-plan, attendant que le fournisseur de service décide quels fournisseurs sont dignes de confiance, quels attributs sont acceptés et si la session est encore valide. Enfin, le contrat ne confirme que la validité de la preuve et enregistre une session publique. Sur la chaîne, il ne reste plus que la preuve qu’une preuve d’habilitation (credential) valide a été utilisée.

Ce que je ne sais pas encore, c’est comment ce mécanisme fonctionnera lorsque la politique change, que le fournisseur délivre une attestation incorrecte, ou qu’une ancienne session reste valable au lieu des conditions idéales. La question est de savoir si la cryptographie élimine réellement le besoin de révéler l’identité pour le contrôle d’accès, ou si elle ne fait que transférer la confiance à l’émetteur et à l’interprétation de la preuve d’habilitation. Je suis la manière dont #dusk $DUSK
aborde la frontière entre preuve cryptographique et politique de service lorsque la finance réglementée commence réellement à l’utiliser. $AIO $KII
#LMECopperStocksFall42DaysLongestSince2014 #SP500TopsRecord7800 #USToPressNationsToPickUSOrChinaAICoalition #SP500EarningsBeatExpectations

#binancep2pantoan @Binance Vietnam
Avant d’aller plus loin dans cette question, je pensais toujours que le trading P2P consistait principalement à trouver un marchand fiable, avec un badge, un taux d’achèvement élevé et beaucoup de commandes, ce qui le rendrait relativement sûr.

À ce moment-là, je n’avais jamais vraiment vérifié si ces signes suffisaient à confirmer qu’une transaction était sûre.

J’ai donc décidé de revenir en arrière et de vérifier quels éléments doivent réellement être considérés comme des preuves fiables lorsqu’on négocie en P2P.

Le résultat s’est avéré plus nuancé que je ne l’avais prévu.

Il y avait un point qui correspondait à ce que j’avais pensé : le badge, le taux d’achèvement élevé et l’historique des transactions restent des signaux utiles.

Mais ce qui m’a surpris, c’est qu’ils ne peuvent pas remplacer la vérification personnelle du fait que l’argent est bien arrivé sur le compte.

Le vrai problème ne consiste pas à savoir si le vendeur a un badge ou non, mais l’écart entre « croire que l’argent est arrivé » et le moment où l’argent apparaît réellement.

Une capture d’écran n’est qu’une image qui a été envoyée. Elle ne prouve pas que l’argent est effectivement entré sur le compte.

Si l’acheteur libère la crypto avant de vérifier par lui-même, cet écart peut devenir une leçon très coûteuse.

En repensant à cela, j’ai réalisé que j’avais abordé ce problème en me basant sur la réputation et les indicateurs du marchand, au lieu de vérifier avec des preuves concrètes.

Le processus de recherche ne m’a pas amené à penser que chaque marchand est peu fiable.

Il m’a simplement fait réaliser une chose plus clairement encore : ne faites pas confiance à quelque chose que vous n’avez pas vérifié personnellement.

Par conséquent, ma vision du P2P a elle aussi changé.

Un badge peut être un signal. Une capture d’écran peut être une information. Mais ce n’est que lorsque l’argent arrive réellement sur le compte que je le considère comme une preuve.

Et si quelqu’un vous pousse à libérer rapidement, c’est encore plus une raison de ralentir.
$KII $AEON $PRL
#BNBChainToActivatePasteurHardFork #SanDiskRises7%OnRevenueGrowthOutlook #USJulyRetailSalesFall0.6% #SaudiPIFDiscloses154.1MSpaceXShares