O site de um mercado de previsão é a entrada de um sistema que realiza várias tarefas. A interface apresenta o mercado, o sistema de negociação encontra ordens compatíveis, os contratos liquidam as movimentações de ativos e os serviços de dados tornam os registros compreensíveis. Um oráculo fornece a resposta final do mercado por meio do processo de resolução configurado.
Essas tarefas acontecem em lugares diferentes. Clicar em um botão, ter uma ordem aceita e ter uma negociação liquidada são etapas distintas. Entender essas fronteiras explica por que um mercado pode estar visível enquanto a negociação está indisponível, ou por que uma transação concluída pode demorar a aparecer na carteira de posições.
Este é o segundo artigo da série Como Polymarket e Kuest funcionam. Comece por o que o preço de um mercado de previsão realmente significa se você ainda está conhecendo os preços e pagamentos desses mercados.
Quatro camadas, quatro responsabilidades
| Camada | Função |
|---|---|
| Interface | Apresentar perguntas, regras e controles da conta |
| Sistema de negociação | Validar ordens e encontrar interesse de negociação compatível |
| Contratos | Aplicar as regras de ativos e permissões da modalidade escolhida |
| Serviços de dados | Organizar metadados, saldos e atividade para as aplicações |
A visão geral das APIs da Polymarket reflete essa separação: Gamma atende à descoberta, CLOB atende às ordens e ao estado atual do mercado, e Data API atende à atividade de contas e mercados. WebSockets fornecem atualizações; eles não substituem as regras de liquidação subjacentes.
Uma página não é um identificador de posição
Um evento agrupa mercados relacionados para apresentação. Um mercado binário faz uma pergunta específica que pode ser resolvida e oferece resultados YES e NO separados. Um evento pode conter vários mercados, portanto o endereço de sua página não basta para especificar uma ordem. Veja o modelo de mercados e eventos da Polymarket.
No Conditional Tokens Framework, ou CTF, o identificador da pergunta representa os dados de entrada da resolução. O identificador da condição é derivado do endereço do oráculo, do identificador da pergunta e do número de resultados possíveis. O identificador de uma posição de resultado também depende do ativo de garantia e do caminho de coleções. Não é seguro usar um desses identificadores no lugar de outro.
Um mapa de agrupamento, não uma fórmula de hash. Selecione o mercado e o resultado exatos antes de consultar o livro ou enviar uma ordem.
O guia de dados on-chain da Polymarket distingue essas derivações do CTF dos identificadores do Protocol V2. Um título igual em outro site não comprova que o ativo é o mesmo.
Acompanhe uma ordem pelo sistema
Primeiro, a interface encontra um mercado e obtém seus identificadores de resultado e sua configuração de negociação. O cliente prepara uma ordem, e o signatário correspondente autoriza suas condições. Assinar uma ordem não é a mesma ação que transmitir uma transação à blockchain.
A instrução assinada chega ao livro central de ofertas limitadas, ou CLOB. O serviço verifica se a ordem pode ser aceita e procura ordens compatíveis. Uma ordem aceita pode permanecer aberta quando não consegue ser executada imediatamente; o encontro de ordens representa um acordo de negociação sob as regras do sistema, ainda não uma prova de entrega dos ativos.
Em seguida vem a liquidação. Um serviço de execução envia uma transação aos contratos correspondentes na Polygon. A modalidade de liquidação valida a negociação autorizada e atualiza os ativos se a execução for bem-sucedida. Uma transação que falhou não se torna uma compra concluída apenas porque a API havia informado um encontro de ordens.
As setas contínuas acompanham a instrução até a liquidação. As tracejadas mostram dados registrados voltando à interface; elas não movimentam a garantia.
A Polymarket documenta o ciclo de vida da ordem e, separadamente, orienta as integrações a aguardar a liquidação da execução antes de consultar a posição resultante. A inclusão da transação e o estado de confirmação exigido importam; o identificador de uma ordem, sozinho, não basta.
Por fim, indexadores processam as alterações registradas e as APIs disponibilizam visões atualizadas. A interface pode então mostrar a posição e a atividade. Essas etapas precisam de mensagens de estado separadas, em vez de um único “sucesso” ambíguo.
Os contratos formam uma família, não uma caixa única
Um sistema baseado em CTF divide responsabilidades entre várias famílias de contratos. Os nomes abaixo descrevem funções; os contratos e as permissões exatos dependem da modalidade utilizada.
Um mapa de responsabilidades. Esses painéis não afirmam que toda transação chama as cinco famílias.
| Família | Função |
|---|---|
| Carteiras, fábricas e infraestrutura de atualização | Guardar ativos e aplicar regras de propriedade, assinatura e implementação |
| CTF Exchange ou modalidade de negociação de risco negativo | Validar e liquidar as ordens compatíveis aplicáveis |
| Conditional Tokens | Registrar saldos de resultados CTF e permitir divisão, combinação e resgate |
| Adaptadores de oráculo e modalidades de resolução | Ligar uma resposta aceita ao pagamento registrado para uma condição |
| Apoio a taxas, recompensas e custódia em garantia | Atender a processos adicionais de contabilização, incentivo ou financiamento, quando configurados |
Liquidação e resolução respondem a perguntas diferentes. A liquidação verifica se essa negociação pode movimentar ativos. A resolução determina qual pagamento decorre das regras do mercado. A documentação de resolução da Polymarket distingue atualmente mercados baseados em UMA de mercados de alta/baixa com TWAP da Chainlink; um mecanismo de encontro de ordens não decide esse resultado ao escolher o preço de uma negociação.
A versão importa. A Polymarket documenta atualmente tanto o sistema de posições CTF quanto o Protocol V2. O Protocol V2 usa PositionManager, enquanto o CTF usa Conditional Tokens. Seu registro de contratos lista componentes de liquidação diferentes. “Exchange V2” não é sinônimo de “Protocol V2”; identifique sempre a versão do mercado, o registro de posições e a modalidade em conjunto.
Os dados tornam o registro utilizável, mas podem estar atrasados
Um indexador transforma eventos dos contratos em registros que podem ser consultados. Uma API pode combinar esses registros com metadados do mercado, preços ou cálculos. Esses dados são úteis para a aplicação, mas sua atualização pode ocorrer em um ritmo diferente do recibo de uma transação ou do fluxo de ordens em tempo real.
O guia de dados on-chain da Polymarket descreve eventos de transferência e de execução de ordens. Esses registros não contêm todas as ordens abertas fora da blockchain. Da mesma forma, chamar um indexador de “subgrafo do livro de ofertas” não faz dele o livro em tempo real. Uma cotação atual e uma execução histórica pertencem a registros diferentes.
Se uma carteira de posições parecer desatualizada, compare o horário de atualização com a transação e o registro de posições correspondente. Se uma cotação desaparecer, consulte o livro atual. São investigações diferentes; atualizar um catálogo não comprova nem que uma ordem deixou de ser executada nem que há recursos desaparecidos.
Um relayer ajuda a enviar transações; ele não elimina dependências
Um relayer pode enviar ações de carteira compatíveis, como implantação ou aprovações. A documentação de carteiras da Polymarket descreve ações patrocinadas que permitem à conta funcionar sem manter o token nativo de gas para essas chamadas. O gas continua sendo consumido; seu custo é pago por outra parte.
Um relayer de carteiras e os serviços de encontro de ordens e liquidação do sistema de negociação têm tarefas diferentes. Disponibilidade, chamadas permitidas e políticas de patrocínio importam. Não presuma que toda negociação passa por um relayer de carteira nem que o patrocínio comprove algo sobre custódia, poder de atualização ou correção do oráculo.
O diferencial da Kuest: a vitrine pode mudar enquanto a infraestrutura é compartilhada
O guia público de arquitetura da Kuest distingue a marca e o catálogo do operador da infraestrutura compartilhada de negociação. Operadores podem selecionar mercados para suas audiências usando serviços comuns de execução compatíveis.
A execução compartilhada exige serviços, rede e ativos compatíveis. Uma marca diferente não cria nem garante liquidez.
Dois sites com marcas próprias que usam os mesmos serviços e ativos da Kuest podem apresentar interesse de negociação comum com catálogos diferentes. Para o operador, isso permite reutilizar a infraestrutura de execução enquanto organiza uma experiência voltada a uma audiência específica.
O operador apresenta o mercado aos participantes; um formador de mercado fornece interesse de negociação por meio de ordens. Esses papéis são separados dos serviços que encontram e liquidam negociações. Criar um mercado não fornece, por si só, contrapartes dispostas a negociar ou quantidade executável.
Os serviços compartilhados da Kuest não unem seu livro ao da Polymarket, e espelhar uma pergunta não torna os saldos transferíveis entre plataformas de negociação.
As famílias de contratos acima explicam responsabilidades, não um inventário completo de implantação. Antes de operar um mercado, confira a rede real, os endereços dos contratos, o código publicado, as permissões e o sistema de posições compatível. Uma auditoria do projeto de origem não cobre automaticamente outra implantação ou alterações personalizadas.
Para o operador, a revisão útil é concreta: quais ativos de mercado este site mostra, quais serviços aceitam suas ordens, quais contratos as liquidam e quão atuais são os registros exibidos? Uma nova marca deve facilitar encontrar essas respostas.
Quer construir essa experiência para sua audiência? Crie seu próprio mercado de previsão pela configuração guiada da Kuest.