Mitchell Amador, CEO da Immunefi, explica o que as empresas de segurança estão a fazer para evitar a próxima exploração de mil milhões de dólares em moedas estáveis.
Resumo
À medida que a adoção de moedas estáveis explode, a infraestrutura de segurança está a lutar para acompanhar.
Mais de 90% dos projetos auditados tinham vulnerabilidades críticas, diz o CEO da Immunefy
A grande maioria dos projetos não utiliza recursos de segurança essenciais como firewalls
À medida que o cripto avança para a adoção mainstream, as moedas estáveis estão se tornando a espinha dorsal financeira da economia em cadeia. Mas, enquanto o capital continua a fluir, a infraestrutura de segurança que sustenta esses sistemas permanece perigosamente subdesenvolvida.
Mitchell Amador, CEO da empresa de segurança Web3 Immunefi, acredita que estamos em uma “corrida contra o tempo”. Nesta entrevista, ele expõe os verdadeiros riscos ocultos dentro dos sistemas de moeda estável, por que a maioria das instituições não está preparada para o próximo exploit de bilhões de dólares.
Crypto.news: O que pode dizer-me sobre o estado atual da segurança quando se trata de moedas estáveis?
Mitchell Amador: Estamos em uma espécie de novo mundo corajoso. Estamos apenas começando a descobrir se as medidas de segurança que usamos nos últimos anos realmente funcionaram.
Por um lado, não temos visto um grande hack de moeda estável há bastante tempo. Você pode olhar para incidentes como os primeiros hacks de DeFi, ou problemas como a desvinculação do USDC durante o colapso do Silicon Valley Bank — esses foram eventos sérios, mas não tivemos nada desse tamanho desde então.
As pessoas estão se sentindo bem em relação à segurança da moeda estável. Mas a verdade é: não sabemos realmente se as coisas são seguras. Para dar uma comparação, pense em quanto tempo levou para se sentir confiante em algo como MakerDAO, Aave ou Compound. Levou anos para os usuários construírem essa confiança. As moedas estáveis, especialmente as descentralizadas, ainda são menos maduras do que esses protocolos.
Estamos prestes a adicionar outro trilhão de dólares em liquidez de moeda estável ao sistema nos próximos anos. A verdadeira questão é: estamos prontos para absorver tanto valor sem uma falha catastrófica? Não acho que saibamos a resposta a isso ainda — e podemos descobrir da maneira difícil.
CN: Quais são os riscos de hacking especificamente?
MA: Esse é o único risco que mais me preocupa. Já vimos eventos de desestabilização financeira — desvinculações, desfechos de alavancagem, até resgates — e sabemos como gerenciá-los. Mas com os hacks, sempre há um fator cisne negro.
Um grande hack direcionado a moedas estáveis poderia deslegitimar todo o cripto. Imagine uma vulnerabilidade em um contrato inteligente afetando várias centenas de bilhões de dólares — ou um erro em um ativo central de moeda estável que alimenta outros protocolos. Isso não é ficção científica. É possível.
Do ponto de vista da Immunefi, mais de 90% dos projetos que auditamos têm vulnerabilidades críticas — incluindo sistemas de moeda estável. A boa notícia é que fizemos muitos progressos. Há alguns anos, quase todos os projetos com que trabalhávamos experienciavam uma violação dentro de poucos anos. Hoje, isso é menos da metade — ainda alto, mas uma melhoria.
Ainda assim, estamos essencialmente a apostar todo o ecossistema em código que pode não estar pronto. E só saberemos realmente quando for testado sob pressão. Penso nisso como um cronómetro. Desde o momento em que uma moeda estável como USDC ou USDT é implementada, o risco de uma exploração crítica começa a contar.
À medida que o contrato se torna mais complexo e ganha mais funcionalidades, o risco aumenta. Entretanto, do outro lado do relógio, estamos a correr para melhorar a infraestrutura de segurança — recompensas por bugs, firewalls, scanners de vulnerabilidades baseados em IA, ferramentas de blacklist. Estes estão a ajudar a “adicionar tempo” a essa contagem decrescente.
A corrida é: conseguimos garantir estes sistemas rápido o suficiente antes que ocorra um hack catastrófico?
Neste momento, estamos no meio dessa corrida — e podemos conseguir. Há uma chance de que nos tornemos seguros o suficiente para que uma falha massiva nunca aconteça. Mas ainda não temos certeza. Os próximos dois anos serão críticos.
PT: Quais são as maiores fontes de vulnerabilidades de contratos inteligentes em moedas estáveis?
MA: Os riscos são semelhantes aos da maioria das aplicações DeFi — com algumas diferenças. A maioria das moedas estáveis não é descentralizada, então geralmente você não tem problemas relacionados à governança. Mas você tem duas classes principais de vulnerabilidades:
Risco de código — Os contratos inteligentes podem ser escritos de maneiras que os deixem abertos a manipulações. Já vimos erros matemáticos, lógica de resgate falhada, oráculos sendo mal utilizados — tudo isso pode levar a grandes explorações. É assim que ocorreram alguns dos primeiros hacks de moeda estável.
Controle de acesso — Muitas moedas estáveis são centralizadas, o que significa que existem funções privilegiadas — como a cunhagem ou o resgate — que são controladas pelo emissor. Se alguém comprometer esses controles, todo o sistema pode colapsar. Você pode se lembrar do problema do PayPal, onde alguém acidentalmente cunhou $300 trilhões em PYUSD. Isso foi um erro inofensivo — mas mostra o que é possível.
O risco financeiro é real. Vimos isso com a Circle durante a crise do SVB — não por causa de colaterais ruins, mas devido à pressão de liquidez. Uma enxurrada de resgates pode criar um cenário de “corrida ao banco”, mesmo que os ativos estejam tecnicamente lá.
O risco legal também está a aumentar. Os governos podem e irão intervir. Mas estas não são realmente questões de “segurança” no sentido dos contratos inteligentes — são preocupações de segurança mais amplas. Você precisa de um conjunto de ferramentas completamente diferente para gerir isso.
CN: Você acha que as instituições e os bancos entendem os riscos que você está descrevendo?
Amador: Não realmente. Eles entendem os riscos financeiros e legais — esse é o mundo deles. Mas quando se trata de risco de código, eles estão principalmente apenas com medo.
Eles sabem que estão fora de sua profundidade. Eles estão tentando aprender, estão contratando equipes nativas de criptomoeda, estão comprando startups de infraestrutura como Privy e Bridge. Mas a maioria ainda não se sente segura. Eles veem os exploits de contratos inteligentes como um problema estrangeiro que não estão equipados para resolver — e eles estão certos.
Eles estão mais confortáveis com a gestão de chaves e controlo de acesso — isso encaixa nos seus processos legados. Mas uma vez que você mergulha mais fundo na pilha de cripto, isso se torna um território alienígena para eles.
CN: O que os convenceria a agir mais rápido?
MA: FOMO. É isso. Eles precisam de um caso de negócio — uma grande oportunidade que não querem perder. Então, eles investirão em entender os riscos. É aí que entramos na Immunefi: ajudando essas instituições a descobrir como se proteger.
CN: O que os projetos de criptomoedas devem realmente estar a fazer hoje para gerir o risco de contratos inteligentes?
MA: Precisamos ter como objetivo “seguro por defeito”. Esse é o objetivo. Temos ferramentas poderosas agora — fuzzing, verificação formal, análise estática impulsionada por IA — muitas das quais pioneiramos na Immunefi. Mas a adoção ainda é muito baixa. A maioria das equipes ainda trata auditorias e recompensas por bugs como listas de verificação únicas. Isso não é suficiente.
Aqui está o que todo projeto sério deve estar a fazer:
Deteção de vulnerabilidades de IA (PR análises): Digitalização automatizada + humana de cada linha de novo código antes de ser mesclada.
Auditorias: Tanto auditorias tradicionais quanto competições de auditoria com dezenas ou centenas de hackers revisando o código.
Recompensas por bugs: Com recompensas significativas ligadas a quanto dinheiro está em risco.
Soluções de monitoramento: Detecção de ameaças em tempo real após a implementação.
Firewalls: “bouncers” a nível de contrato que bloqueiam transações maliciosas antes de serem executadas.
Se você executar este stack completo, você se dá cinco chances distintas de pegar exploits antes que eles causem danos. No entanto, menos de 1% dos projetos usam firewalls, e menos de 10% usam ferramentas de vulnerabilidade baseadas em IA. Essa é uma lacuna massiva — e uma que pode ser resolvida.
PT: Existem outros fatores — como design de linguagem ou arquitetura — que tornam os contratos mais seguros?
MA: Sim, mas depende da aplicação. Contratos mais simples são sempre mais seguros. É por isso que os contratos ERC-20 quase nunca são hackeados — são pequenos, compactos e bem testados. Quanto mais complexa for a sua lógica, maior o risco que você assume.
A capacidade de atualização é outro grande fator. Adiciona flexibilidade na experiência do usuário, mas introduz uma porta dos fundos. Idealmente, apenas você a utiliza — mas já vimos muitos casos em que é abusada. Ainda assim, a maioria dos projetos hoje escolhe a capacidade de atualização porque a compensação vale a pena para a adoção.
CN: Reflexões finais — qual é uma questão importante sobre a qual ninguém está a falar o suficiente?
MA: Definitivamente. Um dos maiores pontos cegos é a responsabilidade do protocolo. À medida que mais dinheiro flui para sistemas on-chain, o panorama legal vai mudar rapidamente. Em algum momento, alguém vai perguntar: Quem é responsável quando algo quebra? Ainda não temos uma resposta clara para isso — mas está a chegar, e vai remodelar como os protocolos são construídos e governados.
Outra coisa que penso é como a cultura das criptomoedas está a mudar. Está a tornar-se finança. Pode-se sentir isso. Os primeiros construtores eram ideólogos — verdadeiros crentes na descentralização e em sistemas abertos. Agora estamos a ver uma onda de profissionais de finanças que abordam este espaço de maneira muito diferente. Isso não é necessariamente mau, mas está a mudar o ethos, e ainda não sabemos quais serão as consequências a longo prazo dessa mudança.
E então há a questão da reversibilidade. À medida que as instituições migram para a blockchain, elas começarão a exigir funcionalidades que atualmente não existem na maioria das blockchains públicas. Uma dessas funcionalidades é a capacidade de reverter transações.
Acho que vamos ver mais cadeias, talvez até mesmo as principais, começarem a oferecer essa capacidade, especialmente em ambientes permitidos ou semi-permitidos. Isso cria uma nova classe de infraestrutura de blockchain que se comporta mais como as finanças tradicionais — jardins murados com pontes para o mundo aberto.
Tudo isso está relacionado a algo que penso que as pessoas estão a perder: a segurança cripto está prestes a ter o seu momento. Ainda é subestimada hoje, mas está a tornar-se claro que todos os principais intervenientes — desde fundos a DAOs até bancos — acabarão por depender de infraestruturas on-chain.
E isso significa que todos eles precisarão de proteção séria. Acho que estamos apenas no início de uma grande explosão na infraestrutura de segurança, e ninguém está realmente preparado para como isso será.
<br>
Ver original
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
Entrevista | A segurança das stablecoins é uma corrida contra o tempo: CEO da Immunefy
À medida que o cripto avança para a adoção mainstream, as moedas estáveis estão se tornando a espinha dorsal financeira da economia em cadeia. Mas, enquanto o capital continua a fluir, a infraestrutura de segurança que sustenta esses sistemas permanece perigosamente subdesenvolvida.
Mitchell Amador, CEO da empresa de segurança Web3 Immunefi, acredita que estamos em uma “corrida contra o tempo”. Nesta entrevista, ele expõe os verdadeiros riscos ocultos dentro dos sistemas de moeda estável, por que a maioria das instituições não está preparada para o próximo exploit de bilhões de dólares.
Crypto.news: O que pode dizer-me sobre o estado atual da segurança quando se trata de moedas estáveis?
Mitchell Amador: Estamos em uma espécie de novo mundo corajoso. Estamos apenas começando a descobrir se as medidas de segurança que usamos nos últimos anos realmente funcionaram.
Por um lado, não temos visto um grande hack de moeda estável há bastante tempo. Você pode olhar para incidentes como os primeiros hacks de DeFi, ou problemas como a desvinculação do USDC durante o colapso do Silicon Valley Bank — esses foram eventos sérios, mas não tivemos nada desse tamanho desde então.
As pessoas estão se sentindo bem em relação à segurança da moeda estável. Mas a verdade é: não sabemos realmente se as coisas são seguras. Para dar uma comparação, pense em quanto tempo levou para se sentir confiante em algo como MakerDAO, Aave ou Compound. Levou anos para os usuários construírem essa confiança. As moedas estáveis, especialmente as descentralizadas, ainda são menos maduras do que esses protocolos.
Estamos prestes a adicionar outro trilhão de dólares em liquidez de moeda estável ao sistema nos próximos anos. A verdadeira questão é: estamos prontos para absorver tanto valor sem uma falha catastrófica? Não acho que saibamos a resposta a isso ainda — e podemos descobrir da maneira difícil.
CN: Quais são os riscos de hacking especificamente?
MA: Esse é o único risco que mais me preocupa. Já vimos eventos de desestabilização financeira — desvinculações, desfechos de alavancagem, até resgates — e sabemos como gerenciá-los. Mas com os hacks, sempre há um fator cisne negro.
Um grande hack direcionado a moedas estáveis poderia deslegitimar todo o cripto. Imagine uma vulnerabilidade em um contrato inteligente afetando várias centenas de bilhões de dólares — ou um erro em um ativo central de moeda estável que alimenta outros protocolos. Isso não é ficção científica. É possível.
Do ponto de vista da Immunefi, mais de 90% dos projetos que auditamos têm vulnerabilidades críticas — incluindo sistemas de moeda estável. A boa notícia é que fizemos muitos progressos. Há alguns anos, quase todos os projetos com que trabalhávamos experienciavam uma violação dentro de poucos anos. Hoje, isso é menos da metade — ainda alto, mas uma melhoria.
Ainda assim, estamos essencialmente a apostar todo o ecossistema em código que pode não estar pronto. E só saberemos realmente quando for testado sob pressão. Penso nisso como um cronómetro. Desde o momento em que uma moeda estável como USDC ou USDT é implementada, o risco de uma exploração crítica começa a contar.
À medida que o contrato se torna mais complexo e ganha mais funcionalidades, o risco aumenta. Entretanto, do outro lado do relógio, estamos a correr para melhorar a infraestrutura de segurança — recompensas por bugs, firewalls, scanners de vulnerabilidades baseados em IA, ferramentas de blacklist. Estes estão a ajudar a “adicionar tempo” a essa contagem decrescente.
A corrida é: conseguimos garantir estes sistemas rápido o suficiente antes que ocorra um hack catastrófico?
Neste momento, estamos no meio dessa corrida — e podemos conseguir. Há uma chance de que nos tornemos seguros o suficiente para que uma falha massiva nunca aconteça. Mas ainda não temos certeza. Os próximos dois anos serão críticos.
PT: Quais são as maiores fontes de vulnerabilidades de contratos inteligentes em moedas estáveis?
MA: Os riscos são semelhantes aos da maioria das aplicações DeFi — com algumas diferenças. A maioria das moedas estáveis não é descentralizada, então geralmente você não tem problemas relacionados à governança. Mas você tem duas classes principais de vulnerabilidades:
Risco de código — Os contratos inteligentes podem ser escritos de maneiras que os deixem abertos a manipulações. Já vimos erros matemáticos, lógica de resgate falhada, oráculos sendo mal utilizados — tudo isso pode levar a grandes explorações. É assim que ocorreram alguns dos primeiros hacks de moeda estável.
Controle de acesso — Muitas moedas estáveis são centralizadas, o que significa que existem funções privilegiadas — como a cunhagem ou o resgate — que são controladas pelo emissor. Se alguém comprometer esses controles, todo o sistema pode colapsar. Você pode se lembrar do problema do PayPal, onde alguém acidentalmente cunhou $300 trilhões em PYUSD. Isso foi um erro inofensivo — mas mostra o que é possível.
O risco financeiro é real. Vimos isso com a Circle durante a crise do SVB — não por causa de colaterais ruins, mas devido à pressão de liquidez. Uma enxurrada de resgates pode criar um cenário de “corrida ao banco”, mesmo que os ativos estejam tecnicamente lá.
O risco legal também está a aumentar. Os governos podem e irão intervir. Mas estas não são realmente questões de “segurança” no sentido dos contratos inteligentes — são preocupações de segurança mais amplas. Você precisa de um conjunto de ferramentas completamente diferente para gerir isso.
CN: Você acha que as instituições e os bancos entendem os riscos que você está descrevendo?
Amador: Não realmente. Eles entendem os riscos financeiros e legais — esse é o mundo deles. Mas quando se trata de risco de código, eles estão principalmente apenas com medo.
Eles sabem que estão fora de sua profundidade. Eles estão tentando aprender, estão contratando equipes nativas de criptomoeda, estão comprando startups de infraestrutura como Privy e Bridge. Mas a maioria ainda não se sente segura. Eles veem os exploits de contratos inteligentes como um problema estrangeiro que não estão equipados para resolver — e eles estão certos.
Eles estão mais confortáveis com a gestão de chaves e controlo de acesso — isso encaixa nos seus processos legados. Mas uma vez que você mergulha mais fundo na pilha de cripto, isso se torna um território alienígena para eles.
CN: O que os convenceria a agir mais rápido?
MA: FOMO. É isso. Eles precisam de um caso de negócio — uma grande oportunidade que não querem perder. Então, eles investirão em entender os riscos. É aí que entramos na Immunefi: ajudando essas instituições a descobrir como se proteger.
CN: O que os projetos de criptomoedas devem realmente estar a fazer hoje para gerir o risco de contratos inteligentes?
MA: Precisamos ter como objetivo “seguro por defeito”. Esse é o objetivo. Temos ferramentas poderosas agora — fuzzing, verificação formal, análise estática impulsionada por IA — muitas das quais pioneiramos na Immunefi. Mas a adoção ainda é muito baixa. A maioria das equipes ainda trata auditorias e recompensas por bugs como listas de verificação únicas. Isso não é suficiente.
Aqui está o que todo projeto sério deve estar a fazer:
Deteção de vulnerabilidades de IA (PR análises): Digitalização automatizada + humana de cada linha de novo código antes de ser mesclada.
Auditorias: Tanto auditorias tradicionais quanto competições de auditoria com dezenas ou centenas de hackers revisando o código.
Recompensas por bugs: Com recompensas significativas ligadas a quanto dinheiro está em risco.
Soluções de monitoramento: Detecção de ameaças em tempo real após a implementação.
Firewalls: “bouncers” a nível de contrato que bloqueiam transações maliciosas antes de serem executadas.
Se você executar este stack completo, você se dá cinco chances distintas de pegar exploits antes que eles causem danos. No entanto, menos de 1% dos projetos usam firewalls, e menos de 10% usam ferramentas de vulnerabilidade baseadas em IA. Essa é uma lacuna massiva — e uma que pode ser resolvida.
PT: Existem outros fatores — como design de linguagem ou arquitetura — que tornam os contratos mais seguros?
MA: Sim, mas depende da aplicação. Contratos mais simples são sempre mais seguros. É por isso que os contratos ERC-20 quase nunca são hackeados — são pequenos, compactos e bem testados. Quanto mais complexa for a sua lógica, maior o risco que você assume.
A capacidade de atualização é outro grande fator. Adiciona flexibilidade na experiência do usuário, mas introduz uma porta dos fundos. Idealmente, apenas você a utiliza — mas já vimos muitos casos em que é abusada. Ainda assim, a maioria dos projetos hoje escolhe a capacidade de atualização porque a compensação vale a pena para a adoção.
CN: Reflexões finais — qual é uma questão importante sobre a qual ninguém está a falar o suficiente?
MA: Definitivamente. Um dos maiores pontos cegos é a responsabilidade do protocolo. À medida que mais dinheiro flui para sistemas on-chain, o panorama legal vai mudar rapidamente. Em algum momento, alguém vai perguntar: Quem é responsável quando algo quebra? Ainda não temos uma resposta clara para isso — mas está a chegar, e vai remodelar como os protocolos são construídos e governados.
Outra coisa que penso é como a cultura das criptomoedas está a mudar. Está a tornar-se finança. Pode-se sentir isso. Os primeiros construtores eram ideólogos — verdadeiros crentes na descentralização e em sistemas abertos. Agora estamos a ver uma onda de profissionais de finanças que abordam este espaço de maneira muito diferente. Isso não é necessariamente mau, mas está a mudar o ethos, e ainda não sabemos quais serão as consequências a longo prazo dessa mudança.
E então há a questão da reversibilidade. À medida que as instituições migram para a blockchain, elas começarão a exigir funcionalidades que atualmente não existem na maioria das blockchains públicas. Uma dessas funcionalidades é a capacidade de reverter transações.
Acho que vamos ver mais cadeias, talvez até mesmo as principais, começarem a oferecer essa capacidade, especialmente em ambientes permitidos ou semi-permitidos. Isso cria uma nova classe de infraestrutura de blockchain que se comporta mais como as finanças tradicionais — jardins murados com pontes para o mundo aberto.
Tudo isso está relacionado a algo que penso que as pessoas estão a perder: a segurança cripto está prestes a ter o seu momento. Ainda é subestimada hoje, mas está a tornar-se claro que todos os principais intervenientes — desde fundos a DAOs até bancos — acabarão por depender de infraestruturas on-chain.
E isso significa que todos eles precisarão de proteção séria. Acho que estamos apenas no início de uma grande explosão na infraestrutura de segurança, e ninguém está realmente preparado para como isso será.
<br>