Cálculo preciso do PnL do Polymarket: por que o seu cálculo de lucro e prejuízo pode estar errado?

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 uma estratégia falha, mas sim não conseguir calcular corretamente quanto ganhei ou perdi.

Não sou ruim. É que o cálculo de PnL do PM é uma armadilha. A API oficial fornece números incorretos, o ranking exibido em 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 de dólares usando um método errado, mas na verdade teve um lucro de 11,4 milhões de dólares. Não é uma diferença de alguns pontos percentuais — é que o símbolo de lucro e perda está invertido.

Este artigo desmonta cada erro que cometi. Para quem faz negociações, desenvolve ferramentas ou acompanha rankings, cedo ou tarde vai 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:

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 sinais de lucro/prejuízo estão invertidos.

Razão: a API /positions retorna um cashPnl que não inclui os lucros realizados que já foram fechados ou resgatados. 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 todo o lucro e 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 makerPnl (lucro/prejuízo do maker), que pelo nome parece ser para calcular PnL. Mas não confie nisso.

Observando os dados de market-making, percebi que a soma de makerPnl calculada difere por uma ordem de grandeza do resultado 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 bate 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 deduplicar por txHash isoladamente

Isso é contraintuitivo.

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

Mas não pode fazer isso. O CLOB (Order Book on-chain) do PM pode combinar múltiplos pedidos de maker na mesma transação na cadeia. Várias entradas com o mesmo txHash representam execuções independentes reais.

Antes, eu deduplicava por txHash + asset, e isso fez com que eu subestimasse $133 na side de compra. Verificando na Polygon, realmente há múltiplos eventos de transferência de USDC por txHash, cada um correspondendo a uma transação real.

Conclusão: não dedupe 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. O documento não informa isso.

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 de alto volume podem ter dezenas de 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, pode ser por: janela de agregação do ranking, atraso na atualização do cache ou o usuário ter múltiplas carteiras proxy vinculadas.

Testes mostram que o método de fluxo de caixa bate quase exatamente com a API lb-api. Se a sua diferença for grande, primeiro verifique se a paginação foi completa (erro 4) e se usou os campos 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 os registros originais de transações.

Fórmula:

PnL = soma de (TRADE com side=SELL) + soma de REDEEM + soma de MERGE + soma de MAKER_REBATE + soma de REWARD - soma de (TRADE com 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 USDC em token (saída)

· MERGE: fundir 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, usar end para paginação, somar por tipo após obter todos os registros.

· Valor de mercado das posições:

GET /positions?user=, size × 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

Depois de calcular pelo método de fluxo de caixa, cruzar 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

Todos os três endereços têm discrepância menor que $10, devido à volatilidade do valor de mercado.

Depois de validar esse método, usei para analisar centenas de endereços de alto volume, 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

Deduplicar por txHash → não funciona, perde execuçõ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 quantificação não é buscar alpha. É primeiro garantir que seus cálculos estão corretos.

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