No existe un pool de liquidez cripto universalmente "mejor"; el pool adecuado depende de su tolerancia al riesgo, tamaño de capital y horizonte temporal. Este artículo proporciona un marco reproducible para evaluar pools: aprenderá a extraer datos en cadena, calcular el rendimiento real neto de pérdida impermanente, evaluar la calidad del TVL y filtrar el riesgo del contrato inteligente. En lugar de una lista estática, obtiene una metodología que puede volver a ejecutar a medida que cambian las condiciones del mercado. La sección final muestra cómo automatizar la recopilación de datos utilizando endpoints RPC y un script simple.
Por qué falla una lista estática de los mejores pools
Buscar los "mejores pools de liquidez cripto" normalmente devuelve listículos que clasifican los pools por el APY anunciado. Estas listas son engañosas por tres razones: las cifras de APY a menudo incluyen emisiones temporales de tokens que colapsan, ignoran la pérdida impermanente (IL) y rara vez tienen en cuenta la profundidad de liquidez necesaria para salir sin deslizamiento. Un pool que muestra un APY del 200% puede tener un TVL de $50k y un deslizamiento de salida del 15% para una posición de $10k.
Un enfoque más fiable es tratar la selección de pools como un problema de cribado cuantitativo. Usted define sus restricciones (tamaño de capital, IL aceptable, preferencia de cadena, tolerancia al riesgo del contrato inteligente) y luego mide cada pool candidato frente a esas restricciones utilizando datos en cadena. El "mejor" pool es el que supera sus filtros con el mayor rendimiento ajustado al riesgo.
Esta guía se centra en la metodología y las herramientas para ejecutarla. Para recomendaciones concretas de endpoints RPC que impulsen su recopilación de datos, consulte la guía de endpoints RPC y la guía de endpoints RPC multicadena.
- El APY anunciado no es rendimiento neto; reste la IL y la decadencia de las emisiones.
- El TVL por sí solo no indica seguridad; verifique la concentración de tenedores y el estado de bloqueo.
- La liquidez de salida importa más que el rendimiento de entrada para posiciones superiores a $5k.
Requisitos previos y supuestos
Para seguir los procedimientos de este artículo necesita: un endpoint RPC funcional para la cadena que está analizando (Ethereum, Arbitrum, Base, Solana, etc.), familiaridad básica con JavaScript o Python, y acceso a un explorador de bloques o API de indexador para datos históricos. No necesita un proveedor de datos de pago; la mayoría de las métricas se pueden derivar de llamadas JSON-RPC estándar y endpoints públicos de subgraph.
Los ejemplos asumen una cadena compatible con EVM y utilizan ethers.js v6. Para pools basados en Solana, la misma lógica se aplica pero los métodos RPC difieren (getAccountInfo, getTokenAccountsByOwner). Si no está seguro de qué proveedor RPC usar para una red determinada, la página de redes de OnFinality enumera las cadenas compatibles, y el servicio API proporciona endpoints gestionados.
Todo el código utiliza marcadores de posición: reemplace RPC_URL con su endpoint y POOL_ADDRESS con la dirección del contrato del pool que está evaluando. Nunca codifique claves privadas en los scripts; utilice variables de entorno.
El modelo mental: cuatro dimensiones de la calidad de un pool
Cada pool de liquidez se puede puntuar en cuatro dimensiones. Primero, rendimiento real: los ingresos por comisiones más las emisiones sostenibles menos la pérdida impermanente, anualizados. Segundo, profundidad: el TVL y su distribución a través de rangos de precios, lo que determina el deslizamiento para el tamaño de su posición. Tercero, seguridad: estado de auditoría del contrato inteligente, privilegios de la clave de administración y dependencias de oráculos. Cuarto, liquidez de su token LP: si puede salir del pool sin un bloqueo o un descuento en el mercado secundario.
Un pool que puntúa bien en rendimiento pero mal en profundidad y seguridad es una trampa de rendimiento. Un pool con liquidez profunda y bajo rendimiento puede ser apropiado para pares de stablecoins donde el objetivo es la preservación del capital. El marco le permite ponderar estas dimensiones según su propio perfil de riesgo en lugar de aceptar una clasificación genérica.
Para una explicación más profunda de cómo los creadores de mercado automatizados (AMM) fijan los precios y cómo surge la IL, consulte la guía de alojamiento de nodos blockchain que cubre la capa de infraestructura que soporta estos protocolos.
Paso 1: Obtener las reservas del pool y calcular la profundidad
La primera medición es la profundidad del pool. Para un AMM de producto constante (estilo Uniswap v2), puede leer las reservas directamente del contrato de par. Para pools de liquidez concentrada (Uniswap v3, Algebra), necesita consultar el tick actual y la liquidez. El siguiente fragmento de JavaScript lee las reservas de un par estilo v2 y calcula el valor en USD de cada lado utilizando una fuente de precios que usted proporcione.
Ejecute esto contra varios pools candidatos para construir una tabla de comparación. La salida le da reserve0, reserve1 y el TVL total en USD. Un pool con un TVL inferior al tamaño de su posición multiplicado por 20 probablemente sufrirá un deslizamiento inaceptable en la salida.
const { ethers } = require('ethers');
const RPC_URL = process.env.RPC_URL;
const POOL_ADDRESS = '0x...'; // pair contract
const provider = new ethers.JsonRpcProvider(RPC_URL);
const ABI = [
'function getReserves() view returns (uint112 reserve0, uint112 reserve1, uint32 blockTimestampLast)',
'function token0() view returns (address)',
'function token1() view returns (address)'
];
async function poolDepth() {
const pair = new ethers.Contract(POOL_ADDRESS, ABI, provider);
const [r0, r1] = await pair.getReserves();
const t0 = await pair.token0();
const t1 = await pair.token1();
console.log({ token0: t0, reserve0: r0.toString(), token1: t1, reserve1: r1.toString() });
// Multiply reserves by token prices (from an oracle or DEX quote) to get USD TVL.
}
poolDepth().catch(console.error);Paso 2: Calcular la pérdida impermanente para su período de tenencia
La pérdida impermanente es la diferencia entre mantener los dos tokens y proporcionarlos al pool. Para un pool de producto constante, la IL en función de la relación de precios k es: IL = 2*sqrt(k)/(1+k) - 1. Esta fórmula asume que no hay comisiones. Para obtener el rendimiento neto, sume el APR de comisiones y reste la IL realizada durante su período de tenencia previsto.
La siguiente función de Python calcula la IL para un rango de relaciones de precios. Úsela para someter a prueba de estrés un pool: si un movimiento de precio de 2x produce una IL del 5,7%, y el APR de comisiones del pool es del 8%, su rendimiento neto durante un año (suponiendo que el movimiento de precio ocurra una vez) es aproximadamente del 2,3% antes de emisiones. Este es el número que importa, no el APY destacado.
Para pares de stablecoins, k se mantiene cerca de 1 y la IL es insignificante; el riesgo dominante es la pérdida de paridad. Para pares volátiles, la IL puede superar los ingresos por comisiones. Calcule siempre ambos.
import math
def impermanent_loss(k):
"""k = price ratio (new price / initial price). Returns IL as a negative fraction."""
return 2 * math.sqrt(k) / (1 + k) - 1
for k in [0.5, 0.8, 1.0, 1.25, 2.0, 4.0]:
print(f"price ratio {k:.2f} -> IL {impermanent_loss(k)*100:.2f}%")Paso 3: Filtrar el riesgo del contrato inteligente y de administración
El rendimiento no tiene sentido si el contrato es actualizable por una sola clave o si el pool depende de un oráculo manipulable. Antes de depositar, verifique tres cosas: si el contrato del pool está detrás de un proxy con un administrador, si el administrador es una multifirma o un timelock, y si el protocolo ha sido auditado por una firma de reputación. Puede verificar el estado del proxy leyendo la ranura de implementación EIP-1967.
El siguiente comando curl consulta la ranura de implementación de un contrato proxy. Si la ranura devuelve una dirección distinta de cero, el contrato es actualizable y debe identificar quién controla las actualizaciones. Una dirección cero indica un contrato no actualizable, lo que reduce el riesgo de administración (aunque no los errores).
También verifique la distribución de tenedores del token del pool. Un pool donde una dirección posee el 80% de los tokens LP está efectivamente controlado por esa dirección; un rug pull o un retiro grande puede drenar la liquidez. Utilice la pestaña de tenedores de un explorador de bloques o consulte los eventos Transfer para calcular la concentración.
curl -s -X POST "$RPC_URL" \
-H "Content-Type: application/json" \
-d '{
"jsonrpc":"2.0",
"method":"eth_getStorageAt",
"params":["0xPOOL_ADDRESS","0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc","latest"],
"id":1
}'Paso 4: Construir una tabla de comparación a partir de datos medidos
Una vez que tenga la profundidad, la IL y los indicadores de seguridad para cada candidato, reúnalos en una tabla. No complete números de memoria ni de un listículo; cada celda debe provenir de una consulta que ejecutó o de una fuente que pueda citar. La siguiente tabla es una plantilla; reemplace las filas de marcador de posición con sus propias mediciones.
| Pool | Cadena | TVL (USD) | APR de comisiones | APR de emisiones | IL (movimiento 2x) | Actualizable | Auditoría | Puntuación neta |
|---|---|---|---|---|---|---|---|---|
| POOL_A | Ethereum | medido | medido | medido | calculado | sí/no | sí/no | calculado |
| POOL_B | Arbitrum | medido | medido | medido | calculado | sí/no | sí/no | calculado |
| POOL_C | Base | medido | medido | medido | calculado | sí/no | sí/no | calculado |
La puntuación neta puede ser una suma ponderada simple: 0,4 * (APR de comisiones - IL) + 0,3 * log(TVL) + 0,2 * indicador_seguridad + 0,1 * indicador_liquidez_salida. Ajuste las ponderaciones a su tolerancia al riesgo. El punto es hacer explícitos los compromisos en lugar de ocultarlos detrás de un único número de APY.
Para el rendimiento y la fiabilidad de la capa RPC que alimenta esta tabla, consulte la categoría de rendimiento y optimización y considere un nodo dedicado si consulta muchos pools con frecuencia.
Resultados de verificación esperados
Después de ejecutar los scripts, debería tener: (1) un objeto JSON por pool con reserve0, reserve1 y direcciones de tokens; (2) una curva de IL para cada par volátil; (3) un indicador de estado del proxy de la consulta de la ranura de almacenamiento; y (4) una tabla de comparación completa. Si alguna consulta devuelve null o se revierte, es probable que la dirección del pool o el ABI sean incorrectos, o que el endpoint RPC no admita el método.
Verifique su cálculo de profundidad contra un panel público para un pool. Si su TVL difiere en más del 5%, revise su fuente de precios de tokens y el manejo de decimales. Un error común es usar valores de reserva sin procesar sin ajustar por los decimales del token (USDC tiene 6, WETH tiene 18).
Solución de problemas comunes de medición
Si getReserves se revierte, el pool puede ser un contrato estilo v3 que no expone esa función; use slot0 y liquidity en su lugar. Si el RPC devuelve un error de límite de velocidad, reduzca la frecuencia de solicitudes o cambie a un proveedor con mayor rendimiento; la página de precios explica los límites del plan. Si su cálculo de IL produce números positivos, ha invertido la relación; k debe ser el precio nuevo dividido por el precio inicial.
Si la consulta de la ranura del proxy devuelve 0x000...000, el contrato no es un proxy EIP-1967 estándar, pero aún puede ser actualizable mediante un patrón personalizado. Verifique el código fuente del contrato en un explorador de bloques antes de concluir que es inmutable. Si los datos de concentración de tenedores no están disponibles, consulte los eventos Transfer del contrato del token LP del pool y agregue los saldos manualmente.
- Reversión en getReserves: el pool probablemente sea v3 o un AMM no estándar.
- Límite de velocidad: agrupe solicitudes o use un endpoint dedicado.
- Error de signo en IL: asegúrese de que k = nuevo/inicial, no inicial/nuevo.
- Discrepancia en TVL: verifique los decimales del token y la marca de tiempo del precio.
Limitaciones y compensaciones
Este marco mide lo que es observable en cadena en un momento dado. No predice cambios futuros en las emisiones, votaciones de gobernanza que alteren el reparto de comisiones ni eventos cisne negro. El APY de emisiones en particular puede cambiar semanalmente; vuelva a ejecutar la medición antes de cada depósito. La puntuación de seguridad es una heurística, no una garantía; las auditorías reducen pero no eliminan el riesgo.
Los pools de liquidez concentrada requieren un cálculo de profundidad diferente porque la liquidez se distribuye entre ticks. El método basado en reservas del Paso 1 subestimará la profundidad para los pools v3. Para esos, consulte la liquidez neta en cada tick inicializado o use un subgraph que exponga datos de ticks. La fórmula de IL también difiere para posiciones concentradas; use la fórmula específica del rango de la documentación del protocolo.
Finalmente, esta guía no recomienda pools específicos. El "mejor" pool para un tenedor de stablecoins difiere del mejor pool para un agricultor de degen. El marco le da las herramientas para decidir; la decisión sigue siendo suya.
Próximos pasos: automatizar y monitorear
Una vez que tenga una tabla de comparación funcional, automatice la recopilación de datos según un calendario. Un trabajo cron que ejecute los scripts de profundidad e IL cada hora y escriba los resultados en una base de datos le permite rastrear cómo cambian el rendimiento y la profundidad con el tiempo. Alerte cuando el TVL de un pool caiga por debajo de su umbral de salida o cuando cambie la clave de administración.
Para el monitoreo en producción, use un endpoint RPC fiable con límites de velocidad suficientes. El servicio API de OnFinality proporciona acceso gestionado a múltiples cadenas, y la página de redes enumera las redes compatibles. Si ejecuta consultas de alta frecuencia en muchos pools, un nodo dedicado reduce la latencia y evita los límites de velocidad compartidos. Para obtener orientación sobre la selección de endpoints, el Asistente RPC cubre opciones concretas de proveedores; este artículo cubre la metodología que esos endpoints soportan.