O que os hooks do Uniswap v4 realmente transformam um pool em
Os hooks do Uniswap v4 são contratos inteligentes que podem ser executados em pontos definidos do ciclo de vida de um pool. Um hook pode ser executado antes ou depois de um pool ser inicializado, de a liquidez mudar, de ocorrer um swap ou de ser feita uma doação. Isto permite a um programador adicionar lógica como taxas dinâmicas, ordens ao estilo de limite, transações divididas ao longo do tempo, controlos de acesso, atualizações de oráculos ou atividade de lending externa sem modificar o core do Uniswap v4.
Essa descrição pode fazer os hooks parecerem plug-ins. Em termos financeiros, estão mais perto de motores de política programáveis. Um pool básico do Uniswap segue regras de contabilidade conhecidas, enquanto um pool com hooks pode impor regras adicionais, mover ativos, calcular os seus próprios deltas ou interagir com outro protocolo. Dois pools a deter os mesmos tokens podem, portanto, ter perfis de segurança e liquidez completamente diferentes.
A pergunta útil não é se os hooks são bons ou maus. É quanta autoridade um hook específico tem, quantos pressupostos externos introduz e o que acontece quando esses pressupostos falham. O ranking abaixo trata hooks mais simples com permissões limitadas como relativamente menos arriscados, não como seguros, e coloca custódia, alavancagem, crédito, contabilidade complexa ou poderes de atualização no extremo de maior risco.
Como funciona o sistema de hooks e onde o risco entra
O Uniswap v4 usa uma arquitetura singleton, o que significa que muitos pools são geridos através de um único contrato central PoolManager em vez de cada pool ser implementado como um contrato separado. A flash accounting regista as obrigações líquidas de tokens durante uma transação e liquida-as antes de a operação terminar. Isto pode reduzir o uso de gas e tornar as operações em múltiplos pools mais eficientes, mas também significa que os programadores de hooks têm de compreender com precisão as regras de lock, settlement e balance-delta.
Um pool escolhe o seu contrato de hook quando é criado. O endereço do hook codifica quais os callbacks ativados, e essas permissões não podem ser tratadas simplesmente como rótulos descritivos. O código executado nos callbacks pode rejeitar uma ação, alterar taxas, devolver deltas de tokens personalizados, atualizar registos internos ou chamar outro contrato. Um erro em qualquer um desses caminhos pode afetar swaps, levantamentos de liquidez ou settlement.
Os hooks também podem usar contabilidade personalizada para alterar o resultado económico entregue pelo PoolManager. Isso é suficientemente poderoso para reproduzir funcionalidades associadas a outros designs de automated market maker, mas expande a base de código confiada. Se um hook mantiver saldos virtuais, taxas acumuladas, reivindicações de ordens, posições de dívida ou partes de recompensa, os utilizadores dependem de que tanto a contabilidade do Uniswap como a contabilidade do hook permaneçam consistentes.
O singleton não significa que um hook malicioso possa reescrever automaticamente todos os pools do Uniswap v4. Os pools continuam logicamente separados, e as permissões dos callbacks restringem quando o código do hook é executado. Ainda assim, integrações que agrupam chamadas, reutilizam routers, aprovam allowances amplas de tokens ou assumem que todos os pools v4 se comportam da mesma forma podem criar caminhos de falha partilhados. Os programadores devem modelar o percurso completo da transação, e não apenas a função de callback do hook.
Os riscos que os developers e os LPs devem analisar primeiro
A reentrância em hooks é uma preocupação principal. A reentrância ocorre quando uma chamada externa regressa a um contrato antes de a operação original ter terminado de atualizar o seu estado. O Uniswap v4 tem regras de bloqueio e liquidação, mas um hook pode chamar tokens, routers, mercados de lending ou outros hooks com o seu próprio comportamento de callback. Um guard local contra reentrância não basta se o design permitir alterações de estado entre funções ou entre protocolos numa ordem inesperada.
O risco do singleton-pool é, em parte, um risco de integração. O PoolManager auditado pode impor as suas invariantes enquanto uma aplicação calcula mal o que deve durante um lock, confunde o estado de um pool com o de outro, ou aceita um pool configurado de forma maliciosa. Os routers e os position managers têm de validar currencies, definições de fees, endereços de hooks, remetentes de callback e deltas devolvidos. Um hook nunca deve confiar em identificadores de pool fornecidos pelo utilizador apenas porque uma chamada teve origem algures no sistema v4.
As primeiras implementações baseadas em hooks já mostraram que perdas reais não exigem uma falha no core do Uniswap v4. A Cork Protocol, que usava maquinaria customizada de mercado e de AMM ligada ao ecossistema v4, sofreu um exploit reportado em cerca de 12 milhões de dólares em 2025 depois de um atacante abusar da contabilidade e da lógica de mercado específicas do protocolo. A Bunni v2, um sistema de liquidez baseado em hooks, sofreu mais tarde uma perda reportada de cerca de 8,4 milhões de dólares ligada à contabilidade customizada de liquidez e de levantamentos. As classificações exatas e os montantes recuperados podem mudar à medida que os relatórios pós-incidente evoluem, mas ambos os casos reforçam o mesmo ponto. A lógica financeira customizada pode falhar enquanto o PoolManager subjacente se comporta conforme o previsto.
Outros modos de falha recorrentes incluem erros de arredondamento que podem ser repetidos para obter lucro, inputs de oracle desatualizados ou manipuláveis, negação de serviço que bloqueia operações normais, cálculos de fees que ultrapassam as expectativas económicas, chaves privilegiadas que podem alterar parâmetros e tokens com comportamento de transferência incomum. O risco de burla também continua simples. Um deployer pode publicar código de hooks copiado, anunciar uma auditoria que cobria um commit diferente, reter uma chave de upgrade ou criar um pool cujas condições de levantamento são deliberadamente hostis.
Padrões de menor risco: fees, intervalos e automação limitada
Risco relativo: baixo a médio. Hooks de fee dinâmica. Um hook de fee dinâmica altera a fee de swap de acordo com uma regra declarada, como volatilidade recente, tamanho da operação, desequilíbrio de inventário ou um oracle externo. Este padrão tem precedentes em automated market makers fora do v4, e uma atualização de fee não exige, por si só, que o hook tenha custódia dos ativos dos utilizadores. Uma fórmula simples e limitada, baseada em observações onchain, está entre os casos de uso mais defensáveis para hooks no Uniswap v4.
A ressalva é importante. Uma fee dinâmica ainda pode ser manipulada se um atacante conseguir distorcer a observação usada pela fórmula, e uma fee mal afinada pode tornar a execução inesperadamente cara. As regras de fee devem ter mínimos e máximos explícitos, intervalos de atualização previsíveis, proteção contra manipulação num único bloco e testes para mercados inativos ou ilíquidos. Os LPs também precisam de saber se um administrador pode substituir a fórmula ou sobrepor a fee.
Risco relativo: médio. Hooks de liquidez concentrada e de range-order. A liquidez concentrada permite que um LP forneça ativos apenas dentro de intervalos de preço selecionados. Um hook de range-order pode automatizar a adição, remoção ou reclamação de liquidez quando um limite de preço é cruzado, produzindo um comportamento semelhante a uma ordem limitada onchain. Isto pode reduzir a gestão manual, mas não garante execução a um preço escolhido, porque o preço pode atravessar um intervalo e inverter-se, as transações podem ser reordenadas, e as fees ou o deslizamento podem alterar o resultado.
As versões mais seguras usam permissões restritas, evitam alavancagem, mantêm as reclamações totalmente colateralizadas e disponibilizam cancelamento e levantamento mesmo quando a automação falha. Versões mais complexas reequilibram posições continuamente, compõem fees, emitem quotas de vault ou dependem de um keeper offchain. Essas adições empurram o design para um vault gerido e aumentam o seu risco. Os leitores que compararem este padrão devem também rever riscos da liquidez concentrada para LPs, incluindo perda impermanente, liquidez inativa e seleção adversa.
Padrões de maior risco: anti-MEV, TWAMMs e lending
Risco relativo: médio a alto. Padrões de hooks de fee dinâmica e anti-MEV. MEV, ou valor máximo extraível, é valor ganho ao controlar a ordem das transações. Um hook anti-MEV pode usar leilões em lote, ordens encriptadas, fluxos de ordens privados, passos de commit-and-reveal, speed bumps ou fees que sobem quando o comportamento de trading parece predatório. Estes mecanismos podem reduzir um ataque específico sob determinadas suposições, mas nenhum callback genérico consegue eliminar todo o MEV.
Um design anti-MEV pode simplesmente deslocar a confiança para outro lado. Um relay privado pode censurar ordens, um sequencer pode reter poder de ordenação, um leilão em lote pode depender de um solver e uma fórmula de deteção pode penalizar arbitragem legítima enquanto falha em detetar um atacante sofisticado. Os hooks de captura de MEV vão mais longe ao tentar redirecionar o valor de arbitragem para os LPs ou para outro destinatário. Isso cria questões sobre precisão do oracle, competição no leilão, inclusão de transações, contabilidade de rebates e quem controla a receita capturada. Estes designs precisam de testes económicos adversariais, bem como de uma auditoria de código convencional.
Risco relativo: alto. Hooks TWAMM. Um time-weighted average market maker, ou TWAMM, divide uma grande ordem em pequenas transações virtuais executadas ao longo do tempo. A ideia antecede o v4 e pode reduzir o impacto imediato de uma grande operação. Um hook pode manter o estado das ordens de longo prazo e liquidar partes dessas ordens quando os pools são tocados, mas tem de lidar com atividade escassa, cancelamento, execuções parciais, arredondamentos, crescimento de fees e movimento de preço entre intervalos de execução.
Risco relativo: muito alto. Hooks de lending usando o Uniswap v4 com Aave ou Compound. Um lending hook pode depositar liquidez ociosa num mercado de lending, pedir emprestado contra ativos dos LPs, encaminhar swaps através de posições colateralizadas ou ajustar automaticamente a dívida. A potencial eficiência de capital vem acompanhada de risco em camadas. O hook, o Uniswap v4, o protocolo de lending, o seu oracle, as mecânicas de liquidação, os tokens suportados e os controlos de governance podem falhar individualmente. A Aave ou o Compound podem ter sido amplamente revistos, mas o código de integração ainda pode aprovar o ativo errado, ler mal saldos que rendem juros, exceder limites de colateral seguros ou tornar os levantamentos indisponíveis quando os mutuantes mais precisam deles.
Como decidir se um hook está pronto para ser lançado
Comece pela autoridade, não pela descrição do produto. Identifique todos os callbacks, chamadas externas, aprovações de ativos, funções administrativas, mecanismos de upgrade, oracles, keepers e controlos de emergência. Determine se o hook pode assumir custódia, criar dívida, devolver deltas customizados, bloquear levantamentos, alterar fees sem atraso ou redirecionar receitas. Se a documentação não conseguir responder a estas questões ao nível do endereço implantado, os LPs não têm informação suficiente para avaliar o pool.
Os rótulos de auditoria exigem uma leitura cuidadosa. O core do Uniswap v4 e os componentes oficiais de periphery receberam revisões de várias equipas de segurança e testes extensivos, mas essas revisões não se estendem automaticamente a hooks de terceiros. Bibliotecas importantes, como as utilities de hooks v4 da OpenZeppelin, podem fornecer blocos de construção revistos, mas o estado do repositório, o âmbito, a versão e as exclusões têm de ser verificados no momento do deployment. Exemplos experimentais de hackathons, incubadoras, repositórios de templates ou projetos de investigação não devem ser descritos como auditados para produção a menos que um relatório publicado cubra o commit e a configuração exatos.
Um deployment credível deve fornecer verificação do código-fonte, testes para invariantes de callback e de liquidação, fuzzing, uma auditoria independente, prova de remediação e um bug bounty significativo. O fuzzing stateful é especialmente útil porque gera longas sequências de swaps, depósitos, levantamentos, cancelamentos e chamadas externas para encontrar estados que testes unitários normais ignoram. Para sistemas de lending ou de MEV, a revisão deve incluir também ataques económicos, manipulação de oracle, stress de liquidação e períodos em que a infraestrutura externa deixa de responder.
Os LPs devem ainda dimensionar a exposição em função da falha, e não do marketing da auditoria. Prefira controlos imutáveis ou com atrasos muito curtos, depósitos limitados durante a fase inicial, aprovações de tokens isoladas e um caminho de saída claro. Evite hooks não auditados com poderes relevantes de custódia ou de endividamento. A posse de UNI não oferece seguro direto contra uma falha de hook, e a visibilidade de governance não deve ser confundida com responsabilidade pelo código de terceiros. Isto é um enquadramento de risco técnico, não aconselhamento financeiro.
Acompanhe o risco dos hooks da Uniswap v4 com melhor contexto
O desenvolvimento da Uniswap v4 muda rapidamente, e uma manchete sobre um lançamento, auditoria, exploit, pausa ou integração raramente diz aos LPs qual contrato e qual pressuposto são afetados. A Zippfeed organiza a cobertura relacionada com Uniswap, UNI, DeFi e hooks com classificação de sentimento bullish, neutral ou bearish, além de uma avaliação de importância, ajudando-o a distinguir atualizações de segurança relevantes de promoção rotineira antes de rever por si próprio o código principal e os relatórios.
CoinTelegraph
CoinDesk
