As Trocas de Engenharia das Pools AMM Imutáveis
A imutabilidade é uma troca de engenharia: uma pool AMM imutável remove a capacidade de substituir o código implantado, mas também remove a capacidade de corrigir um bug dentro dessa pool. A STONfi usa essa divisão: os contratos da Pool são imutáveis, enquanto um Router separado permanece atualizável.
🔒 O QUE A IMUTABILIDADE REMOVE
Um contrato atualizável pode redirecionar a execução para um novo código de implementação. Essa flexibilidade ajuda as equipes a corrigirem bugs, mas cria risco de autoridade de upgrade.
Com uma pool imutável, o bytecode implantado fica fixo. Não há um ponteiro de implementação para substituir e não existe um admin que possa reescrever a lógica central da pool.
O benefício é uma superfície de ataque fixa:
- A lógica da AMM pode ser auditada em um artefato permanente.
- Uma implementação futura não pode substituir esse código de forma silenciosa.
⚠ O CUSTO NÃO DESAPARECE
Se o código imutável contiver um bug, a equipe não consegue corrigir exatamente aquela pool. Uma nova pool precisa ser implantada, enquanto a antiga permanece on-chain. Liquidez e atividade de negociação então precisam migrar voluntariamente.
A imutabilidade reduz o risco futuro de upgrade, mas torna bugs descobertos mais difíceis de reparar.
A STONfi separa responsabilidades: a Pool mantém a lógica da AMM e as reservas sob código fixo, enquanto o Router coordena as operações e pode evoluir.
⏱ FLEXIBILIDADE COM LIMITES
Alguns parâmetros podem permanecer configuráveis sem tornar todo o contrato atualizável. O artigo usa taxas como exemplo: o código original da pool pode permitir uma alteração limitada na taxa sem mudar sua lógica.
As atualizações do Router são adiadas em sete dias. Isso não torna um upgrade malicioso impossível; ele cria tempo para reagir.
A pergunta-chave não é “imutável ou atualizável?”. É qual componente tem o maior raio de impacto, o que precisa mudar e quais proteções cercam essa mudança?
Não é aconselhamento financeiro — pesquise por conta própria! 🚀
$GRAM
A imutabilidade é uma troca de engenharia: uma pool AMM imutável remove a capacidade de substituir o código implantado, mas também remove a capacidade de corrigir um bug dentro dessa pool. A STONfi usa essa divisão: os contratos da Pool são imutáveis, enquanto um Router separado permanece atualizável.
🔒 O QUE A IMUTABILIDADE REMOVE
Um contrato atualizável pode redirecionar a execução para um novo código de implementação. Essa flexibilidade ajuda as equipes a corrigirem bugs, mas cria risco de autoridade de upgrade.
Com uma pool imutável, o bytecode implantado fica fixo. Não há um ponteiro de implementação para substituir e não existe um admin que possa reescrever a lógica central da pool.
O benefício é uma superfície de ataque fixa:
- A lógica da AMM pode ser auditada em um artefato permanente.
- Uma implementação futura não pode substituir esse código de forma silenciosa.
⚠ O CUSTO NÃO DESAPARECE
Se o código imutável contiver um bug, a equipe não consegue corrigir exatamente aquela pool. Uma nova pool precisa ser implantada, enquanto a antiga permanece on-chain. Liquidez e atividade de negociação então precisam migrar voluntariamente.
A imutabilidade reduz o risco futuro de upgrade, mas torna bugs descobertos mais difíceis de reparar.
A STONfi separa responsabilidades: a Pool mantém a lógica da AMM e as reservas sob código fixo, enquanto o Router coordena as operações e pode evoluir.
⏱ FLEXIBILIDADE COM LIMITES
Alguns parâmetros podem permanecer configuráveis sem tornar todo o contrato atualizável. O artigo usa taxas como exemplo: o código original da pool pode permitir uma alteração limitada na taxa sem mudar sua lógica.
As atualizações do Router são adiadas em sete dias. Isso não torna um upgrade malicioso impossível; ele cria tempo para reagir.
A pergunta-chave não é “imutável ou atualizável?”. É qual componente tem o maior raio de impacto, o que precisa mudar e quais proteções cercam essa mudança?
Não é aconselhamento financeiro — pesquise por conta própria! 🚀
$GRAM
