Como cada número é obtido

A faixa sugerida

O ponto de partida são os preços de fechamento diários do próprio pool, como o subgraph dele os publica: os últimos 31 dias UTC completos, sem o de hoje, que ainda não fechou. Deles saem 30 retornos diários, cada um a diferença entre os logaritmos de dois fechamentos consecutivos. Um dia ausente da fonte é pulado — nunca preenchido, repetido do anterior nem interpolado — e a página avisa quando a janela teve lacunas.

A volatilidade é o desvio padrão amostral desses retornos, levado a um ano pela raiz quadrada de 365. Depois é escalada para o horizonte que você escolher (7, 30 ou 90 dias; 30 se você não escolher) pela raiz quadrada da fração do ano que ele representa, e multiplicada pela largura que você escolher (em desvios padrão: 1σ, 1,5σ, 2σ ou 3σ; 1σ se você não escolher). O horizonte só diz até onde à frente o movimento medido é estendido: o movimento é sempre medido sobre os mesmos últimos 30 dias.

A banda é colocada em torno do preço de hoje de forma simétrica em logaritmos, sem deriva: cair pela metade e dobrar são a mesma distância, e por isso as duas porcentagens de cada lado diferem. Depois as bordas são deslocadas para fora sobre a grade de ticks do pool, nunca para dentro, de modo que a faixa sempre cobre pelo menos a banda. Duas verificações a protegem: o preço atual do pool tem de se converter no tick que o próprio pool informa, e tem de vir de um bloco no máximo 15 minutos atrás da rede.

Não é uma previsão: diz quanto o preço já se moveu, não para onde vai. E a largura não é um nível de confiança — transformar "dois desvios padrão" em "95% do tempo" exige uma suposição sobre como os preços se distribuem que não está estabelecida. Ela não dimensiona uma posição nem diz quanto depositar de cada token.

Testado em dias que ele nunca viu

O site lê 121 dias de fechamentos — mais do que a volatilidade precisa — para que o método possa ser testado em dias aos quais não foi ajustado. Ele é recuado um horizonte, ajustado de novo só com os 31 fechamentos anteriores a esse ponto e nada depois, centrado no fechamento desse ponto e colocado sobre os dias seguintes; depois o mesmo mais para trás, enquanto o histórico tiver espaço. Cada dia conta como inteiramente dentro, inteiramente fora ou cruzando uma borda: a máxima e a mínima de um dia não dizem onde o preço estava ao longo do dia, então um dia que cruzou uma borda nunca é dividido no chute.

São alguns trechos de um único pool, não uma medida de com que frequência o método funciona. Ajustes consecutivos se sobrepõem, então os trechos não são independentes entre si, e ninguém de fato manteve essas bandas.

"Aberta há trinta dias" reproduz a faixa que o método teria traçado no início dos últimos trinta dias — com os 31 fechamentos anteriores e nada depois — sobre cada um desses dias. Dá dois números. O valor comparado com segurar, a cada fechamento diário, vem das quantidades exatas da liquidez concentrada e não precisa de preço em dólar. As taxas vêm das taxas diárias do próprio pool nos dias em que o preço ficou inteiramente dentro, repartidas como o número do depósito as reparte, com o depósito dimensionado pela cotação do dólar de hoje porque o histórico não tem uma diária.

"Teste sua própria faixa" reproduz dois preços que você digitar sobre os mesmos trinta dias, a partir do mesmo fechamento de abertura, com a mesma repartição de taxas e a mesma cotação do dólar, de modo que a única diferença entre as duas colunas é a faixa. Uma faixa que não contém o preço de abertura começa com só um dos dois tokens e não recebe taxas até o preço alcançá-la. Uma faixa que foi bem nesses dias não diz nada sobre os próximos.

Taxas e perda impermanente

O que o pool cobrou vem das taxas e do volume que o subgraph dele publica para cada um dos últimos trinta dias. Dividir as taxas de um dia pelo seu volume mede a taxa que quem fez swaps realmente pagou — o dia típico, o mais baixo e o mais alto, e a janela inteira como taxas totais sobre volume total — e ela é comparada com a taxa que o pool declara. Um dia sem volume fica de fora em vez de contar como zero.

O que um depósito teria recolhido: em cada dia em que o preço ficou inteiramente dentro da faixa, uma parcela L / (A + L) das taxas daquele dia, onde L é a liquidez que o depósito compra na faixa e A a liquidez que a fonte informa como ativa naquele dia. O "+ L" é o depósito diluindo a si mesmo, e por isso um depósito maior não recolhe proporcionalmente mais. Dias que cruzaram uma borda não contam, e um dia dentro para o qual a fonte não publicou taxas ou liquidez ativa é informado como tal, não como zero.

Converter dólares na liquidez do pool exige um preço em dólar, e o site usa o do próprio subgraph, derivado do que o pool guarda em cada token e em dólares — a cotação em que estão os números de taxas dele. É a cotação de hoje aplicada a dias passados, e a página diz isso. O resultado são só taxas, sobre dias que já passaram: não é uma taxa anual nem o que o próximo mês vai pagar.

A perda impermanente — a posição comparada com simplesmente segurar os dois tokens — é a aritmética exata da curva do protocolo entre as bordas da faixa, do preço de hoje até cada preço mostrado. Não precisa de dados de mercado nem do tamanho do depósito, porque a liquidez se cancela na razão. Ela só é impermanente se o preço voltar. Conta o movimento do preço e nada mais, e as taxas são o que um provedor recebe por suportá-la, então as duas coisas precisam ser lidas juntas.

Hooks do v4

Um pool do v4 pode nomear um hook, um contrato que o protocolo chama em momentos fixos. As permissões dele são lidas do seu endereço: um hook é implantado num endereço cujos catorze bits mais baixos dizem quais callbacks o PoolManager vai chamar, e o PoolManager confere esses bits em vez de perguntar ao contrato. Então o site lê a regra que o protocolo impõe — não um registro, um rótulo ou a descrição que o contrato faz de si mesmo — e diz o que um hook pode fazer, nunca o que ele faz.

Um hook autorizado a agir antes de um swap pode reescrever a taxa dele; um autorizado a devolver um delta de um swap pode ficar com parte do próprio swap. Quando o hook de um pool tem qualquer uma dessas permissões, todo número de taxas ligado a uma faixa ou a um depósito é retido — as taxas enquanto dentro, a parcela de um depósito, as taxas na reprodução de trinta dias, o rendimento na página do par — porque nada na fonte separa a parte do hook da dos provedores. O que o pool cobrou continua aparecendo, como um fato sobre o pool, e os painéis que mostram quanto custa um swap trazem uma nota. Um pool cuja chave não fixa taxa aparece sem taxa, e a taxa que ele de fato cobrou é medida a partir dos seus dias.

Liquidez inteligente

Em cada rede onde as posições podem ser listadas (Ethereum, Base, Arbitrum One, OP Mainnet e Polygon), a página olha os 12 pools v3 mais negociados da semana, pega as posições que estão dentro da faixa agora e pergunta à rede sobre até 100 por pool, as maiores primeiro, cada uma valendo pelo menos US$ 10.000. A medição é refeita a cada seis horas.

As taxas de uma posição são o que ela ganhou desde a última alteração: sua liquidez vezes o crescimento das taxas dentro da sua faixa desde que o gerenciador de posições gravou seu último instantâneo, lido da rede. O par, a taxa e os ticks de cada posição têm de levar ao pool em que ela foi listada. Essas taxas, sobre o que a posição vale agora, sobre os dias desde essa alteração, levadas a um ano, são o rendimento dela. Posições abaixo de US$ 10.000, ou alteradas há menos de 3 dias, ficam de fora por serem pequenas ou novas demais para dizer algo; os 20% de maior rendimento são as inteligentes.

O subgraph lista as posições e data a última alteração de cada uma, e nada mais. Os campos de taxas dele não são usados: conferidos em 2026-09-30, informavam dois bilhões de dólares recolhidos por uma posição que tinha depositado trinta e dois milhões. Os valores devidos do gerenciador de posições também não contam, porque depois de um saque eles guardam o principal sacado até ser recolhido.

O que o rendimento deixa de fora: são só taxas, e o que uma posição abriu mão em comparação com segurar os dois tokens não está nele. Cobre uma janela por posição, lê só posições dentro da faixa agora e não diz nada sobre o que qualquer uma delas vai ganhar depois nem sobre quem a detém.

Cada medição é guardada, para que a página possa dizer como as coisas se moveram na última semana assim que houver um dia de medições. A faixa de um par é comparada como preços, nunca como distâncias do preço atual, porque essas distâncias mudam sempre que o preço se move, mesmo que ninguém toque numa posição. "Titulares que continuam aparecendo" são os endereços que estiveram nos 20% do topo em pelo menos metade das medições, quando elas são 8 ou mais. Cada um é marcado como carteira ou contrato conforme a rede guarde ou não código no endereço: um contrato é um cofre, um bot ou outro programa, e o rendimento é desse programa.

Um par, todos os pools

A página do par lista todo pool v3 e v4 cujos dois símbolos são exatamente o par digitado, em toda rede que o site lê. Cada um é ordenado pelas taxas que cobrou na última semana, sobre o que há nele agora, levadas a um ano — juros simples, não compostos. São taxas passadas sobre liquidez presente: não é uma previsão nem o que uma posição ganharia, já que uma posição só ganha enquanto o preço está dentro da faixa dela, divide as taxas com todos os outros ali e abre mão de algo em comparação com segurar.

O que há num pool é medido de forma diferente em cada protocolo, então os dois são ordenados separadamente: no v3, o que os contratos dos tokens guardam para o pool; no v4, onde todos os tokens ficam num único PoolManager, sua profundidade no preço atual. Só são ordenados os pools que valem pelo menos US$ 100.000 — abaixo disso, o trading de uma tarde mexe demais no número e um token imitador é mais provável — e o resto aparece embaixo por tamanho, sem rendimento. Um pool v4 cujo hook pode mudar o que os swaps pagam mostra suas taxas com uma nota e sem rendimento. Uma rede que não pode ser lida aparece como tal.

A explicação escrita

Na página de um pool, depois que cada número foi calculado e conferido, um modelo de linguagem escreve quatro parágrafos curtos: o que a faixa cobre, o que acontece quando o preço sai dela, o que a volatilidade mede e o que não mede, e o que a análise deixa de fora. Ele recebe os números como a página os mostra, no idioma de quem lê, com as direções já escritas como frases. Nada que um visitante escreva chega até ele — exceto um endereço de pool que passou por uma verificação de formato rigorosa; nenhuma descrição de token, nenhum texto livre — e nenhum tick chega até ele.

Ele é instruído a nunca dizer um número, nunca aconselhar e nunca prever. Isso é imposto, não só pedido: cada parágrafo é conferido antes de aparecer. Um parágrafo com um dígito em qualquer escrita — incluindo dígitos árabes, devanágari e de largura total, frações e sobrescritos —, fora dos nomes v3 e v4, ou com um número de onze para cima escrito por extenso em qualquer um dos dez idiomas, é recusado, assim como um curto ou longo demais. Se um único parágrafo falhar, a explicação inteira é descartada e os números ficam por conta própria.

O que uma verificação não consegue impor é o tom; isso fica a cargo da instrução, e a página não finge o contrário. A página nomeia o modelo que escreveu o texto, como o provedor o informa, e a mesma explicação é reutilizada por no máximo uma hora para o mesmo pool, as mesmas configurações e o mesmo idioma.

Fontes de dados e limites

Os pools são lidos dos subgraphs v3 e v4 da Uniswap no The Graph, em Ethereum, Base, Arbitrum One, Unichain, OP Mainnet e Polygon; Unichain é lida só para o v4. Onde um subgraph erra ou se cala, a rede é consultada diretamente, só para leitura: o espaçamento de ticks de um pool v3 e o que os contratos dos tokens guardam, a liquidez e o preço de um pool v4 no PoolManager, os ganhos e o titular de uma posição no gerenciador de posições, e se um endereço guarda código. Cada subgraph é verificado de hora em hora.

O estado atual de um pool tem de vir de um bloco no máximo 15 minutos atrás da rede, ou é recusado. Os históricos diários são guardados durante o dia UTC, os pools mais negociados da semana por meia hora, as buscas e as leituras de pares por dez minutos, e uma explicação por uma hora; a medição da liquidez inteligente é renovada a cada seis horas.

Quando uma fonte falha, a página diz que parte não pôde ser obtida e mostra o resto; um número ausente aparece como ausente, nunca como zero, e nunca é trocado por um chute. Na página de liquidez inteligente, um pool que não pode ser lido custa só esse pool, e uma renovação que falha mantém a última medição de pé até ela expirar; na página do par, uma rede que não pode ser lida aparece como tal. A explicação é a única parte que pode faltar.

Nada é guardado sobre quem lê o site. Uma visita é contada como uma linha que nomeia a página, o pool, se houver (um contrato público), o idioma e se parecia um bot — sem endereço IP, sem dados do navegador, sem texto de busca, e nunca um endereço digitado para ver suas posições. A única coisa guardada sobre um leitor é um alerta no Telegram que ele mesmo configura: o endereço que digitou, o idioma dele, o id numérico do chat e se cada posição estava dentro da faixa da última vez. /stop o apaga na hora, e dos backups ele some em até sete dias.