Le ladder et le rebalance
Le ladder est la liquidité de travail du protocole. Il comporte des positions de CUBIT proposées à l’achat et une position d’ETH, le cushion, qui peut absorber des ventes proches du marché.
Ses positions sont mobiles. Leur disponibilité dépend des fonds du protocole, du prix et des contraintes de géométrie du pool.
La répartition des tokens
Le modèle lu dans le code vise 70 % des tokens détenus pour le ladder en positions actives, avec le reste en réserve. La partie déployée est répartie entre trois bandes selon 20 % / 30 % / 50 %.
| Bande | Part de la quantité destinée aux bandes | Plage de prix approximative |
|---|---|---|
| Première | 20 % | Référence → ×2 |
| Deuxième | 30 % | ×2 → ×4 |
| Troisième | 50 % | ×4 → ×8 |
Chaque plage fait 6 930 ticks, soit environ un doublement du prix. Ces proportions sont des objectifs de placement : arrondis, plafonds de liquidité et position du marché peuvent laisser davantage de tokens en réserve.
Les pourcentages ne représentent pas des allocations à l’équipe. Les tokens isolés pour le burn et les CUBIT déposés dans le Vault ne sont pas une réserve libre du ladder.
Le cushion en ETH
Le cushion est une position d’achat mobile, normalement située sous le marché. La géométrie historique vise environ une division par deux du prix sur sa largeur. Son placement doit respecter les murs.
Un ETH simplement comptabilisé dans ladderIdleEth n’est pas un ETH présent dans une position active. Il ne crée donc pas de profondeur exécutable tant qu’il reste idle.
Ce qui se passe lorsque le prix range
Quand le prix oscille dans des plages du ladder, leurs inventaires peuvent passer progressivement de CUBIT à ETH, ou d’ETH à CUBIT. Le ladder peut réutiliser ses propres tokens et réorganiser ses positions lors d’un rebalance.
Les murs suivent une règle différente : les CUBIT qu’ils rachètent sont isolés puis détruits, et ne reviennent pas alimenter la LP. Des oscillations qui atteignent les murs peuvent donc retirer des tokens du marché et consommer la liquidité de certaines plages.
Un range qui reste au-dessus des murs ne déclenche pas ces burns. Le prix doit réellement traverser les positions concernées ; il n’existe pas de vidage automatique de tous les ticks par le simple passage du temps. Absorption et déflation.
La compatibilité entre le ladder et plusieurs murs fixes fait partie de la révision en cours. Les détails de la géométrie de l’ancienne version ne suffisent pas à valider la nouvelle.
Ce que fait un rebalance
Un rebalance retire les positions concernées du ladder, comptabilise les actifs et les frais réalisés, affecte les parts prévues, puis redéploie la liquidité disponible autour de la référence retenue par le contrat.
Le sweep transfère 15 % des ETH entrant dans son calcul vers la réserve des murs. La prime keeper est bornée et provient du ladder. Si le Vault est actif et financé par l’activité, sa part porte sur les frais LP du ladder effectivement réalisés en ETH.
Le rebalance ne donne pas au caller le choix du prix, du destinataire des murs ou d’un retrait vers son wallet.
Quand l’appel est éligible
Les sources utilisent un déplacement de référence d’au moins 1 250 ticks et un cooldown de 25 blocs. Le contrat vérifie aussi son initialisation, la pause de maintenance et son contexte d’exécution.
Les blocs du cooldown et les secondes du calendrier V2 sont des horloges différentes. Vingt-cinq blocs ne sont pas une durée fixe garantie.
Le Lens expose l’éligibilité ; une simulation avec le compte appelant précède toujours l’envoi. Entre lecture et exécution, une autre transaction peut modifier l’état. Déclencher la maintenance.
Sources : CubitHook._deployAsks, _rebalance, _referenceTick et libraries/BandLib.sol. Les paramètres décrits sont ceux des sources lues ; leur intégration multi-murs reste à valider.