Os tokens YES e NO começam como dois direitos lastreados por um conjunto completo de garantia. A divisão cria esses direitos, a combinação os reúne novamente e o resgate os paga conforme um resultado registrado. Comprar um token de outro participante é uma operação separada.
Este terceiro artigo de Como Polymarket e Kuest funcionam acompanha os ativos por trás da interface, do sistema de negociação e dos contratos. Se pagamento e preço ainda parecem a mesma coisa, comece por o que o preço de um mercado de previsão significa.
Comece pela garantia, não pelo preço
Use nossa pergunta hipotética: “O Observatório A publicará uma temperatura de pelo menos 30.0°C para a Cidade B às 12:00 UTC da Data C?” Considere que a fonte, o arredondamento, as alternativas em caso de indisponibilidade e as regras de cancelamento foram definidos. Vamos modelar uma condição binária padrão do Conditional Tokens Framework (CTF), com YES como primeiro resultado e NO como segundo.
Garantia é o ativo comprometido para lastrear as posições. Neste exemplo, um token vencedor paga uma unidade de garantia; uma unidade não é automaticamente um dólar. Uma stablecoin traz riscos de emissor, transferência e valor, mesmo quando a interface mostra um símbolo de dólar.
Todos os saldos abaixo excluem taxas, gas e financiamento. Eles usam uma condição, um ativo de garantia e nenhuma posição-pai. Essas premissas permitem conferir cada unidade sem misturar ativos de outro mercado na conta.
O CTF normalmente usa um token ERC-20 como garantia e saldos ERC-1155 para os resultados. O ERC-1155 permite que um contrato registre muitos identificadores de token: um saldo YES da pergunta sobre temperatura e um saldo YES de uma eleição são ativos separados, mesmo que ambos apareçam com a mesma sigla.
Um conjunto completo tem uma identidade precisa
Preparar uma condição registra seu oráculo, identificador da pergunta e quantidade de resultados. Isso não deposita garantia nem cria saldos de resultados para ninguém. No código CTF da Kuest analisado, preparação e divisão são funções separadas.
No CTF, o identificador da condição é keccak256(abi.encodePacked(oracle, questionId, outcomeSlotCount)). O endereço do oráculo faz parte dessa identidade: atribuir o mesmo identificador de pergunta a outro oráculo produz uma condição diferente.
Uma coleção identifica um conjunto de resultados, incluindo eventual coleção-pai. O endereço da garantia e o identificador da coleção identificam então a posição. A derivação da coleção tem seu próprio algoritmo; use a função auxiliar getCollectionId do contrato em vez de inventar um hash dos rótulos. O guia de desenvolvimento do CTF explica essa construção.
Um mapa de construção, não uma fórmula de hash da coleção. Garantias ou caminhos de coleções diferentes produzem posições diferentes.
No nosso exemplo binário, a partição é [1, 2]: máscaras de bits que selecionam separadamente o primeiro e o segundo resultado. Juntas, elas abrangem todos os resultados sem sobreposição. A coleção-pai é formada por 32 bytes zero, indicando que essa divisão parte da garantia, não de uma posição-pai já condicional.
Portanto, títulos iguais não bastam para combinar posições. Confira rede, contrato do token, condição, garantia e caminho de coleções. Um YES da Polymarket e um NO da Kuest não formam um conjunto completo local apenas porque as perguntas têm o mesmo enunciado.
Divisão: bloqueie 100 e receba 100 de cada resultado
Comece com 100 unidades de garantia. Uma divisão bem-sucedida as transfere para o contrato CTF e emite 100 YES e 100 NO para quem chamou a função. A implementação da divisão valida a partição e realiza essas movimentações em uma única transação; uma falha reverte a operação.
Um par corresponde a uma unidade de garantia. A divisão cria os saldos dos dois resultados sem escolher uma previsão.
A carteira agora tem 200 tokens de resultado, mas apenas 100 pares completos. Cada par YES–NO é lastreado por uma unidade de garantia. Em um resultado comum YES, seu YES paga um e seu NO paga zero; um resultado comum NO inverte essa distribuição. A divisão criou estoque, não duplicou o patrimônio.
Manter os dois lados também não expressa uma previsão direcional. Um formador de mercado pode dividir a garantia para obter estoque e ofertar nos dois lados. Vender alguns YES em seguida muda sua exposição, pois a carteira ainda mantém os NO correspondentes; a divisão, sozinha, não trouxe um comprador nem garantiu receita de negociação.
Uma compra comum pode, em vez disso, transferir tokens existentes entre contas. Se outro participante vender a você 10 YES existentes, o saldo YES dele diminui e o seu aumenta; essa transferência não precisa emitir novos YES ou NO. A origem do estoque e o preço pago por ele são perguntas diferentes.
Combinação: queime 40 pares e libere 40 unidades de garantia
Antes da resolução, você pode combinar quantidades iguais dos resultados correspondentes. Partindo de 100 YES e 100 NO, combine 40 pares: o contrato queima 40 de cada e devolve 40 unidades de garantia. Restam 60 YES, 60 NO e 40 unidades de garantia disponíveis para uso.
Queimar pares correspondentes libera seu lastro. Os saldos de resultados restantes não são queimados nem pagos.
Este registro acompanha apenas nossa carteira e o lastro atribuível a seus conjuntos completos; ele não representa o saldo total do contrato. Taxas, gas e financiamento continuam excluídos.
Os saldos da carteira aparecem como garantia / YES / NO.
Etapa | Saldos da carteira | Lastro |
|---|---|---|
| Início | 100 / 0 / 0 | 0 |
| Dividir 100 | 0 / 100 / 100 | 100 |
| Combinar 40 | 40 / 60 / 60 | 60 |
| Combinar os 60 restantes | 100 / 0 / 0 | 0 |
A última linha mostra um próximo passo possível, não uma etapa realizada antes do exemplo de resgate abaixo. Ela devolve a carteira aos saldos iniciais antes dos custos, demonstrando conservação, não lucro.
Com 60 YES e apenas 20 NO correspondentes, você pode combinar no máximo 20 pares. Os 40 YES restantes continuam expostos ao resultado. Um YES isolado não libera uma unidade inteira antes da resolução porque não cobre o resultado NO.
A implementação da combinação não exige um resultado de pagamento. Reunir um conjunto completo funciona antes da resolução; a função não se restringe a esse período. Ela usa o lastro do par em vez de procurar um comprador no livro de ofertas.
Resgate: use o resultado, não a última cotação
Retome agora o estado anterior, com 40 unidades de garantia e 60 de cada token. Se o resultado registrado for YES, resgatar esses saldos selecionados paga 60 unidades de garantia pelos YES e zero pelos NO. A carteira chega a 100 unidades de garantia antes dos custos; os tokens resgatados são queimados.
Uma carteira que mantivesse apenas os 60 YES receberia o mesmo pagamento de 60 unidades pelos YES. O resgate não exige que seu proprietário forneça NO também. Essa é a principal diferença em relação à combinação antes da resolução: um resultado registrado determina quais direitos individuais pagam.
Na função de resgate analisada, o valor de cada posição selecionada é seu saldo multiplicado pelo numerador de pagamento correspondente e dividido pelo denominador. O denominador é a soma dos numeradores registrados. Selecionar uma posição resgata todo o seu saldo nessa função CTF; não há um argumento de quantidade parcial.
Garantia recebida por 100 tokens de cada resultado, antes dos custos. O caso 50/50 é uma capacidade do CTF comum, não uma promessa nem um resultado permitido em NegRisk.
Para 100 de cada token, [1, 0] paga 100 YES / 0 NO, e [0, 1] paga 0 YES / 100 NO. Um pagamento permitido de [1, 1] no CTF comum tem denominador 2 e paga 50 para cada lado. Esses valores são recebimentos de garantia, não lucro líquido; os custos de aquisição continuam importando.
Essa capacidade de pagamento fracionário não é uma promessa universal de reembolso por cancelamento. As regras do mercado e o responsável pela resolução precisam permitir esse resultado. Um evento NegRisk vinculado exige suas próprias regras de pagamento e recuperação compatíveis; não presuma que a alternativa de um mercado binário comum se aplica.
O contrato calcula com unidades-base inteiras e arredonda as divisões para baixo. Se um token de garantia tem seis casas decimais, 100 unidades correspondem a 100000000 unidades-base; uma unidade-base sob um pagamento pela metade é arredondada para zero. Decimais exibidos na tela nunca devem ser enviados como inteiros brutos ao contrato.
O relógio chegar ao horário de encerramento do mercado não estabelece um pagamento. O resgate exige um denominador de pagamento registrado diferente de zero; o oráculo e seu processo configurado precisam primeiro fornecer o resultado. Isso pode gerar espera mesmo depois de a negociação terminar.
Vender e resgatar são saídas diferentes
Vender exige interesse de compra executável. Você transfere tokens de resultado a um comprador pelo preço acordado, sujeito à quantidade disponível, aos custos de execução e à liquidação bem-sucedida. Isso pode encerrar uma posição antes do resultado, mas um ponto médio exibido não é uma oferta de compra disponível.
Uma venda precisa de comprador e preço executável. O resgate precisa de resultado registrado e da modalidade de contrato correta.
O resgate usa o pagamento registrado e a modalidade de contrato apropriada após a resolução. Ele não exige um novo comprador no livro de ofertas. Uma aquisição a 0.60 seguida de um pagamento vencedor de uma unidade gera um ganho bruto de 0.40 por token; um resultado perdedor gera uma perda de 0.60, antes dos custos em ambos os casos.
Comprar os dois resultados abaixo de seu valor de combinação só permite um spread bruto depois de quantidades iguais serem efetivamente executadas no mesmo conjunto completo. Uma perna não executada, identificadores incorretos, taxas, aprovações, falhas de transação e riscos da garantia podem eliminar esse spread ou deixar exposição direcional. Uma cotação, sozinha, não é uma estratégia concluída.
O diferencial da Kuest: o contexto do criador acompanha as posições
A Kuest mantém essa mecânica de ativos CTF e amplia a preparação da condição com um endereço de criador e uma referência externa de metadados. Sua função de atualização de metadados restringe as atualizações ao criador ou a um administrador e registra a referência anterior, a nova referência e o responsável pela alteração.
Para o operador, isso oferece, no código, uma forma de associar a condição a seu criador e acompanhar mudanças na referência de metadados. Isso não armazena o documento completo do mercado no registro CTF, não torna toda regra exibida imutável nem decide o pagamento. Operadores continuam precisando de documentos acessíveis e de uma modalidade de resolução claramente identificada.
O guia público do CTF separa as operações de divisão, combinação e resgate do registro de posições. Um adaptador NegRisk é uma modalidade de contrato diferente; identifique sua interface publicada e seu ativo de garantia antes de tentar a mesma operação de estoque.
As permissões seguem essa modalidade: a divisão precisa de autorização de uso da garantia para o contrato CTF ou adaptador correspondente. A combinação e o resgate de risco negativo também precisam de permissão para o adaptador movimentar as posições CTF. Aprovações de negociação para o sistema de ordens não autorizam automaticamente essas operações de estoque.
Verificação de versão em 30 de outubro de 2026: a documentação atual de gestão de posições da Polymarket distingue adaptadores de garantia CTF do Router e do PositionManager do Protocol V2. Um número de versão ou nome de método parecido não comprova compatibilidade com outra plataforma. Use a modalidade documentada para a posição real.
As explicações sobre o CTF da Kuest acima podem ser conferidas em seu contrato público verificado na Polygon. Elas não estabelecem a garantia, as permissões ou o responsável pela resolução atuais de todo mercado listado. Antes de habilitar operações de estoque, confirme esses detalhes e apresente divisão, combinação e resgate como movimentações distintas de ativos.
Está planejando essa experiência para sua audiência? Crie seu próprio mercado de previsão com a Kuest e reúna as regras do mercado, as jurisdições da audiência pretendida e os requisitos de liquidez necessários para escolher a configuração operacional adequada.