PREUVES DE RETRAIT, LITIGES ET CONTESTATIONS DE RACINE
Chaque paiement USDC — partage des bénéfices de challenge, prix du classement, commission de parrainage — quitte le vault contre une preuve cryptographique qui lie le wallet de l'utilisateur, le solde dû, le nonce et une racine de règlement publiée commit sur Base. Si la preuve de Merkle ne reconstruit pas contre la racine stockée, finalizeWithdraw revert. Cette page parcourt le cycle de vie de la demande en quatre étapes, les trois méthodes de contestation qui permettent à tout membre de la communauté de contester une mauvaise racine avant que les USDC ne bougent, et le chemin de récupération exact si un retrait reste dans la fenêtre de preuve plus longtemps que la cible de 24 heures.
Sept primitives de contrat composent la sortie basée sur preuves. Les quatre premières sont requises pour chaque retrait ; les trois dernières sont disponibles pour toute adresse ayant qualité pour contester une racine publiée.
| Mécanisme | Ce qu'il fait |
|---|---|
| requestWithdraw(amount) | Émet un nonce on-chain qui lie le wallet de l'utilisateur, le montant et le timestamp à une intention de retrait spécifique — pas de nonce, pas de chemin de sortie |
| Historique des racines d'état | Ring append-only des racines de règlement récentes ; finalizeWithdraw doit référencer une racine encore dans cet historique, ce qui rend le remplacement silencieux détectable |
| Preuve de Merkle + feuille | Données de feuille côté utilisateur (wallet, solde, liste de nonces) plus le chemin frère qui reconstruit la racine référencée — l'échec de reconstruction revert l'appel |
| disputeWindowSec | Fenêtre de contestation configurable entre le commit de racine et le finalizeWithdraw le plus tôt ; calée pour équilibrer paiements rapides et temps de contestation |
| challengeRootFraudProof | Soumet une sortie de vérificateur de fraude prouvant que le runtime a commit une racine incohérente avec des transitions d'état valides |
| challengeRootInvalidLeaf | Soumet une contre-feuille montrant qu'un solde de compte spécifique dans l'arbre publié contredit ce que le runtime doit |
| challengeRootConflict | Soumet deux racines dont les numéros de parent ou de séquence déclarés se contredisent, exposant un fork d'historique |
#Le chemin de retrait est conditionné par preuve
L'utilisateur commence par appeler requestWithdraw avec le montant d'USDC qu'il veut sortir. Le contrat émet un nonce qui lie la demande au wallet de l'utilisateur, au montant et au timestamp du bloc. Ce nonce est la seule chose sur laquelle le runtime est autorisé à agir — un paiement initié par le runtime vers un wallet qui n'a jamais appelé requestWithdraw ne peut pas passer finalizeWithdraw parce qu'aucun nonce correspondant n'existe dans la feuille de Merkle.
Le runtime inclut ensuite la demande dans le prochain état de règlement. Quand cet état est commit sur Base, la nouvelle racine entre dans le ring d'historique append-only et disputeWindowSec commence. La passerelle expose les données de feuille de l'utilisateur et le chemin frère nécessaire à reconstruire la racine, pour que l'utilisateur (ou tout client en qui il a confiance) puisse vérifier la preuve hors-chaîne avant de la soumettre. Une fois disputeWindowSec écoulé sans contestation réussie, finalizeWithdraw est appelable : le contrat ré-exécute la reconstruction de Merkle on-chain contre la racine référencée, vérifie que le nonce correspond et n'a pas été consommé, vérifie que la racine est toujours dans l'historique, et ce n'est qu'alors qu'il transfère les USDC vers le wallet de l'utilisateur.
Si un retrait reste au-delà de la cible de 24 heures, la défaillance est observable. Soit disputeWindowSec est encore ouvert (visible sur le contrat), soit la racine n'a pas encore été commit (visible sur Basescan comme l'absence d'une transaction commitSettlement depuis requestWithdraw), soit la file de revue manuelle a flaggé le paiement pour vérification top trois du podium ou au-dessus de 5 000 $. Dans tous les cas, la demande reste en file et finalisable dès que la condition de porte se lève — rien n'expire.
requestWithdraw(amount)
-> le nonce on-chain lie wallet + montant + timestamp
-> le runtime inclut la demande dans la prochaine racine de règlement
-> commitSettlement(root) poste sur Base, entre dans le ring d'historique
-> disputeWindowSec commence
-> la passerelle expose feuille + chemin frère pour vérification hors-chaîne
-> disputeWindowSec s'écoule sans contestation réussie
-> finalizeWithdraw(nonce, leaf, proof, rootRef) libère les USDC#Pourquoi les contestations et preuves de fraude existent
La publication n'est pas la même chose que la correction. La fenêtre de litige existe pour que quiconque peut construire un contre-exemple ait qualité pour arrêter une mauvaise racine avant que les USDC ne bougent contre elle. Trois chemins de contestation couvrent les trois modes de défaillance qu'un runtime malveillant ou bogué pourrait introduire. challengeRootFraudProof cible le cas où la racine publiée n'aurait pas pu être produite par des transitions d'état valides — le hook vérificateur de fraude exécute l'étape disputée on-chain et rejette la racine si sa sortie diverge. challengeRootInvalidLeaf cible le cas où une feuille de compte spécifique annonce mal un solde que le runtime est censé devoir ; le contestataire soumet la contre-feuille et le contrat compare les signatures et les soldes accumulés. challengeRootConflict cible les forks d'historique : deux racines commit dont les références de parent ou les numéros de séquence se contredisent sont mutuellement exclusives et le contrat invalide le commit le plus tardif.
Une contestation réussie invalide la racine disputée, fige tout retrait qui l'a référencée, et force le runtime à recalculer et recommit depuis le dernier état connu-bon. Une contestation échouée consume le bond posté du contestataire et laisse la racine en place. L'asymétrie économique — perte du bond pour les fausses alarmes, prévention d'impact à l'échelle du vault pour les alarmes correctes — est délibérée. Elle récompense la discipline de soumettre des contre-exemples reproductibles plutôt que des plaintes spéculatives, tout en gardant le chemin de contestation ouvert à toute adresse qui peut en produire un.
C'est pourquoi un retrait Dexter ne repose pas sur la confiance au runtime en isolation. Il repose sur une racine commit, une preuve vérifiable, un historique qui ne peut pas être réécrit silencieusement, une fenêtre dans laquelle toute tierce partie peut contester, et un vault multi-sig qui poste chaque finalisation sur Base.