Falha de cunhagem infinita

O que é uma falha de cunhagem infinita em cripto?

Uma falha de cunhagem infinita é um defeito em um contrato inteligente que permite criar novos tokens de cripto sem os limites, as permissões ou os controles de oferta corretos.

Em termos simples, é um bug que pode permitir que um invasor cunhe mais tokens do que o protocolo pretendia.

O termo costuma ser usado informalmente, enquanto pesquisadores de segurança podem descrever o mesmo problema como uma vulnerabilidade de cunhagem infinita, bug de cunhagem ilimitada, vulnerabilidade de cunhagem não autorizada ou ataque de cunhagem infinita.

O glossário de cripto da Ledger descreve um ataque de cunhagem infinita como uma situação em que uma falha em um contrato inteligente ou um problema no código permite que um invasor crie uma quantidade ilimitada de tokens dentro de um protocolo.

Uma falha de cunhagem infinita pode afetar tokens fungíveis, ativos wrapped, tokens de governança, tokens de recompensa, ativos sintéticos, tokens de jogos, ativos semelhantes a stablecoins e coleções de NFT.

Os danos podem ser graves, pois a oferta de tokens é um dos fundamentos centrais do valor em cripto.

Se um token deveria ter uma oferta limitada ou controlada, mas um bug permite a cunhagem ilimitada, o mercado pode perder a confiança muito rapidamente.

Em muitos casos, o invasor cunha tokens, vende-os em pools de liquidez ou mercados, drena ativos reais e deixa os detentores com tokens diluídos ou desvalorizados.

Uma falha de cunhagem infinita não é um mecanismo normal de inflação.

É uma falha não intencional na lógica do token, no desenho das permissões, nos controles de atualização, na contabilidade da bridge ou na segurança do contrato inteligente.

Por que as falhas de cunhagem infinita são importantes

As falhas de cunhagem infinita são importantes porque podem destruir a integridade econômica de um ativo cripto.

As regras de oferta de um token informam aos usuários quantos tokens podem existir, quem pode criá-los e em quais condições uma nova oferta pode entrar no mercado.

Se essas regras puderem ser contornadas, o preço de mercado, a liquidez, o poder de governança, o valor como garantia e a confiança dos usuários podem entrar em colapso.

Esse risco é especialmente grave em finanças descentralizadas, pois os tokens costumam ser usados como garantia, ativos de pools de liquidez, ativos de recompensa, ativos de votação ou representações wrapped de ativos em outra chain.

Se for possível cunhar tokens falsos ou sem lastro, eles poderão ser trocados por ativos reais antes que o bug seja descoberto.

A perda não é apenas teórica, pois os contratos inteligentes podem movimentar valor automaticamente assim que uma transação é confirmada.

Ao contrário de um erro normal em um banco de dados, uma transação na blockchain pode ser difícil ou impossível de reverter sem uma ação especial de governança, intervenção no nível da chain ou uma recuperação negociada.

Por isso, as falhas de cunhagem infinita são tratadas como vulnerabilidades de alta gravidade em contratos inteligentes.

Elas combinam risco técnico com risco direto para a tokenomics.

A ausência de uma única verificação de permissão pode se transformar em uma crise de oferta que afeta todo o mercado.

Como funciona uma falha de cunhagem infinita

Uma falha de cunhagem infinita geralmente começa com uma função que cria novos tokens.

Essa função pode se chamar mint, issue, bridgeMint, depositMint, rewardMint, claim, redeem ou ter outro nome específico do projeto.

A função deve permitir a criação de tokens somente por contas aprovadas, módulos confiáveis ou condições válidas do protocolo.

Se a função for pública, estiver mal protegida, tiver sido inicializada incorretamente ou puder ser acessada por um caminho de chamada inesperado, um invasor poderá acioná-la.

Quando consegue cunhar tokens, o invasor pode repetir a ação muitas vezes ou cunhar uma quantidade extremamente grande em uma única transação.

Os tokens recém-criados podem então ser vendidos, transferidos, usados como garantia, usados para governança ou enviados para outra chain por meio de uma bridge.

O caminho exato depende do desenho do protocolo.

Algumas falhas de cunhagem infinita decorrem da ausência de controle de acesso.

Outras resultam de uma lógica contábil falha.

Há ainda as causadas por uma inicialização insegura de contratos atualizáveis.

Outras surgem de falhas na verificação da bridge, quando um contrato cunha ativos wrapped sem confirmar que ativos reais foram bloqueados ou queimados em outro local.

Falha de cunhagem infinita e padrões de token

Muitos tokens cripto seguem padrões como o ERC-20 para tokens fungíveis.

O padrão de token ERC-20 define funções comuns, como totalSupply, balanceOf, transfer, approve e transferFrom.

A documentação para desenvolvedores do ERC-20 da Ethereum explica que o ERC-20 oferece funções para transferir tokens, consultar saldos e a oferta total e aprovar gastos por terceiros.

O próprio padrão ERC-20 não exige que todo token tenha uma função pública de cunhagem.

A cunhagem geralmente é um recurso adicional controlado pelo contrato do token ou pela lógica do projeto.

Um contrato de token seguro deve definir quem pode cunhar, quanto pode ser cunhado, quando a cunhagem é permitida e se há uma oferta máxima.

Uma falha de cunhagem infinita costuma surgir quando essas regras adicionais de cunhagem estão ausentes, incompletas ou conectadas incorretamente a outros contratos.

Por isso, usar um padrão de token não é suficiente por si só.

Um token pode seguir uma interface comum e, ainda assim, ter uma lógica de cunhagem perigosa.

Causas comuns de falhas de cunhagem infinita

A causa mais comum é a falta de controle de acesso em uma função de cunhagem.

Se qualquer pessoa puder chamar uma função que cria tokens, qualquer pessoa poderá inflar a oferta.

Outra causa comum é o gerenciamento incorreto de funções e permissões.

Um contrato pode usar funções como owner, admin, minter, bridge ou operator, mas atribuí-las incorretamente.

A terceira causa é a inicialização desprotegida em contratos atualizáveis.

Se um proxy ou contrato de implementação não for inicializado corretamente, um invasor poderá se tornar owner ou minter.

A quarta causa é uma verificação falha da bridge.

Um contrato de bridge pode cunhar tokens wrapped sem verificar adequadamente se os ativos foram bloqueados, queimados ou comprovados na chain de origem.

A quinta causa são erros de aritmética ou contabilidade.

Um contrato pode calcular incorretamente recompensas, participações, depósitos ou saldos disponíveis para resgate e permitir resgates repetidos.

A sexta causa são chamadas externas inseguras.

Se a lógica de cunhagem interagir com outros contratos antes de atualizar o estado interno, um invasor poderá encontrar uma maneira de repetir ou manipular o processo.

Falha de cunhagem infinita e controle de acesso

O controle de acesso é uma das defesas mais importantes contra falhas de cunhagem infinita.

A documentação de controle de acesso da OpenZeppelin explica que o controle de acesso determina quem pode realizar ações como cunhar tokens, votar ou congelar transferências.

O Smart Contract Top 10 da OWASP lista as vulnerabilidades de controle de acesso como um dos principais riscos de contratos inteligentes, pois verificações de permissão ausentes ou fracas podem permitir que usuários não autorizados acessem funções sensíveis.

Uma função de cunhagem é sensível porque altera a oferta de tokens.

Se a cunhagem deve ser limitada a um tesouro, bridge, conjunto de validadores, contrato de governança ou módulo de recompensas, o código precisa impor essa regra sempre.

Um bom controle de acesso não deve depender apenas da confiança fora da blockchain ou da honestidade dos usuários.

O contrato inteligente deve rejeitar cunhagens não autorizadas, mesmo que um invasor chame a função diretamente.

Os desenvolvedores também devem evitar conceder amplos poderes de cunhagem a muitas contas.

Quanto mais contas puderem cunhar, maior será a superfície de ataque.

Falha de cunhagem infinita e oferta máxima

Uma oferta máxima pode reduzir o risco de cunhagem infinita, mas somente se for aplicada corretamente no código.

Um token pode anunciar uma oferta máxima na documentação, em páginas de marketing ou em um white paper.

No entanto, o limite relevante é aquele imposto pelo contrato inteligente.

Se o contrato permitir cunhagem acima do limite divulgado, os usuários estarão confiando em promessas em vez de código.

Um limite de oferta seguro deve verificar a oferta total antes de cada operação de cunhagem.

A função de cunhagem deve falhar se a nova oferta ultrapassar o limite.

Essa verificação deve se aplicar a todos os caminhos de cunhagem, e não apenas à função principal.

Por exemplo, a cunhagem por bridge, a cunhagem de recompensas de staking, a cunhagem para resgates e a cunhagem administrativa não devem contornar o limite de oferta, a menos que o desenho permita isso claramente.

Um limite de oferta aplicado a uma função, mas não a outra, pode criar um caminho oculto para cunhagem infinita.

Usuários e auditores devem sempre verificar todos os caminhos que podem aumentar a oferta de tokens.

Falha de cunhagem infinita em ativos wrapped

Ativos wrapped estão especialmente expostos ao risco de cunhagem infinita porque representam ativos que deveriam existir em outro lugar.

Um token wrapped geralmente é cunhado quando um ativo real é bloqueado, queimado ou comprovado de outra forma em uma chain de origem ou sistema de custódia.

Se o contrato do token wrapped cunhar sem uma comprovação válida, os novos tokens poderão ficar sem lastro.

Isso cria um problema direto de solvência.

Os usuários podem acreditar que cada token wrapped tem como lastro um ativo subjacente, mas a exploração cria mais direitos sobre os ativos do que o sistema consegue resgatar.

O invasor pode então trocar tokens wrapped sem lastro por ativos líquidos antes que o mercado reaja.

Por isso, as funções de cunhagem da bridge precisam de regras rígidas de verificação.

Elas devem validar mensagens, assinaturas, nonces, eventos da chain de origem, proteção contra repetição de transações e permissões de relayers confiáveis.

Uma falha de cunhagem infinita de um ativo wrapped não é apenas um bug de token.

Também é uma falha de contabilidade entre chains.

Falha de cunhagem infinita em sistemas de recompensa

Sistemas de recompensa também podem gerar falhas de cunhagem infinita.

Um contrato de staking, farming, jogos ou fidelidade pode cunhar recompensas com base na atividade do usuário.

Se a fórmula de recompensa estiver errada, os usuários poderão resgatar mais tokens do que o pretendido.

Se a função de resgate não atualizar corretamente os saldos resgatados, a mesma recompensa poderá ser resgatada repetidamente.

Se o contrato confiar em valores fornecidos pelo usuário, um invasor poderá enviar dados falsos que gerem grandes recompensas.

Se o sistema de recompensas não limitar as emissões, um pequeno erro lógico poderá se transformar em um enorme problema de oferta.

Os contratos de recompensa devem acompanhar cuidadosamente depósitos, participações, histórico de resgates, débitos de recompensa e limites de emissão.

Também devem testar casos extremos, como depósitos iguais a zero, depósitos muito grandes, vários resgates no mesmo bloco e caminhos de saque de emergência.

A cunhagem de recompensas deve ser tratada com a mesma seriedade que a cunhagem pelo tesouro.

Falha de cunhagem infinita e contratos atualizáveis

Contratos atualizáveis podem criar riscos específicos de cunhagem infinita.

Um projeto pode usar um contrato proxy para permitir a atualização futura da lógica.

Isso pode ser útil para corrigir bugs, adicionar recursos ou melhorar o funcionamento do protocolo.

No entanto, a capacidade de atualização também adiciona riscos, pois o administrador da atualização pode conseguir alterar a lógica de cunhagem.

Se o proxy for inicializado incorretamente, um invasor poderá assumir o controle da função de administrador.

Se a função de atualização não estiver protegida, um invasor poderá substituir uma lógica segura por uma lógica maliciosa de cunhagem.

Se a nova implementação tiver um erro no layout de armazenamento, os dados de oferta ou de permissões poderão ser corrompidos.

As considerações de segurança oficiais do Solidity alertam que contratos semelhantes a proxies e o desenho de autorizações exigem atenção cuidadosa, pois sistemas de contratos podem conceder, sem intenção, permissões poderosas ao componente errado.

Projetos que usam contratos atualizáveis devem adotar timelocks, aprovações multisig, auditorias, monitoramento e processos de atualização documentados com clareza.

Sinais de alerta de uma falha de cunhagem infinita

Um sinal de alerta é uma função pública de cunhagem sem verificação de permissão visível.

Outro sinal é uma função de cunhagem que verifica apenas condições fracas, como tx.origin, número do bloco ou dados fornecidos pelo usuário.

Um terceiro sinal é um sistema de permissões em que a função minter é controlada por uma conta desconhecida, não verificada ou de propriedade externa.

Um quarto sinal é um token que afirma ter oferta fixa, mas mantém funções de cunhagem ativas sem um limite claro.

Um quinto sinal é um token de bridge com comprovações de lastro pouco claras ou documentação insuficiente sobre a verificação de mensagens.

Um sexto sinal é um contrato de recompensas que pode cunhar recompensas sem um cronograma máximo de emissões.

Um sétimo sinal é um contrato atualizável sem timelock, política de atualização publicada ou controle administrativo claro.

Nenhum desses sinais prova que exista uma exploração.

Mas eles apontam áreas que merecem uma análise mais profunda antes que os usuários confiem no token.

Como os desenvolvedores evitam falhas de cunhagem infinita

Os desenvolvedores podem evitar falhas de cunhagem infinita definindo as regras de cunhagem antes de escrever o código.

O projeto deve definir quem pode cunhar, por que a cunhagem é permitida, quanto pode ser cunhado e quando ela deve parar.

Todos os caminhos de cunhagem devem aplicar o controle de acesso.

Todos os caminhos de cunhagem devem respeitar os limites de oferta ou de emissão, caso a tokenomics os exija.

Os desenvolvedores devem evitar duplicar a lógica de cunhagem em muitos contratos, pois código duplicado aumenta a chance de verificações inconsistentes.

Quando apropriado, devem usar bibliotecas bem revisadas e evitar criar uma lógica de token personalizada sem um motivo sólido.

Devem escrever testes unitários, testes de integração, testes de invariantes e testes fuzz para o comportamento da oferta.

Também devem testar se contas não autorizadas são impedidas de cunhar em qualquer condição normal ou extrema.

O desenho mais seguro pressupõe que invasores chamarão funções diretamente, reorganizarão transações, usarão contratos como chamadores e testarão todos os caminhos do código.

Auditoria do risco de cunhagem infinita

Uma auditoria de contrato inteligente deve rastrear todas as funções que podem aumentar a oferta de tokens.

O auditor deve procurar funções diretas de cunhagem, chamadas internas de cunhagem, resgates de recompensas, mensagens de bridge, contratos wrapper de depósito, funções administrativas, funções de atualização e controles de emergência.

O auditor deve confirmar que cada caminho que aumenta a oferta tem as permissões corretas.

Também deve verificar se a oferta total não pode ultrapassar o limite ou o modelo de emissão pretendido.

O Padrão de Verificação de Segurança de Contratos Inteligentes da OWASP oferece requisitos de segurança e testes que podem ajudar as equipes a projetar, revisar e verificar contratos inteligentes seguros.

Os auditores também devem revisar os eventos, pois a cunhagem deve gerar registros on-chain claros.

Se a oferta puder mudar sem eventos transparentes, o monitoramento ficará mais difícil.

Uma auditoria não deve perguntar apenas se a cunhagem funciona.

Também deve perguntar se ela pode funcionar quando não deveria.

Testes para detectar falhas de cunhagem infinita

Os testes para detectar falhas de cunhagem infinita devem incluir tanto o comportamento normal quanto o comportamento em caso de falha.

O comportamento normal significa que os emissores autorizados podem cunhar a quantidade correta sob condições válidas.

O comportamento em caso de falha significa que usuários não autorizados não podem cunhar, quantidades excessivas não podem ser criadas e comprovações inválidas não podem aumentar a oferta.

Os testes de invariantes são especialmente úteis porque verificam se regras essenciais são sempre respeitadas.

Uma invariante útil pode determinar que a oferta total nunca ultrapasse a oferta máxima.

Outra pode determinar que a oferta de tokens wrapped nunca ultrapasse o lastro verificado.

Uma invariante de recompensas pode determinar que o total de recompensas cunhadas nunca ultrapasse o cronograma de emissões.

Os testes fuzz podem ajudar a encontrar entradas incomuns que as pessoas talvez não pensem em testar.

A verificação formal também pode ajudar em sistemas de alto valor, especialmente quando as regras de oferta são simples o suficiente para serem expressas matematicamente.

Os bons testes devem ocorrer antes da implantação e continuar depois das atualizações.

Monitoramento do risco de cunhagem infinita após o lançamento

A segurança não termina quando um contrato é implantado.

Após o lançamento, os projetos devem monitorar a oferta de tokens, os eventos de cunhagem, as mudanças de permissões, as mensagens de bridge, os eventos de atualização e as transferências incomuns.

Um sistema de monitoramento pode alertar a equipe se a oferta aumentar rápido demais ou se um endereço inesperado cunhar tokens.

Também pode alertar a equipe quando funções administrativas mudarem, contratos de implementação forem atualizados ou grandes quantidades de tokens recém-cunhados forem transferidas para pools de liquidez.

Painéis públicos podem ajudar os usuários a verificar se a oferta de tokens corresponde à tokenomics divulgada pelo projeto.

Os planos de resposta a emergências devem ser preparados antes que um incidente aconteça.

Esses planos podem incluir pausar contratos, desativar a cunhagem, contatar parceiros de segurança, notificar usuários, coordenar-se com plataformas de liquidez e publicar um relatório pós-incidente.

Um projeto que descubra tarde uma falha de cunhagem infinita talvez tenha apenas alguns minutos para reduzir os danos.

A detecção rápida costuma ser tão importante quanto um bom código.

Impacto sobre os detentores de tokens

Uma falha de cunhagem infinita pode prejudicar os detentores de tokens por meio da diluição.

Se o invasor criar uma grande quantidade de novos tokens, cada token existente poderá representar uma parcela menor da oferta total.

O mercado também pode precificar o temor de que mais tokens sejam criados no futuro.

Isso pode reduzir a liquidez e dificultar a saída dos detentores de suas posições.

Em alguns casos, a governança também pode ser afetada.

Se o poder de governança for determinado pelo saldo de tokens, um invasor poderá cunhar tokens suficientes para influenciar votações.

Em DeFi, o invasor poderá usar os tokens cunhados como garantia se um protocolo de empréstimo aceitar o ativo.

Isso pode gerar perdas que vão além do contrato original do token.

O impacto pode se espalhar por pools de liquidez, mercados de empréstimo, bridges, carteiras e rastreadores de portfólio.

Por isso, falhas de cunhagem infinita são riscos sistêmicos para tokens integrados a muitos protocolos.

Impacto sobre os pools de liquidez

Os pools de liquidez costumam ser o primeiro lugar em que os danos de uma cunhagem infinita ficam visíveis.

Um invasor pode cunhar tokens e trocá-los pelos ativos pareados em um pool.

À medida que o invasor vende os tokens falsos ou excedentes, o pool fica cheio do token explorado e perde o ativo pareado.

Os provedores de liquidez podem sofrer perdas porque o saldo de ativos do pool muda drasticamente.

Oráculos de preço que dependem dos preços do pool também podem ser distorcidos.

Se outros protocolos usarem esses preços, os danos poderão se espalhar.

Um protocolo bem projetado não deve depender de um único pool de liquidez com pouca profundidade para precificação crítica.

O desenho de oráculos, a profundidade da liquidez, os disjuntores e o monitoramento da oferta podem reduzir a possibilidade de uma falha de cunhagem infinita se transformar em uma falha mais ampla de DeFi.

Ainda assim, o bug original de oferta precisa ser corrigido no nível do contrato.

Falha de cunhagem infinita vs. tokenomics inflacionária

Uma falha de cunhagem infinita não é o mesmo que uma tokenomics inflacionária.

Tokenomics inflacionária significa que o protocolo cria intencionalmente novos tokens de acordo com regras conhecidas.

Uma falha de cunhagem infinita significa que o protocolo cria ou permite a criação de novos tokens fora das regras pretendidas.

A inflação pode ser normal quando financia recompensas de staking, recompensas de mineração, incentivos ao ecossistema ou a segurança dos validadores.

A cunhagem ilimitada e não autorizada é anormal porque viola o modelo de oferta esperado.

Um token pode ser inflacionário e ainda assim ser seguro se a emissão for limitada, transparente e controlada.

Um token pode afirmar ter oferta fixa e ainda ser inseguro se houver caminhos ocultos de cunhagem.

Os usuários devem se concentrar no código aplicável, e não apenas na linguagem de marketing.

A questão principal é se a nova oferta segue as regras publicadas e se essas regras estão protegidas pela lógica do contrato inteligente.

Falha de cunhagem infinita vs. ataque de reentrância

Uma falha de cunhagem infinita e um ataque de reentrância são conceitos diferentes, embora às vezes possam se sobrepor.

Um ataque de reentrância ocorre quando uma chamada externa permite que um contrato ou invasor entre novamente em uma função antes que a primeira execução termine.

Uma falha de cunhagem infinita se concentra na criação não autorizada ou excessiva de tokens.

Um bug de reentrância pode causar cunhagens repetidas se a lógica de cunhagem atualizar o estado depois de uma chamada externa.

No entanto, muitas falhas de cunhagem infinita não exigem reentrância.

Elas podem decorrer da falta de controle de acesso, de comprovações incorretas da bridge, de inicialização insegura ou de cálculos incorretos da oferta.

Essa distinção importa porque corrigir uma classe de bug não corrige automaticamente a outra.

Um contrato pode usar proteção contra reentrância e ainda ter uma função de cunhagem desprotegida.

Um token seguro precisa tanto de um fluxo de execução seguro quanto de uma autorização de oferta segura.

Falha de cunhagem infinita vs. aprovação ilimitada

Uma falha de cunhagem infinita não deve ser confundida com uma aprovação ilimitada de tokens.

Uma aprovação ilimitada significa que um usuário dá a outro contrato permissão para gastar até uma quantidade muito grande de seus tokens existentes.

A cunhagem infinita significa que novos tokens podem ser criados além das regras de oferta pretendidas.

Ambas podem ser perigosas, mas afetam partes diferentes do sistema de tokens.

A aprovação ilimitada ameaça o saldo do usuário se o gastador aprovado for malicioso ou comprometido.

A cunhagem infinita ameaça toda a oferta de tokens se a lógica de cunhagem estiver vulnerável.

Um usuário pode reduzir o risco de aprovações ilimitadas gerenciando as permissões de gasto dos tokens.

Um usuário não pode corrigir pessoalmente um bug de cunhagem infinita em um contrato de token implantado.

Para reduzir o risco de cunhagem infinita, os usuários dependem do desenho do contrato, de auditorias, do monitoramento, da governança e da resposta do projeto.

Como os usuários podem verificar o risco de cunhagem infinita

Os usuários podem começar verificando se o contrato do token está verificado em um explorador de blockchain.

Um contrato verificado permite que usuários e auditores leiam o código-fonte correspondente ao bytecode implantado.

Os usuários podem procurar funções com palavras como mint, issue, create, reward, bridge, claim ou upgrade.

Podem verificar se essas funções são protegidas por permissões, propriedade, governança ou verificações de módulos confiáveis.

Também podem verificar se o token tem uma oferta máxima e se esse limite é aplicado on-chain.

Além disso, podem conferir se as funções administrativas são controladas por uma carteira multisig, um timelock ou uma única conta desconhecida.

Os usuários devem ler os relatórios de auditoria, se disponíveis, mas precisam lembrar que uma auditoria não é uma garantia.

Também devem verificar se o projeto tem monitoramento público, programas de bug bounty e procedimentos claros de resposta a incidentes.

Se as regras de oferta de um token não forem claras, o mais prudente é presumir que o risco é maior.

Boas práticas para projetos

Os projetos devem manter a lógica de cunhagem simples e fácil de auditar.

Devem usar controle de acesso baseado em funções em todas as funções de cunhagem.

Devem aplicar limites de oferta máxima ou de emissão quando a tokenomics exigir.

Devem evitar conceder poder de cunhagem a contas comuns de propriedade externa quando houver controles mais seguros de governança ou multisig.

Devem usar timelocks para mudanças importantes relacionadas à oferta quando o sistema não estiver em modo de emergência.

Devem publicar uma tokenomics que corresponda ao comportamento real do contrato inteligente.

Devem monitorar em tempo real os eventos de cunhagem e as mudanças de permissões.

Devem realizar auditorias antes do lançamento e depois de atualizações importantes.

Devem criar um plano de resposta a emergências antes que usuários e liquidez estejam em risco.

Devem tratar toda função que aumenta a oferta como uma superfície crítica de segurança.

Boas práticas para usuários

Os usuários não devem confiar apenas na oferta máxima declarada de um token.

Devem verificar se o contrato realmente aplica esse limite.

Devem evitar tokens com permissões de cunhagem pouco claras, controles administrativos ocultos ou contratos não verificáveis.

Devem ter cautela com ativos wrapped cuja documentação de comprovação seja fraca ou cujo lastro não esteja claro.

Devem tratar com cuidado tokens de recompensa muito recentes, pois bugs na cunhagem de recompensas podem ser difíceis de detectar no início.

Devem monitorar aumentos repentinos de oferta, grandes eventos de cunhagem e transferências anormais de tokens.

Devem diversificar o risco em vez de concentrar muito valor em um único token não auditado.

Devem entender que um alto rendimento pode ocultar um alto risco de contrato inteligente.

Devem lembrar que, depois de uma exploração de cunhagem infinita, não há certeza de recuperação do preço.

Equívocos comuns sobre falhas de cunhagem infinita

Um equívoco comum é pensar que uma falha de cunhagem infinita afeta apenas memecoins ou projetos de baixa qualidade.

Na realidade, qualquer token com lógica complexa de cunhagem, bridge, recompensas ou atualização pode estar sujeito a esse risco.

Outro equívoco é acreditar que uma alegação de oferta fixa garante segurança.

Uma oferta fixa só é significativa se o contrato inteligente a aplicar em todos os caminhos de cunhagem.

Um terceiro equívoco é pensar que o controle de acesso, por si só, é suficiente.

O controle de acesso é essencial, mas limites de oferta, comprovações da bridge, verificações contábeis, testes, monitoramento e controles de atualização também importam.

Um quarto equívoco é acreditar que uma auditoria elimina todos os riscos.

Uma auditoria reduz o risco, mas não pode garantir que não exista nenhum bug nem que futuras atualizações continuarão seguras.

Um quinto equívoco é pensar que a cunhagem infinita sempre exige técnicas avançadas de invasão.

Alguns incidentes resultam de erros simples, como uma função desprotegida, uma função atribuída incorretamente ou um inicializador esquecido.

Perguntas frequentes

O que significa falha de cunhagem infinita?

Uma falha de cunhagem infinita significa que um bug em um contrato inteligente permite criar novos tokens sem os limites ou as permissões pretendidos.

Falha de cunhagem infinita é o mesmo que ataque de cunhagem infinita?

Os termos estão estreitamente relacionados, mas a falha é a vulnerabilidade e o ataque é a exploração dessa vulnerabilidade.

Uma falha de cunhagem infinita pode destruir o valor de um token?

Sim. Ela pode destruir valor ao criar oferta excessiva, drenar a liquidez, abalar a confiança e causar forte diluição.

O que causa uma falha de cunhagem infinita?

As causas comuns incluem falta de controle de acesso, configuração incorreta de funções, inicialização insegura, comprovações falhas da bridge, erros na contabilidade de recompensas e limites de oferta fracos.

Tokens ERC-20 podem ter falhas de cunhagem infinita?

Sim. Um token ERC-20 pode ter uma falha de cunhagem infinita se a lógica de cunhagem adicionada for insegura ou mal controlada.

Uma oferta máxima impede a cunhagem infinita?

Uma oferta máxima só ajuda se o contrato a aplicar corretamente em todos os caminhos possíveis de cunhagem.

Ativos wrapped podem sofrer falhas de cunhagem infinita?

Sim. Ativos wrapped podem sofrer falhas de cunhagem infinita se uma bridge ou um contrato de cunhagem criar tokens sem lastro e sem comprovação válida.

Uma auditoria pode evitar falhas de cunhagem infinita?

Uma auditoria pode reduzir o risco, mas não pode garantir segurança, especialmente se o contrato for atualizado posteriormente ou integrado a novos sistemas.

Como os usuários podem detectar o risco de cunhagem infinita?

Os usuários podem revisar contratos verificados, funções de cunhagem, permissões de controle de acesso, limites de oferta, relatórios de auditoria, controles administrativos e eventos de cunhagem on-chain.

O que um projeto deve fazer ao descobrir uma falha de cunhagem infinita?

Se possível, o projeto deve pausar as funções afetadas, interromper a cunhagem, proteger a liquidez restante, notificar os usuários, investigar a causa e publicar um relatório claro do incidente.

Uma falha de cunhagem infinita é o mesmo que inflação?

Não. Inflação é a emissão planejada de tokens; uma falha de cunhagem infinita é a criação não intencional ou não autorizada de oferta.

Por que o controle de acesso é importante para a cunhagem?

O controle de acesso é importante porque a cunhagem altera a oferta de tokens e deve ser realizada apenas por contratos ou contas autorizados, seguindo regras rigorosas.

Conclusão

Uma falha de cunhagem infinita é uma das vulnerabilidades mais perigosas de contratos inteligentes em cripto, pois pode romper as regras de oferta de um token.

Ela ocorre quando um contrato permite cunhar tokens sem a autorização, os limites, as comprovações ou os controles contábeis corretos.

O resultado pode ser uma diluição massiva, liquidez drenada, sistemas de garantia comprometidos, governança prejudicada e perda de confiança dos usuários.

O risco é especialmente relevante para tokens com funções de cunhagem, sistemas de recompensa, ativos wrapped, bridges, contratos atualizáveis e gerenciamento complexo de permissões.

Os desenvolvedores podem reduzir o risco usando um controle de acesso robusto, aplicando limites de oferta, testando invariantes, auditando todos os caminhos de cunhagem, protegendo atualizações e monitorando as mudanças de oferta após o lançamento.

Os usuários podem reduzir sua exposição verificando contratos, analisando permissões de cunhagem e auditorias, acompanhando as mudanças de oferta e evitando tokens cujo controle sobre novas emissões não esteja claro.

Uma falha de cunhagem infinita não é inflação normal nem um erro inofensivo de programação.

É uma falha no nível da oferta que pode afetar todos os detentores e todos os protocolos conectados ao token.

Em cripto, o código controla o dinheiro, e o código de cunhagem controla a oferta.

Por isso, toda função que aumenta a oferta deve ser projetada, testada, auditada e monitorada como uma parte crítica da segurança do token.