Casos de uso reales de Uniswap v4 Hooks, según su riesgo

En qué convierte realmente un pool el sistema de hooks de Uniswap v4

Los hooks de Uniswap v4 son contratos inteligentes que pueden ejecutarse en puntos definidos del ciclo de vida de un pool. Un hook puede ejecutarse antes o después de que un pool se inicialice, cambie la liquidez, se produzca un swap o se haga una donación. Esto permite a un desarrollador añadir lógica como comisiones dinámicas, órdenes de estilo limit, operaciones fraccionadas en el tiempo, controles de acceso, actualizaciones de oráculos o actividad externa de lending sin modificar el core de Uniswap v4.

Esta descripción puede hacer que los hooks parezcan complementos. Desde el punto de vista financiero, se parecen más a motores de políticas programables. Un pool básico de Uniswap sigue reglas de contabilidad conocidas, mientras que un pool con hooks puede imponer reglas adicionales, mover activos, calcular sus propios deltas o interactuar con otro protocolo. Por eso, dos pools que mantienen los mismos tokens pueden tener perfiles de seguridad y liquidez completamente distintos.

La pregunta útil no es si los hooks son buenos o malos. Es cuánta autoridad tiene un hook concreto, cuántos supuestos externos introduce y qué ocurre cuando esos supuestos fallan. La clasificación siguiente considera los hooks más sencillos con permisos limitados como relativamente de menor riesgo, no como seguros, y sitúa la custodia, el apalancamiento, el crédito, la contabilidad compleja o los poderes de actualización en el extremo de mayor riesgo.

Cómo funciona el sistema de hooks y dónde entra el riesgo

Uniswap v4 utiliza una arquitectura singleton, lo que significa que muchos pools se gestionan a través de un único contrato central PoolManager en lugar de desplegar cada pool como un contrato independiente. La flash accounting registra las obligaciones netas de tokens durante una transacción y las liquida antes de que la operación se complete. Esto puede reducir el gas y hacer más eficientes las operaciones con varios pools, pero también significa que los desarrolladores de hooks deben entender con precisión las reglas de bloqueo, liquidación y delta de balances.

Un pool elige su contrato de hook cuando se crea. La dirección del hook codifica qué callbacks están habilitados, y esos permisos no pueden tratarse simplemente como etiquetas descriptivas. El código que se ejecuta en los callbacks puede rechazar una acción, alterar comisiones, devolver deltas de tokens personalizados, actualizar registros internos o llamar a otro contrato. Un error en cualquiera de esas rutas puede afectar a los swaps, a las retiradas de liquidez o a la liquidación.

Los hooks también pueden usar contabilidad personalizada para cambiar el resultado económico entregado por el PoolManager. Esto es lo bastante potente como para reproducir funciones asociadas a otros diseños de automated market maker, pero amplía la base de código de confianza. Si un hook mantiene balances virtuales, comisiones acumuladas, reclamaciones de órdenes, posiciones de deuda o participaciones en recompensas, los usuarios dependen de que tanto la contabilidad de Uniswap como la del hook sigan siendo coherentes.

El singleton no significa que un hook malicioso pueda reescribir automáticamente todos los pools de Uniswap v4. Los pools siguen separados lógicamente, y los permisos de callback limitan cuándo se ejecuta el código del hook. Aun así, las integraciones que agrupan llamadas, reutilizan routers, aprueban allowances amplios de tokens o asumen que todos los pools v4 se comportan igual pueden crear vías de fallo compartidas. Los desarrolladores deben modelar la ruta completa de la transacción, no solo la función callback del hook.

Los riesgos que desarrolladores y LPs deberían examinar primero

La reentrada en hooks es una preocupación principal. La reentrada ocurre cuando una llamada externa vuelve a entrar en un contrato antes de que la operación original haya terminado de actualizar su estado. Uniswap v4 tiene reglas de bloqueo y liquidación, pero un hook puede llamar a tokens, routers, mercados de préstamo u otros hooks con su propio comportamiento de callback. Una protección local contra reentrada no es suficiente si el diseño permite cambios de estado entre funciones o entre protocolos en un orden inesperado.

El riesgo del singleton pool es en parte un riesgo de integración. El PoolManager auditado puede hacer cumplir sus invariantes mientras una aplicación calcula mal lo que debe durante un bloqueo, confunde el estado de un pool con el de otro o acepta un pool configurado de forma maliciosa. Los routers y gestores de posiciones deben validar divisas, ajustes de comisiones, direcciones de hooks, remitentes de callbacks y deltas devueltos. Un hook nunca debería confiar en identificadores de pool proporcionados por el usuario solo porque una llamada se originó en algún punto del sistema v4.

Los primeros despliegues basados en hooks ya han mostrado que las pérdidas reales no requieren un fallo en el núcleo de Uniswap v4. Cork Protocol, que usaba mecanismos personalizados de mercado y AMM conectados al ecosistema v4, sufrió un exploit valorado en alrededor de 12 millones de dólares en 2025 después de que un atacante abusara de la contabilidad y la lógica de mercado específicas del protocolo. Bunni v2, un sistema de liquidez basado en hooks, sufrió posteriormente una pérdida reportada de unos 8,4 millones de dólares vinculada a la contabilidad personalizada de liquidez y retiradas. Las clasificaciones exactas y las cantidades recuperadas pueden cambiar a medida que evolucionan los análisis post mortem, pero ambos casos refuerzan la misma idea: la lógica financiera personalizada puede fallar mientras el PoolManager subyacente se comporta según lo previsto.

Otros modos de fallo recurrentes incluyen errores de redondeo que pueden repetirse para obtener beneficio, entradas de oráculo obsoletas o manipulables, denegación de servicio que bloquea operaciones normales, cálculos de comisiones que superan las expectativas económicas, claves privilegiadas que pueden cambiar parámetros y tokens con comportamientos de transferencia inusuales. El riesgo de estafa también sigue siendo directo. Un desplegador puede publicar código de hook copiado, anunciar una auditoría que cubría un commit distinto, conservar una clave de actualización o crear un pool cuyas condiciones de retirada sean intencionadamente hostiles.

Patrones de menor riesgo: comisiones, rangos y automatización limitada

Riesgo relativo: bajo a medio. Hooks de comisiones dinámicas. Un hook de comisiones dinámicas cambia la comisión de swap según una regla establecida, como la volatilidad reciente, el tamaño de la operación, el desequilibrio de inventario o un oráculo externo. El patrón tiene precedentes en automated market makers fuera de v4, y una actualización de comisiones no exige inherentemente que el hook custodie activos de usuarios. Una fórmula sencilla con límites que use observaciones onchain se encuentra entre los casos de uso de hooks de Uniswap v4 más defendibles.

La matización es importante. Una comisión dinámica aún puede manipularse si un atacante puede distorsionar la observación utilizada por la fórmula, y una comisión mal ajustada puede hacer que la ejecución sea inesperadamente cara. Las reglas de comisiones deberían tener mínimos y máximos explícitos, intervalos de actualización predecibles, protección contra la manipulación en un solo bloque y pruebas para mercados inactivos o ilíquidos. Los LPs también necesitan saber si un administrador puede sustituir la fórmula o anular la comisión.

Riesgo relativo: medio. Hooks de liquidez concentrada y órdenes por rango. La liquidez concentrada permite a un LP aportar activos solo dentro de rangos de precio seleccionados. Un hook de orden por rango puede automatizar la adición, retirada o reclamación de liquidez cuando se cruza un límite de precio, generando un comportamiento similar a una orden límite onchain. Esto puede reducir la gestión manual, pero no garantiza la ejecución a un precio elegido porque el precio puede cruzar un rango y revertir, las transacciones pueden reordenarse y las comisiones o el deslizamiento pueden cambiar el resultado.

Las versiones más seguras usan permisos limitados, evitan el apalancamiento, mantienen las reclamaciones totalmente colateralizadas y permiten la cancelación y retirada incluso cuando la automatización falla. Las versiones más complejas reequilibran posiciones de forma continua, capitalizan comisiones, emiten participaciones de bóveda o dependen de un keeper offchain. Esas incorporaciones acercan el diseño a una bóveda gestionada y elevan su riesgo. Los lectores que comparen este patrón también deberían revisar los riesgos de la liquidez concentrada para LPs, incluida la pérdida impermanente, la liquidez inactiva y la selección adversa.

Patrones de mayor riesgo: anti-MEV, TWAMMs y préstamos

Riesgo relativo: medio a alto. Patrones de hooks de comisiones dinámicas y anti-MEV. MEV, o maximal extractable value, es el valor obtenido al controlar el orden de las transacciones. Un hook anti-MEV puede usar subastas por lotes, órdenes cifradas, flujo de órdenes privado, pasos de commit-and-reveal, retardos de ejecución o comisiones que aumentan cuando el comportamiento de trading parece depredador. Estos mecanismos pueden reducir un ataque concreto bajo supuestos específicos, pero ningún callback genérico puede eliminar todo el MEV.

Un diseño anti-MEV puede simplemente trasladar la confianza a otro lugar. Un relay privado puede censurar órdenes, un secuenciador puede conservar el poder de ordenación, una subasta por lotes puede depender de un solver y una fórmula de detección puede penalizar el arbitraje legítimo mientras no detecta a un atacante sofisticado. Los hooks de captura de MEV van más allá al intentar redirigir el valor de arbitraje a los LPs o a otro destinatario. Eso plantea preguntas sobre la precisión del oráculo, la competencia en subastas, la inclusión de transacciones, la contabilidad de reembolsos y quién controla los ingresos capturados. Estos diseños necesitan pruebas económicas adversariales además de una auditoría de código convencional.

Riesgo relativo: alto. Hooks TWAMM. Un time-weighted average market maker, o TWAMM, divide una orden grande en operaciones virtuales más pequeñas ejecutadas a lo largo del tiempo. La idea es anterior a v4 y puede reducir el impacto inmediato en el precio de una operación grande. Un hook puede mantener el estado de órdenes a largo plazo y liquidar partes de esas órdenes cuando se interactúa con los pools, pero debe gestionar actividad escasa, cancelación, reclamaciones parciales, redondeo, crecimiento de comisiones y movimiento de precios entre intervalos de ejecución.

Riesgo relativo: muy alto. Hooks de préstamo que usan Uniswap v4 con Aave o Compound. Un hook de préstamo podría depositar liquidez inactiva en un mercado de préstamo, tomar prestado contra activos de LP, enrutar swaps a través de posiciones colateralizadas o ajustar deuda automáticamente. La posible eficiencia de capital viene acompañada de riesgos apilados: el hook, Uniswap v4, el protocolo de préstamo, su oráculo, los mecanismos de liquidación, los tokens admitidos y los controles de gobernanza pueden fallar cada uno por su cuenta. Aave o Compound pueden estar ampliamente revisados, pero el código de integración aún puede aprobar el activo equivocado, interpretar mal saldos que devengan intereses, superar límites seguros de colateral o impedir retiradas cuando los prestamistas más las necesitan.

Cómo decidir si un hook está listo para desplegarse

Empieza por la autoridad, no por la descripción del producto. Identifica cada callback, llamada externa, aprobación de activos, rol administrativo, mecanismo de actualización, oráculo, keeper y control de emergencia. Determina si el hook puede tomar custodia, crear deuda, devolver deltas personalizados, bloquear retiradas, cambiar comisiones sin demora o redirigir ingresos. Si la documentación no puede responder a esas preguntas a nivel de dirección desplegada, los LPs no tienen información suficiente para evaluar el pool.

Las etiquetas de auditoría requieren una lectura cuidadosa. El núcleo de Uniswap v4 y los componentes oficiales de periferia han recibido revisiones de múltiples equipos de seguridad y pruebas extensas, pero esas revisiones no se extienden automáticamente a hooks de terceros. Bibliotecas importantes como las utilidades de hooks v4 de OpenZeppelin pueden proporcionar bloques de construcción revisados, pero el estado del repositorio, el alcance, la versión y las exclusiones deben comprobarse en el momento del despliegue. Los ejemplos experimentales de hackathons, incubadoras, repositorios de plantillas o proyectos de investigación no deberían describirse como auditados para producción salvo que un informe publicado cubra el commit y la configuración exactos.

Un despliegue creíble debería proporcionar verificación del código fuente, pruebas de invariantes de callback y liquidación, fuzz testing, una auditoría independiente, evidencia de remediación y un bug bounty significativo. El fuzzing con estado es especialmente útil porque genera largas secuencias de swaps, depósitos, retiradas, cancelaciones y llamadas externas para encontrar estados que las pruebas unitarias ordinarias pasan por alto. Para sistemas de préstamo o MEV, la revisión también debería incluir ataques económicos, manipulación de oráculos, estrés de liquidación y periodos en los que la infraestructura externa deja de responder.

Los LPs aun así deberían dimensionar la exposición en función del fallo, no del marketing de auditoría. Prioriza controles inmutables o con retrasos estrictos, depósitos limitados durante el funcionamiento inicial, aprobaciones de tokens aisladas y una ruta de salida clara. Evita hooks no auditados con poderes significativos de custodia o endeudamiento. La titularidad de UNI no proporciona un seguro directo frente al fallo de un hook, y la visibilidad de gobernanza no debería confundirse con responsabilidad por código de terceros. Este es un marco técnico de riesgo, no asesoramiento financiero.

Sigue el riesgo de los hooks de Uniswap v4 con mejor contexto

El desarrollo de Uniswap v4 cambia rápidamente, y un titular sobre un lanzamiento, una auditoría, un exploit, una pausa o una integración rara vez indica a los LP qué contrato y qué supuesto se ven afectados. Zippfeed organiza la cobertura relacionada con Uniswap, UNI, DeFi y hooks con puntuaciones de sentimiento bullish, neutral o bearish, además de una calificación de importancia, lo que te ayuda a distinguir las actualizaciones de seguridad relevantes de la promoción rutinaria antes de revisar por tu cuenta el código principal y los informes.