Le règlement des transferts ne signifie pas que le cycle de vie peut s’exécuter de lui-même. @Dusk Les chiffres affichés sur le site officiel, à savoir « 210 M+ DUSK mis en gage, ~10 s pour une clôture déterministe SBA, une confirmation du volume d’émission de 300 M€ côté NPEX, et XSC qui compresse la liste des investisseurs éligibles dans la racine d’un Sparse Merkle-Segment Trie de Zedger — prouvent que le « lancement du jour 1 » tient. Elles ne prouvent pas que le « troisième anniversaire/année d’émission supplémentaire » tient.
Regardons l’émission supplémentaire en détail : à quelle slot le jour du snapshot lie-t-on ? Le droit préférentiel d’achat est-il calculé à partir de quelle partie du shareholder register de XSC (solde shieldé) ? Les parts des abstentionnistes retournent-elles au pool ou sont-elles annulées, et quel signataire déclenche l’exécution ? Côté trésorerie, utilise-t-on EURQ de Quantoz ou un canal fiduciaire ; l’encaissement et la livraison des actions sont-ils réglés atomiquement dans la même manche SBA ? Le livre blanc v3 donne la base cryptographique de Phoenix/Zedger/Rusk VM, mais la machine à états des corporate actions laisse un vide : la norme XSC dit seulement que « le lifecycle management est programmable », sans écrire pour l’émetteur les fonctions de l’émission supplémentaire.
Ainsi, en période de marché calme, tout le monde s’échange l’affiche : « 300 M€ d’RWA mises en chaîne ». Une fois l’affiche échangée, l’avocat de l’émetteur prend la parole : pour le prochain tour, comment calculer la décote/la conversion en actions dans une fusion, et la priorité de liquidation sous ZK ? La réponse relève de l’infrastructure ; la réponse ne fait pas office de vitrine. La vitrine, la première année, est nourrie par des communiqués ; la deuxième année, le budget est coupé — et au moment où l’on coupe, sur X on continue de tourner la publication de lancement ; la repost ne sauve pas le TCO.
#dusk L’identité à reconnaître est « l’environnement dans lequel un événement peut être exécuté de manière déterministe », pas « l’événement lui-même ». L’environnement apporte : une clôture ~10 s, une livraison vs paiement (delivery-versus-payment) prête, et une divulgation sélective de la view key à l’AFM. Mais qui a le droit, en quelle proportion, que faire des abstentionnistes — tout cela doit encore être encodé dans l’extension XSC des conditions, avec une identité eIDAS liée via Citadel, et le règlement via DuskDS avec EURQ. Si cette couche n’est pas comblée, l’émission « native » n’est qu’un demi-système : on peut faire une démo de la tarification, mais pas la liquidation de la huitième année.
Je prends l’émission supplémentaire comme pierre de touche, pas comme un simple pinaillage. Un système à moitié fait peut tromper la section commentaires en période de marché haussier ; il ne trompe pas la legal team de NPEX. Avant que la legal team ne signe, $DUSK ne te donnera pas le droit de souscription : il ne garantit qu’une chose — au cas où quelqu’un écrirait l’émission supplémentaire dans XSC, cette exécution ne pourra pas être annulée (rollback).
Regardons l’émission supplémentaire en détail : à quelle slot le jour du snapshot lie-t-on ? Le droit préférentiel d’achat est-il calculé à partir de quelle partie du shareholder register de XSC (solde shieldé) ? Les parts des abstentionnistes retournent-elles au pool ou sont-elles annulées, et quel signataire déclenche l’exécution ? Côté trésorerie, utilise-t-on EURQ de Quantoz ou un canal fiduciaire ; l’encaissement et la livraison des actions sont-ils réglés atomiquement dans la même manche SBA ? Le livre blanc v3 donne la base cryptographique de Phoenix/Zedger/Rusk VM, mais la machine à états des corporate actions laisse un vide : la norme XSC dit seulement que « le lifecycle management est programmable », sans écrire pour l’émetteur les fonctions de l’émission supplémentaire.
Ainsi, en période de marché calme, tout le monde s’échange l’affiche : « 300 M€ d’RWA mises en chaîne ». Une fois l’affiche échangée, l’avocat de l’émetteur prend la parole : pour le prochain tour, comment calculer la décote/la conversion en actions dans une fusion, et la priorité de liquidation sous ZK ? La réponse relève de l’infrastructure ; la réponse ne fait pas office de vitrine. La vitrine, la première année, est nourrie par des communiqués ; la deuxième année, le budget est coupé — et au moment où l’on coupe, sur X on continue de tourner la publication de lancement ; la repost ne sauve pas le TCO.
#dusk L’identité à reconnaître est « l’environnement dans lequel un événement peut être exécuté de manière déterministe », pas « l’événement lui-même ». L’environnement apporte : une clôture ~10 s, une livraison vs paiement (delivery-versus-payment) prête, et une divulgation sélective de la view key à l’AFM. Mais qui a le droit, en quelle proportion, que faire des abstentionnistes — tout cela doit encore être encodé dans l’extension XSC des conditions, avec une identité eIDAS liée via Citadel, et le règlement via DuskDS avec EURQ. Si cette couche n’est pas comblée, l’émission « native » n’est qu’un demi-système : on peut faire une démo de la tarification, mais pas la liquidation de la huitième année.
Je prends l’émission supplémentaire comme pierre de touche, pas comme un simple pinaillage. Un système à moitié fait peut tromper la section commentaires en période de marché haussier ; il ne trompe pas la legal team de NPEX. Avant que la legal team ne signe, $DUSK ne te donnera pas le droit de souscription : il ne garantit qu’une chose — au cas où quelqu’un écrirait l’émission supplémentaire dans XSC, cette exécution ne pourra pas être annulée (rollback).