Título original: 《Cálculo preciso de PnL na Polymarket: por que seus lucros e perdas podem estar totalmente errados》
Autor original: Leo, analista de criptomoedas

Tenho estado a desenvolver uma negociação automatizada na Polymarket há seis meses, e o maior erro que cometi não foi uma estratégia falhada, mas sim não conseguir calcular corretamente quanto ganhei ou perdi.

Não sou incompetente. É que o cálculo de PnL (lucros e perdas) do PM é uma verdadeira mina de armadilhas. Os números fornecidos pela API oficial estão incorretos, e os rankings exibidos por sites de análise de terceiros também estão errados. 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 de dólares usando um método errado, enquanto o lucro real foi de 11,4 milhões de dólares. Não é uma diferença de alguns pontos percentuais — é que o sinal do lucro ou prejuízo foi invertido.

Este artigo desmonta cada erro que cometi. Se você faz negociações, escreve ferramentas ou acompanha rankings, cedo ou tarde irá se deparar com eles.

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).

Testes com os três principais endereços 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, sinal invertido

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

Para esses três endereços, dois sinais de lucro/prejuízo estão invertidos.

Razão: a API /positions retorna cashPnl sem incluir os lucros realizados que já foram liquidados. Quando uma posição vencedora é automaticamente resgatada em USDC, essa posição 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 o total de lucros e perdas? 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

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

Percebi que, ao somar o makerPnl no dado de market-making, o resultado difere de uma ordem de grandeza do fluxo de caixa na cadeia. A multiplicidade exata pode variar dependendo do cenário, mas a direção é clara: 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 é contraintuitivo.

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

Mas não pode fazer isso. O CLOB ( livro de ordens on-chain) da PM pode combinar várias ordens de maker numa única transação na cadeia, e múltiplos registros sob o mesmo txHash representam execuções reais distintas.

Antes, eu deduzia por txHash + ativo, e isso fez eu subestimar em $133 na side de compra. No Polygon, verifiquei que um único 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: limite na paginação por offset

Na API /activity, usar offset para paginação? Se passar de 3000 registros, dá erro 400. O documento não informa isso.

Verifiquei com esses três endereços: GET /activity?offset=3100 retorna HTTP 400, com a mensagem de erro “max historical activity offset of 3000 exceeded”. Usuários de alto volume, com dezenas de milhares de transações, não conseguem passar de 3000.

Usar o parâmetro end (com o timestamp da última transação da página anterior - 1) para paginação por cursor 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 compará-lo com o ranking, há uma pequena diferença.

Na maioria dos casos, a discrepância é inferior a $10 (devido à volatilidade do valor de mercado das posições). Mas, se a diferença for maior, as razões podem incluir: janela de agregação do ranking, atraso na atualização do cache ou múltiplos proxies vinculados ao usuário.

Na prática, ao usar o método de fluxo de caixa, o PnL de um endereço corresponde quase exatamente ao valor retornado pela API lb-api. Se a sua diferença for grande, primeiro verifique se a paginação está completa (erro 4) e se está usando os campos corretos (erros 1-2).

Método correto

Depois de testar várias abordagens, confirmei que a mais confiável é usar a API de dados para somar o fluxo de caixa. Sem campos pré-calculados, apenas somando as transações originais.

Fórmula:

PnL = SOMA (negociações onde side=SELL) + SOMA (REDEEM) + SOMA (MERGE) + SOMA (MAKER_REBATE) + SOMA (REWARD) - SOMA (negociações onde side=BUY) - SOMA (SPLIT) + valor de mercado das posições

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

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

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

· SPLIT: cunhar USDC em tokens (saída)

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

· MAKER_REBATE: reembolso do maker (entrada)

· REWARD: recompensas/audições (entrada)

· Fonte de dados:

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

· Valor de mercado das posições:

GET /positions?user=<endereço>, tamanho × preço atual.

· Validação cruzada:

Compare o resultado com a API de ranking da Polymarket (lb-api.polymarket.com/profit?window=all&address=X); diferença < $10 é aceitável. Discrepâncias vêm da volatilidade do valor de mercado.

Validação: ranking top 15, testes reais

Após calcular pelo método de fluxo de caixa, compare com a API de 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 entre os três endereços estão dentro de $10, sendo causadas pela volatilidade do valor de mercado.

Depois de validar o método, apliquei-o para analisar o lucro real de centenas de endereços de destaque. E aí, a coisa mudou de figura.

Resumo

SOMA(cashPnl) de /positions → não funciona, não inclui lucros realizados, o sinal pode estar invertido

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

Calculado após deduzir por txHash → não funciona, acima de $100, remove execuções reais

Paginação por offset + soma → não funciona, dados truncados, erro >3000

Método de fluxo de caixa na API → atualmente o mais confiável, com diferença < $10

Para quem faz quant trading, o primeiro passo não é encontrar alpha. É garantir que seus cálculos estão corretos.

Tudo acima vem de experiências reais, não de teoria. A API da PM pode mudar a qualquer momento, por isso recomenda-se verificar periodicamente com a API de ranking para validar seus cálculos.

Link original

Clique para conhecer as vagas na BlockBeats

Participe do grupo oficial da BlockBeats no Telegram:

Telegram assinatura: https://t.me/theblockbeats

Grupo de discussão no Telegram: https://t.me/BlockBeats_App

Conta oficial no Twitter: https://twitter.com/BlockBeatsAsia