Eu costumava tratar "imutável" como uma garantia. Código publicado, regras corrigidas, ninguém mexe. Então você se vê diante de uma obrigação que precisa viver por vinte anos. Nesse intervalo, um bug surge, uma lei muda, um erro precisa ser corrigido. Código imutável não pode ser remendado. O recurso vira uma armadilha.
Então as equipes silenciosamente adicionam atualizabilidade — chaves administrativas, um voto de governança que pode trocar a lógica. E agora você reintroduziu exatamente aquilo que a imutabilidade deveria matar: alguém que pode reescrever as regras do seu ativo depois que você o comprou. Imutável e atualizável são opostos, e um ativo regulado de longa duração parece precisar dos dois.
Isso significa que a pergunta honesta nunca foi "é imutável?" É "quem pode mudar o código, e você vai ver isso vindo?" Uma chave administrativa silenciosa é uma porta dos fundos com branding.
É aqui que uma cadeia como @Dusk precisa ter cuidado. Regras que vivem no próprio ativo só ajudam se as mudanças forem limitadas, versionadas, visíveis — uma emenda legal, não uma troca por uma chave oculta. A cadeia precisa tornar impossível esconder quem mudou o quê.
Continuo cético. A maioria dos contratos "atualizáveis" se apoia em multisigs frágeis; uma única concessão pode virar tudo. E uma governança lenta o suficiente para ser segura pode ser lenta demais para um bug que está sangrando ativamente.
Quem precisa disso? Emissores de ativos que sobrevivem ao primeiro código. O que destrói isso: chaves ocultas, ou governança lenta demais para um incêndio.
Vale ficar de olho. A verdadeira pergunta é quem segura a caneta.
$DUSK #dusk