Explicação do Algoritmo Subjacente da Polymarket

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

Prefácio: O lado B da Polymarket que desconhece

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

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

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

No entanto, o "Fa", que se refere à estrutura de negociação subjacente dos mercados de previsão, cálculos de PNL e as regras de fluxo de dinheiro, é discutido apenas por esse 1% das pessoas, maioritariamente disperso por alguns tweets concisos. Estes especialistas eremitas parecem não estar dispostos, ou não ter energia, para partilhar os seus métodos completos com todos de uma vez.

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

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

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

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

Por isso, penso que podemos ser aqueles que melhor conseguem dissecar o "Fa" da Polymarket.

Neste artigo, ajudá-lo-ei a compreender como o contrato inteligente ctf-exchange-v2 subjacente lida com cada fundo, como o Relayer o ajuda 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 da Polymarket a partir da perspetiva de um programador.

Comecemos pelo básico. Ou seja, quando coloca uma ordem, o que está exatamente a enviar?

P.S. Este artigo também foi adaptado em estilo e estrutura por IA, sinta-se à vontade para o partilhar com o seu OpenClaw, Manus, Hermes ou qualquer Agente de IA como material de treino!!!

Capítulo 1: O que acontece desde o clique até à blockchain

1.1 As ordens não são transações, são "intenções"

Nas bolsas descentralizadas tradicionais (como a Uniswap), quando negocia, a sua carteira abre uma caixa de confirmação, precisa de pagar taxas de Gas e, em seguida, enviar uma transação para a rede blockchain (Mempool) para esperar que os mineiros a empacotem.

Mas na Polymarket, quando coloca uma ordem, a sua carteira geralmente abre um pedido de "assinatura", em vez de um pedido de "transação". Além disso, não precisa de pagar qualquer Gas.

Isto não é apenas uma otimização da experiência do utilizador; é uma diferença fundamental em toda a arquitetura subjacente.

Na Polymarket, uma ordem é essencialmente um conjunto de dados estruturados que cumpre o padrão EIP-712. Estes dados contêm o que pretende fazer:

• É um Maker ou um Taker? Que Token (tokenId) quer comprar?

• Quanto quer pagar (makerAmount)?

• Quanto quer receber (takerAmount)?

Quando assina, está simplesmente a carimbar estes dados com a sua chave privada, provando "Eu quero realmente fazer isto". Depois, estes dados assinados são enviados para o servidor centralizado da Polymarket e armazenados num Livro de Ordens de Limite Central (CLOB) fora da cadeia.

Nesta fase, nada aconteceu na blockchain. O seu dinheiro ainda está na sua carteira e os tokens não foram transferidos. A sua ordem é apenas um registo na base de dados.

1.2 Expressão implícita de preço

Vamos pausar o tempo no momento em que envia a ordem. Se olhar atentamente para a estrutura de ordens dos contratos subjacentes da Polymarket, encontrará algo muito contraintuitivo: não existe um campo de "preço" nos dados de assinatura da ordem.

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

No design subjacente do protocolo da Polymarket, o preço é implícito. É calculado com base no montante que está disposto a pagar e no montante que quer receber.

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

• Precisa de pagar: 60 pUSD (makerAmount = 60)

• Quer receber: 100 contratos YES (takerAmount = 100)

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

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

• Precisa de pagar: 100 contratos YES (makerAmount = 100)

• Quer receber: 60 pUSD (takerAmount = 60)

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

(Nota: Embora no SDK V2 mais recente, os programadores possam inserir diretamente o preço e o tamanho, o SDK ainda os converte para makerAmount e takerAmount durante a assinatura subjacente. A inteligência deste design reside no facto de o contrato inteligente não precisar de entender o que é "preço"; apenas precisa de lidar com a lógica de "ativo A trocado pelo ativo B". Isto simplifica muito a lógica de cálculo na cadeia e reduz o consumo de Gas.)

1.3 Operador: O "polícia de trânsito" da Polymarket

Uma vez que as ordens estão todas fora da cadeia, como se tornam transferências reais de ativos na cadeia?

Isto leva-nos ao papel de caixa negra mais central na arquitetura da Polymarket: Operador.

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

Isto é completamente diferente das DeFi tradicionais. Na Uniswap, qualquer pessoa pode chamar o contrato de encaminhamento. Mas na Polymarket, não pode corresponder negociações na cadeia sozinho. Todas as correspondências devem ser submetidas pelo Operador.

Por que é desenhado desta forma? Para eliminar MEV (Valor Extraível pelo Mineiro) e front-running.

Nos livros de ordens tradicionais na cadeia, se alguém colocar uma ordem grande a um preço muito baixo, todos os bots de arbitragem licitarão freneticamente na Mempool (aumentando as taxas de Gas) para tentar passar à frente dos outros e consumir essa ordem. Isto leva a taxas de Gas disparadas e a uma experiência pobre para os utilizadores comuns.

Na Polymarket, todas as ordens estão no CLOB fora da cadeia. O motor de correspondência do Operador calcula quem deve negociar com quem no servidor, depois empacota o resultado numa transação, que é enviada para a cadeia pelo Operador.

Como apenas o Operador pode submeter os resultados da correspondência, mesmo que os bots na Mempool vejam esta transação, não podem fazer front-running porque não têm autoridade para chamar as funções de execução.

Esta é uma arquitetura típica de "descentralização híbrida". A correspondência e a ordenação são centralizadas (decididas pelo Operador), mas a liquidação e a custódia de fundos são descentralizadas (executadas por contratos inteligentes).

O Operador pode decidir quem corresponder primeiro e quem corresponder depois, mas não pode absolutamente roubar os seus fundos porque tem de fornecer os dados EIP-712 assinados por si, e o contrato verificará estritamente a assinatura.

P.S: No entanto, devo mencionar que a nossa equipa @insidersdotbot parece ter descoberto recentemente uma forma de explorar este mecanismo, permitindo que os seguidores façam front-running ou atrasem significativamente as transações. Se houver alguma atualização, anunciaremos na conta oficial o mais rapidamente possível.

Capítulo 2: A economia do Relayer

2.1 A ilusão de "sem Gas"

Um dos maiores pontos de venda da Polymarket são as suas "Transações sem Gas" para os utilizadores. Só precisa de pUSD para negociar, sem precisar de comprar POL (anteriormente MATIC) para manter na sua carteira.

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

Uma vez que não pagou, quem pagou? A resposta é: Relayer.

2.2 A rede de retransmissão do Relayer

A Polymarket não permite que os utilizadores enviem transações eles próprios, mas implementou uma infraestrutura chamada Relayer Client (relayer-v2.polymarket.com).

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

Quando a sua aplicação cria uma transação (como Aprovar tokens, Resgatar lucros), assina-a com a sua chave privada e envia-a para o Relayer. O Relayer atua como um "Patrocinador de Transação", submetendo esta transação à cadeia e cobrindo as taxas de Gas com o seu próprio pool de fundos.

Arquitetura e Ciclo Económico do Relayer

2.3 A lã vem da ovelha?

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

Mas a Polymarket é extremamente agressiva: na arquitetura V2 atual, eles cobrem realmente o valor total por si.

A documentação oficial declara claramente: "A Polymarket paga o gas para todas as operações encaminhadas através do relayer." Quer seja implementar carteiras, autorizar tokens, ou dividir (Split), fundir (Merge), ou resgatar (Redeem), tudo é sem gas e não são cobradas taxas operacionais ocultas.

Por que a Polymarket está disposta a assumir esta perda?

Porque os custos de Gas na Polygon são muito baixos (geralmente apenas alguns cêntimos), e a experiência sem gas pode atrair um influxo massivo de utilizadores Web2. Desde que os utilizadores incorram numa pequena taxa de Taker durante a negociação (que será discutida mais tarde), é suficiente para cobrir este custo de Gas extremamente baixo.

Sabendo isto, a questão seguinte surge naturalmente: que impacto tem esta arquitetura "sem gas" na nossa negociação?

O maior custo oculto é a latência. A sua ordem não só tem de passar pelo motor de correspondência da Polymarket, mas se for uma operação direta na cadeia, também tem de passar pela verificação do Relayer, estimativa de Gas e alocação de fila.

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

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

Nas bolsas tradicionais (como o livro de ordens da Binance), a lógica de correspondência é muito simples: a Alice quer comprar 1 token por $60, o Bob quer vender 1 token por $60. A bolsa corresponde-os, o token vai do Bob para a Alice e o dinheiro vai da Alice para o Bob. Fim da história.

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

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

Estrutura Geral de Complementary, Mint, Merge

3.1 COMPLEMENTARY (Correspondência Complementar): Negociação tradicional em segunda mão

Este é o método de correspondência mais fácil de entender e o único método que as bolsas tradicionais têm.

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

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

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

O Operador encontra estas duas ordens (COMPRA vs VENDA) e empacota-as na cadeia. O contrato inteligente executa uma transferência direta ponto a ponto:

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

2. Transfere $60 pUSD do endereço da Alice para o 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: Num mercado maduro e líquido, a grande maioria das negociações diárias é conduzida desta forma.

3.2 MINT (Correspondência de Cunhagem): Criar liquidez do nada

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

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

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

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

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

Num livro de ordens tradicional, estas duas ordens só podem olhar uma para a outra e nunca conseguirão executar. Na Polymarket, se ocorrer uma COMPRA vs COMPRA (e os tokens forem complementares), o Operador corresponderá estas duas ordens!

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

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

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

4. Envia 100 YES para a Alice.

5. Envia 100 NO para o Bob.

O acionamento deste mecanismo deve basear-se numa condição matemática estrita: a soma das licitações dos compradores deve ser maior ou igual a $1,00.

Se a Alice licitar $0,60 por YES e o Bob licitar $0,35 por NO, o total é apenas $0,95. O contrato inteligente não pode cunhar um par de tokens completo no valor de $1,00 com $0,95. Esta correspondência falhará diretamente.

Mecanismo de Correspondência MINT

Da perspetiva de um criador de mercado, este mecanismo é a arma definitiva para resolver o problema do "arranque a frio". Quando o mercado abre, os criadores de mercado não precisam de gastar dinheiro para cunhar um monte de tokens para manter (o que ocuparia muitos fundos). Eles só precisam de colocar ordens de compra em ambos os lados YES e NO simultaneamente (por exemplo, $0,49 para YES, $0,49 para NO). Quando os investidores retalhistas vêm vender, isso acionará a lógica de cunhagem.

3.3 MERGE (Correspondência de Fusão): A aniquilação da liquidez

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

Vejamos um caso inverso. O mercado está prestes a fechar e todos estão a fechar as suas posições.

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

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

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

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

1. O contrato inteligente retira 100 YES da Alice.

2. O contrato inteligente retira 100 NO do Bob.

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

4. Envia $60 pUSD para a Alice.

5. Envia $40 pUSD para o Bob.

O mecanismo de Fusão 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", desde que os preços de venda de YES e NO possam somar $1,00 (na verdade, desistindo de $1,00 de espaço), todos ainda podem levantar dinheiro.

Compreender estes três métodos de correspondência dá-lhe uma visão sobre o ciclo de vida do mercado da Polymarket:

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

• Fase Intermédia (Dominada por COMPLEMENTARY): O mercado tem ampla liquidez e a maioria das negociações são trocas de tokens existentes. A oferta total estabiliza.

• Fase Final (Dominada por MERGE): Os resultados tornam-se mais claros e todos começam a fechar as suas posições. Tanto os lados otimistas como pessimistas destroem tokens através do mecanismo MERGE para levantar dinheiro. A oferta total diminui.

Tenha em atenção que estes três caminhos não são escolhidos subjetivamente pelo Operador, mas são estritamente determinados pelas regras de encaminhamento do contrato inteligente com base na direção das ordens (COMPRA vs VENDA).

Ciclo de Vida do Mercado

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

Tendo compreendido o mecanismo de correspondência, vejamos três operações subjacentes que pode usar todos os dias, mas nunca compreendeu verdadeiramente o seu impacto financeiro: Split, Merge e Redeem.

Estas três operações são as operações ao nível atómico da Polymarket. Não são "negociações" (não passam pelo livro de ordens, não incorrem em taxas), mas interagem diretamente com o contrato inteligente para conversão de ativos.

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

• Merge: Dá ao contrato 1 YES e 1 NO e o contrato devolve-lhe $1 pUSD. O lucro é sempre exatamente $1.

• Redeem: Após o mercado determinar o vencedor e o vencido, 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 estas operações?

• Criadores de Mercado: São os maiores utilizadores de Split. Os criadores de mercado precisam de colocar ordens em ambos os lados simultaneamente, mas não querem comprar tokens no mercado (o que incorre em taxas). Eles dividem diretamente $100.000 em 100.000 YES e 100.000 NO e, em seguida, colocam-nos no livro de ordens.

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

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

Atualmente, incluindo a própria Polymarket, ninguém consegue resolver o problema do cálculo de PnL. Claro, pode ter adivinhado - o insiders.bot já resolveu este problema nos cálculos de PnL e navegadores de smart money.

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

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

Deixe-me calcular um exemplo para si e verá quão profunda é esta armadilha.

Passo 0: Assuma que tem um capital de $100. Está otimista quanto ao mercado "Ethereum a ultrapassar os $5000".

Passo 1: Gasta $50 para executar um Split. Agora tem 50 YES e 50 NO. O seu dinheiro permanece $50.

Passo 2: Sente que 50 YES não são suficientes, por isso vai ao mercado e compra 50 YES a um preço de $0,40. Custando $20. O dinheiro permanece $30.

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

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

Como a maioria das tabelas de classificação calcula (Algoritmo Errado):

Eles apenas olham para os seus registos de "negociação". Veem que comprou 50 YES, custando $20. Ignoram completamente o Split (porque isso não é uma negociação).

Por isso, pensam que o seu custo é: $20 / 50 = $0,40 cada.

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

Como deve calcular realmente (Algoritmo Correto, e o que o insiders.bot está a usar):

A sua saída total de dinheiro: $50 (Split) + $20 (compra) = $70.

A sua entrada total de dinheiro: $17,50 (venda de NO)

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

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

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

Vê a diferença? A tabela de classificação mostra que ganhou $40, mas na verdade só ganhou $7,50. Os $32,50 de "lucro fantasma" no meio devem-se ao facto de o sistema não ter lidado corretamente com o custo do Split e a receita da venda de NO.

A fórmula matemática correta de PnL deve 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 vê alguns grandes jogadores na tabela de classificação a mostrar perdas de milhões, mas na realidade, estão a fazer fortuna. Porque posições vencedoras, após serem Resgatadas, muitas ferramentas "apagarão" estas posições dos registos históricos, deixando apenas aquelas que ainda estão em perda.

Armadilha de Cálculo de PnL

Capítulo 5: Curva de Taxas

Se negociar frequentemente, descobrirá que as taxas da Polymarket não são uma percentagem fixa. Às vezes, cobram-lhe $10 por comprar um contrato de $1000 e, às vezes, apenas $2.

Porquê? Vamos dar uma olhada na fórmula de taxas escondida profundamente no código:

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

5.1 Por que p(1-p)?

Suponha que quer 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

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, existe simetria. Comprar YES a $0,90 e comprar NO a $0,10 são matematicamente equivalentes. Se lhe for cobrada uma taxa alta por comprar YES a $0,90 e uma taxa baixa por comprar NO a $0,10, os arbitradores ficarão loucos a comprar NO e depois a arbitrar através do mecanismo MINT. O design de p(1-p) garante que, independentemente do lado de onde expressa a sua opinião, os custos de fricção cobrados pelo sistema são absolutamente simétricos.

5.2 A beleza matemática escondida

Se 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 da 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 aposta a 50%, fornece a maior quantidade de informação nova ao mercado, por isso o 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 é mais incerto (50/50), os primeiros participantes serão cobrados com as taxas mais altas, protegendo os criadores de mercado de choques desnecessários; enquanto quando o mercado é quase certo, taxas extremamente baixas encorajam os arbitradores a entrar e empurrar os preços para o 1 ou 0 final.

Curva de Taxas

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

Se jogou mercados de múltiplos resultados como eleições, Óscares ou eventos desportivos na Polymarket, 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 o nosso cofundador @DakshBigShit resolveu após uma maratona de 36 horas enquanto desenvolvia a nossa própria API.

6.1 Pontos de dor dos mercados tradicionais de múltiplos resultados

Suponha que existem quatro candidatos: A, B, C, D. Odeia absolutamente A e tem a certeza de que A não pode ganhar. Quer "vender a descoberto" A.

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

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

6.2 A magia do Adaptador de Negative Risk (NegRiskAdapter)

A Polymarket implementou um contrato inteligente dedicado NegRiskAdapter para resolver este problema. Fornece uma função chamada convertPositions.

O objetivo da função é converter instantaneamente os seus contratos NO em contratos YES para todos os outros candidatos e devolver-lhe um montante em dinheiro.

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

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

• Tem A ações de contratos NO para o candidato 1 e A ações de contratos NO para o candidato 2 (está a vender a descoberto ambos 1 e 2).

• Detém um total de m contratos NO diferentes (aqui m=2).

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

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

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

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

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

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

Neste exemplo, devolve: 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 das suas participações (em todas as linhas temporais possíveis):

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

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

• Se o candidato 3 ganhar: o seu YES_3 vale $1, os 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 desenvolve, o valor antes e depois da conversão é absolutamente igual.

Prova Matemática da Conversão de Negative Risk

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 encantadora: é unidirecional e irreversível.

Pode converter NO em YES + dinheiro. Mas nunca pode converter YES + dinheiro de volta em NO.

Porquê? Porque ao nível subjacente do contrato inteligente, quando converte NO em YES, o contrato envia realmente os seus contratos NO para um endereço de buraco negro (Burn) e, em seguida, usa o espaço colateral libertado a partir disto para "sintetizar" novos contratos YES. Isto não requer a injeção de novos fundos externos.

Mas se quiser reverter e transformar YES em NO, precisa de criar novo colateral 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.

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

Existe uma enorme oportunidade de arbitragem aqui: se 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, pode comprar esse NO, chamar convertPositions para obter dinheiro e um monte de YES, e depois vender imediatamente esses YES. Esta é a estratégia de arbitragem sem risco de nível mais alto em mercados de múltiplos resultados.

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

Finalmente, falemos 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). Na Polymarket, discutimos milissegundos. Mas existe uma enorme desigualdade estrutural aqui.

Se se misturou na secção de negociação algorítmica do Reddit, descobrirá que todos os programadores que desenvolvem bots da Polymarket se queixaram da mesma coisa: "Por que tenho sempre de esperar 300 milissegundos por ordens Taker, enquanto as ordens Maker só levam 25 milissegundos?"

7.1 Por que as ordens Maker são rápidas e as ordens Taker lentas?

• Quando coloca uma Maker (ordem limite): A sua ordem (dados de assinatura) é enviada para o servidor da Polymarket. O servidor verifica a validade da assinatura e insere diretamente este registo na base de dados CLOB (livro de ordens) na memória. Depois, devolve imediatamente um ACK (confirmação) para si. Todo o processo ocorre inteiramente fora da cadeia e requer apenas uma escrita na base de dados. Tempo necessário: ~25 milissegundos.

• Quando coloca uma Taker (ordem de mercado): A sua ordem é enviada para o servidor. O motor de correspondência descobre que a sua ordem pode corresponder a um Maker no livro de ordens. Neste ponto, o Operador deve iniciar um pipeline de liquidação complexo:

  1. Decidir qual caminho de correspondência usar (COMPLEMENTARY, MINT ou MERGE).

  2. Construir dados de transação na cadeia 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. Esperar que os nós confirmem que esta transação não reverterá devido a saldo insuficiente ou outras razões.

  Todo o processo abrange múltiplos microsserviços e até toca as bordas da blockchain. Tempo necessário: ~250 a 300 milissegundos.

7.2 O que significam estes 250 milissegundos?

Este hiato físico de 250 milissegundos molda profundamente o ecossistema da Polymarket.

Primeiro, é muito difícil fazer front-running na Polymarket. Como todas as ordens Taker devem esperar na fila pelo Operador para processar, não pode cortar 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 as ordens Maker são ambas operações fora da cadeia, levam apenas 25 milissegundos. Quando ocorrem notícias de última hora, os criadores de mercado experientes podem usar esta diferença de tempo de 250 milissegundos para cancelar as suas ordens antes que as ordens Taker sejam liquidadas (isto chama-se evitar a seleção adversa).

7.3 Os 90 segundos de inatividade todas as terças-feiras de manhã

Existe outro detalhe pouco conhecido sobre o tempo. De acordo com a documentação oficial, todas as terças-feiras às 7:00 da manhã (hora do Leste), o motor de correspondência da Polymarket reinicia. Durante estes aproximadamente 90 segundos, o sistema para de processar quaisquer correspondências e a API devolve 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, cancelará automaticamente todas as ordens abertas para esse utilizador. Durante estes 90 segundos de reinício, os heartbeats dos criadores de mercado são forçosamente interrompidos e as suas ordens serão coletivamente limpas pelo sistema.

Estes 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) destes 90 segundos e como aproveitar o mercado quando o motor retoma no 91º segundo, é o puzzle final para as principais plataformas e estúdios quantitativos.

Comparação da Linha Temporal de Atraso

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

Se leu até aqui, compreendeu a estrutura central da Polymarket. Mas se quer continuar a ganhar dinheiro neste mercado em 2026, deve compreender o grande terramoto que acabou de ocorrer.

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

8.1 O que é o Ghost Fill? A desconexão de estado entre a cadeia e fora da cadeia

Antes da atualização da Polymarket V2, inúmeros criadores de mercado e bots quantitativos eram atormentados por um fenómeno: o seu bot captura uma grande oportunidade num mercado de nível de 5 minutos (como BTC Up/Down 5m) e envia imediatamente um pedido Taker. A API da Polymarket devolve instantaneamente: "Correspondido! Sucesso!" O seu alerta do Telegram também aparece com a excitação de "FILLED". Mas quando 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 a sua posição permanece inalterada.

O livro de ordens mostra claramente uma correspondência, mas a blockchain diz que nada aconteceu. Isto é ghost fill (Ghost Fill).

Para entender a essência deste bug, precisamos de voltar à arquitetura subjacente discutida no Capítulo 1: Correspondência fora da cadeia + Liquidação na cadeia.

Quando a ordem de compra da Alice e a ordem de venda do Bob correspondem no Livro de Ordens de Limite Central (CLOB) fora da cadeia, o sistema apenas desenha um sinal de igual entre estas duas ordens na base de dados. A transferência real de ativos requer que o Operador empacote as assinaturas de ambas as partes e as submeta à cadeia Polygon para execução de TransferFrom.

Isto cria um hiato temporal fatal. Durante este hiato temporal, o estado da carteira do utilizador 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 criadores de mercado maliciosos exploraram este hiato temporal para inventar dois métodos de ataque altamente destrutivos:

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

  Na arquitetura V1, os estados das ordens eram geridos por um nonce global (número aleatório). Jogadores maliciosos podiam publicar loucamente ordens falsas altamente atraentes (Spoofing) fora da cadeia. Quando um comprador real morde o isco e a ordem mostra uma correspondência fora da cadeia, o jogador malicioso pode chamar a função incrementNonce na cadeia antes que o Operador a submeta.

  Esta operação custa muito pouco (alguns cêntimos em Gas) mas pode invalidar instantaneamente todas as ordens de nonce antigas para esse endereço. Quando o Operador submete a transação correspondida na cadeia, 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, como também pode ser enganado pelo livro de ordens falso.

• Segundo: "Ordens Zombi" de carteiras vazias (Início da V2)

  A atualização V2 removeu o nonce global e usou um hash de ordem única para gerir estados de cancelamento, bloqueando o primeiro caminho. Mas os hackers descobriram rapidamente uma vulnerabilidade mais profunda: o engano de saldo. Um utilizador malicioso pode depositar $1000 numa carteira, assinar um monte de ordens limite no valor total de $10.000 e, em seguida, transferir imediatamente todo o dinheiro para fora da carteira. Como as ordens da Polymarket são assinadas offline, desde que a assinatura seja válida e a aprovação do token (Approval) não seja revogada, estas ordens parecem "legítimas" para o motor de correspondência fora da cadeia. Mas na realidade, o saldo desta carteira é $0.

  Quando o seu bot consome estas "ordens zombi" e o Operador submete na cadeia, a função TransferFrom da biblioteca Solady subjacente lançará um erro (código de erro 0x7939f424) devido a saldo insuficiente do outro lado. A sua transação reverte novamente.

8.3 Por que as bolsas tradicionais não têm este problema?

Pode perguntar: por que a Binance ou as bolsas descentralizadas tradicionais (como a Uniswap) não têm este problema?

Porque a Binance é puramente centralizada; o seu dinheiro existe na sua base de dados e tem controlo absoluto. A correspondência e a dedução ocorrem atomicamente. E a Uniswap é puramente na cadeia; a correspondência e a dedução são concluídas na mesma transação de um contrato inteligente, também atomicamente.

Mas a Polymarket escolheu uma arquitetura híbrida: a correspondência fora da cadeia procura velocidade, enquanto a liquidação na cadeia procura transparência. Entretanto, os fundos dos utilizadores são armazenados em carteiras completamente autocustodiadas (como EOA ou Gnosis Safe), onde os utilizadores têm direitos de disposição absolutos e podem transferir dinheiro a qualquer momento.

Desde que os estados de financiamento em ambas as extremidades da correspondência estejam ligados à carteira autocustodiada verdadeiramente livre do utilizador, a "desconexão de estado" existirá sempre.

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

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

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

A Polymarket percebeu finalmente que a forma fundamental de resolver os ghost fills é restringir a "liberdade absoluta" de fundos dos utilizadores. Sob a nova arquitetura, os utilizadores já não podem participar diretamente na correspondência fora da cadeia com as suas carteiras nativas (EOA). Deve primeiro depositar fundos numa Carteira de Depósito controlada por um contrato inteligente.

Nesta tesouraria:

• Tem propriedade, mas não direitos de disposição imediatos absolutos.

• Quando coloca uma ordem fora da cadeia, a tesouraria bloqueia logicamente o saldo disponível correspondente.

• Se quiser levantar dinheiro da tesouraria, esta operação de levantamento (Revogação de Estado) é atribuída a um custo de tempo físico. Deve passar por verificação pelo contrato inteligente para garantir que não tem ordens pendentes a serem correspondidas.

Ao introduzir esta camada de buffer, a Polymarket liga forçosamente o estado de correspondência fora da cadeia e o estado de financiamento na cadeia, eliminando completamente a possibilidade de "ordens de carteira vazia". Isto não é apenas uma vitória de 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 o Ghost Fill, a arquitetura V2 também inclui várias atualizações profundas que mudam o panorama do mercado:

• Transferência de Poder de pUSD: A 28 de abril, o colateral subjacente mudou totalmente de USDC.e para pUSD. Isto permitiu à Polymarket ganhar controlo sobre os ativos subjacentes que geram juros, permitindo-lhe fornecer aos utilizadores até 4,00% de recompensas anuais de detenção. 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 taxas 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 Lombas de Velocidade Artificiais: Nos primeiros tempos, para proteger os criadores 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 as ordens), a equipa oficial removeu completamente esta lomba de velocidade artificial no final de fevereiro, declarando que a Polymarket entrou oficialmente no combate de HFT (negociação de alta frequência) ao nível de microssegundos. (É também por isso que nós no insiders.bot estamos a preparar o open-source da API em breve para nos juntarmos a esta batalha.)

Conclusão: Ver através desta máquina a partir do zero

Desde o momento em que clica para colocar uma ordem:

• A sua assinatura é enviada para o livro de ordens fora da cadeia.

• O Relayer queima o seu Gas para abrir caminho para si.

• O Operador procura o caminho de correspondência ideal para si entre COMPLEMENTARY, MINT e MERGE.

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

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

Em última análise, 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.)

O seu dinheiro não desapareceu. Está apenas a seguir estritamente as leis físicas desta máquina precisa chamada ctf-exchange-v2, fluindo para onde deve ir.

Da próxima vez que vir probabilidades ultrajantes ou uma oportunidade de arbitragem tentadora na Polymarket, não se apresse a clicar em Comprar. Primeiro, percorra as engrenagens desta máquina na sua mente.

Compreendendo estes "Fa" fundamentais, combinados com o "Dao" correto, será certamente invencível.

P.S. A versão PDF deste artigo também está pronta. Siga @insidersdotbot e envie DM "PDF" para a obter rapidamente.

Referências

[1] Documentação Oficial da Polymarket: Reinícios do Motor de Correspondência e Mecanismo de Heartbeat.

[2] Documentação Oficial da 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: "Why Your Polymarket PnL is Wrong" (análise contabilística de Split/Merge).

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

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