Absorption et burn
Lorsqu’une vente atteint une plage financée en ETH, elle peut échanger des CUBIT contre ces ETH. Les tokens acquis par le mur doivent être retirés de la liquidité négociable et réservés exclusivement à leur destruction.
La baisse de profondeur ETH du mur et la destruction des tokens sont deux conséquences distinctes de cette opération.
Une offre initiale fixe, puis déflationniste
21 millions de CUBIT sont émis au départ, sans mint ultérieur. Lorsque le hook détruit des tokens rachetés par les murs, totalSupply() diminue et totalBurned() augmente. La déflation correspond à ces destructions effectives ; elle ne dépend pas simplement du temps écoulé.
Une vente atteint un mur
→ des ETH de cette position rachètent des CUBIT
→ les CUBIT sont isolés, puis détruits
→ l’offre totale diminue
Les CUBIT rachetés par un mur ne retournent jamais dans la LP négociable, y compris si le prix remonte ensuite. Une file de burn en attente demeure déjà retirée de cette liquidité.
Quand le prix oscille dans un range
Si les oscillations atteignent les murs, les ventes successives peuvent y consommer des ETH et retirer progressivement des CUBIT du marché. Certaines plages peuvent finir sans liquidité exécutable. Leurs ticks restent identifiés même lorsque leurs fonds sont épuisés.
Une remontée du prix ne recharge pas automatiquement un mur avec les CUBIT qu’il a rachetés : ils ont été isolés pour être détruits. Un nouveau financement peut toutefois épaissir la position au même tick.
| Zone des oscillations | Effet possible |
|---|---|
| Le range reste au-dessus des murs | Les swaps n’atteignent pas ces positions ; aucun burn de mur n’en découle |
| Le range traverse un ou plusieurs murs | Des CUBIT sont absorbés et détruits ; les ETH de ces plages peuvent être progressivement consommés |
| Le prix traverse le ladder | Ses positions changent d’inventaire ; ses propres tokens peuvent être recyclés ou replacés au rebalance |
Ce sont les plages de liquidité qui peuvent s’épuiser, pas les ticks en tant qu’unités de prix qui disparaissent. Tout range ne vide donc pas automatiquement tous les ticks. Voir le rôle du ladder.
Trois états à distinguer
| État | Signification |
|---|---|
| ETH dans une position de mur | Fonds encore utilisables par cette position selon le prix et la plage |
| CUBIT absorbés et isolés | Inventaire retiré du marché, en attente éventuelle de burn |
| CUBIT détruits | Offre totale effectivement réduite par CubitToken.burn() |
Le token n’autorise que le hook à exécuter le burn. Le point d’entrée public burnAbsorbed() ne permet pas au caller de choisir un destinataire pour récupérer l’inventaire isolé.
Le chemin du routeur CUBIT
Dans le routeur livré, la vente règle d’abord les échanges du pool, termine les transferts arbitraires nécessaires au remboursement, puis appelle le burn si une file est présente. Un burn échoué fait revenir la vente entière en arrière.
Ce comportement est propre à ce chemin d’exécution. Il ne permet pas d’affirmer qu’une vente passant par n’importe quel routeur tiers détruit toujours tous les tokens dans la même transaction.
Les intégrations tierces
Un routeur compatible peut laisser une file de tokens isolés. Ceux-ci demeurent réservés au burn et ne doivent plus pouvoir être rachetés dans la liquidité des murs. Un appel ultérieur à burnAbsorbed() termine leur destruction.
Cette fonction reste callable pendant une pause guardian de maintenance et ne verse pas de prime. Un keeper avec un seuil de rentabilité positif peut donc retarder son appel.
Ce que le burn ne garantit pas
La destruction réduit l’offre ; elle ne crée pas d’ETH. Si un mur a dépensé ses fonds pour absorber une vente, son niveau historique ne lui rend pas automatiquement de la profondeur.
Avec plusieurs murs fixes, l’isolation et les reliquats doivent rester correctement affectés à chaque position. Les campagnes de tests de l’ancien mur unique ne prouvent pas à elles seules ces propriétés pour la nouvelle implémentation.
Vérifier les preuves
Les événements TokensBurned du hook et Burned du token, ainsi que totalBurned() et totalSupply(), permettent de suivre la destruction effective. La file pendingBurnTokens représente un état distinct.
L’absorption effective sur un environnement réseau ou fork canonique et la revue indépendante du strict-burn restent des conditions de validation. Voir les limites connues.
Sources : CubitRouter._finishSwap, CubitHook._isolateAbsorbedTokens, _burnAbsorbed, CubitToken.burn et contracts/docs/STRICT_BURN.md pour l’historique de conception.