Prefácio
Durante o desenvolvimento de @insidersdotbot, mantive diálogos aprofundados com diversas equipas especializadas em market making de alta frequência e arbitragem. A questão mais recorrente foi: como estruturar estratégias de arbitragem realmente eficazes.
Os nossos utilizadores, amigos e parceiros estão a explorar o percurso complexo e multidimensional da arbitragem na @Polymarket. Se utiliza o Twitter de forma ativa, certamente já encontrou publicações como: “Ganhei X quantia em mercados de previsão com a estratégia de arbitragem Y.”
No entanto, a maioria dos artigos simplifica em demasia a lógica fundamental da arbitragem, reduzindo-a a “qualquer pessoa pode fazer” ou “basta usar o Clawdbot”, sem explicar de forma sistemática como construir um sistema próprio de arbitragem.
Se pretende compreender como as ferramentas de arbitragem da Polymarket geram lucros reais, recomendo este artigo de @RohOnChain—a análise mais completa que encontrei até hoje.
Tal como no meu artigo anterior, dado que o texto original em inglês contém secções técnicas que exigem estudo adicional, reestruturei e complementei o conteúdo para permitir que apreenda todos os pontos essenciais sem necessidade de procurar informação adicional.
Arbitragem na Polymarket: Não é Apenas um Problema de Matemática
Imagine que observa um mercado na Polymarket:
Preço YES 0,62$, preço NO 0,33$.
Pensa: 0,62 + 0,33 = 0,95, menos que 1—há uma oportunidade de arbitragem! Compra ambos YES e NO por 0,95$, e independentemente do resultado, recebe 1,00$, obtendo um lucro de 0,05$.
Correto.
Mas existe um problema—enquanto soma manualmente esses números, os sistemas quantitativos realizam um processo radicalmente diferente.
Estão a analisar simultaneamente 17 218 condições em 2^63 combinações possíveis de resultados, identificando todas as incoerências de preços em milissegundos. Quando coloca as suas ordens, o spread já desapareceu. O sistema já encontrou ineficiências semelhantes em dezenas de mercados relacionados, calculou tamanhos ideais de posição considerando profundidade do livro de ordens e taxas, executou todas as transações em paralelo e transferiu capital para a próxima oportunidade [1].
A diferença não está apenas na velocidade. É infraestrutura matemática.
Capítulo 1: Porque a “Adição” Não Basta—O Problema do Polítopo Marginal
A Falácia do Mercado Único
Considere um exemplo simples.
Mercado A: “Trump vai vencer na Pensilvânia?”
Preço YES 0,48$, preço NO 0,52$. Totaliza exatamente 1,00$.
Parece perfeito—sem arbitragem, certo?
Errado.
Adicione outro mercado e tudo muda.
Agora, Mercado B: “O Partido Republicano vai vencer na Pensilvânia por mais de 5 pontos percentuais?”
Preço YES 0,32$, preço NO 0,68$. Novamente, totaliza 1,00$.
Cada mercado parece “normal”. Mas existe uma dependência lógica:
A eleição presidencial nos EUA decide-se estado a estado. Cada estado é um “campo de batalha” separado, e quem obtém mais votos ganha todos os votos eleitorais desse estado (winner-takes-all). Trump é o candidato republicano. Assim, “Republicanos vencem na Pensilvânia” e “Trump vence na Pensilvânia” são o mesmo evento. Se os Republicanos vencerem por mais de 5 pontos, Trump não só vence na Pensilvânia como o faz de forma decisiva.
Ou seja, o YES do Mercado B (vitória esmagadora dos Republicanos) é um subconjunto do YES do Mercado A (Trump vence)—uma vitória esmagadora implica sempre uma vitória, mas uma vitória não implica necessariamente uma vitória esmagadora.
Esta dependência lógica cria oportunidades de arbitragem.
É como apostar em “Vai chover amanhã?” e “Vai haver uma trovoada amanhã?” Se há trovoada, tem de estar a chover (trovoada ⊆ chuva). Portanto, o preço de “Trovoada YES” nunca deveria ser superior ao de “Chuva YES”. Se o mercado precifica mal, pode comprar baixo e vender alto simultaneamente para um lucro sem risco. Isso é arbitragem.
Explosão Exponencial: Porque a Busca Bruta Falha
Para qualquer mercado com n condições, existem 2^n combinações possíveis de preços.
Parece gerível? Considere um exemplo real.
Mercado do Torneio NCAA 2010 [2]: 63 jogos, cada um com resultados de vitória/derrota. Isso dá 2^63 = 9 223 372 036 854 775 808 combinações possíveis—mais de 9 quintiliões. O mercado tinha mais de 5 000 livros de ordens.
Quão grande é 2^63? Mesmo verificando mil milhões de combinações por segundo, demoraria cerca de 292 anos a esgotá-las todas. Por isso, a busca bruta é completamente impraticável neste contexto.
Verificar cada combinação individualmente? Computacionalmente impossível.
Agora, veja as eleições dos EUA em 2024. Os investigadores encontraram 1 576 pares de mercados com possíveis dependências [2]. Se cada par tiver 10 condições, isso dá 2^20 = 1 048 576 combinações por par. Multiplique por 1 576 pares. Quando o seu portátil terminar, as eleições já acabaram há muito.
Programação Inteira: Usar Restrições em vez de Enumeração
Os sistemas quantitativos não resolvem isto com “enumeração mais rápida”, mas sim sem enumerar.
Utilizam programação inteira [3] para descrever “quais os resultados válidos”.
Exemplo real: mercado Duke vs. Cornell—cada equipa tem 7 livros de ordens (0 a 6 vitórias), totalizando 14 condições, ou 2^14 = 16 384 combinações possíveis.
Mas existe uma restrição: ambas não podem vencer mais de 5 jogos, pois encontrar-se-iam nas semifinais (apenas uma pode avançar).
Como resolve a programação inteira? Apenas três restrições:
Restrição 1: Exatamente um dos 7 livros de ordens da Duke é verdadeiro (a Duke só pode ter um número final de vitórias).
Restrição 2: Exatamente um dos 7 livros de ordens da Cornell é verdadeiro.
Restrição 3: Vitórias da Duke 5 + Vitórias da Duke 6 + Vitórias da Cornell 5 + Vitórias da Cornell 6 ≤ 1 (não podem ambas vencer tanto).
Três restrições lineares em vez de 16 384 verificações brutas.
Busca Bruta vs. Programação Inteira
Ou seja, a busca bruta é como ler cada palavra do dicionário para encontrar uma. A programação inteira é como ir diretamente à página certa. Não precisa de verificar todas as possibilidades—basta descrever como são as “respostas válidas” e deixar o algoritmo encontrar resultados mal precificados.
Dados Reais: 41% dos Mercados Oferecem Arbitragem
O artigo original indica que a equipa de investigação analisou dados de abril de 2024 a abril de 2025 [2]:
• 17 218 condições verificadas
• 7 051 condições tinham arbitragem de mercado único (41%)
• Desvio mediano do preço: 0,60$ (deveria ser 1,00$)
• 13 oportunidades confirmadas de arbitragem entre mercados
Um desvio mediano de 0,60$ significa que o mercado diverge frequentemente em 40%. Isto não é “quase eficiente”—é “amplamente explorável”.
Capítulo 2: Projeção de Bregman—Calcular a Operação Ótima de Arbitragem
Encontrar arbitragem é uma coisa. Calcular a operação ótima é outra.
Não pode simplesmente “fazer média” ou “ajustar preços”. Precisa de projetar o estado atual do mercado no espaço livre de arbitragem, preservando a estrutura informacional dos preços.
Porque a “Distância em Linha Reta” Não Funciona
A abordagem intuitiva é encontrar o “preço válido mais próximo” e negociar a diferença.
Matematicamente, isto significa minimizar a distância euclidiana: ||μ - θ||²
Mas isto trata todas as alterações de preço como iguais.
Uma passagem de 0,50$ para 0,60$ e de 0,05$ para 0,15$ são ambas alterações de 0,10$—mas o seu conteúdo informacional é drasticamente diferente.
Porquê? Porque os preços representam probabilidades implícitas. Passar de 50% para 60% é um ajuste moderado. Passar de 5% para 15% é uma mudança significativa—um evento quase impossível torna-se “algo possível”.
Imagine pesar-se: passar de 70 kg para 80 kg é “ganhou um pouco”. Mas de 30 kg para 40 kg (para um adulto), isso é “de quase morte para subnutrição severa”. A mesma alteração de 10 kg, mas significado completamente distinto. Alterações de preço perto de 0 ou 1 carregam muito mais informação.
Divergência de Bregman: A “Distância” Correta
O market maker da Polymarket utiliza LMSR (Logarithmic Market Scoring Rule) [4], onde os preços representam distribuições de probabilidade.
Aqui, o métrico de distância correto não é o euclidiano, mas a divergência de Bregman [5].
Para LMSR, a divergência de Bregman torna-se divergência KL (Kullback-Leibler) [6]—uma medida de “distância informacional” entre duas distribuições de probabilidade.
Não precisa de memorizar a fórmula. Basta saber:
A divergência KL atribui automaticamente maior peso a alterações próximas de preços extremos. Uma passagem de 0,05$ para 0,15$ é “mais distante” sob divergência KL do que de 0,50$ para 0,60$. Isto corresponde à nossa intuição—alterações extremas de preço significam choques informacionais maiores.
Bom exemplo: no mercado de previsão de @zachxbt, Axiom ultrapassou Meteora no último minuto, impulsionado por uma alteração extrema de preço.
Projeção de Bregman vs. Projeção Euclidiana
Lucro de Arbitragem = Distância de Projeção de Bregman
Uma conclusão central do artigo referenciado:
O lucro máximo garantido de qualquer operação equivale à distância de projeção de Bregman do estado atual do mercado ao espaço livre de arbitragem.
Simplificando: quanto mais os preços de mercado divergem do “espaço válido”, mais pode ganhar. A projeção de Bregman indica:
- O que comprar ou vender (direção da projeção = direção da operação)
- Quanto comprar ou vender (considerando a profundidade do livro de ordens)
- Quanto pode ganhar (distância da projeção = lucro máximo)
O principal arbitrador ganhou 2 009 631,76$ num ano [2]. A sua estratégia foi simplesmente resolver este problema de otimização mais rápido e com mais precisão do que qualquer outro.
Polítopo Marginal e Arbitragem
Imagine-se no topo de uma montanha, com um rio (espaço livre de arbitragem) no sopé. A sua posição atual (preços de mercado) está a certa distância do rio.
A projeção de Bregman ajuda-o a encontrar o “caminho mais curto da sua posição ao rio”—não a distância em linha reta, mas o caminho mais curto considerando o terreno (estrutura do mercado). O comprimento deste percurso é o seu lucro máximo possível.
Capítulo 3: Algoritmo Frank-Wolfe—Tornar a Teoria Executável
Agora sabe: para calcular a arbitragem ótima, precisa de uma projeção de Bregman.
Mas aqui está o problema—calcular diretamente a projeção de Bregman não é viável.
Porquê? Porque o espaço livre de arbitragem (o polítopo marginal M) tem um número exponencial de vértices. A otimização convexa padrão requer acesso ao conjunto completo de restrições, ou seja, enumerar todos os resultados válidos. Isso é impossível à escala.
A Ideia Central do Frank-Wolfe
A genialidade do algoritmo Frank-Wolfe [7] é que não tenta resolver tudo de uma vez, mas converge passo a passo.
Funciona assim:
Passo 1: Comece com um pequeno conjunto de resultados válidos conhecidos.
Passo 2: Otimize sobre este conjunto para encontrar a melhor solução atual.
Passo 3: Use programação inteira para encontrar um novo resultado válido e adicioná-lo ao conjunto.
Passo 4: Verifique se está suficientemente próximo do ótimo. Se não, volte ao Passo 2.
Cada iteração adiciona apenas um vértice. Mesmo após 100 iterações, está apenas a acompanhar 100 vértices—não 2^63.
Iteração Frank-Wolfe
Imagine procurar uma saída num labirinto gigantesco.
O método de força bruta é percorrer todos os caminhos. O método Frank-Wolfe é escolher um caminho aleatório e, em cada bifurcação, perguntar a um “guia” (solucionador de programação inteira): “Daqui, qual a direção mais provável de levar à saída?” Depois, dá um passo nessa direção. Não precisa de explorar todo o labirinto—basta tomar a decisão certa em cada junção-chave.
Solucionador de Programação Inteira: O “Guia” em Cada Passo
Cada iteração Frank-Wolfe requer resolver um problema de programação linear inteira. Em teoria, isto é NP-difícil (não existe algoritmo geral rápido conhecido).
Mas solucionadores modernos como o Gurobi [8] conseguem tratar problemas bem estruturados com eficiência.
A equipa de investigação utilizou o Gurobi 5.5. Tempos reais de resolução [2]:
• Iterações iniciais (poucos jogos concluídos): menos de 1 segundo
• Fase intermédia (30–40 jogos concluídos): 10–30 segundos
• Fase final (50+ jogos concluídos): menos de 5 segundos
Porquê mais rápido no fim? Porque, à medida que mais resultados são determinados, o espaço de soluções viáveis encolhe. Menos variáveis, restrições mais apertadas, resoluções mais rápidas.
Explosão do Gradiente e Frank-Wolfe com Barreira
O Frank-Wolfe padrão tem um problema técnico: à medida que os preços se aproximam de 0, o gradiente LMSR tende para menos infinito, provocando instabilidade.
A solução é o Frank-Wolfe com Barreira: otimizar não no polítopo completo M, mas numa versão ligeiramente “reduzida” M’. O parâmetro de redução ε diminui adaptativamente em cada iteração—começando mais longe da fronteira (para estabilidade), depois aproximando-se gradualmente da verdadeira fronteira (para precisão).
A investigação mostra que, na prática, 50 a 150 iterações são suficientes para convergência [2].
Desempenho Real
O artigo revela um achado importante [2]:
Nos primeiros 16 jogos do torneio NCAA, o market maker Frank-Wolfe (FWMM) e um market maker de restrições lineares simples (LCMM) tiveram desempenho semelhante—porque o solucionador de programação inteira ainda era demasiado lento.
Mas após 45 jogos, foi concluída a primeira projeção de 30 minutos.
A partir daí, o FWMM superou o LCMM em preços em 38%.
O ponto de viragem: quando o espaço de resultados encolheu o suficiente para a programação inteira resolver dentro da janela de negociação.
O FWMM é como um estudante a aquecer na primeira metade do exame, mas, uma vez “no ritmo”, começa a dominar. O LCMM é o estudante constante mas limitado. A diferença fundamental: o FWMM tem uma “arma” mais poderosa (projeção de Bregman), mas precisa de tempo para “carregar” (esperar pelo solucionador).
Capítulo 4: Execução—Porque Pode Perder Dinheiro Após o Cálculo
Detetou arbitragem. Usou a projeção de Bregman para calcular a operação ótima.
Agora precisa de executar.
É aqui que a maioria das estratégias falha.
Execução Não Atómica
A Polymarket utiliza um CLOB (Central Limit Order Book) [9]. Ao contrário das exchanges descentralizadas, as transações num CLOB executam-se sequencialmente—não pode garantir que todas as suas ordens sejam preenchidas de uma vez.
Plano de arbitragem:
Comprar YES a 0,30$. Comprar NO a 0,30$. Custo total: 0,60$. Independentemente do resultado, recebe 1,00$. Lucro: 0,40$.
Realidade:
Submete ordem YES → preenchida a 0,30$ ✓
A sua ordem altera o preço de mercado.
Submete ordem NO → preenchida a 0,78$ ✗
Custo total: 1,08$. Pagamento: 1,00$. Resultado real: perde 0,08$.
Um lado é preenchido, o outro não. Fica exposto.
Por isso, o artigo só contabiliza oportunidades com margem de lucro superior a 0,05$ [2]. Spreads menores são eliminados pelo risco de execução.
Risco de Execução Não Atómica
VWAP: O Preço Real de Execução
Não presuma que pode sempre preencher ao preço cotado. Deve calcular o Preço Médio Ponderado pelo Volume (VWAP) [10].
Método da equipa de investigação: para cada bloco na cadeia Polygon (aproximadamente a cada 2 segundos), calcula-se o VWAP para todas as transações YES e todas as transações NO nesse bloco. Se |VWAP_yes + VWAP_no - 1,0| > 0,02, regista-se como oportunidade de arbitragem [2].
O VWAP é o “preço médio que realmente paga”. Se quiser comprar 10 000 tokens mas o livro de ordens tem 0,30$ para 2 000, 0,32$ para 3 000, 0,35$ para 5 000—o seu VWAP é (2000×0,30 + 3000×0,32 + 5000×0,35) / 10000 = 0,326$. Muito superior ao “melhor preço” de 0,30$ que viu.
Restrições de Liquidez: O Lucro Depende da Profundidade do Livro de Ordens
Mesmo que os preços estejam desalinhados, o seu lucro é limitado pela liquidez disponível.
Exemplo real [2]:
O mercado mostra arbitragem: preços YES somam 0,85$. Potencial de lucro: 0,15$ por dólar. Mas a profundidade do livro de ordens nesses preços é apenas 234$. Lucro máximo extraível: 234 × 0,15 = 35,10$.
Para arbitragem entre mercados, precisa de liquidez em todas as posições simultaneamente. A menor liquidez disponível define o teto.
Por isso, nas plataformas quantitativas atuais, o impacto dos preços das ordens no preço de execução é crítico.
insiders.bot
Esta é a resposta a esta questão durante o período Beta público.
Capítulo 5: O Sistema Completo—O que Está Realmente Implementado
A teoria é simples. A produção é complexa.
Veja como é um sistema real de arbitragem operacional [2].
Pipeline de Dados
Dados em tempo real: ligação WebSocket à API da Polymarket [9], recebendo atualizações do livro de ordens (alterações de preço/quantidade), notificações de transações e eventos de criação/liquidação de mercados.
Dados históricos: consulta de eventos de contrato via API do nó Polygon da Alchemy—OrderFilled (transação executada), PositionSplit (novo token emitido), PositionsMerge (token queimado).
A equipa de investigação analisou 86 milhões de transações [2]. Esta escala exige infraestrutura, não apenas scripts.
P.S. Atualmente, nós
insiders.bot
planeamos disponibilizar uma API de trading de alta velocidade em open source. Se pretende utilizar um modelo de trading semelhante e deseja acesso antecipado, envie-me uma mensagem privada.
Camada de Deteção de Dependências
Para 305 mercados das eleições dos EUA, existem 46 360 pares possíveis a analisar. Análise manual é impossível.
A equipa de investigação utilizou uma abordagem engenhosa: recorrendo ao modelo de linguagem DeepSeek-R1-Distill-Qwen-32B para triagem inicial [2].
Input: descrições das condições de dois mercados. Output: JSON de combinações válidas de resultados.
Depois, três camadas de validação: cada mercado tem exatamente uma condição verdadeira? O número de combinações válidas é inferior a n × m (indicando dependência)? O subconjunto dependente cumpre as condições de arbitragem?
Resultado: 40 057 pares independentes (sem arbitragem) → 1 576 pares dependentes (potencial arbitragem) → 374 pares que cumprem critérios rigorosos → 13 pares confirmados exploráveis por humanos [2].
A precisão do LLM em mercados multi-condição complexos é de 81,45%. Suficiente para triagem inicial, mas é necessário verificação manual antes da execução.
Motor de Otimização de Três Camadas
Camada 1: Restrições lineares simples (LCMM). Verificações rápidas de regras básicas—“a soma das probabilidades é igual a 1”, “se A implica B, então P(A) não pode exceder P(B)”. Conclui em milissegundos, eliminando erros óbvios de preços.
Camada 2: Projeção por programação inteira (Frank-Wolfe + Gurobi). Este é o núcleo. Parâmetros: Alpha = 0,9 (extrair pelo menos 90% da arbitragem disponível), ε inicial = 0,1 (redução de 10%), limiar de convergência = 1e-6, limite de tempo = 30 minutos. Iterações típicas: 50–150. Tempo de resolução por iteração: 1–30 segundos [2].
Camada 3: Validação de execução. Antes de submeter ordens, simula preenchimentos no livro de ordens atual. Verifica: há liquidez suficiente? Qual o slippage esperado? Qual o lucro garantido após slippage? O lucro excede o limiar mínimo (0,05$)? Só se todos os critérios forem cumpridos é que executa.
Gestão de Posições: Fórmula de Kelly Modificada
A fórmula de Kelly padrão [11] indica que fração do capital deve alocar a uma operação. Para arbitragem, deve ajustar pelo risco de execução:
f = (b×p - q) / b × √p
Onde b é a percentagem de lucro de arbitragem, p é a probabilidade de execução total (estimada pela profundidade do livro de ordens) e q = 1 - p.
Limite: 50% da profundidade do livro de ordens. Acima disso, a sua ordem altera significativamente o mercado.
Resultados Finais
De abril de 2024 a abril de 2025, lucro total extraído [2]:
Arbitragem de condição única: Comprar ambos os lados baixo 5 899 287$ + vender ambos os lados alto 4 682 075$ = 10 581 362$
Rebalanceamento de mercado: Comprar todos os YES baixo 11 092 286$ + vender todos os YES alto 612 189$ + comprar todos os NO 17 307 114$ = 29 011 589$
Arbitragem combinada entre mercados: 95 634$
Total: 39 688 585$
Os 10 principais arbitradores arrecadaram 8 127 849$ (20,5% do total). O principal arbitrador: 2 009 632$ em 4 049 operações, média de 496$ por operação [2].
Não é sorteio. Não é sorte. É execução sistemática, matematicamente precisa.
A Realidade Final
Enquanto os traders lêem “10 Dicas para Mercados de Previsão”, o que fazem os sistemas quantitativos?
Usam programação inteira para detetar dependências entre 17 218 condições. Usam projeção de Bregman para calcular operações ótimas de arbitragem. Correm o algoritmo Frank-Wolfe para lidar com explosões de gradiente. Utilizam VWAP para estimar slippage e executar ordens em paralelo. Extraem sistematicamente 40 milhões de dólares em lucro garantido.
A diferença não é sorte. É infraestrutura matemática.
O artigo é público [1]. Os algoritmos são conhecidos. Os lucros são reais.
A verdadeira questão: consegue construir antes de serem extraídos os próximos 40 milhões?
Referência Rápida
• Polítopo Marginal → O conjunto de todos os preços válidos. Os preços devem estar nesta região para serem livres de arbitragem.
• Programação Inteira → Descreve resultados válidos com restrições lineares, evitando enumeração bruta. Comprime 2^63 verificações em poucas restrições [3].
• Divergência de Bregman / Divergência KL → Mede a “distância” entre duas distribuições de probabilidade, mais adequada do que a distância euclidiana para cenários de preço/probabilidade. Atribui maior peso a alterações extremas [5][6].
• LMSR (Logarithmic Market Scoring Rule) → O mecanismo de preços do market maker da Polymarket; os preços representam probabilidades implícitas [4].
• Algoritmo Frank-Wolfe → Algoritmo de otimização iterativo que adiciona um novo vértice por iteração, evitando a enumeração de resultados válidos exponencialmente numerosos [7].
• Gurobi → Solucionador de programação inteira líder na indústria, o “guia” para cada iteração Frank-Wolfe [8].
• CLOB (Central Limit Order Book) → Mecanismo de trading da Polymarket; ordens executam-se em sequência, sem atomicidade [9].
• VWAP (Preço Médio Ponderado pelo Volume) → O preço médio que realmente paga, considerando a profundidade do livro de ordens. Mais realista do que a “melhor cotação” [10].
• Fórmula de Kelly → Indica que fração de capital alocar a uma operação, equilibrando retorno e risco [11].
• Execução Não Atómica → O problema em que várias ordens não podem ser garantidas de serem preenchidas simultaneamente. Um lado é preenchido, o outro não—risco de exposição.
• DeepSeek → O modelo de linguagem utilizado para triagem de dependências de mercado, precisão de 81,45%.
Referências
[1] Publicação original: https://x.com/RohOnChain/status/2017314080395296995
[2] Artigo de investigação “Unravelling the Probabilistic Forest: Arbitrage in Prediction Markets”: https://arxiv.org/abs/2508.03474
[3] Fundamentação teórica “Arbitrage-Free Combinatorial Market Making via Integer Programming”: https://arxiv.org/abs/1606.02825
[4] Explicação LMSR: https://www.cultivatelabs.com/crowdsourced-forecasting-guide/how-does-logarithmic-market-scoring-rule-lmsr-work
[5] Introdução às Divergências de Bregman: https://mark.reid.name/blog/meet-the-bregman-divergences.html
[6] Divergência KL - Wikipedia: https://en.wikipedia.org/wiki/Kullback%E2%80%93Leibler_divergence
[7] Algoritmo Frank-Wolfe - Wikipedia: https://en.wikipedia.org/wiki/Frank%E2%80%93Wolfe_algorithm
[8] Gurobi Optimizer: https://www.gurobi.com/
[9] Documentação da API Polymarket CLOB: https://docs.polymarket.com/
[10] Explicação VWAP - Investopedia: https://www.investopedia.com/terms/v/vwap.asp
[11] Fórmula de Kelly - Investopedia: https://www.investopedia.com/articles/trading/04/091504.asp
[12] Artigo Decrypt “The $40 Million Free Money Glitch”: https://decrypt.co/339958/40-million-free-money-glitch-crypto-prediction-markets
Aviso Legal
- Este artigo é reproduzido de [mrryanchi], com direitos de autor pertencentes ao autor original [@RohOnChain]. Caso tenha alguma objeção a esta reprodução, contacte a equipa Gate Learn, e trataremos o assunto prontamente de acordo com os procedimentos relevantes.
- Aviso legal: As opiniões e pontos de vista expressos neste artigo são exclusivamente do autor e não constituem qualquer recomendação de investimento.
- As versões noutras línguas deste artigo são traduzidas pela equipa Gate Learn. Sem menção explícita de Gate, a reprodução, distribuição ou plágio de artigos traduzidos é proibida.
