Se você passar tempo suficiente entre construtores de mercados de previsão, vai notar que as conversas se dividem com clareza em dois campos: a frente do stack (matching, UX, liquidez) e o fundo do stack (resolução, liquidação, oracles). Os problemas da frente do stack são solucionáveis com horas de engenharia e capital. Os problemas do fundo do stack são solucionáveis com design criptoeconômico — e é onde plataformas de mercado de previsão de fato vivem ou morrem.
Este post é para operadores e engenheiros que já entendem o caso de negócio (comece pela nossa análise de mercado, se não) e querem saber como a camada de liquidação realmente funciona.
Esse número é o resultado-manchete de cerca de seis anos de design de optimistic oracle: a esmagadora maioria das resoluções nunca precisa de uma votação, porque o sistema é projetado para tornar proposers honestos mais baratos do que desonestos. Abaixo está como isso é alcançado, onde quebra e o que implica para qualquer operador movimentando volume real em cima dele.
O problema da liquidação, posto com clareza
Cada contrato de mercado de previsão tem um único trabalho ao final de sua vida: emitir um pagamento ao lado que estava certo. Para fazer isso, o contrato precisa saber o que de fato aconteceu. O desafio é que um smart contract não tem olhos — ele não pode assistir à CNN, ler uma divulgação de IPC ou conferir um placar esportivo. Ele depende de um mecanismo externo para lhe dizer a verdade.
Esse mecanismo externo é o oracle. Todo mercado de previsão se apoia em um. O oracle é a premissa de confiança do sistema todo. É a razão pela qual „os contratos foram auditados pela OpenZeppelin" importa menos do que as pessoas pensam — os contratos podem ser impecáveis e a plataforma falhar mesmo assim, se o oracle for manipulável.
Há três propriedades que qualquer oracle nesse contexto precisa entregar:
- Correção. O resultado reportado precisa coincidir com a realidade.
- Liveness. O resultado precisa ser reportado dentro de uma janela razoável após a resolução; mercados não podem ficar pendurados indefinidamente.
- Resistência à censura. Nenhum ator único pode impedir que um resultado verdadeiro seja registrado.
O espaço de trade-offs entre essas três propriedades é todo o campo do design de oracles.
Resolução centralizada: simples, rápida, frágil
A abordagem mais antiga e mais simples é o operador (ou um time designado de integridade de mercado) resolver os mercados diretamente. A Kalshi faz assim: a exchange consulta fontes de dados pré-publicadas, aplica sua política de resolução documentada e publica o resultado.
Isso funciona bem quando:
- A fonte de dados é inequívoca e está disponível (por exemplo, a divulgação de IPC do BLS).
- O operador tem identidade regulada (no caso da Kalshi, a CFTC).
- A política de resolução é publicada com antecedência e não muda.
Falha quando:
- A fonte de dados é ambígua ou contestada.
- O operador tem interesse financeiro no resultado.
- A política de resolução é reescrita retroativamente.
A resolução centralizada é apropriada para espaços de contrato estreitos e altamente regulados. É estruturalmente inadequada para a cauda longa de mercados que move a maior parte do volume de mercados de previsão — casos extremos esportivos, eventos geopolíticos, qualquer coisa em que o fato subjacente seja interpretado, e não medido.
O padrão optimistic oracle
O optimistic oracle, popularizado pela UMA em 2020, substitui um único resolvedor confiável por um processo de afirmação-e-desafio baseado em teoria dos jogos. A estrutura é intuitiva assim que você a vê.
Passo 1. Proposta. Qualquer pessoa pode propor um resultado a
um mercado depositando um bond. „Afirmo que o contrato sobre O Fed vai cortar juros em julho? resolve SIM." O proposer anexa garantia
(tipicamente algumas centenas de dólares em USDC) e submete.
Passo 2. Janela de contestação. Um cronômetro começa — geralmente 2 horas em mercados de dinheiro real, mais longo para mercados de maior risco. Durante essa janela, qualquer um pode disputar a proposta depositando seu próprio bond.
Passo 3. Dois caminhos.
- Sem contestação. Se ninguém disputar dentro da janela de contestação, o resultado proposto é definitivo. O bond do proposer é devolvido e uma pequena recompensa é paga pelo trabalho de propor.
- Contestação. Se alguém disputar (com bond), a questão escala para uma votação dos detentores do token UMA. A votação decide qual lado tinha razão. A garantia do lado perdedor é paga ao lado vencedor e ao protocolo. O lado vencedor recupera seu bond e recebe uma recompensa.
A economia é deliberadamente assimétrica. Um proposer veraz não espera contestação — porque qualquer observador pode ver que o resultado é verdadeiro, e contestar um resultado verdadeiro significa perder seu bond. Um disputante veraz só contesta quando o resultado proposto é visivelmente errado — porque uma disputa frívola também custa o bond.
O resultado, na prática, é que quase toda resolução se acerta no caminho otimista. O caminho de disputa existe principalmente como ameaça crível que mantém o caminho otimista honesto.
Como as disputas escalam de fato
O modo de falha interessante é a própria disputa. Quando uma discordância real chega à votação, o protocolo precisa lidar com três subproblemas:
- Integridade do voto. A votação da UMA usa commit-reveal para que os votantes não possam copiar uns aos outros. Os votantes submetem um voto hashado e revelam depois. Isso impede colusão trivial.
- Resolução por ponto de Schelling. Os votantes são recompensados por votar com a maioria dos demais votantes honestos. O protocolo presume que para qualquer contrato bem especificado emerge naturalmente um ponto focal (a resposta „óbvia"). Isso funciona tão bem quanto a especificação do contrato — contratos vagos recebem resoluções vagas.
- Escalada ao árbitro final. Para disputas de altíssimo risco, a UMA tem uma escalada multirodada: se uma votação é ambígua, pode ser refeita com quórum mais alto e janela de votação mais longa. Na prática, é usada talvez algumas poucas vezes por ano.
O custo a nível de protocolo de um mercado disputado é alto. O disputante e o proposer têm ambos capital travado. Os votantes UMA gastam atenção real. Uma plataforma limpa evita disputas escrevendo mercados que não as gerem. A disciplina da especificação de contrato — que parece um problema de papelada — é, na verdade, a alavanca operacional mais importante que uma venue tem.
Por que a maioria das plataformas erra nisso
O erro mais comum que vemos em construções de operadores é tratar a resolução como uma preocupação de back-office que pode ser resolvida com „a gente concilia manualmente". Isso funciona com 50 mercados por semana e quebra com 5.000.
Três modos de falha aparecem consistentemente:
A falha do contrato vago. O mercado é redigido de forma ambígua (por exemplo, „O conflito vai terminar em 2026?" sem definição de „terminar"). Dois resultados são defensavelmente verdadeiros. O mercado vai a disputa, a disputa se arrasta, traders perdem confiança e a reputação do operador toma um golpe que não se reverte.
A falha da fonte de dados que se move. O mercado especifica uma fonte de dados que é renomeada, reestruturada ou colocada atrás de paywall em pleno ciclo de vida. O contrato aponta para uma fonte que já não existe e a resolução precisa ser reconstruída manualmente.
A falha do conflito de interesses. O operador (ou alguém próximo a ele) tem posição no mercado. Quando a resolução é opaca, isso vira escândalo público independentemente do que o operador realmente fez. A ótica, sozinha, destrói a credibilidade da plataforma.
A defesa mais limpa contra os três é desenhar o contrato de modo que o caminho de resolução não dependa do critério do operador. O padrão optimistic oracle é estruturalmente bem adequado a isso: o operador não é o resolvedor, a fonte de dados é nomeada e travada na criação do mercado, e o mecanismo de disputa é público.
| Modo de falha | Resolvedor centralizado | Optimistic oracle |
|---|---|---|
| Contrato vago | Alta exposição | Disputas; identifica corretamente a má spec |
| Fonte de dados se move | Conciliação manual | Replay via disputa |
| Conflito de interesse do operador | Existencial | Estruturalmente separado |
| Custo de resolução maliciosa | Colapso de confiança | Bond + reescrita por voto |
| Velocidade em mercados triviais | Mais rápido | Igual (sem caminho de disputa) |
O que a Kuest de fato faz na camada de liquidação
A abordagem da Kuest herda o padrão optimistic oracle da arquitetura de produção da Polymarket e a endurece para implantação multi-operador. Na prática:
- Fluxo de disputa baseado em UMA. Propostas de resolução seguem a mecânica de optimistic oracle da UMA, em vez de decisão ad-hoc do operador.
- Regras e metadados de fonte por mercado. Cada mercado carrega regras explícitas e URL opcional de fonte de resolução, visíveis no painel de regras do evento.
- Checagens de qualidade antes da publicação. O fluxo de criação de eventos valida campos obrigatórios e formato da URL de resolução antes do lançamento.
- Visibilidade de disputa nos dados da plataforma. Os payloads de mercado expõem campos de estado de disputa (por exemplo, se a resolução foi disputada), para monitoramento operacional.
O sentido disso tudo é tornar a resolução entediante. Uma plataforma onde a resolução é a coisa mais empolgante que acontece é uma plataforma prestes a perder usuários.
Como a economia de disputas se comporta de fato sob carga
Uma sutileza que vale a pena destacar: a economia de disputas do optimistic oracle não é só teoria. Ela foi submetida a estresse com volume adversarial real, e os dados dizem algo útil sobre onde o modelo segura e onde sofre pressão.
Os maiores mercados disputados na Polymarket desde 2023 compartilham um formato comum. Eles se concentram em contratos onde o evento subjacente é genuinamente disputado no mundo real — não onde o contrato foi mal especificado, mas onde observadores razoáveis discordam sobre o que aconteceu. Um evento geopolítico com duas interpretações plausíveis, um evento eleitoral com prazos de contagem sobrepostos, um evento esportivo com revisão pós-jogo mudando o resultado horas depois. O mecanismo de disputa lida com esses casos forçando a questão à votação, mas a votação em si reflete uma ambiguidade genuína do mundo. O protocolo faz tão bem quanto um protocolo pode fazer; ele não consegue resolver fatos que o mundo ainda não resolveu.
O que isso significa na prática para um operador: o caminho de disputa não é uma „exceção" a ser tratada como falha de sistema. É um mecanismo projetado para lidar com a ambiguidade irredutível dos eventos do mundo real. Mercados que vão a disputa e depois liquidam corretamente são o sistema funcionando como pretendido, não o sistema quebrando.
A disciplina do lado do operador é manter a taxa de disputa dentro da faixa estruturalmente explicável. Se a taxa de disputa da sua venue é de 0,1–0,3 % (em linha com a taxa de longo prazo da Polymarket), você provavelmente está escrevendo bem os mercados. Se você vê 1 %+, os próprios mercados estão subespecificados e você tem um problema de design de contrato, não um problema de camada de liquidação.
O modelo de disputa também tem arestas suaves conhecidas em torno das quais operadores maduros planejam. Mercados disputados podem ficar pendurados em limbo de votação por vários dias enquanto os votantes UMA resolvem, o que é um problema de UX se um trader tem capital preso na posição e precisa do dinheiro por motivos não relacionados. A maioria dos operadores trata isso limitando a janela máxima de disputa para mercados não críticos e aceitando um pequeno overhead de taxa de protocolo em troca da previsibilidade.
O que isso significa se você está operando
Três implicações decorrem diretamente disso para qualquer operador rodando em Kuest ou avaliando o protocolo contra alternativas.
- Gaste mais tempo do que imagina na especificação dos contratos. Toda ambiguidade no enunciado do mercado cria exposição de resolução. Os operadores com quem trabalhamos tratam a especificação de mercado como cargo sênior, não junior.
- Herde um modelo de liquidação, não construa um. O custo de um oracle caseiro é enorme, os modos de falha são catastróficos, e a alternativa — usar resolução estilo UMA como serviço — é madura, auditada e testada em batalha. Não há essencialmente caso para construir um oracle próprio em 2026, a não ser que design de oracle seja o seu produto principal.
- Acompanhe a taxa de disputas como indicador antecedente. Uma taxa de disputa acima de cerca de 0,5 % em uma venue é sinal de que as especificações de contrato estão afrouxando. Ela antecipa a degradação da confiança do usuário em várias semanas. A maioria dos operadores não acompanha essa métrica; deveria.
A camada de liquidação é a parte do stack que mais diretamente determina se sua venue é uma venue ou uma curiosidade. A boa notícia é que também é a parte onde o trabalho pesado já foi feito.