Qué problema intenta resolver Uniswap v4
Uniswap v3 fue un avance en eficiencia de capital. La liquidez concentrada permitía a los LP concentrar sus depósitos dentro de un rango de precios elegido, de modo que los mismos dólares podían generar más comisiones que una posición de rango completo al estilo de la v2. La contrapartida era la complejidad: gestionar los rangos, vigilar la pérdida impermanente y pagar gas para rebalancear.
El diseño de la v3 también tenía una limitación estructural en la que pocos usuarios minoristas llegaron a pensar. Cada nuevo pool era un nuevo contrato inteligente, desplegado por el factory de la v3. Cientos de pools significaban cientos de contratos, cada uno con su propio almacenamiento, y cada swap tenía que saltar entre contratos para enrutar a través de los pares. Esto encarecía el gas justo en el momento en el que Ethereum intentaba escalar las Layer 2.
Uniswap v4 rediseña el mecanismo en torno a ese problema. En lugar de un contrato por pool, el protocolo colapsa prácticamente todo en un único contrato, el singleton, que concentra toda la liquidez y despacha cada acción a través de un único punto de entrada. Los hooks son la característica que hace que ese rediseño sea lo bastante flexible como para mantener la variedad que tenía la v3, sin la sobrecarga de despliegue.
Cómo cambia el diseño singleton de la v4 el protocolo
El cambio arquitectónico estrella de la v4 es el singleton. En la v3, desplegar un nuevo pool significaba desplegar un nuevo contrato. En la v4, los pools son, en la práctica, registros dentro de un único contrato, y ese mismo contrato gestiona cada swap, mint y burn. Esto tiene tres consecuencias prácticas para los usuarios.
En primer lugar, los swaps multi-hop resultan más baratos. Un swap que iba de USDC a WETH y luego a UNI solía tocar dos o tres contratos de pool. En la v4, toca uno solo. Parece un detalle de fontanería, pero en mainnet puede marcar la diferencia entre que un swap sea económicamente viable o que el usuario termine yendo a una Layer 2 o a un exchange centralizado.
En segundo lugar, el singleton puede mantener ETH nativo en lugar de WETH envuelto. La contabilidad del pool era antes una historia de tokens envueltos, porque cada acción necesitaba un contrato que pudiera recibir transferencias ERC-20. Con un único contrato y un modelo de flash accounting, el singleton puede acreditar y debitar ETH directamente, ahorrando a los usuarios el gas de envolver y desenvolver.
En tercer lugar, el gas se reduce aún más gracias a un patrón de almacenamiento transitorio que el equipo denomina "flash accounting". En lugar de mover tokens hacia dentro y hacia fuera del pool en cada acción, el singleton registra los deltas internamente y solo liquida los saldos de tokens al final de la transacción. El resultado neto es que swapear en la v4 resulta apreciablemente más barato que en la v3, lo cual importa para los LP activos y para las estrategias que rebalancean con frecuencia.
Sin embargo, hay un compromiso fácil de pasar por alto. Concentrar todo el DEX en un único contrato también concentra el radio de impacto de un bug. Una vulnerabilidad grave en el singleton sería una vulnerabilidad en todos los pools de la v4 a la vez. Es la imagen especular arquitectónica del riesgo fragmentado de la v3, y es parte de la razón por la que el equipo invirtió más de un año en auditorías antes del despliegue más amplio.
Qué es realmente un hook de Uniswap v4
Un hook es un contrato inteligente al que el singleton llama en puntos específicos del ciclo de vida de un pool. Los eventos del ciclo de vida que expone el protocolo incluyen beforeSwap e afterSwap, beforeModifyLiquidity e afterModifyLiquidity, y beforeDonate e afterDonate. Un hook se registra en un pool, y el singleton lo invoca en el paso correspondiente.
Puedes pensar en un pool en v4 como compuesto por hooks y una posición de liquidez. El pool sigue utilizando la matemática de producto constante por la que Uniswap es conocido, a menos que el hook la modifique. El hook puede leer los parámetros del swap, leer el estado del pool y devolver un resultado que el singleton utilizará. Fundamentalmente, el hook también puede rechazar la acción revirtiendo la transacción.
Para que esto funcione, el equipo de v4 introdujo un sistema de permisos para hooks. Cada dirección de hook codifica qué eventos del ciclo de vida implementa, y el singleton utiliza los bits bajos de la dirección del hook para consultar una marca que indica qué callbacks disparar. Es un truco de optimización de gas, pero también significa que los permisos de un hook son visibles solo a partir de su dirección, lo cual resulta útil para integradores y paneles.
Para los desarrolladores, el modelo práctico es este: despliegas un contrato que implementa los callbacks que te interesan, lo registras en el pool que quieres personalizar, y a partir de ese momento, cada acción en el pool pasa por tu código. Básicamente estás construyendo un AMM pequeño, o un gestor de mercado automatizado, sobre la capa de liquidación de Uniswap.
Lo que los hooks realmente permiten: AMMs personalizados y comisiones dinámicas
El argumento de marketing en torno a los hooks es que "Uniswap se convierte en una plataforma en lugar de un producto". Esto es mayormente cierto, y la forma más sencilla de entender por qué es recorrer lo que los hooks pueden hacer realmente.
Comisiones dinámicas y por niveles. Un hook puede cambiar la comisión cobrada en un swap según las condiciones. Por ejemplo, un hook para stablecoins podría cobrar una fracción de punto básico cuando el precio está cerca del peg, y una comisión más alta cuando la volatilidad es elevada. Un hook también podría cobrar una comisión diferente según si el swap mueve el precio al alza o a la baja, lo cual es una forma primitiva de captura de MEV para los LPs.
Curvas AMM personalizadas. El pool v4 por defecto sigue usando la fórmula de producto constante x*y=k, pero un hook puede ejecutar en la práctica cualquier modelo de precios. Puedes construir una invariante tipo stableswap para pares de baja volatilidad, una curva híbrida estilo Curve, una curva gaussiana o de reversión a la media para activos sintéticos, o incluso un hook que siga un oráculo externo por completo. El pool se convierte en un venue de liquidez de propósito general, con Uniswap aportando la liquidación, el enrutamiento y el modelo de seguridad del singleton.
Órdenes limit onchain y TWAMM. Un hook beforeModifyLiquidity puede convertir adiciones de liquidez de un solo tick en órdenes limit: el LP especifica un rango de precios, y el hook mintea y quema posiciones a medida que el precio de mercado cruza ese rango. Las estrategias de market maker con promedio ponderado en el tiempo, en las que una orden grande se divide en muchos swaps pequeños a lo largo de horas, también pueden expresarse como un hook.
Oráculos onchain y protecciones para LPs. Un hook puede escribir un TWAP, un VWAP o cualquier otra estadística en almacenamiento en cada swap, que otros contratos pueden leer de forma económica. Los hooks también pueden imponer reglas como "no se permiten swaps en el último bloque de una ventana de 1 minuto", que es una forma rudimentaria pero útil de protección anti-MEV, o implementar kill switches que pausen un pool si se cumplen ciertas condiciones.
ETH nativo y reembolsos de gas. Dado que el singleton mantiene ETH, los hooks pueden implementar reembolsos de gas en ETH para los LPs, o pagar recompensas de MEV en ETH en lugar del token intercambiable. Esto es pequeño para un usuario individual, pero es una palanca estructural para los diseñadores de protocolos que intentan atraer liquidez.
Nada de esto es automático. Cada función mencionada requiere que un desarrollador construya, despliegue y mantenga un hook. Uniswap está enviando un toolkit, no una lista de funciones.
Los riesgos de seguridad del código de hooks no auditados
Cada hook nuevo es una nueva superficie de contrato inteligente, y esa es la parte de la historia de v4 que merece mayor atención. En v3, los contratos que custodiaban la liquidez eran un conjunto relativamente pequeño y bien auditado. En v4, cualquiera puede registrar un hook en un pool, y ese hook ejecuta código en la ruta crítica de cada swap, mint y burn de ese pool.
Los riesgos se agrupan en varias categorías, y los LPs deberían conocer cada una antes de depositar en un pool con hooks habilitado.
Errores de lógica en el hook. Un bug en beforeSwap o beforeModifyLiquidity puede corromper la contabilidad del pool, permitir retiros que superen los depósitos, o congelar el pool por completo. Como el singleton es la fuente de verdad, el hook no puede robar tokens directamente, pero sí puede dejar al pool en un estado explotable mediante una transacción posterior, a menudo dentro del mismo bloque.
Reentrancia e interferencia entre hooks. Los hooks son contratos externos, y un hook malicioso puede reentrar al singleton o llamar a otros hooks del mismo pool. El protocolo tiene bloqueos de reentrancia, pero la superficie de interacción entre hooks es nueva y no toda ella ha sido probada en batalla. Dos hooks unidos al mismo pool, por ejemplo, pueden componerse de formas que ninguna auditoría individual cubrió.
Claves de administrador y capacidad de upgrade. Muchos hooks se despliegan con una dirección de owner que puede cambiar parámetros, pausar el comportamiento o actualizar el contrato. Una clave de administrador es un punto único de fallo: una clave comprometida puede cambiar el comportamiento del hook mientras el pool sigue activo, y los LPs pueden no tener una forma limpia de retirar fondos antes de que el cambio surta efecto. Un multisig con timelock es mejor que un EOA, pero sigue siendo confianza.
Manipulación de oráculos. Los hooks que leen oráculos externos, o que cambian comisiones según el precio, son tan seguros como el oráculo. Un oráculo manipulado puede engañar a un hook para que cobre un swap con comisión cero que drene a los LPs, o para que bloquee al pool en un estado que beneficie al atacante.
Riesgo concentrado dentro del singleton. Un bug en un hook que afecte a un pool sigue afectando a un solo pool. Pero ciertas clases de bugs, especialmente los que interactúan con la contabilidad del singleton sobre el ETH nativo, podrían en principio extenderse a muchos pools a la vez. Esto no es exclusivo de v4, pero el singleton hace que la topología sea más peligrosa que el diseño por pool de v3.
El resumen honesto es que los hooks son la parte de v4 que un usuario casual no puede evaluar por sí mismo. "Este pool usa un hook" no es una etiqueta que deba ignorarse. La suposición más segura es tratar cualquier hook como un contrato inteligente de terceros que tiene custodia de la ruta del swap, y sopesar el riesgo adicional frente al rendimiento adicional.
MEV, protección para LPs y el upside realista
El valor máximo extraíble, el beneficio que los productores de bloques y los searchers pueden capturar reordenando, insertando o censurando transacciones, es uno de los costes de fondo persistentes para los LPs. Los ataques sándwich, en particular, extraen valor de los swaps operando antes y después de la transacción del usuario. Los LPs absorben la pérdida porque el precio efectivo del pool es peor que el precio que el usuario acordó.
Los hooks son una herramienta creíble para reducir ese coste. Un hook beforeSwap puede comprobar si la transacción forma parte de un sándwich, usando esquemas commit-reveal, memos firmados o rutas de transacción privadas, y revertir el swap si detecta uno. Un hook también puede forzar que los swaps solo se ejecuten en ciertas posiciones de bloque, cobrar comisiones más altas a transacciones que parezcan sándwiches, o dividir swaps grandes en fragmentos atómicos más pequeños que sean más difíciles de atacar con sándwiches.
Por el otro lado, los hooks también son una nueva superficie de MEV. Un hook con acceso privilegiado a los parámetros del swap y al estado del pool puede ser utilizado por su operador para hacer front-running a los usuarios en ese pool. El protocolo no puede evitar esto del mismo modo que no puede evitar que un operador de oráculo manipule un oráculo. La mitigación es la misma que en el resto de DeFi: reputación, auditorías, monitorización pública y una comunidad dispuesta a retirar liquidez cuando un hook se comporta mal.
El upside realista para LPs serios es real pero acotado. Un hook bien diseñado en un pool profundo puede reducir de forma significativa la selección adversa, que es el término técnico para "mi operación fue cazada". Eso se traduce en un APR neto mayor, a veces de varios puntos porcentuales. No es un truco de magia, y no sustituye a entender el pool en el que estás.
Qué significa esto para los proveedores de liquidez y los desarrolladores
Si eres un LP, el mundo de v4 exige un flujo de trabajo ligeramente distinto al de v3. Antes de depositar, deberías poder responder a cuatro preguntas. ¿Qué hook está asociado a este pool y qué hace realmente? ¿Quién puede cambiar los parámetros del hook y en qué plazo? ¿Se ha auditado el hook y por quién? ¿Cuál es el modo de fallo si el hook deja de funcionar por completo, sigue siendo retirable tu posición?
Si la respuesta a cualquiera de ellas es «no lo sé», el pool no es el lugar adecuado para estacionar la mayor parte de tu capital. El rendimiento que proviene de un hook sobre el que no puedes razonar es un rendimiento que puede desaparecer de la noche a la mañana. El mismo consejo que aplicaba a v3 se aplica aún más a v4: dimensiona las posiciones según lo que estarías dispuesto a perder en el peor escenario de un fallo de smart contract, no según el APY titular.
Si eres desarrollador, los hooks son una auténtica expansión del espacio de diseño. Puedes lanzar un AMM personalizado en semanas en lugar de meses, puedes iterar sobre curvas de precios sin hacer un fork de Uniswap, y puedes componer con el router de v4 existente, lo que te da acceso a liquidez que de otro modo tendrías que conseguir por tu cuenta. La trampa es que también estás lanzando un producto de seguridad. Los equipos de hooks más minuciosos del ecosistema de v4 tratan las auditorías, los programas de bug bounty y la respuesta a incidentes como parte del producto, no como un sobrecoste.
Una nota práctica para ambos grupos: v4 es intencionadamente más permissionless que v3, y el equipo ha dejado claro que no curará una lista predeterminada de hooks «aprobados». Se espera que el mercado haga ese trabajo a través de la reputación, los dashboards y los agregadores. Hasta que esas señales maduren, cada decisión sobre un hook es una decisión de riesgo personal.
Cómo seguir los hooks de Uniswap v4 de forma inteligente
Los hooks de Uniswap v4 se mueven rápido, y las noticias sobre ellos también. Nuevos diseños de hooks, auditorías, exploits y migraciones se anuncian en foros de investigación, hilos de gobernanza y blogs de proyectos, y leer cada uno de forma aislada es una batalla perdida. Zippfeed muestra los titulares sobre hooks de Uniswap v4 con puntuación de sentimiento (bullish, neutral o bearish) y una calificación de importancia, para que puedas separar los avances genuinos del protocolo del bombo publicitario y rastrear qué hooks están ganando liquidez real frente a cuota de marketing.
