RACINES D'ÉTAT, RETRAITS ET FLUX DE RÈGLEMENT

Chaque racine d'état que le vault accepte est plus qu'un instantané de soldes. Cinq références voyagent avec elle, pour qu'un seul commit de racine lie non seulement la valeur de chaque compte mais tout le contexte sous lequel le runtime opérait quand l'instantané a été scellé. Un reviewer lisant le contrat plus tard peut reconstruire la configuration exacte qui a produit n'importe quel paiement donné.

#Comment le règlement fonctionne réellement

Le contrat du vault conserve la racine active, l'identifiant de racine et les commits environnants pour que le côté contrat porte un registre explicite et interrogeable de chaque état d'échange publié. Le règlement n'est donc jamais résolu contre ce que le runtime croit à la dernière seconde — il est résolu contre un état commit qui peut être référencé depuis la chaîne, contesté on-chain et prouvé on-chain. Le runtime est rapide ; le vault est final.

Les retraits sont basés sur la demande et suivis par nonce. L'utilisateur signe une demande de retrait on-chain, ce qui mint un nonce de compte que le contrat suit. Le runtime prend cette demande dans le prochain cycle de publication, l'inclut à l'intérieur de l'instantané qui produit la prochaine racine d'état, et poste la racine avec les cinq références liées listées ci-dessus. L'utilisateur (ou tout wallet agissant en son nom) appelle ensuite l'étape de finalisation avec la feuille de Merkle, le chemin de preuve et le nonce correspondant ; le contrat du vault vérifie la preuve contre la racine commit, confirme que le nonce est à jour, vérifie que la fenêtre de preuve s'est écoulée, et libère les USDC.

C'est matériellement différent d'un modèle où un opérateur décide quand les fonds partent. Le runtime ne peut pas libérer des fonds qu'il a échoué à sceller dans une racine. Le vault ne peut pas libérer contre une racine qui n'a pas passé sa fenêtre de preuve. Un opérateur avec les clés complètes du runtime ne peut toujours pas pousser un paiement à travers sans produire un état commit cohérent plus une preuve correspondante. Cette superposition — demande, commit de racine, fenêtre de preuve, libération de contrat — est ce qui rend le chemin de paiement on-chain défendable sans faire confiance à un seul acteur.

 requestWithdraw(amount)
   -> un nonce de compte on-chain est créé
   -> le runtime inclut la demande dans le prochain instantané
   -> racine d'état + 4 commits liés publiés sur Base
   -> la fenêtre de preuve s'ouvre (période de contestation)
   -> l'utilisateur reçoit les données de feuille et la preuve de Merkle du runtime
   -> finalizeWithdraw(leaf, proof, nonce)
        -> le vault vérifie la preuve contre la racine commit
        -> le vault vérifie que le nonce correspond à l'état du compte
        -> le vault confirme que la fenêtre de preuve s'est écoulée
        -> USDC libérés vers le wallet sur Base

#Preuves, contestations et gestion des défaillances

Les preuves comptent parce que le vault n'est pas conçu pour faire confiance aveuglément aux revendications du runtime. Entre la publication de la racine et la finalisation, une fenêtre de preuve s'ouvre durant laquelle toute partie peut contester une racine douteuse ou une transition de règlement malformée. L'historique des racines est conservé on-chain pour qu'une contestation puisse référencer un commit spécifique par identifiant, pas seulement une vague accusation. Les contrôles de gardien et les flags de pause peuvent geler d'autres libérations contre une racine en litige. Les hooks de vérificateur de fraude et la logique de garde-racine existent pour rendre une mauvaise mise à jour d'état visible et contestable avant que la valeur ne parte — pas seulement pour la logger après coup.

Cela ne justifie pas de prétendre que le système est inhackable. Aucune plateforme sérieuse ne devrait faire cette promesse. Cela justifie de dire que Dexter est conçu pour qu'un retrait réussi exige quatre hypothèses qui tiennent simultanément : le runtime doit publier un état cohérent, le contrat du vault doit accepter la racine correspondante, le nonce de demande doit correspondre à l'état du compte on-chain de l'utilisateur, et le chemin de preuve doit vérifier contre la racine commit. Un compromis d'une seule couche en isolation ne produit pas un paiement non autorisé. C'est le modèle de règlement en couches — moins de points de défaillance uniques, plus d'endroits où un litige peut intercepter un mauvais résultat.

#Timeline de paiement à laquelle s'attendre

• Retrait de partage des bénéfices (compte financé, partage 90 / 10). Demande depuis le cashier dans l'app contre votre équité financée. Si le KYC est déjà validé sur le wallet, la cible est moins de 24 heures de la demande à l'arrivée des USDC sur Base — la demande entre dans le prochain cycle de publication, la racine se publie, la fenêtre de preuve s'écoule, l'étape de finalisation libère. Le premier retrait de partage des bénéfices déclenche le KYC s'il n'a pas encore été complété ; prévoyez 1 à 2 jours supplémentaires la première fois.
• Cash du classement. Posté à la clôture de saison depuis le contrat pool-de-récompenses dédié, payé en une seule transaction batch par grille. Les wallets qui ont déjà validé le KYC pour un retrait de partage des bénéfices ne revérifient pas. Les finishes du podium (top 3) sont revues avant que le batch ne quitte la trésorerie — chaque saison, sans exception — pour qu'un exploit du classement ne puisse pas contourner la revue opérations en se classant n°1.
• Cash de parrainage. Payé mensuellement en batch le premier jour ouvré du mois, ancré au wallet amont. Chaque transfert porte l'identifiant de paiement du filleul et le hash de tx Basescan, pour que le lien entre un événement d'attribution et les USDC qui ont atterri dans votre wallet soit auditable de bout en bout.
• Retraits de haute valeur (5 000 $+). Toute demande unique au-dessus de 5 000 $ est revue par les opérations avant l'ouverture de la fenêtre de preuve. Cela ajoute quelques heures mais ne change pas le chemin de règlement on-chain — la preuve, la référence de racine et la libération du contrat sont identiques.

La conception conditionnée par preuves a une conséquence importante : même avec un accès complet au cashier et au runtime, les opérations ne peuvent pas pousser un paiement à travers qui n'a pas une référence de racine valide et une preuve de Merkle correspondante. L'UI du cashier expose l'identifiant de racine publié et la preuve au moment de la finalisation ; vous pouvez coller l'un ou l'autre dans un appel read Basescan et vérifier vous-même la libération on-chain contre la même racine. Si le total de grille publié sur dexter.market diverge de la somme des transactions sortant de l'adresse pool-de-récompenses, le registre on-chain est la vérité et le dashboard a tort — pas l'inverse. La comptabilité du vault (comment les frais, les tirages d'assurance et le financement du pool de récompenses bougent) est documentée sur Trésorerie et comptabilité.