0xMinh

Auparavant, je pensais souvent que la conformité était quelque chose qui se situait en dehors de la blockchain. Le protocole n’avait qu’à être permissionless, et les règles seraient gérées au niveau de l’application, ou par un intermédiaire.

En creusant davantage au sujet du réseau Dusk, j’ai découvert une approche qui m’a fait m’arrêter net. La conformité n’est pas considérée comme une simple couche de contrôle ajoutée par-dessus : elle apparaît dès la manière dont le système modélise les actifs, l’identité, les droits d’accès et les données.
Au début, je pensais que Dusk n’ajoutait que quelques outils pour servir les RWA, puis j’ai réalisé que le problème était plus vaste. Si un actif est soumis à des réglementations, l’éligibilité, les restrictions de transfert, la divulgation et le règlement font déjà partie intégrante du cycle de vie de l’actif.

À l’heure actuelle, je vois les choses ainsi : Dusk Network cherche à intégrer ces contraintes dans le même environnement d’exécution. Citadel traite l’identité et la divulgation sélective, tandis que Moonlight et Phoenix permettent de trouver un équilibre entre transparence et confidentialité.

Cela reflète un modèle de confiance différent. Au lieu de supposer que la blockchain doit être totalement neutre vis-à-vis de la réglementation, Dusk semble supposer que le marché, une fois encadré, doit aussi être programmable.

Je ne pense toujours pas que cela rende automatiquement Dusk plus adapté que n’importe quelle autre Layer 1. La question plus intéressante est la suivante : lorsque la Réglementation devient une partie de la conception, où se situera la frontière entre le protocole, l’application et l’infrastructure financière ?
#dusk $DUSK @Dusk $BTC

Auparavant, je pensais souvent que la confidentialité et la conformité étaient presque deux directions opposées. D’un côté, on voulait masquer les données, et de l’autre, on avait besoin de la capacité à vérifier, authentifier et retrouver des informations quand c’est nécessaire.
J’étais habitué à cette façon de voir les choses depuis longtemps, donc lorsque j’ai lu à propos de Dusk Network, je m’attendais initialement à un certain compromis.
Mais plus je lisais la documentation, plus je devais m’arrêter sur une autre idée : la confidentialité ne signifie pas nécessairement que tout doit être invisible.
Au départ, je pensais que Dusk Network cherchait simplement à rendre les transactions plus discrètes grâce aux preuves à divulgation nulle (zero knowledge proofs). Ensuite, j’ai compris que le problème se situe dans la manière dont le système gère les autorisations et qui a le droit de voir les données.
Phoenix peut masquer des informations de transaction, tandis que le mécanisme de selective disclosure permet de divulguer des données précises à des parties autorisées. Moonlight conserve des flux transparents lorsque la publicité est nécessaire.
C’est à ce moment-là que j’ai compris que j’avais posé la mauvaise question.
Ce n’est pas « confidentialité ou conformité ? », mais « qui doit savoir quoi, et dans quel contexte ? ».
Au moins, d’après mon point de vue actuel, Dusk Network est en train de faire évoluer le modèle de confiance dans cette direction. Le système ne exige pas que tout le monde voie la même vérité, il cherche plutôt à produire des preuves suffisantes pour vérification, tout en limitant les droits d’accès à l’information.
Je ne pense pas encore que ce soit une solution complète pour la conformité. Le droit se trouve toujours en dehors de la blockchain.
Et il y a peut-être quelque chose de plus intéressant encore : Dusk Network ne cherche pas à supprimer la contradiction ; il essaie de changer la façon dont nous définissons cette contradiction.
#dusk $DUSK @Dusk $BTC

Auparavant, je pensais souvent que la tokenisation était presque synonyme de liquidité. Mettre un actif sur une blockchain, fractionner la propriété puis ouvrir la porte à davantage de participants, ça semblait assez logique. Mais en lisant plus en profondeur au sujet du réseau Dusk et de leur approche des RWA, j’ai commencé à voir que cette hypothèse posait problème. Il existe une distance entre « pouvoir tokeniser » et « pouvoir négocier efficacement ».

Au départ, je croyais que la blockchain était la partie la plus difficile. Puis j’ai réalisé que créer des tokens ne résout qu’une couche du problème. La liquidité dépend encore de la réglementation, des droits de propriété, de la capacité à transférer et de la confiance entre les parties.
La façon dont je le vois aujourd’hui est assez différente. La tokenisation ne crée pas automatiquement de la liquidité : elle rend simplement un actif plus facile à représenter et à transférer dans un système numérique.

Ce qui m’a particulièrement interpellé avec Dusk Network, c’est qu’ils ne dissocient pas la blockchain des contraintes des actifs réels. Lorsque les RWA impliquent des titres, des investisseurs et des réglementations, « ouvrir » ne peut pas simplement signifier que tout le monde peut y participer.
C’est à ce moment-là que j’ai compris que le vrai problème ne se situe pas dans le token lui-même : il se situe dans le modèle de confiance qui se trouve derrière le token.
Je reste avec une question : si la blockchain réduit la friction des transactions, mais que les contraintes juridiques demeurent, avons-nous vraiment créé une nouvelle liquidité, ou ne faisons-nous que transférer l’ancienne liquidité vers une autre forme ?
#dusk $DUSK @Dusk $BTC

Auparavant, je pensais que la confidentialité sur la blockchain signifiait qu’il fallait masquer l’intégralité des transactions. Plus il y avait peu de données révélées, plus je le considérais comme une bonne conception.
Mais en lisant plus en profondeur le fonctionnement du réseau Dusk, cette hypothèse commence à changer. Un détail dans Phoenix m’a fait relire plusieurs fois : le réseau doit toujours vérifier les transactions, mais il n’est pas nécessaire de voir la totalité de la valeur contenue dans celles-ci.
Au départ, je croyais que les Confidential Transactions consistaient simplement à chiffrer le montant, puis j’ai réalisé que cette interprétation était insuffisante. Phoenix utilise des notes protégées et des nullifiers. Les preuves à connaissance nulle permettent de prouver le droit de dépenser, la validité et d’empêcher la double dépense, sans divulguer les données sensibles de la transaction.
Aujourd’hui, je le vois ainsi : la différence réside dans la frontière entre « être vérifié » et « être vu ». La blockchain doit toujours savoir que la transaction est valide, mais elle n’a pas forcément besoin de connaître le montant ni les parties impliquées.
Phoenix 2.0 pousse encore plus loin cette idée. Le destinataire peut identifier l’expéditeur, alors que cette information ne devient pas une donnée publique pour l’ensemble du réseau.
Ce qui me paraît remarquable n’est donc plus la fonctionnalité de confidentialité en tant que telle. C’est la manière dont cette conception modifie le modèle de confiance : au lieu d’obliger tout le monde à voir les données pour y croire, le système utilise des preuves cryptographiques pour remplacer une partie de l’observation.
Et peut-être que c’est là la question la plus difficile : dans une blockchain destinée à la finance sous contrôle, qu’est-ce que nous voulons réellement cacher et qu’est-ce que nous voulons prouver ?
#dusk $DUSK @Dusk $BTC

Auparavant, je pensais que l’adoption de la blockchain commençait par les développeurs, les applications et les utilisateurs. Plus il y a d’utilisateurs, plus l’écosystème s’étend de lui-même.
Je voyais cela presque comme une loi, mais en lisant plus en profondeur à propos de Dusk Network, j’ai commencé à douter de cette hypothèse.
Ce qui m’a fait m’arrêter, c’est le lien avec NPEX. Dusk est devenue actionnaire de NPEX dès 2020, tandis que NPEX est un MTF autorisé aux Pays-Bas.
Au début, je pensais que NPEX offrait principalement un cas d’usage pour la RWA, mais ensuite j’ai réalisé qu’il y avait un sujet plus large. L’adoption ne nécessite pas seulement une blockchain performante : elle requiert aussi la présence d’émetteurs, l’accès des investisseurs, une plateforme de négociation et des processus déjà acceptés par le marché.

NPEX dispose déjà d’une partie de cette couche de marché. Dusk fournit l’infrastructure permettant de faire passer, sur la blockchain, les workflows d’émission, de trading et de règlement.
Ainsi, ma façon de voir le problème actuel est différente. NPEX n’est pas une preuve que l’adoption a déjà eu lieu, mais elle peut créer une voie plus concrète pour que l’adoption commence.

Ce qui mérite d’être réfléchi ici, c’est : plutôt que de forcer le marché traditionnel à aller chercher une blockchain, Dusk essaie d’introduire la blockchain dans un marché déjà existant.

Je ne sais pas encore jusqu’où ce modèle pourra s’étendre, mais il est probable que la question importante ne soit pas le nombre d’utilisateurs que Dusk aura, mais plutôt de savoir si NPEX peut transformer un besoin financier réel en besoin d’utilisation de l’infrastructure onchain.
#dusk $DUSK @Dusk $BTC

Auparavant, je trouvais les protocoles de lending plutôt simples : d’un côté, quelqu’un dépose des fonds ; de l’autre, quelqu’un emprunte ; et le taux d’intérêt, lui, varie selon des ajustements liés au marché. Je supposais presque par défaut que l’élément le plus important résidait dans l’allocation de la liquidité et le contrôle du risque associé aux prêts.

En lisant plus en profondeur sur TermMax, un détail m’a amené à m’arrêter : le protocole ne se contente pas de fixer un taux d’intérêt, il rattache aussi le prêt à une échéance précise.
Au départ, je pensais qu’il s’agissait simplement d’une variante du lending à taux fixe, mais j’ai ensuite réalisé que cette façon de voir reste trop proche du modèle de lending traditionnel. TermMax intègre à la fois le taux, la durée et le droit de recevoir une valeur future dans une structure qui peut être négociée.
Ce n’est qu’à ce moment-là que j’ai compris pourquoi la documentation parle autant de FT, XT et des courbes d’évaluation. Ce ne sont pas seulement des tokens accessoires : ils modifient la manière dont les droits des emprunteurs et des prêteurs sont séparés, puis échangés.

À mon point de vue actuel, je ne considère plus TermMax comme un simple endroit pour déposer ou emprunter des actifs.
Je commence à le voir comme une tentative de construire un marché de fixed income onchain, où le temps et le taux d’intérêt deviennent des éléments qui peuvent être évalués séparément.

Mais je m’interroge encore : lorsque la durée devient une partie intégrante de ce marché, dans quelle mesure cela va-t-il transformer la manière dont DeFi définit la liquidité ?
#termmax @TermMax $BTC

Je pensais autrefois qu’une forte liquidité suffisait à se lire en regardant simplement le volume de capital présent dans le protocole, mais en lisant davantage sur TermMax, je me suis rendu compte que cette mesure ne raconte pas toute l’histoire.

Un même capital peut être réparti sur différents marchés. Le problème survient lorsque, dans un market, la demande devient importante : la part de liquidité déjà placée sur d’autres marchés ne peut pas être transférée immédiatement.

C’est un détail qui a retenu mon attention en lisant Atomic Orders.
Selon la conception de TermMax, une même source de liquidité peut être positionnée sur plusieurs marchés en même temps, mais elle ne peut pas être utilisée plusieurs fois. Lorsqu’une commande retire une portion de liquidité, la partie correspondante disparaît simultanément de l’ensemble des autres marchés.

Au départ, j’ai compris cela comme une façon simple de rendre la liquidité « plus profonde », mais ensuite j’ai réalisé que le vrai enjeu réside dans la capacité à allouer le capital.
Le capital n’a pas besoin d’être immobilisé dès le départ sur un seul marché. Il peut rester derrière plusieurs besoins différents, puis n’être consommé que là où les échanges ont réellement lieu.

Ainsi, ma façon de voir Atomic Orders a changé : je ne le considère plus comme un mécanisme de création supplémentaire de liquidité, mais plutôt comme une manière de déplacer l’emplacement de la liquidité avant l’apparition de la demande.
Mais je veux toujours voir davantage de données réelles : la profondeur de l’appariement des ordres, la taille des prêts et l’utilisation du capital dans le temps.

Peut-être que, pour moi, la question la plus intéressante n’est pas le montant de TVL de TermMax, mais dans quelle mesure chaque unité de liquidité peut réellement servir le marché de façon efficace.
#termmax @TermMax $BTC

J’ai déjà vécu une situation qui m’a obligé à changer la façon dont je vois le fait de contacter le support. Je me souviens que c’était à l’approche du Têt 2026 : j’ai vendu 500 USDT sur Binance P2P pour acheter des articles pour la maison. L’acheteur a dit avoir transféré 13 millions de dongs et avoir envoyé une photo du reçu dans la conversation, mais en vérifiant mon compte bancaire, je ne voyais pas encore l’argent crédité.

Ma première réaction à ce moment-là était assez simple : je comptais contacter le support en disant que l’acheteur avait payé, mais que je n’avais pas encore reçu l’argent. Je pensais que cela suffisait pour commencer à résoudre le problème.

Mais j’ai alors réfléchi plus lentement et j’ai relu attentivement les informations sur Binance P2P. J’ai commencé à réaliser que j’avais omis une étape. Binance indique que, lorsqu’un litige survient, les parties peuvent faire appel (appliquer une procédure) et que l’équipe d’assistance examinera les preuves pertinentes. Cela m’a fait revoir ma démarche.

Au lieu de me contenter de raconter les faits, j’ai commencé à vérifier le code de la commande, l’état de la transaction, le montant qui devait m’être versé et l’historique du compte bancaire. J’ai aussi conservé les photos de confirmation ainsi que les preuves liées, au cas où il faudrait introduire un appel.

Au départ, je voyais le support comme un endroit où l’on résout le problème, mais ensuite j’ai compris que j’avais aussi la responsabilité de préparer des données suffisamment claires avant de demander une intervention. La différence, c’est que je fournis soit une histoire, soit un événement vérifiable.

Grâce à une préparation complète des informations et des preuves, tout s’est ensuite déroulé très facilement.

Depuis ce jour, je vérifie toujours tout ce qui peut être vérifié avant de contacter le support. Dans un nouveau litige, ce qui est vérifiable est ce qu’il faut être capable de croire.
#binancep2pantoan @Binance Vietnam $BTC

Aujourd’hui, j’ai passé pas mal de temps à lire la façon dont Dusk gère les transactions privées. J’ai fini par remarquer un détail que, jusqu’ici, j’avais souvent tendance à négliger.

Ici, la confidentialité n’est pas simplement une couche ajoutée après coup. Dusk utilise des preuves à divulgation nulle de connaissance (Zero Knowledge Proof) pour prouver qu’une condition est vraie sans avoir à rendre publiques toutes les données qui se trouvent en arrière-plan. Cela peut être la capacité de paiement, les conditions d’éligibilité ou l’état de la transaction.

Au début, je pensais encore que la crypto devait choisir l’un des deux. Soit être transparente pour être facilement vérifiable, soit être privée pour dissimuler les données. Mais à mesure que je me suis plongé dans la divulgation sélective, je me suis rendu compte que la façon de poser le problème est peut-être trop simpliste.

Aujourd’hui, je le vois ainsi : la confidentialité ne signifie pas nécessairement l’impossibilité d’auditer. Une autorité compétente peut être autorisée à consulter les informations nécessaires, tandis que les autres n’ont qu’à savoir que la transaction a bien satisfait aux conditions.

Zedger et l’orientation de Dusk vers la tokenisation d’actifs ont attiré mon attention précisément sur ce point. DuskEVM mérite aussi d’être suivi, car il ouvre la voie aux développeurs Solidity pour accéder à l’écosystème sans devoir repartir de zéro.

Mais je ne veux pas conclure trop vite.

« Privé mais audit-able » semble cohérent sur le plan de la conception. La question plus difficile est de savoir comment cela tiendra face à une autorité de régulation, à un litige concret et à grande échelle.

NPEX montre que ce modèle s’approche du marché réel, mais les essais concrets et la preuve à grande échelle restent deux choses différentes.

C’est peut-être justement la partie que je veux continuer à observer chez Dusk.
#dusk $DUSK @Dusk $BTC

Auparavant, je pensais qu’en cas de capital disponible, l’essentiel était de trouver le taux d’intérêt le plus élevé. Mais en m’intéressant davantage à TermMax, j’ai commencé à voir le problème sous un autre angle. Le taux fixe apporte quelque chose que la DeFi n’offre pas toujours : la capacité de prévoir.

Je connais le taux d’intérêt, je connais la durée, et je peux établir des plans en me basant sur ces chiffres, mais la certitude a toujours un prix. Une fois ma position verrouillée, le marché continue d’évoluer. Les taux peuvent devenir plus élevés, une autre opportunité peut apparaître, ou tout simplement ma stratégie peut changer en cours de route. Et à ce moment-là, ce qui donnait l’impression de sécurité redevient une limite.

Ainsi, je ne pense plus qu’il existe un meilleur choix entre le taux fixe et le taux variable. D’après mon point de vue actuel, ils répondent à deux besoins différents : le taux fixe privilégie la certitude, tandis que le taux variable privilégie la flexibilité.

Supposons que j’aie 15 000 USD à prêter pendant 6 mois. Je ne me demanderais pas seulement quel taux est le plus élevé. Je me demanderais plutôt : est-ce que je veux verrouiller mon rendement pour obtenir de la stabilité, ou est-ce que je préfère conserver le droit d’ajuster ma position lorsque le marché fluctue ? Peut-être que répartir son capital entre les deux est aussi une option. Finalement, la vraie question à se poser n’est pas “lequel est le meilleur”, mais plutôt “qu’est-ce que je suis prêt à sacrifier”.
#termmax @TermMax

Auparavant, je pensais souvent qu’un marché financier fonctionnait comme une série de systèmes interconnectés. On émet quelque part, on négocie ailleurs, puis le paiement et la compensation sont traités après.

En approfondissant Dusk Network et NPEX, j’ai commencé à revoir cette hypothèse. Ce qui m’a fait m’arrêter n’est pas le concept de mise d’actifs sur la blockchain, mais la manière dont Dusk décrit l’ensemble du workflow d’un actif relié.

Au départ, je pensais qu’il s’agissait principalement de tokenisation. Créer un token qui représente l’actif, puis l’introduire sur le marché, mais la documentation de Dusk distingue clairement la tokenisation de la native issuance. Avec la native issuance, le cycle de vie de l’actif peut être conçu autour du ledger lui-même, plutôt que d’utiliser le token uniquement comme couche de représentation.

Ensuite, j’ai compris que j’avais omis quelque chose de plus important. Dusk Trade ne parle pas seulement d’achat et de vente. Il inclut l’éligibilité, la divulgation, la coordination entre la jambe de paiement et la jambe d’actif, puis le règlement.
NPEX fournit, lui, une couche d’infrastructure de marché gérée. Aujourd’hui, Dusk décrit la démarche visant à intégrer l’émission, la négociation, la divulgation et le règlement dans un workflow onchain unifié.

D’après mon point de vue actuel, le changement le plus important se situe dans le modèle de confiance. Le problème ne consiste plus simplement à savoir « le token existe-t-il sur la blockchain ? », mais à déterminer dans quelle mesure les règles d’accès, de transfert, d’information et de règlement peuvent être appliquées de manière cohérente.

Je reste toutefois inquiet au sujet de la frontière entre ce que la blockchain exécute et ce que le cadre réglementaire de NPEX continue de prendre en charge. C’est peut-être là que se trouve la partie la plus intéressante à suivre.
#dusk $DUSK @Dusk $BTC

Auparavant, je pensais que déposer une plainte sur Binance P2P était l’étape finale à utiliser uniquement lorsque la transaction s’était réellement soldée par un échec.

J’avais tendance à vouloir tout gérer moi-même. En envoyant quelques messages de plus, en attendant que l’autre partie réponde, je pensais que le problème pourrait être résolu sans faire intervenir un tiers.
Mais en relisant la façon dont Binance P2P traite les litiges, j’ai commencé à penser autrement. Il y avait un point que j’avais négligé : lorsque les deux parties ne parviennent plus à s’entendre sur l’état de la transaction, continuer à négocier ne fait parfois qu’ajouter de la confusion au lieu d’éclaircir la situation.

Au départ, je croyais que lancer un litige signifiait forcément rendre les choses plus graves.
Ensuite, j’ai compris que je m’étais trompé sur son objectif. Une plainte n’est pas nécessairement un geste de confrontation. C’est un moyen d’inscrire le litige dans un processus afin que Binance l’examine à partir des informations et des preuves pertinentes.

À mon point de vue actuel, le moment où il vaut la peine de déposer une plainte n’est pas quand je perds patience. C’est lorsque la transaction rencontre un problème et que les deux parties ne peuvent pas résoudre clairement la situation par elles-mêmes.
Cela a aussi changé ma façon de voir la notion de responsabilité. Ce n’est pas parce qu’il y a un litige qu’il faut ouvrir une plainte immédiatement, mais il ne faut pas non plus retarder la démarche par crainte de complexifier les choses.
Peut-être que la question la plus importante n’est pas « quand faut-il déposer une plainte ? », mais plutôt : à quel moment dois-je arrêter de croire que la négociation directe suffit encore ?
#binancep2pantoan @Binance Vietnam $BTC

Auparavant, je regardais souvent un nouveau token à travers son prix après le TGE. La hausse ou la baisse du prix semblait être le signal le plus rapide pour comprendre ce que le marché pense, mais en relisant attentivement la documentation TMX, j’ai commencé à voir que cette façon de regarder ne suffisait pas.

TermMax prévoit un TGE le 25/08/2026. Ainsi, ce qui m’intéresse ne se limite pas au niveau de prix auquel le marché s’est formé après cette date, mais à ce qui se passe ensuite.

Ce qui m’a fait m’arrêter, c’est la manière dont TermMax conçoit le rôle de TMX. Le livre blanc décrit TMX pour la gouvernance, le staking et les incitations de l’écosystème. L’offre totale est de 1 milliard de tokens, dont 20 % sont alloués à la circulation initiale.
Au début, je pensais que le TGE était principalement un moment où le marché fixe un prix. Puis je me suis rendu compte que c’était aussi le point de départ pour vérifier un design économique.

La façon dont je vois aujourd’hui TMX s’en est trouvée changée. Je veux observer si le staking crée réellement une incitation à conserver, si la gouvernance est réellement utilisée et si les incitations génèrent une activité durable ou si elles ne font que stimuler une demande à court terme.
Je remarque aussi que les groupes d’allocation ont des calendriers de vesting différents. La part dédiée à l’Écosystème, à elle seule, se voit attribuer 290 millions de TMX avec une durée de vesting de 48 mois.
Cela me fait penser que le prix ne reflète qu’une coupe extrêmement courte.
Peut-être que, après le 25/08, la question la plus intéressante n’est pas le prix de TMX, mais plutôt de savoir si les mécanismes qui l’entourent fonctionnent réellement comme prévu.
#termmax @TermMax $BTC

Auparavant, je trouvais la compatibilité EVM assez simple. Si une blockchain supportait Solidity et les outils Ethereum, je partais du principe que c’était la manière de faire venir des développeurs dans une nouvelle ecosystem.

Mais en lisant plus en profondeur la documentation de Dusk, je me suis rendu compte que cette hypothèse était insuffisante. Un détail m’a notamment fait m’arrêter : la façon dont Dusk sépare l’exécution du settlement.

Au début, je pensais que DuskEVM aidait surtout les applications Ethereum à fonctionner sur Dusk ; puis j’ai réalisé que son rôle allait plus loin, mais aussi de manière plus précise que ce que j’imaginais.

DuskEVM est l’environnement d’exécution EVM, tandis que DuskDS gère le consensus, le settlement et la disponibilité des données. La finance regulated repose quant à elle sur plusieurs autres composants, comme le contrôle d’accès, la divulgation sélective et les modèles de transactions de Dusk.

De mon point de vue actuel, je ne considère plus DuskEVM comme un simple bridge Ethereum au sens technique. Je le vois plutôt comme une couche de compatibilité qui aide les applications Solidity et les outils Ethereum à accéder à l’infrastructure de Dusk.
Le plus intéressant, c’est cette répartition des responsabilités. L’EVM conserve le modèle de développement familier, tandis que le settlement et les exigences de la finance regulated sont traités dans d’autres couches.
Sans doute que le « bridge » ici n’est-il pas entre deux blockchains, mais entre deux façons de construire des systèmes.
Je reste cependant avec une question en tête : est-ce que la séparation elle-même — entre la compatibilité et la nouvelle infrastructure regulated — est la partie la plus remarquable du design de Dusk ?
#dusk $DUSK @Dusk

Je pensais qu’il suffisait que l’argent arrive sur le compte pour que la transaction puisse continuer, mais en observant davantage Binance P2P, je vois qu’un petit détail mérite peut-être d’être pris en compte : le nom du payeur ne correspond pas.

Binance indique clairement que si le compte de paiement du partenaire ne correspond pas au nom vérifié sur la plateforme, le vendeur ne doit pas libérer le crypto. Binance permet un remboursement et recommande de signaler la commande via le chat Binance.

Avant, je pouvais considérer cela comme une simple étape de vérification “à la forme”, mais un cas concret m’a fait changer d’avis.
Un vendeur m’a déjà partagé qu’il avait reçu l’argent via Momo, mais que le nom de l’expéditeur ne correspondait pas à celui figurant sur Binance. Il a quand même libéré le crypto, puis le paiement a été contesté et l’argent a été retenu.

Je ne peux pas affirmer que tous les cas où les noms ne correspondent pas sont des arnaques, mais ce cas montre que le fait que “l’argent soit arrivé” ne signifie pas forcément que la vérification est terminée.
Ma façon de voir les choses aujourd’hui est plus simple : avant de libérer, il faut faire correspondre les informations de la commande avec le paiement réellement effectué. S’il y a un point anormal, je préfère créer un peu plus de friction plutôt que d’agir trop vite.
Peut-être que Binance P2P ne supprime pas la confiance : elle essaie seulement de réduire la quantité de confiance à accorder au partenaire, en maintenant la transaction dans un processus vérifiable.
Et je me pose encore cette question : quel risque se cache derrière un nom qui ne correspond pas ?
#binancep2pantoan @Binance Vietnam $BTC

Auparavant, je considérais le TGE comme une sorte de point cible pour un projet de jeton. Quand le token commence à être négocié, je suppose que la partie la plus difficile est déjà passée.
Mais en lisant la documentation de TermMax, je me suis mis à voir cette vision comme un peu trop simpliste.

Le livre blanc TMX décrit une offre totale de 1 milliard de tokens, 20 % en circulation lors du TGE, ainsi qu’un mécanisme de distribution contrôlé sur 48 mois. Je m’arrête au mot « ensuite ».

Au départ, je pensais que le TGE était principalement un problème de tokenomics. Puis j’ai compris qu’il ajoutait une couche économique autour du protocole. TermMax a construit le lending, le borrowing et le leverage avec des taux d’intérêt avant même l’apparition du TMX.

La façon dont je le vois aujourd’hui est un peu différente. Le TGE ne sert pas seulement à vérifier la distribution des tokens : il commence aussi à vérifier si le token est lié aux activités du protocole.
Pour moi, c’est un changement de confiance. Avant le TGE, je regardais la conception et le produit ; après le TGE, je dois observer les incitations, les avantages liés aux tokens et l’interaction des activités du protocole.

Ainsi, je ne considère plus le TGE de TermMax comme un test final. Il ressemble plutôt à un point de bascule.
La question que je veux toujours suivre est la suivante : après l’apparition du TMX, comment le système prouvera-t-il sa valeur par des activités concrètes ?
#termmax @TermMax $BTC

Auparavant, je pensais qu’un bon système financier devait choisir un camp. Soit de la transparence pour pouvoir tout vérifier facilement, soit de la confidentialité pour protéger les participants.

En lisant plus en profondeur la documentation de Dusk Network, j’ai découvert une approche qui m’a fait m’arrêter. Dusk ne considère pas la confidentialité et la transparence comme deux états mutuellement exclusifs. Le système permet des flux publics, shielded (protégés) et en disclosure sélective selon les besoins.

Au départ, je pensais que la confidentialité consistait principalement à dissimuler les données de transactions, puis je me suis rendu compte que ce point de vue était un peu simpliste. Dans les marchés régulés, le véritable enjeu consiste davantage à savoir qui a le droit de connaître quelles informations, et dans quelles circonstances.

Ma façon de voir Dusk a donc aussi changé. La confidentialité n’est pas nécessairement opposée à la conformité. Phoenix peut masquer des informations de transaction, tandis que les viewing keys et la disclosure sélective permettent de révéler des données lorsque le workflow l’exige.

Cela m’a amené à réfléchir davantage au modèle de confiance. Peut-être qu’un système financier n’a pas besoin de rendre tout public pour offrir des capacités de vérification ; plus important encore, il s’agit de contrôler les frontières entre la confidentialité, la transparence et le droit d’accès.

Je me pose toutefois encore des questions sur la manière dont ces principes seront déployés de façon différente selon chaque application. La question la plus intéressante n’est peut-être pas de savoir si Dusk choisit la confidentialité ou la transparence, mais plutôt comment il décide quelles informations doivent être dignes de confiance, démontrables et divulguées.
#dusk $DUSK @Dusk $BTC

Auparavant, je pensais qu’une transaction qui se déroule sans accroc en disait quand même quelque chose sur la fiabilité de l’autre partie. Si l’acheteur paie correctement et que la transaction est finalisée, je m’imaginais quasiment par défaut que tout ce qui vient après ne présentait rien d’inquiétant, mais une transaction Binance P2P récente m’a forcé à reconsidérer cette idée.

Je me souviens qu’à l’époque, je vendais 500 USDT et l’acheteur a payé normalement. Pendant que j’ouvrais la banque pour vérifier les fonds, il a commencé à me demander si je faisais souvent des transactions en crypto. Ensuite, il m’a présenté un nouveau projet et m’a demandé mon numéro de téléphone, ainsi que mon Telegram, pour discuter en privé.
Au début, je n’ai pas trouvé que c’était un problème particulièrement important, mais j’ai ensuite compris que cette invitation était totalement en dehors du cadre de la transaction en cours.

Je ne savais pas si le projet qu’ils voulaient me présenter était bon ou mauvais, donc je n’ai pas jugé, et je ne leur ai pas donné mon numéro de téléphone ni mon Telegram. Je suis revenu vérifier uniquement ce qu’il fallait vérifier : le montant réellement reçu, les informations de l’expéditeur, puis seulement après j’ai confirmé la finalisation. Avant cela, les 500 USDT restaient toujours bloqués dans l’Escrow par le système jusqu’à ce que je confirme.

Ce que j’en retiens n’est pas qu’il faut soupçonner tous les acheteurs, mais plutôt qu’il ne faut pas utiliser une transaction valide pour étendre cette conclusion à d’autres sujets.

Le fait que l’acheteur transfère le bon montant à payer ne fait que confirmer que cette transaction s’est déroulée correctement selon la procédure ; cela ne m’aide pas à évaluer le projet qu’il vient de présenter.
C’est pourquoi je conserve tout de même la conversation, le code de transaction et les justificatifs s’il y a un problème à contester ou à contacter le support de Binance P2P.
Grâce à cette expérience, je me rappelle que pour tout ce qui sort du cadre de la transaction, il vaut peut-être mieux garder une certaine dose de scepticisme et vérifier par soi-même avant de croire.
#binancep2pantoan @Binance Vietnam $BTC

Auparavant, je pensais souvent que le consensus était une histoire où plusieurs validateurs confirment un bloc. Je supposais par défaut que plus il y a de nœuds qui participent au réseau, plus c’est fiable.

En approfondissant Dusk Network, un détail de la Succinct Attestation m’a obligé à m’arrêter. Dusk ne conçoit pas le consensus dans l’idée que tous les provisioners traitent toutes les décisions.

Au départ, je comprenais la SA de façon assez simple : les détenteurs de DUSK mettent en commun leurs propositions et votent, mais cette compréhension oubliait une partie essentielle. La SA est un mécanisme de Proof-of-Stake basé sur des comités, où les provisioners sont sélectionnés pour des rôles différents.

En lisant plus attentivement, j’ai compris que chaque round passe par trois étapes : Proposition, Validation et Ratification. Un provisioner propose un bloc, puis un comité le vérifie, ensuite un autre comité confirme le résultat et finalise le bloc.

Avec le recul, je ne vois plus la SA comme une simple manière de voter. Je la considère plutôt comme une façon de répartir les responsabilités dans le consensus. Le système n’exige pas que tous les provisioners confirment tout. Il choisit des groupes pour chaque tâche, puis fixe les conditions pour que le bloc atteigne la finalité.

Cela a changé ma manière de concevoir le modèle de confiance. La confiance ne repose pas seulement sur le nombre de nœuds, mais aussi sur les règles de sélection des comités et sur le stake.

Je reste toutefois avec une question : lorsque le consensus s’appuie sur des groupes sélectionnés, où se situe la véritable limite de la confiance ?
#dusk $DUSK @Dusk

Une note qui m’a empêché de ne pas « release » USDT....!

Je me souviens encore qu’à l’occasion de Noël 2025, j’ai vendu 1 000 USDT pour préparer les dépenses de fin d’année. En vérifiant l’appli de ma banque, j’ai vu que l’argent était bien arrivé sur mon compte, avec la mention « chuyen tien mua usdt binance ».
Le montant était exact, et les fonds étaient bien là. Après un certain temps d’attente, relâcher les USDT à ce moment-là m’est presque venu comme une évidence.

Mais je me suis arrêté à cause d’un petit détail : la commande exigeait que la note de paiement ne contienne aucun mot lié à la crypto ou à Binance.
Au début, je pensais que cette note ne prouvait pas forcément un problème de paiement, mais elle montrait qu’une partie de la transaction ne correspondait plus aux conditions initiales. Avec ma façon de trader la crypto, ce simple décalage suffisait déjà pour tout re-vérifier.

Je suis retourné dans la conversation sur Binance P2P et j’ai demandé au vendeur d’authentifier davantage l’identité du payeur. Je voulais être sûr que la personne qui a payé était bien le bon partenaire de la commande.
Quand la situation ne pouvait plus continuer, j’ai choisi de rembourser selon la procédure, plutôt que de forcer la transaction à aboutir.

Ce n’est qu’à ce moment-là que j’ai mieux compris le rôle de l’Escrow. Binance P2P conserve la crypto dans la commande, mais avant de « Release Crypto », je dois quand même vérifier moi-même le montant réellement reçu. Le statut « paid » ne remplace pas la vérification du compte bancaire.

C’est pourquoi je conserve toujours toutes les interactions sur Binance P2P. Le chat, l’Order ID et les détails du paiement constituent un dossier de liaison au cas où j’aurais besoin de faire un Appeal ou de contacter l’Assistance.

Finalement, ce dont je me souviens le plus, ce n’est pas une note de paiement problématique, mais la façon dont un petit détail peut rendre toute la transaction moins sûre. Et tant qu’il reste un maillon non confirmé, je pense qu’il vaut mieux ralentir plutôt que se précipiter.
#binancep2pantoan @Binance Vietnam $BTC