Absorção e queima
Quando uma venda atinge uma faixa financiada em ETH, ela pode trocar CUBIT por esses ETH. Os tokens adquiridos pelo muro devem ser retirados da liquidez negociável e reservados exclusivamente à destruição.
A redução da profundidade em ETH do muro e a destruição dos tokens são duas consequências distintas dessa operação.
Uma oferta inicial fixa, depois deflacionária
21 milhões de CUBIT são emitidos inicialmente, sem emissão posterior. Quando o hook destrói tokens recomprados pelos muros, totalSupply() diminui e totalBurned() aumenta. A deflação corresponde a essas destruições efetivas; ela não depende apenas do tempo decorrido.
Uma venda atinge um muro
→ ETH dessa posição recompra CUBIT
→ os CUBIT são isolados e depois destruídos
→ a oferta total diminui
Os CUBIT recomprados por um muro nunca voltam à LP negociável, mesmo que o preço suba depois. Uma fila de queima pendente já está retirada dessa liquidez.
Quando o preço oscila em um intervalo
Se as oscilações atingirem os muros, vendas sucessivas poderão consumir ETH neles e retirar CUBIT gradualmente do mercado. Algumas faixas podem terminar sem liquidez executável. Seus ticks continuam identificados mesmo quando os fundos se esgotam.
Uma recuperação de preço não recarrega automaticamente um muro com os CUBIT que ele recomprou: eles foram isolados para destruição. Um novo financiamento pode, porém, aprofundar a posição no mesmo tick.
| Zona das oscilações | Efeito possível |
|---|---|
| O intervalo permanece acima dos muros | Os swaps não atingem essas posições; nenhuma queima de muro decorre disso |
| O intervalo atravessa um ou mais muros | CUBIT é absorvido e destruído; os ETH dessas faixas podem ser consumidos gradualmente |
| O preço atravessa o ladder | Suas posições mudam de estoque; seus próprios tokens podem ser reciclados ou realocados no rebalanceamento |
São as faixas de liquidez que podem se esgotar, não os ticks como unidades de preço que desaparecem. Portanto, nem todo intervalo esvazia automaticamente todos os ticks. Veja o papel do ladder.
Três estados a distinguir
| Estado | Significado |
|---|---|
| ETH em uma posição de muro | Fundos ainda utilizáveis por essa posição conforme o preço e a faixa |
| CUBIT absorvidos e isolados | Estoque retirado do mercado, eventualmente aguardando queima |
| CUBIT destruídos | Oferta total efetivamente reduzida por CubitToken.burn() |
O token autoriza apenas o hook a executar a queima. O ponto de entrada público burnAbsorbed() não permite ao chamador escolher um destinatário para recuperar o estoque isolado.
O caminho do roteador CUBIT
No roteador entregue, a venda primeiro liquida as trocas do pool, conclui as transferências arbitrárias necessárias ao reembolso e então chama a queima se houver fila. Uma queima que falha reverte toda a venda.
Esse comportamento é específico desse caminho de execução. Ele não permite afirmar que uma venda por qualquer roteador de terceiros sempre destrói todos os tokens na mesma transação.
As integrações de terceiros
Um roteador compatível pode deixar uma fila de tokens isolados. Eles continuam reservados à queima e não devem mais poder ser comprados na liquidez dos muros. Uma chamada posterior a burnAbsorbed() conclui sua destruição.
Essa função continua acessível durante uma pausa de manutenção do guardian e não paga recompensa. Um keeper com um limite positivo de rentabilidade pode, portanto, adiar a chamada.
O que a queima não garante
A destruição reduz a oferta; ela não cria ETH. Se um muro gastou seus fundos para absorver uma venda, seu nível histórico não restaura automaticamente sua profundidade.
Com múltiplos muros fixos, o isolamento e os resíduos devem permanecer corretamente atribuídos a cada posição. As campanhas de testes do antigo muro único não provam, por si só, essas propriedades para a nova implementação.
Verificar as evidências
Os eventos TokensBurned do hook e Burned do token, assim como totalBurned() e totalSupply(), permitem acompanhar a destruição efetiva. A fila pendingBurnTokens representa um estado distinto.
A absorção efetiva em um ambiente de rede ou fork canônico e a revisão independente do strict-burn continuam sendo condições de validação. Veja os limites conhecidos.
Fontes: CubitRouter._finishSwap, CubitHook._isolateAbsorbedTokens, _burnAbsorbed, CubitToken.burn e contracts/docs/STRICT_BURN.md para o histórico de concepção.