Prince ETH

Qu’avez-vous réellement autorisé lorsque vous avez signé ?

Appuyer sur Signet donne l’impression que le moment où une transaction blockchain devient entièrement définie. La signature prouve qui l’a autorisée, si bien qu’il est tentant de supposer que la transaction a désormais une signification évidente partout et pour toujours.

La mise à niveau Boreas de Dusk montre pourquoi cette hypothèse est incomplète.

Lorsque Boreas est passé en production (mainnet) le 10 juin 2026, au bloc de redémarrage 4 414 095, Rusk a commencé à imposer des limites explicites de version autour de l’interprétation des transactions. Les transactions en direct sont décodées selon les règles du protocole actif. Les enveloppes Aegis prises en charge sont normalisées dans la représentation actuelle. Les transactions scellées localement sont canoniques avant l’engagement dans le registre (ledger). Les anciens décodeurs restent disponibles pour la relecture historique.

L’objectif est plus important que le détail d’implémentation : Dusk empêche explicitement le mempool, le producteur de blocs, le validateur de consensus et le chemin de relecture d’interpréter les mêmes données de transaction selon des règles différentes.

Une signature peut authentifier les données autorisées. Elle ne peut pas, à elle seule, indiquer à chaque version future d’un protocole comment ces données doivent être comprises.

Cela signifie que la sécurité des transactions dépend de deux accords à la fois : qui a autorisé l’action, et quelles sémantiques de protocole définissent cette action.

Pour les portefeuilles, les échanges et les signataires matériels, la gestion de la version de protocole n’est donc pas seulement une plomberie de compatibilité. Elle fait partie de la préservation de la signification de ce qu’un utilisateur a signé.

@Dusk $DUSK #dusk

« En attente » est-il réellement un fait valable pour l’ensemble du réseau ?

Un portefeuille peut étiqueter une transaction Dusk comme « en attente » alors qu’un autre nœud n’a aucune entrée correspondante dans son mempool.

Ce n’est pas forcément une incohérence. Cela découle de la façon dont Dusk gère les transactions avant qu’elles ne deviennent un état du grand livre.

Chaque pair effectue ses propres vérifications d’admission et conserve son propre mempool. La requête mempoolTxs de Dusk affiche donc le mempool réel du nœud interrogé—et non une file d’attente partagée à l’échelle du réseau par chaque pair.

La gestion de l’époque Boreas—Moonlight rend cela encore moins intuitif. Une transaction valide dont le nonce est en avance par rapport à la séquence courante du compte peut être différée pendant l’arrivée des nonces manquants. Durant cette période, elle se trouve en dehors du mempool réel visible par le nœud. Ainsi, même le nœud qui a reçu la transaction peut ne pas l’afficher encore dans mempoolTxs.

L’expiration ajoute aussi une dimension locale supplémentaire : il s’agit d’une politique du nœud, plutôt que d’une durée de vie encodée dans la transaction elle-même.

Cela modifie la façon dont je lirais le mot « en attente ». Avant le consensus, Dusk ne fournit pas un état global unique faisant autorité sur lequel tout le monde peut se baser. Différents nœuds peuvent légitimement détenir des informations différentes concernant la même transaction.

L’état d’un portefeuille est donc un compte rendu issu d’un point d’observation, et non une affirmation que le réseau a déjà convenu d’un fait intermédiaire partagé.

Le consensus est là où ces vues locales fragmentées commencent à se transformer en historique commun du grand livre.

@Dusk $DUSK #dusk

Un événement de fin de soirée archivé peut décrire un changement d’état qui ne s’est jamais produit

Un backend peut lire un événement depuis l’archive finalisée de Dusk et prendre néanmoins la mauvaise décision financière.

Depuis que Boreas est devenu actif sur le mainnet au bloc de redémarrage 4,414,095, Dusk conserve volontairement les événements de contrats annulés (revert) dans les données d’archive, avec un marqueur indiquant qu’ils ont été revert. Ces événements constituent une preuve historique que l’exécution les a produits—ce n’est pas une preuve que leurs effets d’état ont survécu.
Après Boreas, les événements revert sont exclus du bloom de bloc canonique, et les événements de mise (stake) revert ne mettent pas à jour l’état du pourvoyeur.

Cette distinction est importante partout où les événements deviennent des mutations de base de données. Un indexeur qui considère « l’événement existe » comme « l’opération a réussi » peut créditer un dépôt, enregistrer un paiement (payout), ou déclencher une logique en aval pour un état que la chaîne a annulé.

Le guide de dépôt de Moonlight de Dusk énonce explicitement la règle : un dépôt direct n’est accepté que lorsque l’événement de transfert correspond à l’opération attendue et que event.reverted === false.

Ainsi, la finalisation répond à une seule question : cette histoire archivée est-elle réglée (settled) ? Elle n’efface pas la nécessité d’interpréter ce que cette histoire dit.

Pour les intégrations de Dusk après Boreas, revert n’est pas un métadonnée à ignorer. C’est une partie de la condition d’acceptation qui sépare les preuves d’exécution historique de l’état canonique.

@Dusk $DUSK #dusk

Un transaction de Dusk peut-elle réussir sur la chaîne tout en échouant à livrer des DUSK à l’adresse BSC visée ? Oui, car ce flux de pont comporte deux destinations dissimulées dans une seule action utilisateur.

Dans le flux actuel de mainnet Dusk vers BSC, le Web Wallet envoie des DUSK natifs au compte officiel du pont. Le destinataire BSC n’est pas le champ « recipient » de cette transaction ; il est transporté dans le mémo. Le pont lit cette adresse au format EVM et l’utilise pour router le paiement BEP20.

Cela change la signification de « réussi ». Une transaction Dusk confirmée prouve que le transfert côté source a bien atteint le compte du pont. Elle ne prouve pas, à elle seule, que le paiement côté destination a été acheminé vers l’adresse que l’utilisateur avait l’intention. La documentation de Dusk prévient qu’un mémo manquant ou invalide ne peut pas être traité automatiquement et peut rendre le transfert irrécupérable.

Ainsi, le mémo fait plus que décrire la transaction. Dans ce flux, il fait partie des instructions de livraison.

Je pense que cela crée une limite utile pour les wallets et l’UX du pont : une fois que l’infrastructure consomme des métadonnées pour décider où la valeur doit aller ensuite, ces métadonnées doivent être traitées comme une entrée critique pour la transaction. Le compte du pont et l’adresse du mémo méritent la même vérification préalable avant l’envoi.

Un hachage de transaction peut prouver le règlement. Il ne peut pas corriger une instruction d’acheminement qui était erronée avant le règlement.

@Dusk $DUSK #dusk $TRUMP $ZEC

« Zéro risque de liquidation » se lit facilement comme : « Je peux toujours gérer la position proprement. » TermMax Alpha sépare ces deux idées.

Un acheteur Long ou Short paie la prime d’avance, et cette prime correspond aussi à la perte maximale possible de la position. Un mouvement de prix défavorable ne crée pas le parcours habituel menant à une liquidation du collatéral.

Mais clôturer avant l’échéance pose un problème différent. La documentation de TermMax prévient qu’une clôture anticipée nécessite toujours une contrepartie. Si la liquidité est faible, la position peut être difficile à dénouer, ou nécessiter un slippage important.

Cette distinction compte. Le risque de liquidation demande si le protocole peut vous fermer de force parce que le collatéral est insuffisant. Le risque de liquidité à la sortie demande si quelqu’un est prêt à prendre l’autre côté lorsque vous choisissez de partir.

Alpha peut supprimer le premier sans supprimer le second.

Ainsi, « absence de liquidation » ne signifie pas « absence de frottements de marché ». Cela décrit la manière dont le risque baissier est borné, et non la liquidité de la position avant l’échéance. Pour moi, c’est une façon bien plus utile de lire le risque d’une position sur option que le simple titre.

@TermMax #TermMax $BTW $BLESS $BCH

Taux fixe, devis mobile

TermMax peut proposer des prêts à taux fixe tout en offrant à deux utilisateurs qui observent le même marché des APR différents.

Cela semble contradictoire seulement si le « fixe » est traité comme un devis qui existe avant la transaction. Les ordres à fourchette (Range Orders) de TermMax fonctionnent autrement : la liquidité est répartie le long d’une courbe de tarification, et l’APR change à mesure que davantage de cette courbe est remplie. Une petite commande peut s’arrêter près d’un point ; une commande plus importante peut consommer une liquidité plus profonde et verrouiller un taux effectif différent.

Pourquoi concevoir cela de cette manière ? Parce qu’un marché à revenu fixe a encore besoin de la découverte des prix. Au lieu d’imposer un seul taux pour chaque taille de transaction, les ordres à fourchette permettent aux initiateurs d’ordres d’exprimer la quantité de liquidité qu’ils sont prêts à fournir à différents APR. Le taux devient fixe après l’exécution, pas avant.

La conséquence économique est facile à manquer : le taux APR annoncé et l’APR exécutable ne sont pas toujours la même chose. La taille fait partie du prix de la liquidité à taux fixe.

Ainsi, la courbe de TermMax ne rend pas le prêt « à taux variable ». Elle détermine quel taux fixe votre transaction rapporte avant que la position ne soit verrouillée.

Taux fixe ≠ devis fixe.

@TermMax #TermMax $PEOPLE $MAGMA $BTW

La tokenisation n’élimine pas les frictions. Elle les déplace.

Tokeniser un actif est facile comparé à la tâche de faire en sorte que le marché qui l’entoure cesse de se réconcilier en permanence.

C’est, à mes yeux, la partie du design actuel d’infrastructure de marché de Dusk qui est la plus importante, plus que le jeton lui-même. Dusk Trade relie la découverte d’actifs, l’onboarding des investisseurs, l’éligibilité, la coordination des paiements, le trading et le règlement, tandis que la pile Dusk au sens large fournit les contrôles et la couche de règlement qui se trouve en dessous.

La thèse est simple : la tokenisation crée une efficacité réelle uniquement lorsque plusieurs participants peuvent agir sur le même état contrôlé. Si la propriété, l’éligibilité et le règlement résident encore dans des systèmes séparés, le jeton pourrait devenir un autre enregistrement à rapprocher plutôt que l’enregistrement qui supprime la nécessité de réconciliation.

Mais l’intégration a une conséquence moins confortable. Un workflow partagé peut exécuter une mauvaise politique aussi régulièrement qu’une bonne. Dusk peut imposer des règles d’éligibilité et coordonner le règlement ; il ne peut pas décider quelle règle juridique est correcte, s’il existe une demande de marché, ni s’un enregistrement contesté doit être remplacé.

Je ne jugerais donc pas la tokenisation à la vitesse à laquelle un titre peut être émis. L’épreuve la plus difficile est de savoir si l’infrastructure réduit les transferts (handoffs) sans faire semblant que du code remplace les institutions responsables de ces transferts.

@Dusk $DUSK #dusk $BOME $NEIRO

Le compte à rebours P2P n’est pas une preuve de paiement

Un compte à rebours peut créer de l’urgence sans apporter aucune preuve.

Dans le modèle actuel de commande P2P de Binance, une commande marquée « Payé (Non confirmé) » peut afficher une date limite de libération. Ce minuteur est utile : il vous indique où la commande se situe dans le workflow et le temps restant. Mais il ne vous dit pas si le montant VND attendu est réellement parvenu au compte destinataire.

Cette distinction change la décision avant « Confirmer la libération ».
Si le minuteur tourne mais que le compte bancaire n’affiche toujours pas les fonds attendus, les deux signaux ne concordent pas. Le compte à rebours ne doit pas « faire pencher la balance » par rapport au contrôle de paiement. Conservez la crypto en dépôt et résolvez l’incohérence via le parcours Commande/Appel.

Si l’argent est visible, la vérification comporte encore une deuxième couche : le paiement correspond-il à cette commande et aux informations de l’expéditeur que Binance attend ? Les règles spécifiques aux marchands de Binance considèrent en particulier une non-concordance du nom de l’expéditeur comme une raison de ne pas libérer.

Ainsi, le minuteur répond à une question de timing. Votre compte destinataire et les détails de la commande répondent à la question de paiement.

Un modèle mental simple : les délais vous indiquent quand agir ; les preuves vous indiquent quelle action est sûre.

@Binance Vietnam #BinanceP2PAnToan $AVAAI $ACE $ONG

Un taux fixe doit encore être valorisé

TermMax appelle ses opérations de prêt/emprunt à taux fixe, mais la partie la plus intéressante se produit avant que le taux ne devienne fixe.

Sur un marché TermMax, les Range Order Setters peuvent placer plusieurs Range Orders avec des courbes de prix personnalisées. Le preneur ne reçoit pas un taux issu d’une formule unique applicable à l’ensemble du protocole ; l’exécution se fait à partir de liquidités réparties le long de ces courbes. Cela signifie que la taille de l’ordre et la profondeur disponible peuvent modifier le taux effectif que vous verrouillez.
La chaîne causale est simple :

Conception des Range Orders → répartition de la liquidité → prix d’exécution → taux implicite → économie de la position fixe.

Cela change ma façon de penser le « DeFi à taux fixe ». TermMax supprime un type d’incertitude après l’exécution : le coût d’emprunt ou le rendement de prêt est verrouillé jusqu’à l’échéance. Mais il ne supprime pas la découverte des prix avant l’exécution. La certitude de la position repose sur une décision de market making.

Cela déplace aussi l’attention vers qui contrôle la courbe. Un Range Order Setter peut façonner l’endroit où la liquidité est proposée, tandis que le protocole lui-même avertit que des courbes mal configurées peuvent conduire à une exécution défavorable. Donc le risque n’est pas seulement « les taux bougeront-ils plus tard ? ». C’est aussi « ce taux a-t-il été formé efficacement au moment où je suis entré ? »

Le point de second ordre : le revenu fixe onchain n’élimine pas la microstructure de marché. Il rend la microstructure plus déterminante au moment de l’entrée. Un taux fixe peut être prévisible pendant des mois — et pourtant être un mauvais taux si la courbe et la profondeur étaient médiocres lorsque vous l’avez verrouillé.

@TermMax #TermMax $BTW $RE $MAGMA

DuskEVM rend-il les contrats Solidity privés par défaut ?
DuskEVM crée une hypothèse simple : si une application s’exécute sur Dusk, elle doit automatiquement hériter du modèle de confidentialité de Dusk.

L’architecture dit quelque chose de plus précis.

DuskEVM est un environnement d’exécution EVM basé sur l’OP Stack. Les contrats Solidity s’y exécutent avec des outils Ethereum familiers, tandis que les lots et les engagements d’état sont réglés via DuskDS, qui fournit un consensus, une finalité déterministe et la disponibilité des données.

Cette séparation compte, car la compatibilité d’exécution et la capacité de confidentialité ne garantissent pas la même chose.

Les propres documents de Dusk présentent DuskVM comme la voie pour les contrats qui nécessitent un accès direct aux actifs de la couche L1, aux modèles de transactions, aux fonctionnalités de confidentialité ou de preuve à connaissance nulle. DuskEVM, en revanche, résout d’abord un problème différent : une exécution équivalente à l’EVM et la compatibilité pour les développeurs. Les flux orientés confidentialité peuvent se connecter à l’ensemble de la pile Dusk, mais ils dépendent encore de la manière dont l’application est conçue.

La question utile n’est donc pas : « Les développeurs Ethereum peuvent-ils déployer sur Dusk ? » Ils le peuvent.

La question plus difficile est : quelles garanties proviennent de la couche EVM, et lesquelles doivent être composées délibérément à partir de DuskDS ou de primitives natives de Dusk ?

Cela change le modèle mental. Dusk ne fait pas simplement envelopper la confidentialité autour de l’EVM. Il sépare l’exécution, le règlement et l’infrastructure capable de confidentialité afin que les développeurs puissent choisir d’où provient chaque garantie.

Pour la finance réglementée, cette modularité est puissante, mais elle implique aussi que les choix d’architecture font partie du modèle de conformité et de confidentialité.

@Dusk $DUSK #dusk $HEMI $ACE

Une règle Binance P2P mérite davantage d’attention, car elle sépare deux vérifications que les vendeurs traitent souvent comme si c’étaient la même chose : « L’argent est-il arrivé ? » et « Est-ce qu’il provient du client vérifié ? »

Pour les transactions P2P hors CNY, les règles d’appel de Binance indiquent que si le nom figurant sur le compte de paiement de l’acheteur ne correspond pas au nom vérifié sur Binance P2P, la crypto ne doit pas être libérée. Le vendeur est invité à rembourser le montant intégral, et la commande est annulée après soumission des preuves de remboursement et confirmation de la réception par l’acheteur.

Ce détail compte, car recevoir le bon montant n’est qu’une preuve de paiement. Ce n’est pas une preuve que l’identité de l’émetteur correspond à la personne figurant sur la commande.

Une discordance de nom ne prouve pas automatiquement une fraude. Il peut y avoir des explications innocentes : l’acheteur peut utiliser le compte bancaire d’un autre membre de la famille, un compte professionnel, ou simplement ignorer l’exigence de nom lors du paiement. Mais du point de vue du vendeur, la décision pratique est la même : ne pas « régler » la discordance en libérant d’abord et en posant des questions ensuite.

Avant de confirmer la libération, comparez trois éléments :
le montant de la commande,
le solde bancaire réel,
et le nom de l’expéditeur avec le nom vérifié de l’acheteur affiché dans la commande.

Si le montant est correct mais que le nom ne l’est pas, gardez la crypto verrouillée, utilisez la messagerie de la commande et ouvrez un appel (Appeal) sur cette commande plutôt que de la traiter en dehors de la plateforme.

La distinction utile est simple : la vérification du paiement répond à « l’argent a-t-il été reçu ? » La vérification d’identité répond à « qui a payé ? » Sur Binance P2P, une libération en sécurité exige que les deux questions fassent sens ensemble.

@Binance Vietnam #BinanceP2PAnToan $BTC $ETH $SOL

La semaine dernière, j’ai commandé un ordinateur portable sur Shopee. Paiement à la livraison. Le livreur a apporté le colis, j’ai vérifié qu’il était scellé et qu’il correspondait à la commande, j’ai payé 18 millions de VND, puis je l’ai pris. C’est simple.

Mais réfléchissons à ce qui s’est passé : Shopee a retenu ma commande dans un état où le vendeur ne pouvait pas encaisser mon argent et où je ne pouvais pas prendre le produit tant que les deux conditions n’étaient pas remplies. Le vendeur a expédié d’abord, en faisant confiance au paiement à la livraison pour garantir le paiement. J’ai payé à la livraison, en faisant confiance au fait que le colis contenait ce que j’avais commandé. Le livreur était le tiers neutre assurant l’échange de façon atomique : les biens et le paiement sont transférés au même moment.

C’est un mécanisme d’escr ow (séquestre). Il fonctionne parce que l’acheteur, le vendeur et la plateforme suivent les mêmes règles appliquées par le système.

Sur la plupart des blockchains, les smart contracts fournissent un séquestre, mais chaque détail est public. Tout le monde peut voir ce que vous avez acheté, combien vous avez payé et auprès de qui.

@Dusk _Foundation exécute des smart contracts avec une confidentialité intégrée grâce à sa RUSK VM. Les fonds sont verrouillés, les conditions sont vérifiées et l’échange reste atomique. Mais les détails des transactions — qui, combien, quel actif — sont cachés à tous, sauf aux participants. La confidentialité du COD, garantie par la blockchain.

Auto-critique : le COD de Shopee fonctionne parce que si l’ordinateur portable est abîmé, je peux refuser la livraison et le livreur le reprend. Les transactions confidentielles on-chain rendent la résolution des litiges plus difficile. Si je prétends que les "biens numériques" n’ont pas été livrés, mais que le ZKP dit que la transaction était valide, qui arbitre ? La confidentialité limite aussi les preuves disponibles en cas de litige. L’analogie marche sur le chemin le plus favorable, mais se brise quand quelque chose tourne mal.

$DUSK doit être évalué selon la manière dont ses smart contracts confidentiels gèrent les litiges et les exceptions, et pas seulement sur la fluidité avec laquelle ils s’exécutent quand tout se passe bien.

Quelqu’un d’autre s’appuie sur le COD parce que vous ne faites pas confiance aux paiements en ligne ? Vous pensez déjà comme un utilisateur de blockchain 😂 #dusk $BICO $HOME

Le taux d’intérêt est fixe, mais que reçoit le prêteur si l’emprunteur ne parvient pas à rembourser ?

Supposons que vous déposiez 1 000 USDC sur une position à taux fixe, et que vous connaissiez déjà le remboursement attendu à l’échéance. Jusque-là, rien de plus simple. Mais il existe une question souvent négligée : si l’emprunteur ne peut pas régler intégralement la dette, quel actif soutient réellement ce rendement « fixe » ?

Sur TermMax, un prêt n’est pas seulement un chiffre d’APY. Chaque marché à taux fixe dispose d’un token de dette, d’une garantie, d’une date d’échéance et de seuils LTV. La position de l’emprunteur est représentée par un GT, un ERC-721 qui enregistre la dette et la garantie. Si le LTV atteint le seuil LLTV, la position peut être liquidée.

La partie la plus intéressante intervient ensuite. Si la dette ne peut pas être résolue intégralement, TermMax utilise un mécanisme de livraison physique. Lorsque les détenteurs de FT rachètent via le pool, ils peuvent recevoir une répartition proportionnelle à la fois du token sous-jacent et de la garantie, plutôt que de tout récupérer automatiquement dans l’actif initial.

À mes yeux, ce détail compte plus que le chiffre du taux fixe lui-même. La livraison physique ne rend pas le prêt « sans risque ». Elle modifie la manière dont la valeur restante est répartie lorsque la récupération de la dette ne suit pas le scénario idéal.

L’avantage est que le système dispose d’une autre voie pour gérer les situations où la garantie ne peut pas être convertie proprement en l’actif de remboursement attendu. En contrepartie, les prêteurs peuvent se retrouver à détenir un mélange d’actifs différent de celui escompté, tout en restant exposés aux risques liés au prix de la garantie, à la liquidité, à l’oracle et aux smart contracts.

Ainsi, avant de regarder un FT et de demander : « Quel est le rendement ? », je poserais une question de plus :

« Dans le scénario défavorable, avec quoi suis-je réellement remboursé ? »

@TermMax #TermMax $ALPINE $CLO $ACE

Un commerçant a envoyé exactement 10 millions VND, puis a envoyé ce message : « Je l’ai envoyé par erreur, s’il vous plaît, rembours en-moi. »

Je vendais 400 USDT sur P2P. Dès que la commande a été créée, j’attendais que l’acheteur fasse le paiement.

Puis, mon compte Vietcombank a soudain affiché un virement entrant de 10 millions VND. Avant même que je puisse tout vérifier, l’acheteur m’a envoyé :
« Frère, je viens de transférer par accident 10 millions VND sur votre compte. S’il vous plaît, renvoyez-les sur ce compte bancaire. »
Il a fourni un autre compte bancaire — PAS celui affiché sur la commande P2P.

Je me suis arrêté 5 secondes et j’ai pensé :
Attendez. Ma commande de 400 USDT valait 10,08 millions VND. L’acheteur a envoyé exactement 10 millions, soit 80K de moins, et maintenant il prétend que c’était une erreur ?

C’est l’arnaque classique du « virement accidentel ».

Si j’avais remboursé les 10 millions VND vers ce compte sans rapport :
Je pourrais perdre 10 millions VND pour de bon
Mes USDT resteraient bloqués en dépôt sous séquestre
L’acheteur pourrait annuler la commande ou déposer un appel (Appeal)
Je pourrais finir par tout perdre
Donc je N’AI rien renvoyé.

J’ai pris une capture d’écran de toute la conversation, enregistré le reçu bancaire, puis j’ai ouvert immédiatement un appel.

Le support Binance l’a traité en 3 heures. La demande de l’acheteur a été rejetée.

🔴 Quelqu’un dit « Je l’ai envoyé par erreur, s’il vous plaît, rembourse-moi » → SIGNE D’ALARME
🔴 N’ENVOYEZ JAMAIS d’argent en dehors du flux de commande/paiement P2P
🟢 Gardez toutes les preuves → Appeal → Laissez Binance gérer
🟢 Gardez toute l’activité de paiement à l’intérieur de Binance P2P
Avec le recul, si j’avais été trop rapide et que j’avais remboursé cet argent, je serais probablement en train de pleurer 😂

Quelqu’un ici a-t-il déjà rencontré cette arnaque du « virement accidentel » ?

@Binance Vietnam
#BinanceP2PAnToan
$GPS $RED $STAR

LORSQUE LA LIQUIDATION NE SUFFIT PAS : COMMENT LA LIVRAISON PHYSIQUE DE TERMMAX FONCTIONNE

Un prêt garanti semble simple : si une position devient risquée, le protocole liquide une partie de la garantie pour rembourser la dette. Mais que se passe-t-il lorsque la volatilité du marché ou une liquidité insuffisante empêche la liquidation intégrale ?

Dans TermMax, chaque marché à taux fixe dispose d’un seuil LLTV. Lorsque le LTV d’une position atteint ce niveau, elle peut être liquidée. Si l’emprunteur ne peut toujours pas rembourser intégralement, le fait de fixer le taux d’intérêt ne supprime pas le risque de crédit et de garantie restant.

C’est ici que la livraison physique intervient.

Au lieu de supposer que la garantie peut toujours être vendue rapidement à un prix équitable, TermMax peut distribuer les actifs sous-jacents et la garantie restants aux détenteurs de FT lorsque la dette n’est pas totalement réglée.

Imaginez une dette d’une valeur de 1 000 unités. Dans des conditions normales, la garantie est vendue pour récupérer de la valeur pour les prêteurs. Mais si seule une partie peut être liquidée efficacement, forcer le reste dans un marché peu liquide pourrait entraîner une exécution encore plus défavorable. La livraison physique permet alors de transférer les actifs restants aux détenteurs de FT.

L’avantage est clair : le système ne dépend pas uniquement de conditions de liquidation parfaites.

Mais il y a un compromis. Les détenteurs de FT qui s’attendaient à un paiement à taux fixe prévisible peuvent recevoir une garantie au lieu de l’actif uniquement qu’ils avaient initialement anticipé. Ils supportent alors le risque de prix, le risque de liquidité et potentiellement un processus de sortie plus long.

Ainsi, le taux fixe et la livraison physique résolvent deux problèmes différents. Le taux fixe rend le coût d’emprunt ou le rendement plus prévisible. La livraison physique traite de ce qui se passe lorsque la liquidation ne peut pas entièrement clôturer la position.

Cette distinction est importante, car dans DeFi, le risque devient souvent le plus visible lorsque les marchés cessent de fonctionner normalement.

@TermMax #TermMax $CYS $ONG $BMT

J’ai passé 2 heures sur une transaction de 200 USDT parce que l’acheteur “envoyait accidentellement” des montants incorrects

Celui-là a mis ma patience à l’épreuve comme rien d’autre.

J’ai mis 200 USDT en vente. L’acheteur a créé la commande. Total : 5,04 millions de VND.

Premier virement : 504 000 VND. Il manquait un zéro. L’acheteur a dit : “Désolé, faute de frappe, j’envoie le reste.”

Deuxième virement : 4 500 000 VND. Total reçu : 5 004 000 VND. Il manquait encore 36 000 VND. L’acheteur a dit : “Oh, la banque a déduit des frais, libérez juste, s’il vous plaît.”

J’ai dit non. 5 004 000, ce n’est pas 5 040 000.

Troisième message de l’acheteur : “Allez, c’est seulement 36k de différence. Ne complique pas.”

Je suis resté ferme. J’ai tapé : “Le montant de la commande est de 5 040 000. Je libérerai uniquement quand je recevrai exactement 5 040 000.”

L’acheteur s’est tu pendant 40 minutes. Puis il a envoyé un troisième virement de 36 000 VND. Ensuite, il a envoyé immédiatement : “C’est fait. Libérez maintenant.”

J’ai vérifié. Total reçu : 5 040 000. Correct. J’ai libéré.

L’ensemble du processus a pris 2 heures pour une transaction de 200 USDT.

L’acheteur essayait-il vraiment de me scammer ? Peut-être que oui, peut-être que non. Mais le schéma de plusieurs petits virements avec des “erreurs” est une tactique connue pour embrouiller les vendeurs et les faire libérer avant que le montant complet n’arrive.

NE LIBÉREZ PAS tant que le MONTANT EXACT n’est pas reçu

“C’est juste une petite différence” n’est jamais une raison de libérer trop tôt

Restez calme, indiquez clairement le montant requis, et attendez

Si ça dure trop longtemps, faites un appel (Appeal) plutôt que de céder

36 000 VND, ce n’est rien. Mais si j’avais libéré après le deuxième virement, j’aurais donné 200 USDT pour 5 004 000 au lieu de 5 040 000.

Et l’acheteur saurait que “le paiement accidentellement insuffisant” fonctionne.

Quelqu’un d’autre a déjà eu affaire à la tactique des “multiples petits virements” ?

@Binance Vietnam #BinanceP2PAnToan $STAR $HEMI $ACE

Ma société effectue des audits trimestriels. Tous les trois mois, une équipe externe intervient, examine nos livres, vérifie chaque transaction et produit un rapport. Cela nous prend 2 semaines et nous coûte une fortune.

Mais voilà ce qui m’a toujours dérangé : pendant ces 2 semaines, les auditeurs ont accès à TOUT. Chaque salaire, chaque paiement à un fournisseur, chaque valeur de contrat client. Ils doivent tout voir pour vérifier que les chiffres concordent.

Et si on pouvait vérifier que « les chiffres concordent » sans voir réellement les chiffres ?

Ce n’est plus une question théorique. @Dusk utilise les preuves à divulgation nulle de connaissance pour permettre exactement ce type de schéma. Une transaction peut prouver qu’elle est valide, que les entrées sont égales aux sorties, que les règles de conformité ont été respectées, sans révéler au vérificateur les montants réels ni les contreparties. Un auditeur pourrait confirmer que « les comptes de cette entreprise sont équilibrés » sans connaître le salaire individuel de chaque employé.

C’est ce que Dusk appelle « la confidentialité avec auditabilité ». Pas une confidentialité qui se cache des régulateurs. Une confidentialité qui satisfait les régulateurs sans exposer plus de données que nécessaire.

Auto-critique : les auditeurs de ma société ne font pas que vérifier les calculs. Ils cherchent des schémas, des anomalies, des éléments techniquement corrects mais contextuellement suspects. Par exemple, un fournisseur payé exactement 9 999 USD de façon répétée, juste en dessous d’un seuil de déclaration de 10 000 USD.

La vérification par divulgation nulle de connaissance confirme la conformité, mais peut manquer le contexte. Un ZKP peut prouver « cette transaction est valide » mais pas « ce schéma de transactions valides semble suspect ». La conformité, ce n’est pas seulement de la mathématique.

$DUSK devrait être évalué en fonction de la capacité de ses outils d’audit préservant la confidentialité à détecter des schémas suspects, pas uniquement à vérifier la correction de chaque transaction.

Votre entreprise a-t-elle déjà subi un audit au cours duquel vous auriez souhaité qu’on puisse vérifier sans tout voir ?

#dusk $GPS $TUT

Vendu 500 USDT et l’acheteur a envoyé de l’argent depuis le compte bancaire de quelqu’un d’autre 😳

La semaine dernière, j’avais une annonce de vente P2P pour 500 USDT. L’acheteur a marqué le paiement comme effectué, et quand j’ai vérifié mon appli bancaire, 12,6 millions de VND étaient bien arrivés. De l’argent réel, une transaction réelle.

Mais ensuite, j’ai remarqué le nom de l’expéditeur. Il ne correspondait pas au nom de l’acheteur figurant sur la commande Binance. Pas du tout. Un nom de famille différent, tout est différent.

Je suis resté là pendant de bonnes cinq minutes à réfléchir à quoi faire. L’argent était réel. Le montant était correct. Une partie de moi voulait juste libérer la pièce et passer à autre chose.

Mais le problème, c’est que si cet argent venait d’un compte piraté ou volé, ma banque pourrait geler mon compte plus tard quand le vrai propriétaire déposera un signalement. J’aurais l’argent, mais j’aurais aussi un compte gelé et une enquête pour fraude liée à mon nom.

Alors je n’ai pas libéré. J’ai ouvert un Appel et j’ai expliqué à Binance Support le décalage de nom. Ils ont enquêté et l’ont résolu.

Ce que j’ai appris :

🔴 L’argent qui arrive n’est PAS suffisant. Le nom de l’expéditeur DOIT correspondre au nom KYC Binance de l’acheteur. 🟢 Si le nom ne correspond pas, ne libérez PAS. Faites un Appel immédiatement. 🟢 Faites des captures d’écran de tout : la transaction bancaire, les détails de la commande, la discussion. 🟡 Les paiements effectués par des tiers font partie des risques P2P les plus courants que les nouveaux vendeurs sous-estiment.

Le fait que l’argent soit « réel » ne veut pas dire que l’argent est « propre ». Ce sont deux choses très différentes.

Quelqu’un d’autre a-t-il déjà été confronté à un problème de discordance de nom sur du P2P ? Comment l’avez-vous géré ?

@Binance Vietnam #BinanceP2PAnToan $HEMI $APR $VELVET

Mon immeuble a une association de copropriétaires. Chaque mois, chaque logement verse une cotisation d’entretien. En échange, nous obtenons un droit de vote sur les décisions concernant l’immeuble : installer de nouveaux ascenseurs, repeindre le hall, engager une nouvelle société de sécurité. Plus vous payez de manière régulière, plus votre vote est pris au sérieux. Personne qui ne contribue pas ne peut décider comment sont utilisés les ressources communes.
Cette structure correspond presque directement à la manière dont les réseaux Proof-of-Stake gèrent la gouvernance. Les détenteurs de tokens « mettent en jeu » leurs tokens, ce qui revient à payer la cotisation d’entretien. En échange, ils aident à valider les transactions, ce qui permet au réseau de fonctionner, et ils obtiennent une voix dans les décisions du protocole grâce à des votes de gouvernance.
@Dusk utilise le token natif $DUSK exactement pour cela. Les participants (stakers) prennent part à la « Succinct Attestation », le mécanisme de consensus du réseau, et leur mise contribue directement à la sécurité du réseau. Ce n’est pas du « farming » de rendement passif. Les stakers participent activement à la confirmation des blocs et au maintien d’une finalité déterministe. La récompense provient du fait de faire un travail réel, et pas simplement de verrouiller des tokens et d’attendre.
Auto-critique : dans mon immeuble, chaque logement a un vote, indépendamment du montant qu’il paie. Sur Dusk, le pouvoir de vote en gouvernance est proportionnel à la mise. Cela signifie qu’une personne disposant d’une mise nettement plus importante a une voix nettement plus forte. L’analogie avec la cotisation d’entretien s’effondre précisément ici : dans l’immeuble, la famille du penthouse et celle de l’appartement studio ont un avis égal. Dans un modèle de gouvernance pondéré par les tokens, le penthouse gagne toujours. Que cela conduise à de meilleures décisions ou simplement à une concentration accrue dépend entièrement de la qualité avec laquelle le protocole répartit la mise dans le temps.
#dusk devrait être évalué en fonction de l’efficacité de son mécanisme de gouvernance à empêcher que la concentration de la mise ne devienne une concentration des décisions, et pas seulement en fonction de la valeur totale mise.

$PORTAL $ACE

Plus tôt cette année, j’ai ouvert un compte-titres auprès d’une société de courtage dans le district 1. Je pensais que remplir le formulaire me permettrait d’acheter des actions immédiatement. En réalité, cela a pris six jours ouvrés. Ils ont vérifié mon identité, croisé mon adresse, m’ont filtré à partir d’une liste noire, puis seulement ont activé le compte. Quand j’ai demandé pourquoi cela avait pris autant de temps, le personnel a répondu : « Réglementation de la Commission des valeurs mobilières. Tout le monde doit y passer. »

Sur une blockchain classique, quiconque dispose d’un portefeuille peut acheter un jeton instantanément. Pas de KYC, pas de contrôle. C’est pratique, mais cela ne peut pas fonctionner pour de vrais titres financiers, car la loi exige que seuls des investisseurs vérifiés puissent participer aux opérations de trading.

@Dusk intègre cette exigence directement dans des contrats intelligents via la norme XSC, Confidential Security Contracts. Chaque token de sécurité émis sur Dusk emporte avec lui ses conditions de transfert : qui peut acheter, qui peut vendre, les restrictions de juridiction, les périodes de blocage. La conformité programmable signifie que ces contrôles ne sont pas gérés par un humain assis derrière un bureau pendant six jours. Le code bloque automatiquement toute transaction non conforme avant son exécution.

Auto-critique : le code automatisé est plus rapide qu’un réviseur humain, mais un réviseur humain est plus flexible que le code. Le personnel du courtier pouvait décrocher le téléphone et demander des précisions quand mes documents étaient ambigus. Un contrat intelligent ne sait que si c’est valide ou invalide. Un investisseur légitime avec une faute de frappe dans le nom de son KYC pourrait être totalement bloqué, sans personne pour examiner le cas limite, à moins que Dusk ne mette en place un mécanisme de dérogation humaine par-dessus les règles automatisées.

$DUSK devrait être évalué en fonction du fait que sa conformité programmable inclut ou non un mécanisme de dérogation humaine dans les cas ambigus, et pas uniquement sur le nombre de règles qu’il peut automatiser.
#dusk $H $HEMI