Cálculo preciso de PnL na Polymarket: por que seus lucros e perdas podem estar incorretos?

Título original: 《Polymarket PnL Precise Calculation: Why Your Profit and Loss Might Be Completely Wrong》Autor original: Leo, Analista de criptografia

Autor original: BlockBeats

Fonte original:

Reprodução: Mars Finance

Fiquei meio ano desenvolvendo uma negociação automatizada própria na Polymarket, e o maior erro que cometi não foi a estratégia falhar, mas sim não conseguir calcular corretamente quanto ganhei ou perdi.

Não é por falta de habilidade minha. É que o cálculo de PnL do PM é uma armadilha. Os números fornecidos pela API oficial estão incorretos, o ranking exibido por sites de análise de terceiros também está errado. Você escreve seu próprio script para calcular? Provavelmente também está errado.

Quão grande é a discrepância? O terceiro colocado no ranking, kch123, calculou uma perda de $3,5 milhões usando um método errado, mas na realidade teve um lucro de $11,4 milhões. Não é uma diferença de alguns pontos percentuais — é que o símbolo de lucro e prejuízo foi invertido.

Este artigo desmonta cada erro que cometi. Para traders, desenvolvedores de ferramentas ou quem olha o ranking, cedo ou tarde vão encontrar esses problemas.

Erro 1: cashPnl não inclui lucros realizados já liquidados

A abordagem mais intuitiva: usar a interface /positions, somar o campo cashPnl (lucro/prejuízo em dinheiro).

Testando com os três endereços do top 15 do ranking:

swisstony: soma de cashPnl +$35 mil, ranking real +$5,6 milhões, discrepância de 158 vezes

kch123: soma de cashPnl -$3,52 milhões, ranking real +$11,4 milhões, símbolo invertido

gmanas: soma de cashPnl -$2,64 milhões, ranking real +$5,02 milhões, símbolo invertido

Para esses três endereços, dois tiveram o símbolo de lucro/prejuízo invertido.

Razão: o cashPnl retornado pela API /positions não inclui o PnL realizado que já foi fechado ou resgatado. Quando uma posição vencedora é automaticamente resgatada em USDC, ela desaparece da resposta da API. O que fica são posições não liquidadas — geralmente com prejuízo flutuante.

Você acha que está calculando todo o lucro/prejuízo, mas na verdade só está considerando a parte não liquidada.

Erro 2: o campo makerPnl não condiz com o fluxo de caixa na cadeia

Nos dados de negociação em JSONL há um campo chamado makerPnl (lucro/prejuízo do maker), que parece ser para calcular PnL. Mas não confie nele.

Observando os dados de market-making, percebi que a soma de makerPnl calculada difere por um fator de ordem de grandeza do fluxo de caixa na cadeia. A multiplicidade exata pode variar dependendo do cenário, mas a direção é sempre a mesma: a lógica interna do makerPnl não condiz com o fluxo real de USDC.

Por maior que seja a discrepância, a conclusão é a mesma: não use esse campo para calcular PnL.

Erro 3: não deduzir por txHash individualmente

Isso é contra a intuição.

Se um txHash (hash da transação) aparece várias vezes, a reação natural é: dados duplicados, remover.

Mas não faça isso. O CLOB ( livro de ordens on-chain) do PM pode combinar várias ordens maker em uma única transação na cadeia, e várias entradas com o mesmo txHash representam execuções distintas reais.

Antes, eu deduzia por txHash + ativo, e isso fez eu subestimar $133 na side de COMPRA. Verificando na Polygon, uma única txHash realmente pode ter múltiplos eventos de transferência de USDC, cada um correspondendo a uma transação real.

Conclusão: não deduza apenas por txHash. Para calcular PnL, some diretamente os dados brutos de /activity.

Erro 4: paginação com offset tem limite

Na interface /activity, usar offset para paginação? Se passar de 3000, dá erro 400. Isso não está documentado.

Testei com os três endereços acima: GET /activity?offset=3100 retorna HTTP 400, com mensagem de erro “max historical activity offset of 3000 exceeded”. Jogadores com milhares de transações, 3000 não é suficiente.

Usar o parâmetro end (timestamp da última entrada da página anterior - 1) como cursor de paginação não tem limite.

Erro 5: diferenças na métrica de PnL do ranking

Depois de calcular o PnL de um endereço, ao comparar com o ranking, há uma pequena diferença.

Na maioria dos casos, a discrepância é menor que $10 (devido à volatilidade do valor de mercado das posições). Mas se a diferença for maior, possíveis razões incluem: janela de agregação do ranking, atraso na atualização do cache ou o usuário ter múlticas carteiras proxy vinculadas.

Testes mostram que o método de fluxo de caixa bate de frente com a API lb-api do ranking, com diferenças menores que $10. Se a sua diferença for grande, verifique se a paginação foi feita corretamente (erro 4) e se os campos usados estão corretos (erros 1-2).

Método confiável

Depois de testar várias abordagens, a mais confiável que validei é usar a API de Dados para somar fluxo de caixa. Sem usar campos pré-calculados, apenas somando as entradas e saídas de fundos a partir dos registros originais.

Fórmula:

PnL = soma de trades onde side=SELL + soma de REDEEM + soma de MERGE + soma de MAKER_REBATE + soma de REWARD - soma de trades onde side=BUY - soma de SPLIT + valor de mercado das posições

· TRADE BUY: gastar USDC para comprar token (saída)

· TRADE SELL: vender token para recuperar USDC (entrada)

· REDEEM: resgatar USDC de posições vencedoras (entrada)

· SPLIT: cunhar token a partir de USDC (saída)

· MERGE: juntar tokens de volta em USDC (entrada)

· MAKER_REBATE: reembolso do maker (entrada)

· REWARD: recompensas ou airdrops (entrada)

· Fonte de dados:

GET /activity?user=&limit=500, paginar com end, somar por tipo após obter todos os dados.

· Valor de mercado das posições:

GET /positions?user=, quantidade × preço atual.

· Validação cruzada:

Comparar o resultado com a API de ranking do Polymarket (lb-api.polymarket.com/profit?window=all&address=X). Diferença menor que $10 é aceitável. Diferenças maiores vêm da volatilidade do valor de mercado.

Validação: top 15 do ranking, testes

Usando o método de fluxo de caixa, comparando com a API do ranking:

swisstony: fluxo de caixa +$5,601,000, ranking +$5,601,000, diferença < $10

kch123: fluxo de caixa +$11,396,000, ranking +$11,396,000, diferença < $10

gmanas: fluxo de caixa +$5,024,000, ranking +$5,024,000, diferença < $10

As diferenças estão dentro de $10, sendo causadas pela volatilidade do valor de mercado.

Depois de validar esse método, apliquei para analisar centenas de endereços de alto nível, e os resultados foram outros.

Resumo

Soma de cashPnl de /positions → não funciona, não inclui lucros realizados, o símbolo pode estar invertido

Soma do campo makerPnl → não funciona, não condiz com o fluxo de caixa na cadeia

Deduzir por txHash individualmente → não funciona, perde transações reais acima de $100

Paginação com offset + soma → não funciona, dados truncados, erro acima de 3000

API de Dados com fluxo de caixa → atualmente mais confiável, diferença menor que $10

O primeiro passo para quem faz quant é confirmar se seus cálculos estão corretos, não procurar alpha.

Tudo acima vem de experiências reais, não de teoria. Como a API do PM pode mudar a qualquer momento, recomenda-se fazer validações cruzadas regulares com a API do ranking.