TRÉSORERIE, ASSURANCE ET COMPTABILITÉ DES REVENUS
Où va l'argent après que Dexter a collecté vos frais de trade, comment la réserve d'assurance est alimentée par le partage 50 % du résiduel de liquidation, d'où vient le financement du pool de récompenses de la saison, et comment les pertes de mauvaise dette sont absorbées sont quatre flux comptables séparés — gardés séparés par conception pour qu'un prix du classement, un retrait de partage des bénéfices d'un trader financé, un tirage d'assurance et une action de trésorerie n'interfèrent jamais entre eux. Le runtime garde ces totaux en précision USD18 ; un réconciliateur pousse les deltas on-chain pour que les quatre contrats vault sur Base restent alignés avec l'activité d'échange sans recalculer le ledger complet à chaque bloc. Ci-dessous, exactement comment chaque solde bouge et quels contrôles le portent.
| Bucket de solde | Rôle à l'intérieur du protocole |
|---|---|
| feesAccrued | Revenu du protocole depuis les frais maker/taker, le spread de financement et l'entrée des packs de challenge ; atterrit dans le contrat de trésorerie d'exploitation sur Base |
| insuranceReserve | 50 % de chaque résiduel de liquidation plus tout tampon initial ; absorbe le débordement de mauvaise dette et les résultats stressés sans toucher au collatéral utilisateur ni à la trésorerie d'exploitation |
| rewardPool | Financé à l'ouverture de saison depuis la trésorerie d'exploitation vers le contrat pool-de-récompenses dédié ; soutient les grilles publiées du classement pour la saison active |
| Soldes côté revenus | Surface comptable liée à la participation pour les détenteurs de DIP et les bénéficiaires de partage des revenus ; superposée sur la comptabilité frais/assurance, jamais sur le collatéral utilisateur |
#Comment la valeur détenue par le protocole est gérée
Les frais de trading, le spread de financement et les revenus d'entrée des packs de challenge (packs 49 $ / 99 $ / 199 $ / 299 $) s'accumulent dans la comptabilité détenue par le protocole dès le moment où ils sont collectés — ils ne reposent jamais à l'intérieur du vault de collatéral utilisateur et ne sont jamais touchés par la logique de retrait utilisateur. Le runtime suit les totaux de frais et d'assurance en précision USD18 dans son propre modèle comptable ; un réconciliateur snapshote les deltas et pousse uniquement ces deltas on-chain via vaultAddFees, vaultAddInsurance et vaultSubInsurance. Les contrats vault n'essaient donc jamais de recalculer le ledger d'échange complet ; ils enregistrent les soldes détenus par le protocole qui comptent pour le règlement, la gouvernance et la couverture de la réserve.
L'assurance et la trésorerie ne sont délibérément pas regroupées dans un chiffre unique « réserve du protocole ». Le capital d'assurance existe pour un travail spécifique : absorber le stress des comptes financés défaillants, le débordement de mauvaise dette des liquidations violentes, et le résiduel post-liquidation quand une liquidation se clôture sous la maintenance. Chaque résiduel de liquidation est partagé 50 % au keeper qui a déclenché la routine, 50 % à la réserve d'assurance — les incitations du keeper restent alignées avec des liquidations en temps voulu pendant que la réserve se réapprovisionne du même flux. La trésorerie d'exploitation, en revanche, est le revenu du protocole qui peut être routé via des destinataires gouvernés : financement du pool de récompenses à l'ouverture de saison, paie, dépenses d'infrastructure, runway. Les confondre laisserait une action opérations épuiser accidentellement l'assurance, ce qui est exactement ce que la comptabilité séparée et l'exigence 3-sur-5 avec signataire externe sur les tirages d'assurance empêchent.
Le chemin du fee-siphon est le pont optionnel vers la comptabilité côté revenus. Quand la gouvernance l'active, une part configurée de feesAccrued est siphonée au même tick de réconciliation vers la couche côté revenus décrite ci-dessous — mais seulement après que le delta de frais sous-jacent a atterri on-chain. Le siphon n'opère jamais avant le commit on-chain.
totaux frais / assurance du moteur (précision USD18)
-> le réconciliateur snapshote les deltas vs le dernier checkpoint on-chain
-> deltas convertis en unités de collatéral
-> vaultAddFees (contrat de trésorerie d'exploitation)
-> vaultAddInsurance (contrat de réserve d'assurance, +50 % résiduel)
-> vaultSubInsurance (tirage d'assurance, exige 3-sur-5 avec signataire externe)
-> fee siphon optionnel -> couche de comptabilité côté revenus#Comptabilité côté revenus et pourquoi elle reste séparée
La couche de comptabilité côté revenus suit les soldes liés à la participation — revendications des détenteurs de DIP, bénéficiaires de partage des revenus, et toute future règle de distribution programmatique que la gouvernance active. Elle se trouve au-dessus de la comptabilité frais et assurance décrite ci-dessus et dépend de la correction de ces chiffres en dessous. Le revenu peut être siphoné, réservé ou routé dans la couche côté revenus sous des règles explicites, mais la couche elle-même n'est pas de la garde. C'est une surface comptable qui publie les revendications par participant ; les USDC sous-jacents vivent toujours dans le contrat de trésorerie d'exploitation jusqu'à ce qu'une revendication soit finalisée.
Cette séparation est ce qui permet au protocole de parler de revenus, d'assurance, de trésorerie et de participation comme de quatre choses distinctes — pas comme un seul chiffre « réserve » marketing-friendly. Elle rend aussi la revue de sécurité plus propre. Si une action de gouvernance misconfigure un paramètre, le reviewer peut voir quels buckets sont affectés et lesquels ne le sont pas sans inférer depuis les logs. Si une défaillance du runtime produit un delta de frais erroné, l'écart de réconciliation on-chain est visible contre le prochain instantané et peut être corrigé par un appel ciblé vaultAddFees ou vaultSubInsurance sans perturber les autres soldes.
Le modèle financier fait donc partie du design de sécurité de Dexter, pas seulement de son économie. Quatre adresses de vault, quatre jeux de permissions, quatre flux comptables indépendants, et une discipline de réconciliation qui les relie tous aux totaux du runtime — c'est ce qui permet qu'un trader financé, un gagnant du classement, un détenteur de DIP et un wallet de parrainage soient tous payés depuis le même protocole sans que les quatre flux ne se marchent jamais dessus.