Revogar autoridade do token Sui - Renuncie aos caps

A ferramenta de revogação de autoridade Sui da 20lab permite destruir permanentemente os objetos de capacidade (caps) de uma moeda Sui, removendo a capacidade de cunhar, congelar, pausar, atualizar ou modificar metadados para sempre. Esta é a forma como projetos Sui provam que seus tokens são imutáveis e minimizam confiança.

Revogar é irreversível - uma vez que um cap é destruído, ninguém pode restaurá-lo. Esta é a forma mais limpa de demonstrar suprimento fixo (revogando treasury cap), transferibilidade garantida (revogando deny cap), código bloqueado (revogando upgrade cap) ou tokenomics bloqueada (revogando metadata cap). Se você quer mover um cap em vez de desabilitá-lo, use a ferramenta de transferência de autoridade.

Para revogar o treasury cap na Sui:

1. Conecte a carteira que atualmente possui o treasury cap
2. Digite o coin type ou endereço do seu token
3. Selecione Revogar Treasury cap
4. Confirme a transação

Após confirmação, o suprimento do seu token está permanentemente limitado à quantidade circulante atual e os metadados se tornam imutáveis. Ninguém - incluindo você - pode cunhar tokens adicionais ou alterar nome/símbolo/logo, nunca. Esta é a revogação de cap mais comum para projetos comprometidos com um suprimento fixo, e é tipicamente esperada pelos padrões de listagem de DEX antes que eles exibam o token como confiável. Guia detalhado: como revogar treasury cap na Sui.

Para revogar o deny cap na Sui, use o mesmo fluxo de revogar treasury cap mas selecione Revogar Deny cap. Uma vez confirmado:

• Nenhuma carteira pode jamais ser congelada para seu token novamente
• Se seu token usa Deny Cap V2 com pausa habilitada, o token nunca pode ser pausado novamente também
• Contas congeladas existentes não podem ser descongeladas (revogue depois de descongelar se necessário)

Revogar deny cap é um dos sinais mais fortes de confiança que você pode dar à sua comunidade na Sui - garante criptograficamente que seus tokens nunca podem ser congelados ou pausados. Veja nosso guia de token Sui congelável para contexto sobre o modelo deny cap.

"Renunciar à propriedade" na Sui tipicamente se refere a revogar todos os objetos de capacidade - treasury, metadata, upgrade e (onde aplicável) deny cap - tornando as propriedades do token permanentemente fixas.

Diferente do padrão Ownable do Ethereum onde uma chamada de renúncia descarta uma única função de proprietário, a Sui tem múltiplos caps separados por token. Renúncia completa significa revogar cada um individualmente. A ferramenta exibe cada cap ativo em seu token e permite revogá-los em sequência ou seletivamente.

Revogar todos os caps é o compromisso mais forte possível com descentralização, mas é irreversível - então geralmente é feito apenas após o token ter atingido maturidade operacional. Transferir caps para um multisig primeiro é o passo intermediário mais seguro.

A ferramenta da 20lab suporta revogar todos os caps Sui padrão:

• Treasury cap - Bloqueia suprimento total e metadados para sempre
• Metadata cap - Bloqueia nome, símbolo e imagem permanentemente (veja nosso guia de metadata cap)
• Upgrade cap - Bloqueia o código do contrato inteligente Move do token permanentemente
• Deny cap / Deny cap V2 - Garante que nenhuma conta pode jamais ser congelada ou pausada

Cada um pode ser revogado de forma independente. Você pode manter alguns ativos enquanto desabilita outros - o padrão mais comum é revogar treasury e deny cap enquanto mantém upgrade cap disponível para patches de segurança.

Ambos desabilitam permanentemente um cap, mas diferem:

• Revogar destrói o objeto cap on-chain - o sinal mais limpo e explícito de remoção permanente. Mais fácil para auditores e DEXs detectarem automaticamente. Também recupera algum SUI de reembolsos de armazenamento, já que o objeto cap é removido.
• Transferência para endereço de queima atribui o cap a uma carteira que ninguém pode assinar. Funcionalmente idêntico, mas o objeto cap ainda existe on-chain, ligeiramente mais difícil de verificar, e você não recupera o reembolso de armazenamento.

Revogar é a abordagem recomendada. É mais limpa no histórico de transações, recupera armazenamento e é o que a maioria dos padrões de listagem de DEX Sui verifica.

Sim - revogar um cap é absolutamente irreversível. Uma vez que o objeto cap é destruído:

• O cap não pode ser restabelecido por ninguém, incluindo o criador original
• Não há mecanismo de recuperação, override de multisig ou caminho de atualização
• A ação correspondente (cunhagem, congelamento, pausa, atualização, mudanças de metadados) é permanentemente desabilitada

Por causa dessa permanência, considere cuidadosamente se você pode algum dia precisar da funcionalidade novamente. Se você não tem 100% de certeza, transfira o cap para um multisig em vez disso - isso ainda fornece descentralização forte enquanto mantém a opção de agir em emergências genuínas.

Sim - revogação de caps é seletiva. Configurações comuns:

• Revogar treasury, manter deny cap - Suprimento fixo com capacidade de congelar carteiras suspeitas
• Revogar deny cap, manter treasury - Token garantidamente não congelável, mas a equipe ainda pode cunhar conforme o cronograma publicado
• Revogar treasury e deny cap, manter upgrade cap - Tokenomics bloqueada com capacidade de corrigir o contrato se uma vulnerabilidade for encontrada
• Revogar tudo - Totalmente renunciado, maximamente descentralizado, imutável

Combine a configuração com o estágio do seu token. A maioria dos projetos revoga progressivamente conforme o ecossistema amadurece.

Depende do estágio e objetivos do seu token:

• Sim, para tokens comunitários / memecoins - Revogar treasury e deny cap é essencialmente necessário para ser levado a sério por DEXs Sui e rastreadores de listagem
• Sim, para tokens DeFi de suprimento fixo - Demonstra que o suprimento nunca inflará e os metadados nunca mudarão
• Ainda não, para projetos em estágio inicial - Mantenha caps até que tokenomics e operações se estabilizem
• De forma alguma, para stablecoins regulamentadas ou ativos vinculados a conformidade - Deny cap retido é frequentemente um requisito regulatório

Muitos projetos maduros usam uma abordagem em fases: transferem caps para governança multisig primeiro, depois revogam uma vez que o ecossistema amadurece.