VAULT ET TRÉSORERIE
Quatre adresses de contrat, quatre soldes, quatre jeux de règles pour les déplacer. Le collatéral utilisateur, la trésorerie d'exploitation qui détient les revenus de frais, la réserve d'assurance qui absorbe les résiduels de liquidation et le débordement de mauvaise dette, et le pool de récompenses qui finance le cash du classement vivent tous dans des contrats distincts sur Base, avec des politiques de signataires distinctes et des pistes comptables distinctes. Aucun ne peut être vidé pour en réapprovisionner un autre. Cette séparation est la raison structurelle pour laquelle le pipeline de paiement de Dexter est crédible — votre retrait de partage des bénéfices 90 / 10 ne dépend pas de la solvabilité du wallet d'exploitation, la grille des prix de la saison ne dépend pas du collatéral utilisateur, et une chaîne de liquidations ne peut pas retarder un retrait légitime parce que la perte tire sur l'assurance, pas sur la même adresse où se trouvent vos USDC.
Les quatre soldes répondent à quatre questions différentes et se déplacent sous quatre jeux de permissions différents. Le tableau est la disposition des contrats, pas une abstraction marketing — chaque ligne est une adresse déployée sur Base avec sa propre politique de signataires et sa propre piste comptable.
| Vault | Ce qu'il contient | Comment il est censé bouger |
|---|---|---|
| Vault de collatéral utilisateur | Dépôts USDC, marge ouverte, demandes de retrait en attente et piste de nonce par compte | Libéré uniquement contre une racine d'état publiée et une preuve de Merkle correspondante ; aucune clé d'opérateur ne peut contourner la porte de preuve |
| Trésorerie d'exploitation | Revenus de frais accumulés depuis l'activité de trading et fonds de roulement détenus par le protocole | Les sorties au-dessus de 10 000 $ exigent un multi-sig 2-sur-3 ; les destinataires sont gouvernés et visibles sur Basescan |
| Réserve d'assurance | La part de 50 % du résiduel de liquidation, plus tout tampon initial pour les conditions stressées | Les tirages exigent un multi-sig 3-sur-5 incluant un signataire externe ; chaque ajustement est explicitement bucketé |
| Pool de récompenses | Cash du classement de la saison et grilles de prix postées, financés avant l'ouverture de la saison | Libéré contre la grille publiée à la clôture de la saison ; les finishes du podium (top 3) sont revues avant que le batch ne quitte la trésorerie |
#Garde, règlement et soldes protocolaires
Le collatéral utilisateur est détenu dans le contrat vault dédié sur Base. Les dépôts, les demandes de retrait, la piste de nonce par compte et l'étape de finalisation qui libère les USDC vers le wallet passent tous par la logique du contrat — jamais par le runtime seul. Le runtime est assez rapide pour coordonner le matching et le risque en temps réel, mais il ne peut pas réécrire les résultats de garde, parce que chaque libération est conditionnée par une preuve de Merkle contre une racine d'état que le contrat du vault a déjà acceptée. Le flux complet demande-à-libération est documenté sur Règlement et retraits ; ce qui compte ici, c'est que le runtime et le vault sont délibérément découplés.
Le vault stocke plus que des soldes de tokens. Il stocke aussi les références de règlement qui décrivent ce que le runtime croyait quand chaque mise à jour d'état a été scellée : la racine d'état active, l'identifiant de racine, le timestamp de publication, la version de schéma, le commit de séquence, le hash de source oracle de la couche de prix et le commit de batch d'ordres. L'historique des racines est conservé on-chain pour que toute transaction de règlement puisse être reliée à un état d'échange publié spécifique — pas à une affirmation vague que l'opérateur dit que le ledger a changé.
Les trois autres adresses de vault vivent en parallèle, avec leurs propres politiques de permission et leurs propres buckets comptables. La trésorerie d'exploitation détient les revenus de frais issus de l'activité de trading. La réserve d'assurance détient la part de 50 % du résiduel de liquidation plus tout tampon initial utilisé pour absorber les résultats stressés — les autres 50 % de chaque résiduel de liquidation vont au keeper qui a déclenché la routine. Le pool de récompenses détient le cash posté du classement pour la saison active, financé avant l'ouverture de la saison pour que la grille ne puisse pas être réduite silencieusement en milieu de saison. Aucun de ces soldes n'est de la marge utilisateur, et aucun ne se libère sous les règles de retrait utilisateur.
#Pourquoi garde et valeur protocole restent séparées
Cette architecture ne prétend pas que le vault est impossible à attaquer — aucune plateforme sérieuse ne devrait promettre cela. Elle rend tout compromis unique moins puissant qu'un compromis de l'ensemble du système. Une défaillance du runtime ne peut pas déplacer le collatéral utilisateur, parce que le vault ne libère que contre une preuve correspondant à une racine déjà acceptée. Un compromis de signataire sur la trésorerie d'exploitation ne peut pas payer le pool de récompenses, parce que le pool de récompenses est un contrat différent avec un ensemble de signataires différent. Un pic de liquidations sur un seul compte financé ne peut pas vider la trésorerie d'exploitation, parce que la perte tire de l'assurance sous un bucket comptable séparé.
La politique de permission est explicite à chaque couche. Les sorties de trésorerie d'exploitation au-dessus de 10 000 $ exigent un multi-sig 2-sur-3 du groupe opérations. Les tirages de réserve d'assurance exigent un multi-sig 3-sur-5 qui doit inclure un signataire externe hors du groupe opérations, pour qu'un quorum d'initiés seul ne puisse pas épuiser la réserve. Les actions de gouvernance — changements de paramètres, mises à niveau de contrat, changements de destinataires — s'exécutent sous la même exigence 3-sur-5 avec signataire externe. Les flags de pause et la logique de garde-racine donnent à la couche contrat un moyen de figer les libérations pendant qu'un litige ou un incident est enquêté, sans que ces flags permettent aussi un mouvement unilatéral.
Le résultat est une disposition qu'un reviewer peut lire en trois questions : où est l'argent utilisateur (le vault de collatéral, libéré par preuve), qu'est-ce qui appartient au protocole (trésorerie d'exploitation et réserve d'assurance, avec leurs propres politiques de signataires), et qu'est-ce qui doit être vrai avant que tout solde ne bouge (les règles on-chain listées ci-dessus). Aucune partie de la réponse n'exige de faire confiance à la parole de l'opérateur.
#Comment cela protège vos paiements
- Votre collatéral ne peut pas financer le paiement de quelqu'un d'autre. Le vault de collatéral utilisateur libère des USDC uniquement contre une racine d'état publiée et une preuve de Merkle correspondante. La trésorerie d'exploitation ne peut pas y puiser pour couvrir une grille de classement, un batch de cash de parrainage ou un manque d'assurance. L'UI du cashier affiche l'identifiant de racine et la preuve au moment de la finalisation ; vous pouvez vérifier vous-même la libération on-chain contre la même racine sur Basescan.
- L'assurance est un contrat séparé avec sa propre politique de signataires. Chaque résiduel de liquidation est partagé 50 % au keeper qui l'a déclenché, 50 % à l'assurance. Le débordement de mauvaise dette d'un compte financé défaillant tire sur l'assurance, pas sur la trésorerie d'exploitation et pas sur le collatéral utilisateur — c'est pourquoi une chaîne de liquidations ne ralentit pas les retraits légitimes. Les tirages d'assurance eux-mêmes exigent un multi-sig 3-sur-5 incluant un signataire externe.
- Le pool de récompenses est financé à l'ouverture de saison, pas à la clôture. Le cash du classement pour la saison active est déplacé dans le contrat pool-de-récompenses dédié avant l'ouverture de la saison. Les grilles publiées (X $ pour le n°1, Y $ pour les n°2–3, etc.) ne peuvent pas être silencieusement réduites en milieu de saison parce que le cash n'est plus dans le wallet d'exploitation. Les finishes du podium (top 3) sont revues avant que la transaction batch de clôture de saison ne quitte la trésorerie ; les retraits uniques au-dessus de 5 000 $ déclenchent la même revue de haute valeur.
- Le multi-sig porte chaque mouvement côté protocole. Les sorties de trésorerie d'exploitation au-dessus de 10 000 $ exigent un 2-sur-3 ; les tirages de réserve d'assurance et les actions de gouvernance exigent un 3-sur-5 avec un signataire externe. Chaque transaction est postée sur Base, donc un mouvement soudain hors de l'un des quatre vaults est visible pour quiconque surveille l'adresse.
Chaque adresse de vault est publiée sur la page des contrôles de sécurité et peut être épinglée à une watchlist Basescan. Si le total « Verified Rewards » du classement de dexter.market diverge un jour de la somme des transactions sortant de l'adresse du pool de récompenses, le registre on-chain l'emporte — et vous verrez la divergence avant qu'on ne vous en parle. Les mécaniques de règlement qui libèrent le collatéral utilisateur sont documentées sur Règlement et retraits ; les flux comptables pour les frais et l'assurance sont documentés sur Trésorerie et comptabilité.