Que problema o Uniswap v4 tenta resolver
O Uniswap v3 foi um passo em frente em eficiência de capital. A liquidez concentrada permitiu aos LPs concentrarem os seus depósitos dentro de um intervalo de preços escolhido, para que os mesmos dólares ganhassem mais taxas do que uma posição de intervalo completo ao estilo v2. A contrapartida era a complexidade: gerir intervalos, vigiar a perda impermanente e pagar gas para reequilibrar.
O design do v3 também tinha uma limitação estrutural em que poucos utilizadores de retalho pensavam. Cada nova pool era um novo contrato inteligente, implementado pela fábrica do v3. Centenas de pools significavam centenas de contratos, cada um com o seu próprio armazenamento, e cada swap tinha de saltar entre contratos para encaminhar entre pares. Isto tornava o gas caro no momento exato em que o Ethereum estava a tentar escalar a Layer 2.
O Uniswap v4 redesenha a arquitetura em torno desse problema. Em vez de um contrato por pool, o protocolo condensa quase tudo num único contrato, o singleton, que detém toda a liquidez e despacha cada ação através de um único ponto de entrada. Os hooks são a funcionalidade que torna este redesenho flexível o suficiente para manter a variedade que o v3 tinha, sem o custo de implementação.
Como o design singleton do v4 altera o protocolo
A principal mudança arquitetónica no v4 é o singleton. No v3, implementar uma nova pool significava implementar um novo contrato. No v4, as pools são, na prática, registos dentro de um contrato, e o mesmo contrato trata de cada swap, mint e burn. Isto tem três consequências práticas para os utilizadores.
Primeiro, os swaps multi-hop ficam mais baratos. Um swap que vai de USDC para WETH para UNI costumava tocar em dois ou três contratos de pool. No v4, toca num só. Pode parecer um detalhe de plumbing, mas na mainnet pode ser a diferença entre um swap ser economicamente viável e um utilizador ser empurrado para uma Layer 2 ou para uma exchange centralizada.
Segundo, o singleton pode deter ETH nativo em vez de WETH wrapped. A contabilidade da pool era, anteriormente, uma história de tokens wrapped, porque cada ação precisava de um contrato que pudesse receber transferências ERC-20. Com um contrato e um modelo de flash accounting, o singleton pode creditar e debitar ETH diretamente, poupando aos utilizadores o gas de wrap e unwrap.
Terceiro, o gas é ainda mais reduzido por um padrão de armazenamento transitório que a equipa designa de "flash accounting". Em vez de mover tokens para dentro e fora da pool em cada ação, o singleton regista os deltas internamente e só liquida os saldos dos tokens no final de uma transação. O resultado final é que o v4 é consideravelmente mais barato para fazer swap do que o v3, o que é relevante para LPs ativos e para estratégias que reequilibram com frequência.
Há, contudo, uma contrapartida fácil de ignorar. Concentrar toda a DEX num único contrato também concentra o raio de impacto de um bug. Uma vulnerabilidade grave no singleton seria uma vulnerabilidade em todas as pools do v4 em simultâneo. Esta é a imagem espelhada arquitetónica do risco fragmentado do v3, e é parte da razão pela qual a equipa dedicou mais de um ano a auditorias antes do lançamento mais alargado.
O que é efetivamente um hook da Uniswap v4
Um hook é um contrato inteligente que o singleton chama em pontos específicos do ciclo de vida de uma pool. Os eventos do ciclo de vida que o protocolo expõe incluem beforeSwap e afterSwap, beforeModifyLiquidity e afterModifyLiquidity, e beforeDonate e afterDonate. Um hook regista-se junto de uma pool, e o singleton encaminha a execução para esse hook no passo relevante.
Pode pensar numa pool na v4 como tendo hooks e uma posição de liquidez. A pool continua a usar a matemática de produto constante pela qual a Uniswap é conhecida, a menos que o hook a altere. O hook pode ler os parâmetros do swap, ler o estado da pool e devolver um resultado que o singleton depois utiliza. Crucialmente, o hook também pode rejeitar a ação ao reverter a transação.
Para que isto funcione, a equipa da v4 introduziu um sistema de permissões dos hooks. Cada endereço de hook codifica quais os eventos do ciclo de vida que implementa, e o singleton usa os bits menos significativos do endereço do hook para consultar uma flag que indica quais os callbacks a disparar. Trata-se de um truque de otimização de gas, mas também significa que as permissões de um hook são visíveis apenas a partir do seu endereço, o que é útil para integradores e dashboards.
Para os programadores, o modelo prático é este: implementa um contrato que executa os callbacks que lhe interessam, regista-o na pool que pretende personalizar e, a partir desse momento, cada ação sobre a pool passa pelo seu código. Está, na prática, a construir um pequeno AMM — um gestor de mercado automatizado — sobre a camada de liquidação da Uniswap.
O que os hooks realmente permitem: AMMs personalizados e fees dinâmicas
O discurso de marketing em torno dos hooks é que "a Uniswap se torna uma plataforma em vez de um produto." Isso é maioritariamente verdade, e a forma mais simples de perceber porquê é percorrer o que os hooks podem realmente fazer.
Fees dinâmicas e escalonadas. Um hook pode alterar a fee cobrada num swap com base em condições. Por exemplo, um hook para stablecoins poderia cobrar uma fração de basis point quando o preço está próximo da paridade, e uma fee mais elevada quando a volatilidade é alta. Um hook também poderia cobrar uma fee diferente consoante o swap mova o preço para cima ou para baixo, o que constitui uma forma primitiva de captura de MEV para os LPs.
Curvas de AMM personalizadas. A pool v4 padrão continua a usar a fórmula de produto constante x*y=k, mas um hook pode, na prática, executar qualquer modelo de preços. Pode construir um invariante do tipo stableswap para pares de baixa volatilidade, uma curva híbrida ao estilo Curve, uma curva gaussiana ou de reversão à média para ativos sintéticos, ou até um hook que segue um oráculo externo na íntegra. A pool torna-se um local de liquidez de uso geral, com a Uniswap a fornecer a liquidação, o routing e o modelo de segurança do singleton.
Ordens-limite onchain e TWAMM. Um hook beforeModifyLiquidity pode converter adições de liquidez de tick único em ordens-limite: o LP especifica um intervalo de preços, e o hook cria e queima posições à medida que o preço de mercado atravessa esse intervalo. Estratégias de time-weighted average market maker, em que uma ordem grande é fragmentada em muitos swaps pequenos ao longo de horas, também podem ser expressas como um hook.
Oráculos onchain e proteções para LPs. Um hook pode escrever um TWAP, um VWAP ou qualquer outra estatística em storage em cada swap, que outros contratos podem ler de forma barata. Os hooks também podem impor regras como "nenhum swap no último bloco de uma janela de 1 minuto", que é uma forma rudimentar mas útil de proteção anti-MEV, ou implementar kill switches que pausam uma pool se determinadas condições forem cumpridas.
ETH nativo e reembolsos de gas. Como o singleton detém ETH, os hooks podem implementar rebates de gas em ETH para os LPs, ou pagar recompensas de MEV em ETH em vez do token trocável. Para um utilizador individual isto é marginal, mas é uma alavanca estrutural para designers de protocolos que tentam atrair liquidez.
Nada disto é automático. Cada funcionalidade acima exige que um programador construa, implemente e mantenha um hook. A Uniswap está a enviar um toolkit, não uma lista de funcionalidades.
Os riscos de segurança de código de hook não auditado
Cada novo hook é uma nova superfície de contrato inteligente, e essa é a parte da história da v4 que merece mais atenção. Na v3, os contratos que detinham a liquidez eram um conjunto relativamente pequeno e bem auditado. Na v4, qualquer pessoa pode registar um hook numa pool, e esse hook passa a executar código no caminho crítico de cada swap, mint e burn dessa pool.
Os riscos enquadram-se em algumas categorias, e os LPs devem conhecer cada uma delas antes de depositarem numa pool com hooks.
Bugs de lógica no hook. Um bug em beforeSwap ou beforeModifyLiquidity pode corromper a contabilidade da pool, permitir levantamentos que excedem os depósitos, ou congelar a pool por completo. Como o singleton é a fonte de verdade, o hook não pode roubar tokens diretamente, mas pode ainda assim deixar a pool num estado explorável por uma transação seguinte, frequentemente dentro do mesmo bloco.
Reentrância e interferência entre hooks. Os hooks são contratos externos, e um hook malicioso pode reentrar no singleton ou chamar outros hooks na mesma pool. O protocolo tem bloqueios de reentrância, mas a superfície de interação entre hooks é nova e nem toda ela foi testada em batalha. Dois hooks ligados à mesma pool, por exemplo, podem compor-se de formas que nenhuma auditoria individual cobriu.
Chaves de administrador e possibilidade de upgrade. Muitos hooks são implementados com um endereço de owner que pode alterar parâmetros, pausar o comportamento ou fazer upgrade do contrato. Uma chave de administrador é um ponto único de falha: uma chave comprometida pode alterar o comportamento do hook enquanto a pool continua ativa, e os LPs podem não ter uma forma clara de levantar os fundos antes de a alteração entrar em vigor. Uma multisig com timelock é melhor do que uma EOA, mas continua a ser confiança.
Manipulação de oráculos. Hooks que leem oráculos externos, ou que alteram fees com base no preço, são tão seguros quanto o oráculo. Um oráculo manipulado pode levar um hook a cobrar um swap de fee zero que esgota os LPs, ou a bloquear a pool num estado que beneficia o atacante.
Risco concentrado dentro do singleton. Um bug de hook que afeta uma pool continua a afetar uma pool. Mas certas classes de bugs, sobretudo os que interagem com a contabilidade de ETH nativo do singleton, podem, em princípio, propagar-se por muitas pools em simultâneo. Isto não é exclusivo da v4, mas o singleton torna a topologia mais perigosa do que o design por pool da v3.
O resumo honesto é que os hooks são a parte da v4 que um utilizador casual não consegue avaliar por si próprio. "Esta pool usa um hook" não é um rótulo que deva ser ignorado. A suposição mais segura é tratar qualquer hook como um contrato inteligente de terceiros que tem custódia sobre o caminho do swap, e ponderar o risco adicional face ao rendimento adicional.
MEV, proteção dos LPs e o upside realista
Maximal extractable value — o lucro que produtores de blocos e searchers podem capturar ao reordenar, inserir ou censurar transações — é um dos custos de fundo persistentes para os LPs. Os ataques sandwich, em particular, extraem valor dos swaps ao negociar antes e depois da transação do utilizador. Os LPs absorvem o prejuízo porque o preço efetivo da pool é pior do que o preço que o utilizador aceitou.
Os hooks são uma ferramenta credível para reduzir esse custo. Um hook beforeSwap pode verificar se a transação faz parte de um sandwich, usando esquemas commit-reveal, memos assinados ou caminhos de transação privados, e reverter o swap se detetar um. Um hook pode também impor que os swaps só se concretizem em certas posições dentro do bloco, cobrar fees mais elevadas a transações que pareçam sandwiches, ou dividir swaps grandes em pedaços atómicos mais pequenos e mais difíceis de sandwichar.
Do outro lado, os hooks são também uma nova superfície de MEV. Um hook com acesso privilegiado aos parâmetros do swap e ao estado da pool pode ser usado pelo seu operador para fazer front-run dos utilizadores nessa pool. O protocolo não pode impedir isto da mesma forma que não pode impedir um operador de oráculos de manipular um oráculo. A mitigação é a mesma do resto da DeFi: reputação, auditorias, monitorização pública e uma comunidade disposta a retirar liquidez quando um hook se comporta mal.
O upside realista para LPs sérios existe, mas é limitado. Um hook bem desenhado numa pool profunda pode reduzir de forma significativa a adverse selection — o termo técnico para "a minha trade foi apanhada." Isto traduz-se numa APR líquida mais alta, por vezes em vários pontos percentuais. Não é um truque de magia, nem substitui a compreensão da pool em que está.
O que isto significa para fornecedores de liquidez e programadores
Se é um LP, o mundo v4 exige um fluxo de trabalho ligeiramente diferente do v3. Antes de depositar, deve conseguir responder a quatro perguntas. Que hook está associado a este pool, e o que faz de facto? Quem pode alterar os parâmetros do hook, e em que prazo? O hook foi auditado, e por quem? Qual é o modo de falha se o hook deixar de funcionar por completo — a sua posição ainda é levantável?
Se a resposta a qualquer uma destas for "não sei", o pool não é o lugar certo para estacionar a maior parte do seu capital. Rendimentos que vêm de um hook sobre o qual não consegue raciocinar são rendimentos que podem desaparecer de um dia para o outro. O mesmo conselho que se aplicava ao v3 aplica-se ainda mais ao v4: dimensione as posições para aquilo que estaria disposto a perder no pior cenário de bug num contrato inteligente, e não para a APY em destaque.
Se é um programador, os hooks são uma expansão genuína do espaço de design. Pode lançar uma AMM personalizada em semanas em vez de meses, pode iterar sobre curvas de preço sem fazer fork do Uniswap, e pode compor com o router v4 existente, o que lhe dá acesso a liquidez que, de outra forma, teria de bootstrappar sozinho. A contrapartida é que também está a lançar um produto de segurança. As equipas de hooks mais ponderadas no ecossistema v4 estão a tratar auditorias, programas de recompensas por bugs e resposta a incidentes como parte do produto, e não como sobrecarga.
Uma nota prática para ambos os grupos: o v4 é intencionalmente mais permissionless do que o v3, e a equipa tem sido clara ao afirmar que não vai curar uma lista predefinida de hooks "aprovados". Espera-se que o mercado faça esse trabalho através de reputação, dashboards e agregadores. Até que esses sinais amadureçam, cada decisão sobre um hook é uma decisão pessoal de risco.
Como seguir os hooks do Uniswap v4 da forma inteligente
Os hooks do Uniswap v4 movem-se depressa, e as notícias sobre eles também. Novos designs de hooks, auditorias, exploits e migrações são anunciados em fóruns de investigação, tópicos de governação e blogs de projetos, e ler cada um isoladamente é um jogo perdido. A Zippfeed destaca as manchetes sobre hooks do Uniswap v4 com pontuação de sentimento (bullish, neutral ou bearish) e uma classificação de importância, para que possa separar desenvolvimentos genuínos do protocolo do hype e acompanhar que hooks estão a ganhar liquidez real em vez de quota de marketing.
