“Vai chegar a 30 graus?” abre espaço para várias negociações diferentes. A previsão arredondada de um aplicativo de clima, a temperatura medida por uma estação e um relatório oficial publicado depois podem divergir. O mercado precisa dizer qual deles determina o pagamento antes de alguém comprar YES ou NO.
Este sexto artigo de Como Polymarket e Kuest funcionam transforma essa pergunta em uma regra testável e acompanha suas evidências pelas camadas separadas do sistema. Uma página legível, bytes de resolução comprometidos e um documento de metadados acessível comprovam coisas diferentes.
Reescreva a pergunta até dois leitores chegarem à mesma resposta
Mantenha nossos Observatório A, Cidade B e Data C fictícios. “Às 12:00” precisa identificar o horário da observação ou o prazo de publicação; são eventos diferentes. Reescreva o título assim: “A observação das 12:00 UTC do Observatório A para a Cidade B na Data C será de pelo menos 30.0°C?” Depois, especifique a evidência:
Use o CSV oficial de observações diárias do Observatório A, estação B-01, para a Data C. Leia o campo de temperatura do ar em graus Celsius do registro marcado com 12:00:00 UTC. Use a revisão oficial mais recente disponível até 13:00:00 UTC da Data C, incluindo uma revisão publicada exatamente nesse limite. Compare o valor numérico publicado diretamente com 30.0; não o arredonde novamente. Um valor válido de 30.0 ou mais significa YES; um valor válido menor significa NO. Ignore previsões, outras estações e revisões posteriores. Se, nesse limite, o registro tiver sido retirado, houver registros conflitantes sem uma ordem oficial de revisão ou não houver registro válido disponível, use o resultado especificado para dados indisponíveis.
Em um mercado real, substitua cada nome e data fictícios pela URL exata da fonte, pelo identificador da estação, pela data do calendário e pela definição do campo. “Site oficial”, sozinho, deixa o leitor escolher entre páginas, cópias e revisões. Uma fonte alternativa também precisa de prioridade definida; caso contrário, acrescenta outra escolha depois que o resultado já é conhecido.
Aqui, 29.96 significa NO mesmo que um aplicativo mostre 30.0. Uma correção de 29.9 para 30.1 antes do limite significa YES; a mesma correção depois dele não muda a observação selecionada. A igualdade é explicitamente YES, portanto o limiar não deixa um empate sem solução.
O horário da observação seleciona o registro. O limite seleciona sua revisão. A política de pagamento trata a falta de evidência.
O resultado para dados indisponíveis precisa ser compatível com a modalidade de contrato escolhida. Neste exemplo didático, considere um adaptador binário padrão que aceite UNKNOWN: YES paga uma unidade de garantia e NO paga zero em um resultado YES, o inverso em NO, e cada um paga metade em UNKNOWN. Essa é uma premissa explícita do modelo, não uma regra universal de cancelamento ou uma política de pagamento NegRisk.
Meia unidade por token não é uma devolução de seu preço de compra. Um participante que pagou 0.80 por YES recebe 0.50 sob esse resultado assumido. A mecânica de divisão e resgate determina o pagamento; as regras determinam qual resultado permitido deve ser informado.
O prazo da fonte, o encerramento da negociação e o horário da resolução têm funções diferentes. O primeiro seleciona a evidência; o segundo controla a admissão de ordens; o terceiro registra um resultado. Por exemplo, as ordens poderiam parar às 11:55 UTC enquanto revisões elegíveis continuam abertas até 13:00; a resolução pode acontecer depois. O operador precisa configurar a negociação separadamente, e uma transação atrasada não prorroga o limite da evidência.
Acompanhe dois tipos de evidência
Um mercado precisa tanto de uma pergunta de resolução definida quanto de informações de apoio legíveis. Ancillary data são os bytes adicionais da pergunta usados por uma integração específica de oráculo; metadados descritivos também podem incluir imagens, rótulos e links. Eles cumprem funções diferentes e não devem ser tratados como compromissos equivalentes.
O adaptador CTF público da Polymarket é um exemplo de dados de pergunta registrados com uma codificação definida. Recalcular um compromisso exige essa codificação exata, não um parágrafo visualmente parecido. Consulte a interface publicada da implantação escolhida em vez de generalizar um exemplo para várias famílias de adaptadores.
O compromisso da pergunta e um documento externo permitem verificações diferentes; uma referência, sozinha, não comprova integridade ou disponibilidade.
O contrato público verificado de Conditional Tokens da Kuest registra um criador e uma referência externa de metadados. Uma referência localiza informações; ela não comprova, por si só, que um documento esteja disponível, seja imutável ou corresponda ao compromisso original de resolução. Recupere os documentos e compare-os com a evidência registrada da pergunta.
A documentação pública de criação de mercados da Kuest descreve a interface de produto compatível. Um documento enviado, uma condição preparada e uma listagem negociável são observações separadas. Confirme os registros adequados em vez de inferir os três a partir de uma tela de sucesso.
Identificadores parecidos cumprem funções diferentes
Um slug localiza uma página. Um identificador de pergunta identifica uma pergunta conforme o esquema de seu adaptador. Um identificador de condição combina oráculo, identificador da pergunta e quantidade de resultados na construção pública do CTF. Os dados exatos de entrada importam; textos de página semelhantes não estabelecem condições idênticas.
Um identificador de posição identifica o ativo mantido e negociado. No CTF, sua derivação também depende da garantia e da coleção que representa o conjunto de resultados. Títulos ou slugs iguais não estabelecem ativos idênticos. O endereço do criador registra atribuição e determinadas permissões; o identificador externo de metadados localiza conteúdo descritivo. Nenhum deles substitui o identificador da condição ou da posição.
Nem mesmo “identificador de pergunta” indica uma codificação universal. Na NegRiskIdLib específica da Polymarket, uma pergunta compartilha os primeiros 31 bytes do identificador de seu mercado e usa o último byte para o índice da pergunta. Aplique essa regra apenas àquela família de adaptadores, não a toda pergunta de oráculo.
O campo metadata de uma ordem de negociação assinada é outro objeto. Por exemplo, a definição pública do CTF Exchange V2 inclui um bytes32 metadata no nível da ordem. Sua presença não comprova que a assinatura inclua um compromisso com o documento do mercado exibido na tela.
Uma atualização rastreável continua sendo uma atualização
A extensão de Conditional Tokens da Kuest registra o criador da condição e a referência externa atual de metadados. O criador ou um administrador CTF pode substituir essa referência. Cada chamada bem-sucedida incrementa um contador e emite o identificador da condição, a referência anterior, a nova referência e o endereço de quem alterou.
A função analisada não congela alterações na resolução nem verifica se a nova string aponta para conteúdo disponível e não vazio. Um identificador de condição inalterado, portanto, não significa que sua descrição atual exibida nunca mudou. Uma atualização pode apenas acrescentar uma referência de apoio ou corrigir uma imagem; compare os documentos reais antes de decidir se a proposição mudou.
Uma atualização de referência pode enriquecer um documento ou mudar sua descrição. O evento revela quem alterou o apontamento; compare os conteúdos.
Mudar o apontamento não reescreve os bytes originais da pergunta nem concede um novo direito de informar pagamentos. A função de reporte do CTF deriva a condição usando como oráculo quem chama a função. O adaptador e a modalidade de resolução configurada determinam como um resultado chega a essa função; a permissão de editar metadados é um poder separado.
Suponha que a versão A diga 30.0°C e a versão B diga 31.0°C. Um evento de histórico torna a substituição visível; ele não estabelece que 31.0 virou o limiar legítimo. Compare ambas com os bytes originais de ancillary data e com a política de esclarecimentos aplicável antes de interpretar a mudança.
Esclarecimentos precisam de autor e política
A Polymarket já possui compromissos on-chain das perguntas. Seu adaptador UMA CTF, na versão citada, calcula o hash e armazena ancillary data ampliados, enquanto seu quadro de avisos registra atualizações com autoria. Esses são mecanismos específicos do adaptador CTF, não uma afirmação sobre a ABI de toda modalidade atual da Polymarket.
Um esclarecimento também precisa de um autor identificável e de uma política aplicável. No exemplo público da Polymarket, uma publicação com autoria não reescreve os ancillary data originais. Não trate uma declaração qualquer que menciona uma pergunta como uma alteração oficial.
A documentação atual de resolução da Polymarket diz que o contexto dos esclarecimentos deve preservar a intenção fundamental. Identificar uma coluna CSV renomeada pode esclarecer a evidência; trocar um limiar de 30.0 por 31.0 muda a proposição. Um timestamp comprova quando uma declaração foi registrada, não que ela tenha autoridade legítima.
Verifique o caminho da referência até a tela
Uma revisão prática acompanha as evidências em ordem:
- Identifique a implantação. Registre rede, endereços dos contratos, família de adaptadores e uma referência de bloco. Obtenha o recibo de criação, os bytes originais da pergunta, a identidade do oráculo, o criador e o identificador da condição.
- Recalcule os identificadores adequados. Use a codificação, o tratamento do inicializador e a quantidade de resultados daquela implementação. Confira os identificadores de posição com a garantia e o mapeamento de resultados reais.
- Acompanhe o histórico de metadados. Leia a referência de preparação, a referência atual, o contador e os registros de atualização. Recupere os documentos originais e substitutos e compare as mudanças e os endereços de quem alterou.
- Confira integridade e disponibilidade separadamente. Valide o conteúdo pelo esquema real de transação ou compromisso do sistema de armazenamento. Preserve os bytes exatos recuperados e sua origem; uma referência registrada não disponibiliza um documento que ninguém consegue recuperar.
- Compare o que os participantes veem. Confira a fonte, as datas, as regras e os rótulos de resultado exibidos com os dados originais de resolução e o contexto autorizado. Uma interface legível não é uma verificação independente de integridade.
Um documento acessível, uma origem válida e uma apresentação correspondente são verificações separadas. Nenhuma delas, sozinha, estabelece a resolução correta.
Para o operador com marca própria, a contribuição concreta da Kuest é oferecer referências de metadados associadas ao criador e um histórico visível de alterações junto aos dados originais de resolução. Isso permite um catálogo revisável e um processo de publicação com autoria. Não coloca todas as informações do mercado on-chain, não garante disponibilidade dos documentos nem resolve uma divergência de interpretação.
Lance seu próprio mercado de previsão com a Kuest reunindo uma audiência e jurisdições definidas, regras detalhadas, políticas de fontes e correções, uma modalidade de resolução compatível e um plano para preservar evidências acessíveis. Teste esses elementos com exemplos ambíguos antes de aceitar negociações.