Assorbimento e burn
Quando una vendita raggiunge un intervallo finanziato in ETH, può scambiare CUBIT contro quegli ETH. I token acquisiti dal muro devono essere ritirati dalla liquidità negoziabile e riservati esclusivamente alla distruzione.
La riduzione della profondità in ETH del muro e la distruzione dei token sono due conseguenze distinte dell’operazione.
Un’offerta iniziale fissa, poi deflazionistica
All’inizio vengono emessi 21 milioni di CUBIT, senza emissioni successive. Quando l’hook distrugge token riacquistati dai muri, totalSupply() diminuisce e totalBurned() aumenta. La deflazione corrisponde a queste distruzioni effettive; non dipende semplicemente dal tempo trascorso.
Una vendita raggiunge un muro
→ gli ETH di quella posizione riacquistano CUBIT
→ i CUBIT vengono isolati, poi distrutti
→ l’offerta totale diminuisce
I CUBIT riacquistati da un muro non tornano mai nella LP negoziabile, anche se il prezzo successivamente risale. Una coda di burn in attesa è già esclusa da quella liquidità.
Quando il prezzo oscilla in un intervallo
Se le oscillazioni raggiungono i muri, vendite successive possono consumarne gli ETH e ritirare gradualmente CUBIT dal mercato. Alcuni intervalli possono restare senza liquidità eseguibile. I loro tick rimangono identificati anche quando i fondi sono esauriti.
Una risalita del prezzo non ricarica automaticamente un muro con i CUBIT che ha riacquistato: sono stati isolati per essere distrutti. Un nuovo finanziamento può però approfondire la posizione allo stesso tick.
| Zona delle oscillazioni | Effetto possibile |
|---|---|
| L’intervallo resta sopra i muri | Gli swap non raggiungono quelle posizioni; non ne deriva alcun burn del muro |
| L’intervallo attraversa uno o più muri | I CUBIT vengono assorbiti e distrutti; gli ETH di quegli intervalli possono essere consumati progressivamente |
| Il prezzo attraversa il ladder | Le sue posizioni cambiano inventario; i suoi token possono essere riciclati o ricollocati al ribilanciamento |
Sono gli intervalli di liquidità a potersi esaurire, non i tick come unità di prezzo a scomparire. Non ogni intervallo svuota quindi automaticamente tutti i tick. Il ruolo del ladder.
Tre stati da distinguere
| Stato | Significato |
|---|---|
| ETH in una posizione di muro | Fondi ancora utilizzabili da quella posizione secondo prezzo e intervallo |
| CUBIT assorbiti e isolati | Inventario ritirato dal mercato, eventualmente in attesa di burn |
| CUBIT distrutti | Offerta totale effettivamente ridotta da CubitToken.burn() |
Il token autorizza soltanto l’hook a eseguire il burn. L’entry point pubblico burnAbsorbed() non permette al chiamante di scegliere un destinatario per recuperare l’inventario isolato.
Il percorso del router CUBIT
Nel router fornito, la vendita regola prima gli scambi del pool, completa i trasferimenti arbitrari necessari al rimborso e poi chiama il burn se è presente una coda. Un burn fallito annulla l’intera vendita.
Questo comportamento è specifico di tale percorso di esecuzione. Non consente di affermare che una vendita attraverso qualsiasi router di terze parti distrugga sempre tutti i token nella stessa transazione.
Le integrazioni di terze parti
Un router compatibile può lasciare una coda di token isolati. Restano riservati al burn e non devono più poter essere riacquistati nella liquidità dei muri. Una successiva chiamata a burnAbsorbed() completa la distruzione.
Questa funzione resta chiamabile durante una pausa di manutenzione del guardian e non paga premi. Un keeper con una soglia di redditività positiva può quindi ritardare la chiamata.
Cosa non garantisce il burn
La distruzione riduce l’offerta; non crea ETH. Se un muro ha speso i suoi fondi per assorbire una vendita, il livello storico non ne ripristina automaticamente la profondità.
Con più muri fissi, l’isolamento e i residui devono restare correttamente assegnati a ogni posizione. Le campagne di test del vecchio muro unico non dimostrano da sole queste proprietà per la nuova implementazione.
Verificare le prove
Gli eventi TokensBurned dell’hook e Burned del token, insieme a totalBurned() e totalSupply(), permettono di seguire la distruzione effettiva. La coda pendingBurnTokens rappresenta uno stato distinto.
L’assorbimento effettivo in un ambiente di rete o fork canonico e la revisione indipendente dello strict-burn restano condizioni di validazione. I limiti noti.
Fonti: CubitRouter._finishSwap, CubitHook._isolateAbsorbedTokens, _burnAbsorbed, CubitToken.burn e contracts/docs/STRICT_BURN.md per la storia progettuale.