PerpNotes

JE NE M’ATTENDAIS PAS À CE QUE L’ORDRE DE DEUX OPÉRATIONS CHANGE AUTANT QU’UN SLASH.
Je lisais les modifications de Boreas de @Dusk et je me suis arrêté sur une ligne concernant l’ordre des transitions d’état.
Avant Boreas, il y avait un cas au sein du même bloc où la mise était modifiable avant l’application d’un slash en attente.
Boreas a inversé cet ordre.
Le slash se produit désormais en premier.
L’exécution de la transaction intervient ensuite.
C’est un changement étonnamment faible pour quelque chose d’essentiel à la conformité du consensus.
La pénalité elle-même n’avait pas besoin d’une nouvelle philosophie. L’élément important était de s’assurer que la mise ne pouvait pas passer vers un état différent avant que la pénalité déjà en attente ne l’atteigne.
Ce qui rend le changement encore plus intéressant, c’est la façon dont Dusk a géré les anciens blocs.
L’historique pré-Boreas est toujours rejoué avec l’ancien ordre. Les nouveaux blocs utilisent le nouvel ordre.
Ainsi, un nœud doit comprendre deux versions valides de la même machine d’état selon l’endroit où il se trouve dans l’historique de la chaîne.
C’était le détail que je n’avais pas apprécié :
un hard fork peut corriger la suite sans prétendre que la même règle avait toujours existé.
Pour Boreas, même quelque chose d’aussi banal que « quelle opération s’exécute en premier ? » faisait partie de la justesse du consensus.

#dusk $DUSK @Dusk

LE PARTAGE DE LA RÉCOMPENSE PEUT RESTER IDENTIQUE TOUT EN CHANGEANT CE QUI FINANCE LA RÉCOMPENSE.
J’ai continué à examiner les pourcentages de récompense de @Dusk , puis j’ai réalisé que je regardais le mauvais côté de l’équation.
Chaque récompense de bloc est financée par deux éléments :
**les DUSK nouvellement émis
et les frais de transaction payés dans ce bloc.**
La première période d’émission de Dusk libère environ 19,8574 DUSK par bloc.
Après quatre ans, cela tombe à 9,9287.
Puis 4,9644, et cela continue à être divisé par deux tous les quatre ans.
Les règles de distribution peuvent rester les mêmes tandis que la source de la valeur distribuée change.
C’est la distinction que je trouve la plus utile :
allocation de récompense ≠ financement de récompense.
Un pourvoyeur peut recevoir sa part définie par le protocole pendant deux périodes différentes, tandis qu’une période dépend beaucoup plus des émissions et qu’une autre peut recevoir une part plus importante de frais de transaction réels.
Je ne pars pas du principe que les frais remplaceront la baisse des émissions.
C’est précisément ce que je voudrais mesurer plutôt que prédire.
Le chiffre que je surveillerais est simplement :
Quel pourcentage des récompenses totales de blocs provient des frais plutôt que des nouvelles émissions ?
Si ce pourcentage augmente avec le temps, l’activité du réseau finance davantage la réserve de récompenses.
S’il reste faible pendant que les émissions diminuent, alors le mix de financement raconte une autre histoire.
Les pourcentages nous indiquent qui reçoit la récompense.
Le ratio frais/émissions nous indique de plus en plus d’où vient cette récompense.

#dusk $DUSK @Dusk

$TUT $TRUMP

DEUX BASSINS DE DÉTENTION AU CRÉPUSCULE PEUVENT OBTENIR LA MÊME RÉCOMPENSE DE PROTOCOLE TOUT EN SERVANT AUX UTILISATEURS DES TAUX DE RETOUR DIFFÉRENTS.
Je revenais sans cesse à un détail dans la conception de l’Abstraction de mise de @Dusk .
Un smart contract peut détenir des fonds mis en jeu, recevoir des récompenses et décider comment ces récompenses sont distribuées ou réinvesties.
Au premier abord, cela ressemble à une infrastructure pour des pools de staking.
Mais cela change ce que l’utilisateur compare réellement.
Deux pools peuvent interagir avec le même système de staking Dusk et fonctionner de façon similaire au niveau du protocole, alors que les personnes qui y déposent peuvent malgré tout obtenir des rendements différents.
Parce que :
la récompense de protocole ≠ le rendement du déposant.
Dès que la logique de staking passe dans un smart contract, une partie de l’économie se déplace avec elle.
Un contrat peut définir la part de la récompense qui atteint les déposants, la part conservée par un opérateur, si les récompenses sont capitalisées, ou si un autre participant reçoit une part.
Cette flexibilité est utile.
Sans elle, construire des produits de staking plus sophistiqués serait beaucoup plus difficile.
Mais cela signifie aussi que le rendement annoncé d’un produit de staking n’est plus expliqué uniquement par la performance des validateurs.
La politique du contrat compte aussi.
C’est la partie que je voudrais voir rendue extrêmement lisible pour les utilisateurs.
Pas seulement :
« Quel APY ce pool affiche ? »
Mais :
Pour chaque 100 DUSK que ce contrat gagne auprès du protocole, quelle quantité atteint finalement (ou est capitalisée) pour les personnes qui fournissent la mise ?
Si deux pools obtiennent des récompenses de protocole similaires mais produisent des rendements de déposants significativement différents, la variable intéressante n’est plus le consensus.
C’est la couche qui décide où la récompense va après que le consensus l’a déjà payée.
#dusk $DUSK @Dusk

$ZEC $TRUMP

J’ai ouvert aujourd’hui le nouveau @TermMax $TMX Allocation Checker et un chiffre m’a immédiatement paru plus intéressant que l’autre :
30% > 15%.
Puis j’ai lu ce que chaque option fait réellement.
Pour les allocations au-dessus du seuil d’acquisition (vesting), choisir 30% signifie :
30% disponibles maintenant
70% définitivement abandonnés.
Choisir 15% signifie :
15% disponibles maintenant
85% restent à vous et s’acquièrent sur 3 ou 6 mois.
Donc, étrangement, 30% est le plus gros chiffre immédiatement mais le résultat en termes de propriété est plus faible.
Prenons une allocation simple de 10,000 TMX.
Option A — 30%
3,000 TMX disponibles.
7,000 TMX perdus.
Allocation totale préservée : 3,000 TMX.
Option B — 15%
1,500 TMX disponibles.
8,500 TMX continue d’être acquis.
Allocation totale préservée : 10,000 TMX.
C’est une différence bien plus grande que ce que suggèrent les boutons 30% vs 15%.
Et pour être précis, cet arbitrage ne s’applique qu’au-dessus du seuil d’acquisition. En dessous, TermMax dit que l’allocation est directement réclamable sans période de blocage.
Il y a un autre détail que j’ai presque manqué :
ne rien faire reste un choix.
Les sélections doivent être confirmées d’ici le 23 août, 23:59 UTC, et elles sont définitives. Si aucun choix n’est fait, TermMax attribue automatiquement l’option la plus longue : acquisition sur 6 mois + staking sur 6 mois.
Donc avant le TGE du 25 août, j’ai cessé de ne regarder qu’un seul chiffre :
« De combien de $TMX puis-je disposer immédiatement ? »
La meilleure question est :
« Quelle part de mon allocation m’appartient encore après que je choisis cette liquidité ? »
Pour moi, c’est la partie la plus intéressante de cette conception.
TermMax place un vrai arbitrage directement devant les utilisateurs :
plus de liquidité maintenant
contre
plus de propriété conservée pour plus tard.
30% paraît plus grand que 15%.
Mais dès que la notion de confiscation (forfeiture) entre en jeu, le pourcentage plus élevé peut vous laisser posséder beaucoup moins.
C’est le chiffre que je vérifierais deux fois avant de cliquer sur quoi que ce soit.

#termmax @TermMax

$ENA $HYPE $ZEC

« COMPATIBLE AVEC L’EVM » NE SIGNIFIE PAS QUE LA SURVEILLANCE DE L’EVM SUFFIT.
Un détail du flux de bridge de @Dusk m’a fait reconsidérer ce que « compatible avec l’EVM » garantit réellement.
Un retrait commence sur DuskEVM.
Mais il ne s’arrête pas là.
L’utilisateur lance l’action côté EVM, puis le retrait doit être prouvé et finalisé sur Dusk L1.
La préparation dépend de l’état publié, de la maturité des preuves et des vérifications en cas de litige — pas seulement du temps écoulé.
Cela crée un problème que je trouve encore plus intéressant que la vitesse du bridge :
la compatibilité d’exécution ≠ la visibilité opérationnelle.
Une équipe peut apporter Solidity, des portefeuilles EVM, des outils RPC et les habitudes de monitoring qu’elle connaît déjà.
Cela rend le développement plus simple.
Mais cela peut aussi engendrer une hypothèse dangereuse : si la transaction EVM semble complète, l’action économique doit aussi être complète.
Pour un retrait inter-couches, ce n’est pas nécessairement l’état qui compte.
Le côté EVM peut vous dire où l’action a commencé.
Le côté Dusk, lui, détermine quand le retrait est réellement prêt à être prouvé et finalisé.
Donc la question que je poserais à une bourse ou à une équipe d’infrastructure n’est pas :
« Votre pile EVM existante peut-elle voir DuskEVM ? »
Elle est plutôt :
Votre pile peut-elle vous dire quand une action inter-couches est véritablement terminée, sans ajouter un monitoring d’état spécifique à Dusk ?
Si la réponse est non, alors DuskEVM crée un compromis intéressant.
La compatibilité réduit les coûts de changement pour les développeurs tout en pouvant masquer une nouvelle exigence d’observabilité sous des outils familiers.
C’est la partie que je surveillerais quand les applications les plus concrètes arriveront.
Le plus dangereux écart de compatibilité pourrait être celui qui paraît suffisamment compatible pour que personne ne pense à le monitorer différemment.

#dusk $DUSK @Dusk

$ZEC
$ENA

J’ai continué à lire la phrase « zéro liquidation » autour de TermMax Alpha et je me suis rendu compte que je confondais deux choses différentes :
ne pas être forcé de sortir d’une position
et
pouvoir partir quand je veux.
Ce n’est pas la même chose.
Avec @TermMax Alpha, une position Long ou Short est structurée via des options.
Le trader paie la prime d’avance.
Cette prime correspond au Coût Max ; donc si le marché évolue complètement à l’encontre de l’opération, il n’y a pas de seuil de liquidation « automatique » qui viendrait balayer la position.
Cela élimine une des parties les plus horribles du trading avec effet de levier : être directionnellement dans le vrai plus tard, mais être liquidé de force en premier.
Mais ensuite, j’ai regardé ce qui se passe si je change d’avis avant l’échéance.
Il n’y a pas de mécanisme de liquidation qui me force à sortir.
En revanche, si je veux fermer la position moi-même, quelqu’un doit encore prendre l’autre côté.
Cela signifie que la qualité de ma sortie dépend d’un élément que la phrase « zéro liquidation » ne me dit pas :
la liquidité.
Une position peut être protégée contre la liquidation forcée et rester coûteuse à dénouer tôt si le marché est peu liquide.
Un volume important peut subir du slippage.
Un marché de contrepartie faible peut rendre la sortie pire que ce que l’entrée laissait penser.
Donc la distinction qui m’importe maintenant est :
Pas de sortie forcée ≠ sortie volontaire garantie.
Cela ne rend pas la conception TermMax plus faible.
Au contraire, cela rend l’architecture plus intéressante, car elle sépare deux risques que les produits à effet de levier ont généralement tendance à mélanger.
TermMax peut définir ma perte maximale à l’avance.
Il peut supprimer le seuil de liquidation.
Mais la liquidité du marché détermine toujours la marge de manœuvre dont je dispose si je veux sortir tôt.
Alors j’ai cessé de demander :
« De combien le prix peut-il bouger avant que je sois liquidé ? »
Avec Alpha, c’est le mauvais indicateur.
La question que je veux surveiller est :
« Quel volume puis-je fermer volontairement, avec quel slippage, quand le marché évolue rapidement ? »
Zéro liquidation me dit que je ne peux pas être forcé à sortir.
La liquidité de sortie me dit à quel point je peux choisir de partir facilement.
Ce sont deux promesses très différentes.

#termmax @TermMax

$BOME $ACE $HYPE $TMX

« PERSONNE NE PEUT LE DÉPLACER SANS MA CLÉ » SEMBLE ÊTRE UNE PROPRIÉTÉ PARFAITE.
POUR UNE SÉCURITÉ RÉGLEMENTÉE, JE N’ESTIME PAS QUE CE SOIT TOUJOURS LE CAS.
J’AI REMARQUÉ QUELQUE CHOSE DANS LA DOCUMENTATION DE @Dusk QUI SEMBLAIT D’ABORD PRESQUE ANTI-CRYPTO.
EN PLUS DES REGISTRES DES ACTIONNAIRES ET DE LA GOUVERNANCE SUR CHAÎNE, Dusk LISTE DES TRANSFERTS FORCÉS PARMI LES CAPACITÉS PERTINENTES POUR LES ACTIFS RÉGLEMENTÉS.
SA DOCUMENTATION TRAITE ÉGALEMENT LA RÉCUPÉRATION APRÈS LA PERTE DE CLÉS, LA FRAUDE ET LES ACTIONS EXIGÉES PAR LA LOI COMME DES EXIGENCES POUR LES ACTIFS RÉGLEMENTÉS.
CELA M’A AMENÉ À DISSOCIER DEUX IDÉES :
CONTRÔLE CRYPTOGRAPHIQUE ≠ INFRASTRUCTURE LÉGALEMENT COMPLÈTE DE PROPRIÉTÉ.
IMAGINEZ QU’UNE ACTION EXITE NATIVE SUR LA CHAÎNE, ET QUE L’ACTIONNAIRE PERD LA CLÉ.
OU BIEN QUE LA PROPRIÉTÉ DOIT ÊTRE CORRIGÉE APRÈS UNE FRAUDE CONFIRMÉE OU UNE AUTRE ACTION JURIDIQUEMENT REQUISE.
UN SYSTÈME QUI N’A POUR SEULE RÉPONSE : « LA CLÉ CONTRÔLE L’ACTIF POUR TOUJOURS » PEUT ÊTRE CRYPTOGRAPHIQUEMENT PROPRE, MAIS PAS AUTOMATIQUEMENT ADAPTÉ COMME INFRASTRUCTURE DE TITRES.
C’EST LÀ QUE JE PENSE QUE Dusk S’ATTAQUE À UN PROBLÈME PLUS DIFFICILE QUE LA SIMPLE PROPRIÉTÉ PAR JETON.
MAIS LA SOLUTION CRÉE SA PROPRE LIMITE DE CONFIANCE.
DÈS QU’UN SYSTÈME PEUT CORRIGER LA PROPRIÉTÉ SANS LA SIGNATURE DU DÉTENTEUR ACTUEL, LA QUESTION DEVIENT :
QUI EST AUTORISÉ À INVOQUER CETTE EXCEPTION ?
JE NE PENSE PAS QUE « TRANSFERT FORCÉ » SOIT AUTOMATIQUEMENT UNE FAIBLESSE.
POUR LES ACTIFS RÉGLEMENTÉS, NE PAS AVOIR DE VOIE DE RÉCUPÉRATION PEUT CRÉER UNE FAIBLESSE DIFFÉRENTE.
CE QUI COMPTE, C’EST À QUEL POINT L’EXCEPTION EST RESTREINTE.
LES UTILISATEURS PEUVENT-ILS VOIR QUAND CELA S’EST PRODUIT ?
PEUVENT-ILS SAVOIR QUELLE AUTORITÉ L’A DÉCLENCHÉ ?
LES CONDITIONS SONT-ELLES ASSEZ LIMITÉES POUR QUE UN REMÈDE JURIDIQUE EXCEPTIONNEL NE DEVIENNE PAS DISCRÈTEMENT UN CONTRÔLE ADMINISTRATIF ORDINAIRE ?
C’EST CELA QUE JE CHERCHERAIS À EXAMINER.
LE MODÈLE DE PROPRIÉTÉ LE PLUS FORT POUR LA FINANCE RÉGLEMENTÉE N’EST PEUT-ÊTRE PAS CELUI QUI REND LA PROPRIÉTÉ ABSOLUMENT IMMUTABLE.
CE POURRAIT ÊTRE CELUI OÙ LES EXCEPTIONS SONT RARES, VISIBLES ET ASSEZ RESPONSABLES POUR QUE TOUT LE MONDE SACHE OÙ RÉSIDE ENCORE LA CONFIANCE.

#dusk $DUSK @Dusk

$BOME $PNUT

AUJOURD’HUI 8H55, EN REGARDANT CE TABLEAU P2P, JE ME DIS QUE JE ME SUIS TROMPÉ 😅

Dans la rubrique Acheter USDT, la publicité placée tout en haut indique :

26.819đ/USDT.

Et juste en dessous, je vois :

25.934đ.
25.935đ.

Hein ?

Je remonte pour vérifier une nouvelle fois.

Pas d’erreur.

L’écart est d’environ 900đ pour chaque USDT.

Puis je passe à l’onglet Vendre pour voir, et je tombe sur l’inverse.

Publicité tout en haut :

25.037đ/USDT.

Juste en dessous :

25.911đ.
25.910đ.

Donc si on entre dans le P2P, qu’on voit d’abord la première annonce puis qu’on pense « en haut, le prix doit être le meilleur », et qu’on clique direct, on peut finalement acheter plus cher, et vendre beaucoup plus bas.

Même pour seulement 1.000 USDT : comme sur l’image, l’écart est déjà près de 900.000đ.

Ce qui m’a mis la puce à l’oreille, c’est que ces comptes ne ressemblent pas à de nouveaux comptes créés récemment.

Il y a des comptes avec des milliers d’ordres.
Le taux d’achèvement a l’air plutôt bon.

Du coup, à partir de maintenant, je ne regarderai plus uniquement le premier prix.

Quand j’ouvre le P2P, je regarde d’abord vers le bas, 3 à 4 publicités côte à côte.

Je regarde où se situe le niveau de prix.

Ensuite seulement je regarde le nombre d’ordres, le taux d’achèvement, la limite de montant et les conditions de transaction, puis je choisis.

Juste quelques secondes.

Le P2P ne nécessite pas forcément de tomber sur une arnaque pour perdre de l’argent.

Des fois, il suffit que je clique un peu trop vite : j’achète alors plus cher que la personne juste en dessous, ou je vends plus bas 😅

Ceux qui utilisent souvent le P2P : ouvrez la grille de prix et regardez-la attentivement une bonne fois.

Ne vous dites pas « l’annonce est en premier, donc je clique par réflexe » !!!

#binancep2pantoan @Binance Vietnam

$BOME $ETH $HYPE

J’ai vu 5 000 000 TMX attachés à la campagne TermMax RLUSD et je me suis surpris à faire la chose évidente :

essayer d’imaginer ce que valait mon XP.

Puis j’ai réalisé que je regardais le mauvais chiffre.

Le pool de 5M $TMX est fixe.

La valeur d’un XP, elle, ne l’est pas.

Si la récompense est distribuée proportionnellement à l’XP, la relation de base ressemble davantage à :

mon XP / total d’XP éligible × 5 000 000 TMX

Ce dénominateur change totalement la façon dont je perçois la campagne.

10 000 XP ne donnent pas automatiquement droit à une quantité fixe de $TMX.

C’est une part d’un pool, et la taille de cette part dépend de la quantité d’XP éligible qui existe chez tous les autres.

Ça peut sembler une nuance légère, mais pour les utilisateurs, elle compte énormément.

Le tableau de bord peut m’indiquer exactement combien de points j’ai gagnés.

Il peut m’indiquer que le pool de récompense contient 5M TMX.

Mais ces deux nombres visibles ne me disent toujours pas mon allocation finale, à moins que je connaisse aussi le dénominateur et les règles d’éligibilité finales.

En fait, j’aime le fait que @TermMax ait rendu visibles la progression et le pool de récompense avant le TGE.

Mais cela rend aussi le 25 août plus intéressant.

Le TGE n’est pas seulement le moment où $TMX commence à être négocié.

C’est aussi le moment où ces points abstraits de campagne doivent enfin commencer à se convertir en une allocation de token réelle, que les utilisateurs peuvent mesurer.

Donc pour l’instant, je surveille un nombre différent de celui d’avant.

Pas seulement mon XP.

Je veux savoir quel pourcentage de l’XP total éligible cela représente.

Cela pourrait me dire bien plus de choses sur le pool de 5M TMX que le chiffre du titre lui-même.

$TMX

#termmax @TermMax

$BTW
$ACE
$HEMI

LE VENDEUR NE POUVAIT TOUJOURS PAS VOIR LE PAIEMENT.

MAIS L’ACHETEUR AVAIT DÉJÀ OUVERT UN RECOURS.

C’est le genre de situation P2P qui peut vous perturber pendant une seconde.

L’acheteur dit que le paiement a été effectué.
Il y a maintenant un recours sur la commande.

Pendant ce temps, le vendeur ouvre l’application bancaire et ne parvient toujours pas à trouver un crédit correspondant.

À ce stade, il serait très facile de réagir au recours lui-même et de se dire :

« Attends… est-ce que j’ai raté quelque chose ? »

Mais une notification de recours ne fait pas apparaître l’argent sur le compte.

Alors le vendeur a vérifié à nouveau.

Historique bancaire.
Montant.
Heure.
La commande P2P active.

La conversation dans le chat de la commande.

Toujours aucun paiement correspondant qui s’affiche.

Au lieu de libérer la crypto juste parce que l’autre partie poussait le dossier, le vendeur a gardé la crypto en séquestre et a répondu via le recours avec les éléments dont il disposait réellement.

J’aime ce cas, parce que personne n’a besoin de deviner qui « ment » pendant les 30 premières secondes.

Peut-être qu’il y a un retard de paiement.
Peut-être qu’une information a été saisie incorrectement.
Peut-être qu’il faut davantage de preuves.

L’idée, c’est que le vendeur n’a pas essayé de lever l’incertitude en appuyant sur Libérer.

Quand deux parties regardent des versions totalement différentes de la même transaction, je préfère laisser la commande, le relevé bancaire et le processus de recours trier ce qui s’est réellement passé.

Si votre banque n’affichait toujours rien mais que l’acheteur avait déjà ouvert un recours, que vérifieriez-vous d’abord ?

#binancep2pantoan @Binance Vietnam

$BTW
$HEMI
$ACE

LE NOEUD DE SAUVEGARDE PEUT DEVENIR LA FAUTE.

Un avertissement dans la documentation du provisionneur de @Dusk m’a fait repenser ce que signifie « redondance » pour un valideur.

Dusk avertit explicitement les opérateurs de ne pas utiliser la même clé de consensus sur plusieurs nœuds actifs.

Au début, cela paraît étrange.

Pour une infrastructure normale, avoir deux machines prêtes à faire le même travail est exactement ce qui réduit les temps d’arrêt.

Mais une clé de consensus, c’est différent.

Si deux nœuds actifs utilisent la même identité et finissent par signer des propositions ou des votes contradictoires, la redondance elle-même peut devenir une equivocation.

Et Dusk traite cela très différemment du simple fait d’être hors ligne.

Cela m’a permis de faire une distinction que je n’avais pas clarifiée auparavant :

redondance d’infrastructure ≠ redondance de consensus.

Un provisionneur veut un nœud de secours suffisamment prêt pour prendre le relais rapidement.

Mais pas au point d’être si actif que les deux machines puissent parler en même temps pour la même identité de consensus.

Cela rend la conception du basculement bien plus intéressante que « lancez simplement un autre serveur ».

Il existe une ligne étroite entre :

un nœud tombe en panne → le nœud de sauvegarde prend le relais

et

deux nœuds pensent brièvement qu’ils sont le signataire actif.

Dans le second cas, le système de sécurité peut devenir la source du risque.

La documentation de Dusk classe les comportements contradictoires du consensus comme un type de faute pouvant mener à une pénalité sévère, y compris en brûlant une partie de la mise.

Ainsi, la métrique opérationnelle qui m’intéresserait n’est pas simplement la disponibilité du provisionneur.

Je voudrais savoir à quel point un opérateur peut basculer de machine en machine de manière fiable, sans jamais créer une clé de consensus active-active.

C’est une définition très différente de la haute disponibilité.

Le backup le plus sûr est peut-être celui qui est entièrement prêt à signer—

mais qui ne signe jamais tant que le premier nœud n’est pas définitivement hors service.

#dusk $DUSK @Dusk
$BTW
$HEMI

Hier, je regardais ce que @TermMax avait déjà construit avant le TGE du 25 août.

Aujourd’hui, je me suis retrouvé à poser une question différente :

Qu’est-ce qui change réellement une fois que $TMX existe ?

Un TGE peut ne pas être autre chose que le moment où un token devient négociable.

Mais pour TermMax, ça semble trop superficiel.

Le protocole gère déjà quelque chose de bien plus difficile que le simple lancement d’une pièce : des marchés à taux fixes multiples, des échéances différentes, des apporteurs de liquidité, des curateurs, des décisions de tarification et des utilisateurs qui ont tous besoin d’incitations pour maintenir le système en fonctionnement.

C’est là que $TMX devient plus intéressant pour moi.

La gouvernance et le staking sont les parties évidentes.

Mais l’idée plus profonde, c’est la coordination.

À mesure que TermMax grandit, quelqu’un doit encore décider comment le capital est alloué, quels marchés méritent de la liquidité, comment les incitations sont orientées et comment l’écosystème évolue.

Un protocole plus important n’a pas seulement besoin de plus d’utilisateurs.

Il a besoin d’une meilleure coordination entre les personnes qui fournissent le capital, créent des marchés et prennent des risques.

C’est pour ça que j’aime le timing de ce TGE.

TermMax n’a pas commencé avec un token et espéré qu’un système financier apparaisse autour de lui.

Le système financier est venu en premier.

Désormais, $TMX est introduit dans quelque chose qui a déjà besoin de coordination.

Si cela fonctionne, le 25 août voudra dire plus que l’ajout d’un autre actif négociable.

Ce pourrait être le moment où une partie de la couche opérationnelle de TermMax commence à être détenue économiquement et coordonnée par ses participants.

C’est la partie de ce TGE que je veux observer.

$TMX

#termmax @TermMax

Je pensais qu’une fois qu’une demande d’appel (Appeal) était ouverte, mon rôle était presque terminé.

En fait, pas du tout.

Il y a un détail dans le processus d’appel P2P de Binance auquel je n’avais jamais vraiment prêté attention.

Tant que l’appel est encore ouvert, les deux parties peuvent continuer à communiquer dans le chat de commande et essayer de trouver un accord par elles-mêmes.

Si cela ne fonctionne pas, l’affaire peut passer à l’examen par le Service Client (CS Review).

Mais ce que je trouve le plus important, c’est ceci :

Si une partie ne répond pas à l’appel ou ne fournit pas les informations demandées avant la date limite, le support Binance peut prendre une décision en se basant sur les preuves déjà disponibles.

Donc ouvrir un appel ne veut pas dire que je peux fermer l’application et oublier la transaction.

Dès qu’il y a un litige, je traite l’ID de commande, le chat de commande, les preuves de paiement et toute demande supplémentaire du Support comme un processus actif qui nécessite encore mon attention.

Si je suis le vendeur, je vérifie toujours mon propre compte bancaire avant de prendre toute décision de Libération (Release).

Si je suis l’acheteur, je conserve le relevé réel du paiement au lieu de me fier à un message indiquant que j’ai déjà payé.

Et une fois l’appel ouvert, je continue de vérifier l’application et l’e-mail pour ne pas manquer une demande d’informations supplémentaires ou une date limite.

Cela a changé ma façon de voir l’appel.

L’appel n’est pas un bouton qui transfère la responsabilité à Binance.

C’est le moment où la transaction entre dans un processus avec des preuves plus claires, des réponses et des échéances.

Dans un litige P2P, le silence ne signifie pas toujours qu’il ne se passe rien.

Parfois, cela veut dire que la décision devra être prise à partir de toutes les preuves déjà consignées.

#binancep2pantoan @Binance Vietnam

UNE PREUVE VALIDE NE GARANTIT PAS UNE DÉCISION D’ACCÈS VALIDE.

Un détail dans la conception de Citadel de @Dusk est facile à manquer.

Citadel peut vérifier une preuve à connaissance nulle et créer une session valide.

Mais après cela, le prestataire de services a encore du travail à faire.

Il reçoit les informations de session et doit décider si cette session doit réellement être acceptée selon ses propres règles.

Cela inclut notamment la date d’expiration, la révocation, et la question de savoir si la même session peut être réutilisée.

En réalité, il s’agit donc de deux contrôles différents qui se produisent :

la validité de la preuve ≠ la validité de l’accès.

La cryptographie peut être totalement correcte, tandis que la couche applicative prend encore la mauvaise décision.

C’est la partie que je trouve plus intéressante que de simplement dire « l’identité privée fonctionne ».

Imaginez qu’une session était valide au moment où elle a été créée, mais que l’autorisation sous-jacente a ensuite été révoquée.

La preuve elle-même n’est pas soudainement devenue mathématiquement invalide.

Ce qui compte, c’est de savoir si le prestataire de services vérifie correctement l’état actuel de la session avant d’accorder de nouveau l’accès.

Cela crée un chemin d’échec très spécifique.

Citadel peut résoudre le problème de la preuve, tandis qu’une gestion incohérente des sessions peut encore créer un problème applicatif au-dessus.

J’aime d’ailleurs que Dusk garde ces responsabilités séparées.

Un protocole doit prouver ce pour quoi il est conçu à prouver. Il ne doit pas décider silencieusement, pour chaque application, de sa politique d’autorisation.

Mais cela me donne aussi un indicateur plus clair à surveiller.

Pas simplement le nombre de preuves que Citadel vérifie.

Je veux savoir avec quelle régularité les applications gèrent l’expiration de session, la révocation et la réutilisation après qu’une preuve a déjà été acceptée.

Car l’échec intéressant n’est désormais plus une preuve cassée.

C’est une preuve correcte rattachée à la mauvaise décision d’accès.

#dusk $DUSK @Dusk

J’ai vu le 25 août dans l’annonce du TGE TermMax et j’ai presque cru qu’il s’agissait simplement d’une autre date de lancement de token.
Ensuite, je me suis tourné vers l’arrière plutôt que vers l’avant.
Cela a changé la façon dont je vois ce TGE.
Un lancement de token est facile à rendre excitant tant que tout ce qui l’entoure n’est encore qu’une promesse. Ce qui a attiré mon attention avec @TermMax , c’est l’ordre dans lequel les choses se sont produites.
Le produit est venu en premier.
Puis l’usage.
Puis la liquidité.
Et maintenant $TMX.
TermMax aborde le TGE avec 90M+ de TVL, 1,5M+ de portefeuilles enregistrés et 90K+ d’utilisateurs actifs quotidiens déjà présents au sein de l’écosystème.
J’aime beaucoup cet ordre.
Parce que si les gens utilisaient déjà le produit avant l’existence du token, $TMX n’a pas besoin de fabriquer la toute première raison pour laquelle TermMax compte.
La question la plus intéressante commence après le 25 août :
Est-ce que le token peut rendre un système déjà actif encore plus profond ?
Peut-il améliorer la coordination, les incitations et la participation autour d’une activité qui existe déjà ?
C’est pour cela que je prête plus d’attention à ce TGE que je ne le fais d’habitude.
La première bougie $TMX sera visible par tout le monde.
Ce que je veux observer, c’est si l’usage qui existait avant le token devient plus fort après son arrivée.
Pour moi, cela dirait bien plus de choses sur TermMax que le graphique du jour de lancement.
@TermMax $TMX #TermMax
$GPS $TUT

LA MÊME CONDITION P2P PEUT SE RESSENTIR TRÈS DIFFÉREMMENT AVANT ET APRÈS QUE L’ARGENT AILLE DÉPLACÉ.

C’est pourquoi je me suis mis à prêter attention non seulement à ce que disent les conditions, mais aussi au moment où une condition apparaît.

Avant que je paie, la situation est simple.

Je peux lire le mode de paiement, les exigences de vérification et les autres conditions de la commande Binance P2P.

Si elles ne me plaisent pas, je peux m’en aller avant d’engager de l’argent.

Mais une fois que la monnaie fiduciaire a déjà été transférée, l’équilibre change.

Si une nouvelle exigence matérielle apparaît soudainement après cela — une vérification supplémentaire, une condition de paiement différente, ou une autre étape qui n’était jamais incluse dans les conditions initiales — dire non n’est plus aussi facile.

Mon argent est déjà impliqué.

Cela ne rend pas automatiquement la nouvelle demande suspecte.

De vraies transactions P2P ont parfois besoin d’éclaircissements.

Mais je ne pense pas qu’une condition introduite après le paiement doive automatiquement hériter de la même confiance que quelque chose que j’aurais pu voir avant d’entrer dans la transaction.

Si cela se produit, je reviens à la commande active.

Je compare les conditions initiales et les détails de paiement, je garde la conversation dans Binance P2P, et j’évite de régler le changement via un accord privé précipité.

Si le problème reste flou, l’Order ID, l’historique de paiement et l’historique des échanges sont là pour l’Appel/le Support.

Pour moi, c’est la partie des conditions P2P qu’on sous-estime facilement.

Ils ne me disent pas seulement ce que la transaction attend.

Ils montrent aussi ce que les deux parties savaient avant qu’une des deux mette de l’argent à risque.

Donc, quand quelque chose d’important change à mi-parcours, la question que je me pose est très simple :

Est-ce que cette partie du contrat faisait déjà partie de l’accord avant que l’argent ne soit déplacé ?

#binancep2pantoan @Binance Vietnam

$GPS $ACE $PORTAL

L’EXÉCUTION CONFIDENTIELLE NE CRÉE PAS AUTOMATIQUEMENT UNE APPLICATION CONFIDENTIELLE.

C’est cette nuance que je continue de garder en tête avec @Dusk .

DuskEVM offre aux développeurs un environnement EVM familier, tandis que Hedger ajoute l’infrastructure nécessaire aux workflows confidentiels.

Cela résout un problème technique important.

Mais je pense que cela soulève une question de conception plus difficile :

Où la confidentialité doit-elle réellement résider à l’intérieur de l’application ?

Un développeur doit toujours décider quel état doit rester confidentiel, ce qu’un examinateur autorisé doit vérifier, ce qui peut être divulgué en toute sécurité, et comment ces choix se comportent lorsque l’application interagit avec autre chose.

Donc pour moi :

la capacité de confidentialité ≠ une bonne conception de la confidentialité.

Cela compte parce que, plus l’infrastructure de confidentialité sous-jacente devient puissante, plus il peut être facile de supposer que l’application qui se trouve au-dessus est automatiquement privée elle aussi.

Or ce n’est pas le cas.

Une politique de divulgation mal conçue peut encore exposer trop. Un workflow peut préserver la confidentialité des transactions tout en fuyant des métadonnées utiles ailleurs. Et des intégrations peuvent introduire des hypothèses que l’application d’origine n’avait jamais.

Ce n’est pas une faiblesse propre à Dusk. En fait, j’aime le fait que Dusk construise des outils pour un modèle beaucoup plus flexible que de rendre tout public ou tout caché.

Mais la flexibilité déplace une partie de la responsabilité vers la conception applicative.

La question que je surveillerais après l’expansion de DuskEVM n’est pas simplement le nombre de contrats déployés.

Je veux voir combien d’applications utilisent de façon répétée des workflows confidentiels d’une manière qui compte réellement, et si les développeurs peuvent le faire sans transformer la politique de confidentialité en une couche supplémentaire de complexité que les utilisateurs doivent faire confiance aveuglément.

Dusk peut fournir l’infrastructure de confidentialité.

Le véritable test, c’est de savoir si les concepteurs parviendront à transformer cette infrastructure en une confidentialité sur laquelle les utilisateurs puissent réellement compter.

#dusk $DUSK @Dusk

$HEMI
$CYS

LA CHOSE LA PLUS PRÉCIEUSE QUE L’ESCROW ME DONNE PEUT NE PAS ÊTRE PLUS DE TEMPS.

ELLE PEUT ÊTRE PLUS D’OPTIONS.

Quand je regarde une commande Binance P2P, la plupart des contrôles importants ont lieu avant une seule action : Libérer la crypto.

À ce stade, plusieurs choses peuvent encore se produire sans forcer la transaction vers un état final.

Je peux ouvrir mon application bancaire et vérifier si la monnaie fiduciaire est bien arrivée.

Je peux comparer les informations de l’expéditeur avec la commande.

Je peux relire le profil du commerçant et les conditions.

Si quelque chose paraît incohérent, les deux parties peuvent conserver la discussion dans le chat Binance P2P, préserver l’ID de la commande et les justificatifs de paiement, et utiliser Appel/Support si le problème ne peut pas être clarifié normalement.

Pendant cette période, le mécanisme d’escrow fait quelque chose de plus subtil que de simplement conserver la crypto.

Il préserve des options

Un décalage peut encore être vérifié.
Un malentendu peut encore être expliqué.
Les preuves peuvent encore être comparées.
La transaction peut rester non résolue pendant que les faits deviennent plus clairs.

Le moment de la Libération modifie cette structure.

Une fois que le vendeur libère volontairement la crypto, la question n’est plus seulement :

« Ce paiement est-il correct ? »

Elle peut devenir :

« Comment se remettre d’une décision qui a déjà été exécutée ? »

C’est un problème très différent.

Cela ne signifie pas que tout problème survenant après la Libération est impossible à résoudre. Binance P2P conserve toujours des enregistrements de transaction, l’historique du chat et un processus Support/Appel, et certains litiges peuvent encore être traités ensuite.

Donc je ne pense pas que la Libération soit une ligne magique après laquelle tous les recours disparaissent.

Le point, plus précisément, est le suivant :

Avant la Libération, l’escrow maintient davantage de solutions possibles sans renoncer d’abord à la crypto.

Après la Libération, une partie de cette flexibilité disparaît.

Cela change ma façon de penser la sécurité en P2P.

La sécurité ne consiste pas uniquement à ajouter davantage de contrôles.

Parfois, il s’agit de préserver la possibilité de choisir la prochaine étape appropriée tant que les faits ne sont pas suffisamment clairs pour en faire une décision irréversible.
#binancep2pantoan @Binance Vietnam
$CYS $HEMI $AIO

LA DIVULGATION SÉLECTIVE DÉTERMINE QUI PEUT VOIR LES DONNÉES. MAIS QUE SE PASSE-T-IL LORSQUE LES RÈGLES CHANGENT ?
C’est la partie du modèle de confidentialité de @Dusk que je trouve de plus en plus intéressante.
Dans la finance réglementée, la divulgation sélective a du sens intuitivement.
Un auditeur peut avoir besoin d’un ensemble d’informations.
Un régulateur peut en avoir besoin d’un autre.
Une contrepartie n’a peut-être besoin que d’une preuve qu’une condition a été satisfaite.
C’est bien plus pratique que de rendre tout public.
Mais je pense qu’il y a un second problème caché derrière le premier.
Les règles de confidentialité ne sont pas statiques.
Les réglementations changent. Les applications sont mises à niveau. De nouvelles exigences de divulgation apparaissent. Les institutions peuvent avoir besoin d’autorisations qui n’ont jamais été envisagées lorsque le contrat a été déployé pour la première fois.
Ainsi, pour moi, la question plus profonde n’est pas seulement :
Qui est autorisé à voir quoi aujourd’hui ?
C’est :
Que devient le modèle de confiance lorsque cette réponse doit changer demain ?
C’est là que Dusk devient plus intéressant qu’une simple histoire de « transactions privées ».
La confidentialité programmable signifie que la confidentialité et la divulgation autorisée peuvent devenir une partie de la logique même de l’application. C’est puissant, car les marchés réglementés ont précisément besoin de ce type de flexibilité.
Mais la flexibilité crée aussi une responsabilité.
Si la logique liée à la confidentialité peut évoluer, je veux comprendre comment ces changements sont autorisés, à quel point ils sont visibles pour les utilisateurs, et si une mise à niveau peut introduire des hypothèses qui n’étaient pas présentes au moment où une institution s’est appuyée sur l’application.
Ce n’est pas une critique de l’orientation. Au contraire, je pense que cela montre pourquoi Dusk s’attaque à un problème bien plus difficile que de masquer des données de transaction.
L’infrastructure doit préserver la confidentialité et rendre ces changements dans le modèle de confidentialité dignes de confiance.
Ce que j’observerais au fil du temps n’est pas seulement la quantité d’informations que Dusk peut garder privées.
Je surveillerais si les applications peuvent faire évoluer leurs règles de divulgation sans modifier silencieusement qui les utilisateurs doivent finalement avoir confiance.
Pour la finance réglementée, il s’agit peut-être du problème de confidentialité le plus difficile.

#dusk $DUSK @Dusk

$ACE $AKE

LE PAIEMENT ÉTAIT RÉEL.
LE REÇU ÉTAIT RÉEL.
JE NE LÂCHERAIS POURTANT PAS LA COMMANDE.
Voici le genre de situation P2P qui peut sembler totalement propre au premier abord.
Un vendeur a deux commandes USDT ouvertes à peu près au même moment.
La commande A attend un paiement.
La commande B est également active.
Puis un acheteur envoie un virement bancaire et publie le reçu dans le chat Binance P2P.
Rien ne paraît faux.
L’argent est vraiment arrivé sur le compte bancaire du vendeur.
Le reçu provient vraiment d’un virement réussi.
Même le montant semblait raisonnable.
Il serait très facile de penser :
« Paiement confirmé. Libérer. »
Mais avant de toucher à la libération, il reste une question :
À quelle commande ce paiement appartient-il réellement ?
C’est là que la situation change.
Quand le vendeur compare le payeur, le montant, l’ID de commande et les deux commandes actives, les lignes du paiement correspondent à l’autre transaction.
Le paiement est réel.
La preuve est réelle.
Mais ensemble, ils sont utilisés pour faire passer la mauvaise commande pour payée.
Alors le vendeur s’arrête.
Pas d’hypothèses.
Pas de libération d’abord et de tri ensuite.
Les deux conversations restent dans Binance P2P. Le vendeur garde ensemble les deux ID de commande, la transaction bancaire et l’historique du chat, tandis que la crypto reste protégée par le processus de commande.
Si l’attribution ne peut toujours pas être résolue clairement, c’est justement à quoi servent Appel/Support.
Ce que je trouve intéressant dans ce type de cas, c’est que la question « faux vs réel » n’est pas toujours la plus difficile dans le P2P.
Parfois, chaque élément de preuve peut être authentique.
L’erreur consiste à supposer que ces éléments appartiennent à la même transaction.
Avant de libérer, je préférerais répondre à une question en plus :
Non seulement « L’argent est-il arrivé ? »
Mais :
« À quelle commande exacte cet argent a-t-il réglé ? »
@Binance Vietnam #BinanceP2PAnToan