Cómo se obtiene cada cifra

El rango sugerido

Parte de los precios de cierre diarios del propio pool, tal como los publica su subgraph: los últimos 31 días UTC completos, sin el de hoy, que aún no ha cerrado. De ellos salen 30 rendimientos diarios, cada uno la diferencia entre los logaritmos de dos cierres consecutivos. Un día que falta en la fuente se omite — nunca se rellena, se arrastra ni se interpola — y la página avisa cuando la ventana tenía huecos.

La volatilidad es la desviación estándar muestral de esos rendimientos, llevada a un año con la raíz cuadrada de 365. Luego se escala al horizonte que elijas (7, 30 o 90 días; 30 si no eliges) con la raíz cuadrada de la fracción del año que es ese horizonte, y se multiplica por la amplitud que elijas (en desviaciones estándar: 1σ, 1,5σ, 2σ o 3σ; 1σ si no eliges). El horizonte solo dice hasta dónde se proyecta el movimiento medido: el movimiento se mide siempre sobre los mismos últimos 30 días.

La banda se coloca alrededor del precio de hoy de forma simétrica en logaritmos, sin deriva: reducirse a la mitad y duplicarse son la misma distancia, y por eso los dos porcentajes a cada lado son distintos. Después sus bordes se desplazan hacia fuera sobre la cuadrícula de ticks del pool, nunca hacia dentro, de modo que el rango siempre cubre al menos la banda. Dos comprobaciones lo protegen: el precio actual del pool debe convertirse en el tick que el propio pool informa, y debe venir de un bloque como mucho 15 minutos por detrás de la cadena.

No es un pronóstico: dice cuánto se ha movido el precio, no adónde irá. Y la amplitud no es un nivel de confianza — convertir "dos desviaciones estándar" en "el 95 % del tiempo" exige un supuesto sobre cómo se distribuyen los precios que no está establecido. No dimensiona una posición ni dice cuánto depositar de cada token.

Probado en días que nunca vio

El sitio lee 121 días de cierres — más de los que necesita la volatilidad — para poder probar el método en días a los que no se ajustó. Se retrocede un horizonte, se ajusta de nuevo solo con los 31 cierres anteriores a ese punto y nada posterior, se centra en el cierre de ese punto y se coloca sobre los días que siguieron; y lo mismo más atrás, mientras el historial tenga espacio. Cada día cuenta como totalmente dentro, totalmente fuera o cruzando un borde: el máximo y el mínimo de un día no dicen dónde estuvo el precio dentro del día, así que un día que cruzó un borde nunca se reparte a ojo.

Son unos pocos tramos de un solo pool, no una medida de con qué frecuencia funciona el método. Los ajustes consecutivos se solapan, así que los tramos no son independientes entre sí, y nadie mantuvo estas bandas.

"Abierta hace treinta días" reproduce el rango que el método habría trazado al comienzo de los últimos treinta días — con los 31 cierres anteriores y nada posterior — sobre cada uno de esos días. Da dos cifras. El valor frente a mantener, en cada cierre diario, sale de las cantidades exactas de la liquidez concentrada y no necesita precio en dólares. Las comisiones salen de las comisiones diarias del propio pool en los días en que el precio quedó totalmente dentro, repartidas como las reparte la cifra del depósito, con el depósito dimensionado al tipo de cambio en dólares de hoy porque el historial no tiene uno diario.

"Prueba tu propio rango" reproduce dos precios que escribas sobre los mismos treinta días, desde el mismo cierre de apertura, con el mismo reparto de comisiones y el mismo tipo en dólares, de modo que lo único que distingue las dos columnas es el rango. Un rango que no contiene el precio de apertura empieza con solo uno de los dos tokens y no cobra comisiones hasta que el precio lo alcanza. Un rango que fue bien en estos días no dice nada de los siguientes.

Comisiones y pérdida impermanente

Lo que cobró el pool sale de las comisiones y el volumen que su subgraph publica para cada uno de los últimos treinta días. Dividir las comisiones de un día por su volumen mide la tasa que pagaron de verdad quienes intercambiaron — el día típico, el más bajo y el más alto, y la ventana entera como comisiones totales sobre volumen total — y se compara con la comisión que declara el pool. Un día sin volumen se deja fuera en lugar de contarse como cero.

Lo que habría cobrado un depósito: cada día en que el precio quedó totalmente dentro del rango, una parte L / (A + L) de las comisiones de ese día, donde L es la liquidez que el depósito compra en el rango y A la liquidez que la fuente informa como activa ese día. El "+ L" es el depósito diluyéndose a sí mismo, por eso un depósito mayor no cobra proporcionalmente más. Los días que cruzaron un borde no se cuentan, y un día dentro para el que la fuente no publicó comisiones o liquidez activa se indica como tal, no como cero.

Convertir dólares en la liquidez del pool necesita un precio en dólares, y el sitio usa el del propio subgraph, derivado de lo que el pool tiene en cada token y en dólares — el tipo en que están sus cifras de comisiones. Es el tipo de hoy aplicado a días pasados, y la página lo dice. El resultado son solo comisiones, sobre días que ya pasaron: no es una tasa anual ni lo que pagará el próximo mes.

La pérdida impermanente — la posición frente a simplemente mantener los dos tokens — es la aritmética exacta de la curva del protocolo entre los bordes del rango, desde el precio de hoy hasta cada precio mostrado. No necesita datos de mercado ni tamaño de depósito, porque la liquidez se cancela en el cociente. Solo es impermanente si el precio vuelve. Cuenta el movimiento del precio y nada más, y las comisiones son lo que se le paga a un proveedor por asumirlo, así que hay que leer las dos cosas juntas.

Hooks de v4

Un pool de v4 puede nombrar un hook, un contrato al que el protocolo llama en momentos fijos. Sus permisos se leen de su dirección: un hook se despliega en una dirección cuyos catorce bits más bajos dicen qué callbacks llamará el PoolManager, y el PoolManager comprueba esos bits en lugar de preguntar al contrato. Así que el sitio lee la regla que el protocolo hace cumplir — no un registro, una etiqueta ni la descripción que el contrato da de sí mismo — y dice lo que un hook puede hacer, nunca lo que hace.

Un hook autorizado a actuar antes de un intercambio puede reescribir su comisión; uno autorizado a devolver un delta de un intercambio puede quedarse con parte del intercambio. Cuando el hook de un pool tiene alguno de estos permisos, se retiene toda cifra de comisiones ligada a un rango o a un depósito — las comisiones mientras está dentro, la parte de un depósito, las comisiones de la reproducción de treinta días, el rendimiento en la página del par — porque nada en la fuente separa la parte del hook de la de los proveedores. Lo que cobró el pool se sigue mostrando, como un hecho sobre el pool, y los paneles que muestran lo que cuesta un intercambio llevan una nota. Un pool cuya clave no fija comisión se muestra sin ella, y la tasa que realmente cobró se mide a partir de sus días.

Liquidez inteligente

En cada red donde se pueden listar posiciones (Ethereum, Base, Arbitrum One, OP Mainnet y Polygon), la página mira los 12 pools de v3 más negociados de la semana, toma las posiciones que están dentro de rango ahora mismo y pregunta a la cadena por hasta 100 por pool, las mayores primero, cada una de al menos 10.000 US$. Se vuelve a medir cada seis horas.

Las comisiones de una posición son lo que ha ganado desde su último cambio: su liquidez por el crecimiento de comisiones dentro de su rango desde que el gestor de posiciones escribió su última instantánea, leído de la cadena. El par, la comisión y los ticks de cada posición deben llevar al pool en que figuraba. Esas comisiones, sobre lo que vale la posición ahora, sobre los días desde ese cambio, llevadas a un año, son su rendimiento. Las posiciones de menos de 10.000 US$, o cambiadas hace menos de 3 días, se dejan fuera por ser demasiado pequeñas o demasiado nuevas para decir algo; el 20 % con mayor rendimiento son las inteligentes.

El subgraph lista las posiciones y fecha el último cambio de cada una, y nada más. Sus campos de comisiones no se usan: comprobados el 2026-09-30, informaban de dos mil millones de dólares cobrados por una posición que había depositado treinta y dos millones. Tampoco se cuentan los importes adeudados del gestor de posiciones, porque tras una retirada contienen el capital retirado hasta que se cobra.

Lo que el rendimiento deja fuera: son solo comisiones, y lo que una posición cedió frente a mantener los dos tokens no está incluido. Cubre una ventana por posición, solo lee posiciones dentro de rango ahora, y no dice nada de lo que ninguna ganará después ni de quién las tiene.

Cada medición se guarda, para que la página pueda decir cómo se movieron las cosas en la última semana en cuanto haya un día de mediciones. El rango de un par se compara como precios, nunca como distancias al precio actual, porque esas distancias cambian cada vez que el precio se mueve aunque nadie toque una posición. Los "Titulares que siguen apareciendo" son las direcciones que estuvieron en el 20 % superior en al menos la mitad de las mediciones, una vez que hay 8 o más. Cada una se marca como billetera o contrato según si la cadena guarda código en su dirección: un contrato es una bóveda, un bot u otro programa, y su rendimiento es el de ese programa.

Un par, todos sus pools

La página del par lista cada pool de v3 y v4 cuyos dos símbolos son exactamente el par escrito, en cada red que lee el sitio. Cada uno se ordena por las comisiones que cobró la última semana, sobre lo que hay en él ahora, llevadas a un año — simple, sin capitalizar. Son comisiones pasadas sobre liquidez presente: no es un pronóstico ni lo que ganaría una posición, ya que una posición solo gana mientras el precio está dentro de su rango, comparte las comisiones con todos los demás allí y cede algo frente a mantener.

Lo que hay en un pool se mide distinto en cada protocolo, así que los dos se ordenan por separado: en v3, lo que los contratos de sus tokens guardan para él; en v4, donde todos los tokens están en un mismo PoolManager, su profundidad al precio actual. Solo se ordenan los pools que valen al menos 100.000 US$ — por debajo, el trading de una tarde mueve demasiado la cifra y es más probable un token imitador — y el resto se lista debajo por tamaño, sin rendimiento. Un pool de v4 cuyo hook puede cambiar lo que pagan los intercambios muestra sus comisiones con una nota y sin rendimiento. Una red que no se puede leer aparece como tal.

La explicación escrita

En la página de un pool, cuando cada cifra ya se ha calculado y comprobado, un modelo de lenguaje escribe cuatro párrafos cortos: qué cubre el rango, qué pasa cuando el precio sale de él, qué mide la volatilidad y qué no, y qué deja fuera el análisis. Recibe las cifras tal como las muestra la página, en el idioma de quien lee, con las direcciones ya escritas como frases. Nada de lo que escribe un visitante le llega — salvo una dirección de pool que ha pasado una comprobación estricta de formato; ninguna descripción de token, ningún texto libre — y ningún tick le llega en absoluto.

Se le indica que nunca dé un número, nunca aconseje y nunca prediga. Eso se hace cumplir, no solo se pide: cada párrafo se comprueba antes de mostrarse. Se rechaza uno que contenga un dígito en cualquier escritura — dígitos árabes, devanagari y de ancho completo, fracciones y superíndices incluidos —, salvo en los nombres v3 y v4, o un número de once en adelante escrito con palabras en cualquiera de los diez idiomas, y también uno demasiado corto o demasiado largo. Si falla un solo párrafo, se descarta la explicación entera y las cifras quedan por sí solas.

Lo que una comprobación no puede imponer es el tono; eso queda en manos de la instrucción, y la página no finge lo contrario. La página nombra el modelo que escribió el texto, tal como lo informa el proveedor, y la misma explicación se reutiliza como mucho una hora para el mismo pool, los mismos ajustes y el mismo idioma.

Fuentes de datos y límites

Los pools se leen de los subgraphs de v3 y v4 de Uniswap en The Graph, en Ethereum, Base, Arbitrum One, Unichain, OP Mainnet y Polygon; Unichain se lee solo para v4. Donde un subgraph se equivoca o calla, se pregunta directamente a la cadena, solo en lectura: el espaciado de ticks de un pool de v3 y lo que guardan los contratos de sus tokens, la liquidez y el precio de un pool de v4 desde el PoolManager, las ganancias y el titular de una posición desde el gestor de posiciones, y si una dirección guarda código. Cada subgraph se comprueba cada hora.

El estado actual de un pool debe venir de un bloque como mucho 15 minutos por detrás de la cadena, o se rechaza. Los historiales diarios se guardan durante el día UTC, los pools más negociados de la semana media hora, las búsquedas y las lecturas de pares diez minutos, y una explicación una hora; la medición de la liquidez inteligente se renueva cada seis horas.

Cuando falla una fuente, la página dice qué parte no pudo obtenerse y muestra el resto; una cifra que falta se muestra como ausente, nunca como cero, y nunca se sustituye por una suposición. En la página de liquidez inteligente un pool que no se puede leer cuesta solo ese pool, y una renovación fallida deja en pie la última medición hasta que caduca; en la página del par, una red que no se puede leer aparece como tal. La explicación es la única parte que puede faltar.

No se guarda nada sobre quién lee el sitio. Una visita se cuenta como una línea que nombra la página, el pool si lo hay (un contrato público), el idioma y si parecía un bot — sin dirección IP, sin datos del navegador, sin texto de búsqueda, y nunca una dirección escrita para consultar sus posiciones. Lo único que se guarda sobre un lector es una alerta de Telegram que configura él mismo: la dirección que escribió, su idioma, el identificador numérico del chat y si cada posición estaba dentro de rango la última vez. /stop la borra al instante, y de las copias de seguridad desaparece en siete días.