Explicação do Algoritmo Subjacente do Polymarket

Trabalho original: @MrRyanChi, @insidersdotbot Fundador da Plataforma de Negociação de Mercados de Previsão

Prefácio: O lado B do Polymarket que você não conhece

Nos últimos seis meses, centenas de milhões de artigos sobre mercados de previsão surgiram no Twitter.

Noventa por cento deles falam sobre como programas de escrita de IA podem levar ao mito de enriquecer. Este é o "Yuan", o primeiro passo em sua exposição a este mercado nascente.

Outros 9% discutem estratégias de negociação específicas, compartilhamento de mercado e análise de estratégias de smart money. Este é o "Dao", o primeiro passo para explorar suas próprias estratégias de negociação e começar a entender a mentalidade para ganhar dinheiro em mercados de previsão.

No entanto, o "Fa", que se refere ao design de negociação subjacente dos mercados de previsão, cálculos de PNL e as regras de fluxo de dinheiro, é discutido apenas por aquele 1% das pessoas, principalmente espalhado por alguns tweets concisos. Esses especialistas eremitas parecem não querer, ou não ter energia, para compartilhar seus métodos completos com todos de uma vez.

Então, no dia em que o insiders.bot foi lançado e o Polymarket completou sua atualização v2, quero desconstruir o "Fa" deste mercado que temos negociado a partir da tecnologia mais fundamental.

Em outubro passado, escrevi uma versão simplificada que introduziu aproximadamente vários componentes principais do Polymarket. Desta vez, quero realmente mostrar todos os detalhes do design técnico e explicá-los em linguagem simples.

Este artigo contém o trabalho árduo da nossa equipe nos últimos oito meses.

Durante esses oito meses, a equipe do @insidersdotbot dissecou todos os contratos inteligentes subjacentes e a arquitetura de algoritmos do Polymarket para alcançar a negociação mais rápida e os cálculos de PNL mais precisos. Isso é algo que apenas nossa própria API pode alcançar e, até hoje, ninguém mais consegue.

Portanto, acho que podemos ser aqueles que conseguem dissecar mais minuciosamente o "Fa" do Polymarket.

Neste artigo, ajudarei você a entender como o contrato inteligente ctf-exchange-v2 subjacente lida com cada fundo, como o Relayer ajuda você a pagar Gas e como o Negative Risk garante matematicamente a conservação de valor.

Este não é um artigo de divulgação científica simples. Esta é uma desconstrução algorítmica abrangente dos mecanismos subjacentes do Polymarket sob a perspectiva de um desenvolvedor.

Vamos começar pelo básico. Ou seja, quando você faz um pedido, o que exatamente você está enviando?

P.S. Este artigo também teve seu estilo e estrutura adaptados por IA, sinta-se à vontade para compartilhá-lo com seu OpenClaw, Manus, Hermes ou qualquer Agente de IA como material de treinamento!!!

Capítulo 1: O que acontece do clique à on-chain

1.1 Pedidos não são transações, eles são "intenções"

Em exchanges descentralizadas tradicionais (como a Uniswap), quando você negocia, sua carteira abre uma caixa de confirmação, você precisa pagar taxas de Gas e, em seguida, enviar uma transação para a rede blockchain (Mempool) para aguardar que os mineradores a empacotem.

Mas no Polymarket, quando você faz um pedido, sua carteira geralmente abre uma solicitação de "assinatura", em vez de uma solicitação de "transação". Além disso, você não precisa pagar nenhum Gas.

Isso não é apenas uma otimização da experiência do usuário; é uma diferença fundamental em toda a arquitetura subjacente.

No Polymarket, um pedido é essencialmente um conjunto de dados estruturados que está em conformidade com o padrão EIP-712. Esses dados contêm o que você deseja fazer:

• Você é um Maker ou um Taker? Qual Token (tokenId) você deseja comprar?

• Quanto você deseja pagar (makerAmount)?

• Quanto você deseja receber (takerAmount)?

Ao assinar, você está simplesmente carimbando esses dados com sua chave privada, provando que "eu realmente quero fazer isso". Então, esses dados assinados são enviados para o servidor centralizado do Polymarket e armazenados em um Livro de Ofertas de Limite Central (CLOB) off-chain.

Nesta fase, nada aconteceu na blockchain. Seu dinheiro ainda está na sua carteira e os tokens não foram transferidos. Seu pedido é apenas um registro no banco de dados.

1.2 Expressão implícita de preço

Vamos pausar o tempo no momento em que você envia o pedido. Se você observar atentamente a estrutura de pedidos dos contratos subjacentes do Polymarket, encontrará algo muito contraintuitivo: não há campo de "preço" nos dados de assinatura do pedido.

Como isso é possível? Como pode haver uma negociação sem um preço?

No design subjacente do protocolo do Polymarket, o preço é implícito. Ele é calculado com base no valor que você está disposto a pagar e no valor que deseja receber.

Se você quiser comprar 100 contratos YES a um preço de $0,60:

• Você precisa pagar: $60 pUSD (makerAmount = 60)

• Você quer receber: 100 contratos YES (takerAmount = 100)

• Preço implícito = makerAmount / takerAmount = 60 / 100 = $0,60

Se você quiser vender 100 contratos YES a um preço de $0,60:

• Você precisa pagar: 100 contratos YES (makerAmount = 100)

• Você quer receber: $60 pUSD (takerAmount = 60)

• Preço implícito = takerAmount / makerAmount = 60 / 100 = $0,60

(Nota: Embora no SDK V2 mais recente, os desenvolvedores possam inserir diretamente o preço e o tamanho, o SDK ainda os converte em makerAmount e takerAmount durante a assinatura subjacente. A inteligência deste design reside no fato de que o contrato inteligente não precisa entender o que é "preço"; ele só precisa lidar com a lógica de "ativo A trocando por ativo B". Isso simplifica muito a lógica de cálculo on-chain e reduz o consumo de Gas.)

1.3 Operador: O "guarda de trânsito" do Polymarket

Como os pedidos são todos off-chain, como eles se tornam transferências reais de ativos on-chain?

Isso nos leva ao papel de caixa-preta mais central na arquitetura do Polymarket: Operador.

No contrato inteligente ctf-exchange-v2, existe um modificador crucial: onlyOperator. Isso significa que apenas um endereço específico controlado pelo Polymarket tem autoridade para chamar funções de execução como matchOrders e fillOrder.

Isso é completamente diferente do DeFi tradicional. Na Uniswap, qualquer pessoa pode chamar o contrato de roteamento. Mas no Polymarket, você não pode combinar negociações on-chain sozinho. Todo o pareamento deve ser enviado pelo Operador.

Por que foi projetado dessa forma? Para eliminar MEV (Miner Extractable Value) e front-running.

Em livros de ofertas on-chain tradicionais, se alguém faz um pedido grande a um preço muito baixo, todos os bots de arbitragem farão lances frenéticos na Mempool (aumentando as taxas de Gas) para tentar passar na frente dos outros e consumir esse pedido. Isso leva a taxas de Gas altíssimas e a uma experiência ruim para usuários comuns.

No Polymarket, todos os pedidos estão no CLOB off-chain. O motor de pareamento do Operador calcula quem deve negociar com quem no servidor, então empacota o resultado em uma transação, que é enviada para a rede pelo Operador.

Como apenas o Operador pode enviar os resultados do pareamento, mesmo que os bots na Mempool vejam essa transação, eles não podem fazer front-run porque não têm autoridade para chamar as funções de execução.

Esta é uma arquitetura típica de "descentralização híbrida". O pareamento e o pedido são centralizados (decididos pelo Operador), mas a liquidação e a custódia de fundos são descentralizadas (executadas por contratos inteligentes).

O Operador pode decidir quem parear primeiro e quem parear depois, mas ele absolutamente não pode roubar seus fundos porque deve fornecer os dados EIP-712 que você assinou, e o contrato verificará estritamente a assinatura.

P.S: No entanto, devo mencionar que nossa equipe @insidersdotbot parece ter descoberto recentemente uma maneira de explorar esse mecanismo, permitindo que seguidores façam front-run ou atrasem significativamente as transações. Se houver alguma atualização, anunciaremos na conta oficial o mais rápido possível.

Capítulo 2: A economia do Relayer

2.1 A ilusão de "sem Gas"

Um dos maiores pontos de venda do Polymarket são suas "Transações sem Gas" para os usuários. Você só precisa de pUSD para negociar, sem precisar comprar POL (antigo MATIC) para manter em sua carteira.

Mas as leis físicas da blockchain não podem ser violadas: contanto que haja uma mudança de estado na Polygon (como transferência de ativos), alguém deve pagar as taxas de Gas.

Já que você não pagou, quem pagou? A resposta é: Relayer.

2.2 A rede de retransmissão do Relayer

O Polymarket não permite que os usuários enviem transações sozinhos, mas implantou uma infraestrutura chamada Relayer Client (relayer-v2.polymarket.com).

Na arquitetura inicial, tais serviços geralmente dependiam de serviços de nível empresarial como o OpenZeppelin Defender Relay, mantendo um pool de signatários para resolver conflitos de nonce sob alta concorrência.

Quando seu aplicativo cria uma transação (como Aprovar tokens, Resgatar lucros), você a assina com sua chave privada e a envia para o Relayer. O Relayer atua como um "Patrocinador de Transação", enviando essa transação para a rede e cobrindo as taxas de Gas com seu próprio pool de fundos.

Arquitetura do Relayer e Ciclo Econômico

2.3 A lã vem da ovelha?

Em muitas arquiteturas de meta-transação iniciais, após o Relayer cobrir o Gas, ele geralmente deduz uma taxa do depósito do usuário (como 0,3% ou alguns dólares fixos) para compensar os custos de Gas.

Mas o Polymarket é extremamente agressivo: na arquitetura V2 atual, eles realmente cobrem o valor total para você.

A documentação oficial afirma claramente: "O Polymarket paga o gás para todas as operações roteadas através do relayer." Seja implantando carteiras, autorizando tokens ou dividindo (Split), mesclando (Merge) ou resgatando (Redeem), tudo é sem gás e nenhuma taxa operacional oculta é cobrada.

Por que o Polymarket está disposto a ter esse prejuízo?

Porque os custos de Gas na Polygon são muito baixos (geralmente apenas alguns centavos), e a experiência sem gás pode atrair um fluxo massivo de usuários Web2. Contanto que os usuários incorram em uma pequena taxa de Taker durante a negociação (que será discutida mais adiante), é o suficiente para cobrir esse custo de Gas extremamente baixo.

Sabendo disso, a próxima pergunta surge naturalmente: que impacto essa arquitetura "sem gás" tem em nossa negociação?

O maior custo oculto é a latência. Seu pedido não só tem que passar pelo motor de pareamento do Polymarket, mas se for uma operação direta on-chain, ele também tem que passar pela verificação do Relayer, estimativa de Gas e alocação de fila.

Capítulo 3: Três métodos de pareamento, e por que compradores e compradores também podem negociar?

Agora entramos na parte mais hardcore e contraintuitiva de toda a arquitetura do Polymarket.

Em exchanges tradicionais (como o livro de ofertas da Binance), a lógica de pareamento é muito simples: Alice quer comprar 1 token por $60, Bob quer vender 1 token por $60. A exchange os combina, o token vai de Bob para Alice, e o dinheiro vai de Alice para Bob. Fim da história.

Mas no Polymarket (baseado no Conditional Token Framework CTF), as coisas são completamente diferentes. Porque aqui, tokens podem ser "criados do nada" e "destruídos do nada".

Ao abrir o código-fonte do ctf-exchange-v2, você encontrará três caminhos de liquidação de ativos completamente diferentes: COMPLEMENTARY, MINT e MERGE.

Estrutura Geral de Complementary, Mint, Merge

3.1 COMPLEMENTARY (Pareamento Complementar): Negociação tradicional de segunda mão

Este é o método de pareamento mais fácil de entender e o único método que as exchanges tradicionais possuem.

Cenário: O mercado existe há algum tempo e todos têm fichas.

• Alice quer comprar 100 YES por $0,60.

• Bob tem YES, e ele quer vender 100 YES por $0,60.

O Operador encontra esses dois pedidos (COMPRA vs VENDA) e os empacota on-chain. O contrato inteligente executa uma transferência direta ponto a ponto:

1. Transfere 100 YES do endereço de Bob para Alice.

2. Transfere $60 pUSD do endereço de Alice para Bob.

Este mecanismo tem as seguintes características matemáticas e de engenharia:

• Jogo de soma zero: A oferta total de tokens do sistema não mudou.

• Consumo mínimo de Gas: Envolve apenas transferências básicas, sem as operações complexas de CTF.

• Padronização: Em um mercado maduro e líquido, a grande maioria das negociações diárias é conduzida desta forma.

3.2 MINT (Pareamento de Cunhagem): Criando liquidez do nada

Esta pode ser a inovação mais revolucionária no Polymarket e até mesmo em toda a história financeira.

Para explicar melhor, podemos nos referir a este cenário: Um mercado totalmente novo acabou de ser lançado, e ninguém tem tokens YES ou NO.

• Alice está extremamente otimista; ela quer comprar 100 YES por $0,60.

• Bob está extremamente pessimista; ele quer comprar 100 NO por $0,40.

Nota: Ambos são compradores! Nenhum tem os tokens que o outro quer!

Em um livro de ofertas tradicional, esses dois pedidos só podem olhar um para o outro e nunca serão capazes de executar. No Polymarket, se ocorrer uma COMPRA vs COMPRA (e os tokens forem complementares), o Operador combinará esses dois pedidos!

1. O contrato inteligente deduz $60 pUSD da conta de Alice.

2. O contrato inteligente deduz $40 pUSD da conta de Bob.

3. O contrato inteligente pega esses $100 pUSD, bloqueia-os como garantia e, em seguida, chama a função _mint para criar 100 YES e 100 NO do nada.

4. Envia 100 YES para Alice.

5. Envia 100 NO para Bob.

O acionamento deste mecanismo deve ser baseado em uma condição matemática estrita: a soma dos lances dos compradores deve ser maior ou igual a $1,00.

Se Alice der um lance de $0,60 por YES e Bob der um lance de $0,35 por NO, o total é de apenas $0,95. O contrato inteligente não pode cunhar um par de tokens completo no valor de $1,00 com $0,95. Este pareamento falhará diretamente.

Mecanismo de Pareamento MINT

Da perspectiva de um formador de mercado, este mecanismo é a arma definitiva para resolver o problema de "partida a frio". Quando o mercado abre, os formadores de mercado não precisam gastar dinheiro para cunhar um monte de tokens para manter (o que ocuparia muitos fundos). Eles só precisam colocar pedidos de compra em ambos os lados YES e NO simultaneamente (por exemplo, $0,49 para YES, $0,49 para NO). Quando os investidores de varejo vierem vender, isso acionará a lógica de cunhagem.

3.3 MERGE (Pareamento de Mesclagem): A aniquilação da liquidez

Onde há criação, há destruição. MERGE é o processo reverso de MINT.

Vamos olhar para um caso reverso. O mercado está prestes a fechar e todos estão fechando suas posições.

• Alice tem 100 YES, e ela quer vender a $0,60.

• Bob tem 100 NO, e ele também quer vender a $0,40.

Nota: Ambos são vendedores! Ninguém está disposto a pagar pUSD para comprar seus tokens.

Neste ponto, o mecanismo do Polymarket entrará em ação novamente. Ao encontrar VENDA vs VENDA, o Operador fará sua mágica novamente:

1. O contrato inteligente pega 100 YES de Alice.

2. O contrato inteligente pega 100 NO de Bob.

3. O contrato inteligente chama a função _merge para destruir completamente esses 100 pares de YES+NO e desbloquear $100 pUSD do tesouro.

4. Envia $60 pUSD para Alice.

5. Envia $40 pUSD para Bob.

O mecanismo Merge tem as seguintes características matemáticas e financeiras:

• Mecanismo deflacionário: A oferta total de tokens do sistema diminui.

• Canal de saída: Garante que, mesmo sem um "comprador", contanto que os preços de venda de YES e NO possam somar $1,00 (na verdade, abrindo mão de $1,00 de espaço), todos ainda possam sacar.

Entender esses três métodos de pareamento dá a você uma visão do ciclo de vida do mercado do Polymarket:

• Estágio Inicial (Dominado por MINT): O mercado acabou de abrir e não há tokens. Tanto os lados otimistas quanto os pessimistas injetam fundos continuamente no sistema através do mecanismo MINT em troca de tokens. A oferta total aumenta rapidamente.

• Estágio Intermediário (Dominado por COMPLEMENTARY): O mercado tem ampla liquidez e a maioria das negociações são trocas de tokens existentes. A oferta total se estabiliza.

• Estágio Final (Dominado por MERGE): Os resultados tornam-se mais claros e todos começam a fechar suas posições. Tanto os lados otimistas quanto os pessimistas destroem tokens através do mecanismo MERGE para sacar. A oferta total diminui.

Observe que esses três caminhos não são escolhidos subjetivamente pelo Operador, mas são estritamente determinados pelas regras de roteamento do contrato inteligente com base na direção dos pedidos (COMPRA vs VENDA).

Ciclo de Vida do Mercado

Capítulo 4: Split/Merge/Redeem, e por que seu PnL está errado?

Tendo entendido o mecanismo de pareamento, vamos olhar para três operações subjacentes que você pode usar todos os dias, mas nunca entendeu verdadeiramente seu impacto financeiro: Split, Merge e Redeem.

Essas três operações são as operações de nível atômico do Polymarket. Elas não são "negociações" (não passam pelo livro de ofertas, não incorrem em taxas), mas interagem diretamente com o contrato inteligente para conversão de ativos.

• Split: Você dá ao contrato $1 pUSD, e o contrato lhe dá 1 YES e 1 NO. O custo é sempre exatamente $1.

• Merge: Você dá ao contrato 1 YES e 1 NO, e o contrato retorna $1 pUSD para você. O lucro é sempre exatamente $1.

• Redeem: Após o mercado determinar o vencedor e o perdedor, o token vencedor é trocado por $1 pUSD, e o token perdedor é zerado.

Comparação Antes e Depois da Operação Split

4.1 Quem usa essas operações?

• Formadores de Mercado: Eles são os maiores usuários de Split. Os formadores de mercado precisam colocar pedidos em ambos os lados simultaneamente, mas não querem comprar tokens no mercado (o que incorre em taxas). Eles fazem Split de $100.000 diretamente em 100.000 YES e 100.000 NO, e então os colocam no livro de ofertas.

• Arbitradores: Eles são os maiores usuários de Merge. Quando o mercado experimenta uma precificação incorreta temporária, como YES caindo para $0,40 e NO caindo para $0,55, os arbitradores comprarão rapidamente 1 YES e 1 NO (custo total $0,95) e então chamarão imediatamente o Merge para recuperar $1, obtendo um lucro líquido livre de risco de $0,05. A condição matemática é muito clara: quando Preço(YES) + Preço(NO) < 1 - taxas, é óbvio comprar e fazer Merge.

Portanto, quando você tentar seguir o smart money de um arbitrador ou de um formador de mercado, você deve avaliar com precisão o impacto do Split/Merge no PnL. Caso contrário, não é um "smart money" que valha a pena referenciar.

Atualmente, incluindo o próprio Polymarket, ninguém consegue resolver o problema de cálculo de PnL. Claro, você deve ter adivinhado - o insiders.bot já resolveu esse problema nos cálculos de PnL e navegadores de smart money.

4.2 Armadilha de PnL: Por que seu lucro está errado?

Como mencionado acima, este é o erro mais comum em todo o ecossistema do Polymarket. Quase todas as ferramentas de rastreamento de PnL de terceiros, incluindo algumas APIs oficiais, tropeçaram aqui.

Deixe-me calcular um exemplo para você, e você verá quão profunda é essa armadilha.

Passo 0: Suponha que você tenha um principal de $100. Você está otimista com o mercado "Ethereum ultrapassando $5000".

Passo 1: Você gasta $50 para executar um Split. Agora você tem 50 YES e 50 NO. Seu dinheiro permanece $50.

Passo 2: Você sente que 50 YES não é suficiente, então você vai ao mercado e compra 50 YES a um preço de $0,40. Custando $20. O dinheiro permanece $30.

Passo 3: Você vende os 50 NO que tem a um preço de $0,35. Recuperando $17,50. O dinheiro torna-se $47,50.

Agora, você tem 100 contratos YES. Qual é o seu custo real?

Como a maioria dos placares calcula (Algoritmo Errado):

Eles apenas olham para seus registros de "negociação". Eles veem que você comprou 50 YES, custando $20. Eles ignoram completamente o Split (porque isso não é uma negociação).

Então eles acham que seu custo é: $20 / 50 = $0,40 cada.

Se o preço de mercado atual de YES subir para $0,60, eles mostrariam seu lucro como: 100 × $0,60 - $20 = $40.

Como você deveria calcular (Algoritmo Correto, e o que o insiders.bot está usando):

Sua saída total de caixa: $50 (Split) + $20 (compra) = $70.

Sua entrada total de caixa: $17,50 (venda de NO)

Seu investimento líquido: $70 - $17,50 = $52,50

Seu custo real: $52,50 / 100 = $0,525 cada.

Se o preço de mercado atual de YES for $0,60, seu lucro real é: 100 × $0,60 - $52,50 = $7,50.

Você vê a diferença? O placar mostra que você ganhou $40, mas na verdade você só ganhou $7,50. Os $32,50 de "lucro fantasma" no meio ocorrem porque o sistema não lidou corretamente com o custo do Split e a receita da venda de NO.

A fórmula matemática correta de PnL deveria ser:

PnL Total = Σ(receita de venda) + Σ(receita de Merge) + Σ(receita de Redeem) - Σ(despesas de compra) - Σ(despesas de Split) + Valor de mercado da posição atual

É por isso que você vê alguns grandes players no placar mostrando perdas de milhões, mas na realidade, eles estão fazendo uma fortuna. Porque posições vencedoras, após serem resgatadas (Redeemed), muitas ferramentas "apagarão" essas posições dos registros históricos, deixando apenas aquelas que ainda estão em perda.

Armadilha de Cálculo de PnL

Capítulo 5: Curva de Taxas

Se você negociar com frequência, descobrirá que as taxas do Polymarket não são uma porcentagem fixa. Às vezes você é cobrado $10 por comprar um contrato de $1000, e às vezes apenas $2.

Por quê? Vamos dar uma olhada na fórmula de taxa escondida profundamente no código:

Taxa = C × feeRate × p × (1 - p) (onde C é o valor da transação, p é o preço)

5.1 Por que p(1-p)?

Suponha que você queira comprar 100 YES a uma taxa de 2%:

• Se o preço de YES for $0,50: Taxa = 100 × 2% × 0,50 × 0,50 = $0,50

• Se o preço de YES for $0,90: Taxa = 100 × 2% × 0,90 × 0,10 = $0,18

• Se o preço de YES for $0,10: Taxa = 100 × 2% × 0,10 × 0,90 = $0,18

Você vê o padrão? A taxa é mais alta quando o preço está em 0,50 (equilibrado). Quando o preço se aproxima de 0 ou 1 (o resultado é quase certo), a taxa é extremamente baixa.

Mais importante, há simetria. Comprar YES a $0,90 e comprar NO a $0,10 são matematicamente equivalentes. Se você for cobrado uma taxa alta por comprar YES a $0,90 e uma taxa baixa por comprar NO a $0,10, os arbitradores ficarão loucos comprando NO e depois arbitrando através do mecanismo MINT. O design de p(1-p) garante que, não importa de que lado você expresse sua opinião, os custos de fricção cobrados pelo sistema sejam absolutamente simétricos.

5.2 A beleza matemática oculta

Se você estudou estatística, estará muito familiarizado com a fórmula p(1-p). É a fórmula de variância da distribuição de Bernoulli (lançamento de moeda).

Em todo o design do sistema do Polymarket, p(1-p) é a "fórmula de Deus":

1. É a curva de taxas: Quanto maior a incerteza (variância), maiores as taxas cobradas pelo sistema.

2. Reflete a entropia da informação: Quando você aposta em 50%, você fornece a maior quantidade de novas informações ao mercado, portanto, seu custo é o mais alto.

Quem paga as taxas? É sempre o Taker. O Maker está sempre isento de taxas.

Este mecanismo alinha perfeitamente os incentivos: quando o mercado está mais incerto (50/50), os primeiros participantes serão cobrados com as taxas mais altas, protegendo os formadores de mercado de choques desnecessários; enquanto quando o mercado está quase certo, taxas extremamente baixas incentivam os arbitradores a entrar e empurrar os preços em direção ao 1 ou 0 final.

Curva de Taxas

Capítulo 6: Negative Risk, também conhecida como a magia mais elegante em DeFi

Se você já jogou em mercados de múltiplos resultados como eleições, Oscars ou eventos esportivos no Polymarket, você deve ter encontrado mercados de Negative Risk.

Esta é a parte que mais queima o cérebro de todo o artigo, mas também é a que melhor reflete a estética da engenharia de contratos inteligentes.

P.S. Esta também é a parte que nosso cofundador @DakshBigShit resolveu após uma maratona de 36 horas enquanto desenvolvia nossa própria API.

6.1 Pontos problemáticos dos mercados tradicionais de múltiplos resultados

Suponha que existam quatro candidatos: A, B, C, D. Você odeia absolutamente A e tem certeza de que A não pode vencer. Você quer "vender a descoberto" (short) A.

Em um mercado binário tradicional, você só precisa comprar o contrato NO de A. Mas em um mercado de múltiplos resultados, se A perde, significa que um entre B, C ou D deve vencer. Portanto, "vender A a descoberto" é matematicamente estritamente equivalente a "ir comprado (long) em B + ir comprado em C + ir comprado em D." (Esta frase é muito importante; leia-a repetidamente até entender.)

Se você for ao mercado e comprar contratos YES para B, C e D separadamente, encontrará um problema enorme: eficiência de capital muito baixa. Porque você precisa pagar três valores separados, e se os preços desses três somarem mais de $1,00, você pode até incorrer em uma perda.

6.2 A magia do Adaptador de Risco Negativo (NegRiskAdapter)

O Polymarket implantou um contrato inteligente dedicado NegRiskAdapter para resolver esse problema. Ele fornece uma função chamada convertPositions.

O objetivo da função é converter instantaneamente seus contratos NO em contratos YES para todos os outros candidatos e retornar um valor em dinheiro para você.

Vamos provar matematicamente por que essa conversão conserva valor.

Configuração do Cenário: Existem n candidatos.

• Você tem A ações de contratos NO para o candidato 1 e A ações de contratos NO para o candidato 2 (você está vendendo a descoberto ambos 1 e 2).

• Você detém um total de m contratos NO diferentes (aqui m=2).

Antes da conversão, o valor real de suas participações (em todas as linhas do tempo possíveis):

• Se o candidato 1 vencer: NO_1 torna-se inútil, NO_2 vale $1. Valor total = A.

• Se o candidato 2 vencer: NO_1 vale $1, NO_2 torna-se inútil. Valor total = A.

• Se o candidato 3 vencer (qualquer um que você não vendeu a descoberto vencer): NO_1 vale $1, NO_2 vale $1. Valor total = 2A.

O que o contrato lhe dá após chamar convertPositions?

A fórmula é: ele retorna A × (m-1) em dinheiro, mais A ações de contratos YES para os candidatos 3, 4, ... n.

Neste exemplo, ele retorna: A × (2-1) = A em dinheiro! Mais A ações de YES para o candidato 3, A ações de YES para o candidato 4...

Após a conversão, o valor real de suas participações (em todas as linhas do tempo possíveis):

• Se o candidato 1 vencer: seus YES_3 e YES_4 tornam-se inúteis. Você só tem dinheiro A. Valor total = A. (Igual a antes da conversão!)

• Se o candidato 2 vencer: seus YES_3 e YES_4 tornam-se inúteis. Você só tem dinheiro A. Valor total = A. (Igual a antes da conversão!)

• Se o candidato 3 vencer: seu YES_3 vale $1, outros tornam-se inúteis. Mais dinheiro A. Valor total = A + A = 2A. (Igual a antes da conversão!)

Q.E.D. Independentemente de como o mundo se desenvolva, o valor antes e depois da conversão é absolutamente igual.

Prova Matemática da Conversão de Risco Negativo

6.3 Por que este é um processo de aumento de entropia "unidirecional irreversível"?

Este mecanismo de conversão tem uma propriedade física extremamente charmosa: ele é unidirecional e irreversível.

Você pode converter NO em YES + dinheiro. Mas você nunca pode converter YES + dinheiro de volta em NO.

Por quê? Porque no nível subjacente do contrato inteligente, quando você converte NO em YES, o contrato na verdade envia seus contratos NO para um endereço de buraco negro (Burn), e então usa o espaço de garantia liberado disso para "sintetizar" novos contratos YES. Isso não requer a injeção de novos fundos externos.

Mas se você quiser reverter e transformar YES em NO, você precisa criar uma nova garantia do nada (porque os contratos NO cobrem uma gama muito mais ampla do que YES). O adaptador não tem autoridade para usar os fundos do tesouro.

Isso é como quebrar um ovo. NO é o ovo inteiro, contendo todas as possibilidades. A operação de conversão é como quebrar o ovo, separando-o em gema (YES) e clara (dinheiro). O processo conserva valor, mas você nunca pode juntá-los novamente em um ovo inteiro.

Existe uma enorme oportunidade de arbitragem aqui: se você descobrir que o preço do NO de um determinado candidato é maior do que o preço total do YES de todos os outros candidatos, você pode comprar esse NO, chamar convertPositions para obter dinheiro e um monte de YES, e então vender imediatamente esses YES. Esta é a estratégia de arbitragem livre de risco de mais alto nível em mercados de múltiplos resultados.

Capítulo 7: Os extremos físicos da velocidade

Finalmente, vamos falar sobre a dimensão mais brutal da negociação: o tempo.

Na negociação de alta frequência tradicional, discutimos microssegundos (milionésimos de segundo). No Polymarket, discutimos milissegundos. Mas há uma enorme desigualdade estrutural aqui.

Se você se misturou na seção de negociação algorítmica do Reddit, descobrirá que todos os programadores que desenvolvem bots para o Polymarket reclamaram da mesma coisa: "Por que sempre tenho que esperar 300 milissegundos para pedidos Taker, enquanto pedidos Maker levam apenas 25 milissegundos?"

7.1 Por que os pedidos Maker são rápidos e os pedidos Taker são lentos?

• Quando você faz um Maker (pedido limite): Seu pedido (dados de assinatura) é enviado para o servidor do Polymarket. O servidor verifica a validade da assinatura e insere diretamente esse registro no banco de dados CLOB (livro de ofertas) na memória. Então, ele retorna imediatamente um ACK (confirmação) para você. Todo o processo ocorre inteiramente off-chain e requer apenas uma gravação no banco de dados. Tempo gasto: ~25 milissegundos.

• Quando você faz um Taker (pedido de mercado): Seu pedido é enviado para o servidor. O motor de pareamento descobre que seu pedido pode combinar com um Maker no livro de ofertas. Neste ponto, o Operador deve iniciar um pipeline de liquidação complexo:

  1. Decidir qual caminho de pareamento usar (COMPLEMENTARY, MINT ou MERGE).

  2. Construir dados de transação on-chain contendo assinaturas de ambas as partes.

  3. Enviar a transação para o Relayer.

  4. O Relayer estima o Gas e aloca o Nonce.

  5. Transmitir a transação para os nós da Polygon.

  6. Aguardar que os nós confirmem que esta transação não será revertida devido a saldo insuficiente ou outros motivos.

  Todo o processo abrange vários microsserviços e até toca as bordas da blockchain. Tempo gasto: ~250 a 300 milissegundos.

7.2 O que significam esses 250 milissegundos?

Essa lacuna física de 250 milissegundos molda profundamente o ecossistema do Polymarket.

Primeiro, é muito difícil fazer front-run no Polymarket. Como todos os pedidos Taker devem entrar na fila aguardando o Operador processar, você não pode furar a fila aumentando as taxas de Gas. O front-running na Mempool é temporariamente um não-problema aqui.

Segundo, a vantagem absoluta das estratégias Maker. Como o cancelamento (Cancel) e os pedidos Maker são operações off-chain, eles levam apenas 25 milissegundos. Quando ocorrem notícias de última hora, formadores de mercado experientes podem usar essa diferença de tempo de 250 milissegundos para cancelar seus pedidos antes que os pedidos Taker sejam liquidados (isso é chamado de evitar seleção adversa).

7.3 Os 90 segundos de inatividade toda terça-feira de manhã

Existe outro detalhe pouco conhecido sobre o tempo. De acordo com a documentação oficial, toda terça-feira às 7:00 AM Eastern Time, o motor de pareamento do Polymarket reinicia. Durante esses aproximadamente 90 segundos, o sistema para de processar quaisquer pareamentos, e a API retorna um erro HTTP 425 (Too Early).

Mais cruelmente, a V2 introduziu um mecanismo de Heartbeat. Se o servidor não receber um heartbeat do cliente dentro de 10 segundos, ele cancelará automaticamente todos os pedidos abertos para aquele usuário. Durante esses 90 segundos de reinicialização, os heartbeats dos formadores de mercado são forçosamente interrompidos, e seus pedidos serão coletivamente limpos pelo sistema.

Esses 90 segundos representam um verdadeiro "vácuo de liquidez" no sistema. Para modelos de precificação de opções, como precificar o Theta (decaimento temporal) desses 90 segundos, e como aproveitar o mercado quando o motor retoma no 91º segundo, é o quebra-cabeça final para as principais plataformas e estúdios quantitativos.

Comparação da Linha do Tempo de Atraso

Capítulo 8: A reestruturação épica da V2 e a batalha final contra o "Ghost Fill"

Se você leu até aqui, você entendeu a estrutura central do Polymarket. Mas se você quiser continuar ganhando dinheiro neste mercado em 2026, você deve entender o grande terremoto que acabou de ocorrer.

Entre fevereiro e maio de 2026, o Polymarket passou silenciosamente por uma atualização épica da arquitetura V2. Esta atualização não apenas reestruturou as fórmulas de garantia e taxas, mas, mais importante, lançou a batalha final para resolver o bug mais notório nos mercados de previsão, a saber, preenchimentos fantasmas (Ghost Fill).

8.1 O que é Ghost Fill? A desconexão de estado entre on-chain e off-chain

Antes da atualização do Polymarket V2, inúmeros formadores de mercado e bots quantitativos eram atormentados por um fenômeno: seu bot captura uma ótima oportunidade em um mercado de nível de 5 minutos (como BTC Up/Down 5m) e envia imediatamente uma solicitação Taker. A API do Polymarket retorna instantaneamente: "Combinado! Sucesso!" Seu alerta do Telegram também aparece com a empolgação de "PREENCHIDO" (FILLED). Mas quando você abre o Polygonscan para verificar o explorador de blockchain, descobre que esta transação está marcada como REVERTED (falhou), desperdiçando taxas de Gas por nada. E sua posição permanece inalterada.

O livro de ofertas mostra claramente um pareamento, mas a blockchain diz que nada aconteceu. Isso é ghost fill (Ghost Fill).

Para entender a essência deste bug, precisamos retornar à arquitetura subjacente discutida no Capítulo 1: Pareamento Off-chain + Liquidação On-chain.

Quando o pedido de compra de Alice e o pedido de venda de Bob se combinam no Livro de Ofertas de Limite Central (CLOB) off-chain, o sistema apenas desenha um sinal de igual entre esses dois pedidos no banco de dados. A transferência real de ativos requer que o Operador empacote as assinaturas de ambas as partes e as envie para a rede Polygon para execução do TransferFrom.

Isso cria uma lacuna de tempo fatal. Durante essa lacuna de tempo, o estado da carteira do usuário pode mudar.

8.2 Dois caminhos de ataque de Ghost Fill

No início da V1 e na V2 recém-lançada, hackers e formadores de mercado maliciosos exploraram essa lacuna de tempo para inventar dois métodos de ataque altamente destrutivos:

• Primeiro: Ataque de incrementNonce de baixo custo (Era V1)

  Na arquitetura V1, os estados dos pedidos eram gerenciados por um nonce global (número aleatório). Jogadores maliciosos podiam postar loucamente pedidos falsos altamente atraentes (Spoofing) off-chain. Quando um comprador real morde a isca, e o pedido mostra um pareamento off-chain, o jogador malicioso pode chamar a função incrementNonce on-chain antes que o Operador a envie.

  Esta operação custa muito pouco (alguns centavos em Gas), mas pode invalidar instantaneamente todos os pedidos de nonce antigos para aquele endereço. Quando o Operador envia a transação pareada on-chain, o contrato inteligente descobre que o nonce está incorreto e reverte diretamente. O atacante escapa ileso, enquanto o comprador real não só perde a oportunidade de negociação, mas também pode ser enganado pelo livro de ofertas falso.

• Segundo: "Pedidos Zumbis" de carteiras vazias (V2 inicial)

  A atualização V2 removeu o nonce global e usou um único hash de pedido para gerenciar estados de cancelamento, bloqueando o primeiro caminho. Mas os hackers descobriram rapidamente uma vulnerabilidade mais profunda: decepção de saldo. Um usuário malicioso pode depositar $1000 em uma carteira, assinar um monte de pedidos limite no valor total de $10.000 e, em seguida, transferir imediatamente todo o dinheiro para fora da carteira. Como os pedidos do Polymarket são assinados offline, contanto que a assinatura seja válida e a aprovação do token (Approval) não seja revogada, esses pedidos parecem "legítimos" para o motor de pareamento off-chain. Mas, na realidade, o saldo desta carteira é $0.

  Quando seu bot consome esses "pedidos zumbis", e o Operador envia on-chain, a função TransferFrom da biblioteca Solady subjacente lançará um erro (código de erro 0x7939f424) devido a saldo insuficiente do outro lado. Sua transação reverte novamente.

8.3 Por que as exchanges tradicionais não têm esse problema?

Você pode perguntar: por que a Binance ou exchanges descentralizadas tradicionais (como a Uniswap) não têm esse problema?

Porque a Binance é puramente centralizada; seu dinheiro existe em seu banco de dados e ela tem controle absoluto. O pareamento e a dedução ocorrem atomicamente. E a Uniswap é puramente on-chain; o pareamento e a dedução são concluídos na mesma transação de um contrato inteligente, também atomicamente.

Mas o Polymarket escolheu uma arquitetura híbrida: o pareamento off-chain busca velocidade, enquanto a liquidação on-chain busca transparência. Enquanto isso, os fundos dos usuários são armazenados em carteiras totalmente autocustodiadas (como EOA ou Gnosis Safe), onde os usuários têm direitos de disposição absolutos e podem transferir dinheiro a qualquer momento.

Enquanto os estados de financiamento em ambas as extremidades do pareamento estiverem vinculados à carteira verdadeiramente livre e autocustodiada do usuário, a "desconexão de estado" sempre existirá.

8.4 A solução definitiva: Carteira de Depósito (Tesouraria Associada)

Em 4 de maio de 2026, o Polymarket anunciou oficialmente uma grande atualização no nível do protocolo central, reduzindo diretamente a proporção de ghost fills de um pico de 30% para 0,17%, e tendendo a zero.

Como eles fizeram isso? A resposta é a introdução da Carteira de Depósito (Tesouraria Associada).

O Polymarket finalmente percebeu que a maneira fundamental de resolver ghost fills é restringir a "liberdade absoluta" de fundos dos usuários. Sob a nova arquitetura, os usuários não podem mais participar diretamente do pareamento off-chain com suas carteiras nativas (EOA). Você deve primeiro depositar fundos em uma Carteira de Depósito controlada por um contrato inteligente.

Nesta tesouraria:

• Você tem propriedade, mas não direitos de disposição imediatos absolutos.

• Quando você faz um pedido off-chain, a tesouraria bloqueia logicamente o saldo disponível correspondente.

• Se você quiser sacar dinheiro da tesouraria, essa operação de saque (Revogação de Estado) em si é atribuída a um custo de tempo físico. Ela deve passar por verificação pelo contrato inteligente para garantir que você não tenha pedidos pendentes sendo pareados.

Ao introduzir essa camada de buffer, o Polymarket vincula forçosamente o estado de pareamento off-chain e o estado de financiamento on-chain, eliminando completamente a possibilidade de "pedidos de carteira vazia". Isso não é apenas uma vitória da engenharia, mas também um compromisso profundo e reconstrução da contradição entre "autocustódia" e "eficiência de negociação" nas finanças descentralizadas.

8.5 Outras atualizações hardcore na V2

Além da solução definitiva para Ghost Fill, a arquitetura V2 também inclui várias atualizações profundas que mudam o cenário do mercado:

• Transferência de Poder do pUSD: Em 28 de abril, a garantia subjacente mudou totalmente de USDC.e para pUSD. Isso permitiu que o Polymarket ganhasse controle sobre os ativos subjacentes que rendem juros, permitindo que ele fornecesse aos usuários até 4,00% de recompensas anuais por manter. O pUSD tornou-se a nova infraestrutura de eficiência de capital.

• Implementação da Fórmula Perfeita p(1-p): A aproximação grosseira de min(p, 1-p) da era V1 foi abandonada, e a fórmula de taxa foi modificada diretamente para a fórmula de variância de Bernoulli perfeita p × (1-p). A suavidade absoluta permite matematicamente que os modelos de precificação dos arbitradores sejam mais precisos.

• Remoção de Speed Bumps Artificiais: Nos primeiros dias, para proteger os formadores de mercado de serem batidos por bots de API, o código codificou um atraso de Taker de até 500 milissegundos. Com a melhoria de desempenho do motor V2 e a introdução do mecanismo de Heartbeat (desconectar por 10 segundos limpa os pedidos), a equipe oficial removeu completamente esse speed bump artificial no final de fevereiro, declarando que o Polymarket entrou oficialmente no combate corpo a corpo de HFT (negociação de alta frequência) de nível de microssegundo. (É também por isso que nós do insiders.bot estamos nos preparando para abrir o código-fonte da API em breve para participar desta batalha.)

Conclusão: Vendo através desta máquina do zero

A partir do momento em que você clica para fazer um pedido:

• Sua assinatura é enviada para o livro de ofertas off-chain.

• O Relayer queima seu Gas para pavimentar o caminho para você.

• O Operador busca o caminho de pareamento ideal para você entre COMPLEMENTARY, MINT e MERGE.

• A curva de taxas extrai elegantemente pequenos custos de fricção usando a fórmula p(1-p).

• Se sua operação for complexa, o NegRiskAdapter até realizará a alquimia da conservação de material para você.

Por fim, tudo é liquidado dentro daqueles decisivos 250 milissegundos. (É também por isso que o insiders.bot considera a transparência e a velocidade de seguir negociações como cruciais.)

Seu dinheiro não desapareceu. Ele está apenas seguindo estritamente as leis físicas desta máquina precisa chamada ctf-exchange-v2, fluindo para onde deveria ir.

Da próxima vez que você vir probabilidades ultrajantes ou uma oportunidade de arbitragem tentadora no Polymarket, não corra para clicar em Comprar. Primeiro, percorra as engrenagens desta máquina em sua mente.

Entendendo esses "Fa" fundamentais, combinados com o "Dao" correto, você certamente será invencível.

P.S. A versão em PDF deste artigo também está pronta. Siga @insidersdotbot e envie uma DM com "PDF" para obtê-la rapidamente.

Referências

[1] Documentação Oficial do Polymarket: Reinicializações do Motor de Pareamento e Mecanismo de Heartbeat.

[2] Documentação Oficial do Polymarket: Taxas e Fórmula de Cálculo p(1-p).

[3] Código-fonte do Contrato Inteligente Polymarket/ctf-exchange-v2 (GitHub).

[4] NegRiskAdapter.sol: Implementação Matemática de Conversões de Múltiplos Resultados.

[5] leolabs.me: "Por que seu PnL do Polymarket está errado" (análise contábil de Split/Merge).

[6] Reddit r/algotrading & Binance Square: Anúncios de remoção de atraso do Polymarket Taker (fev 2026).

[7] Guia de Migração do Polymarket V2: Transição de USDC.e para pUSD (abril 2026).