Assinar uma ordem autoriza uma negociação sob condições específicas. Isso não significa que ela já aconteceu. A API pode aceitá-la, o livro pode encontrar contraparte para uma parte e a transação de liquidação ainda pode falhar.
Este quinto artigo de Como Polymarket e Kuest funcionam acompanha a autorização por trás dos livros conectados de YES e NO. Percorremos as camadas separadas do sistema: o que o participante assina, o que o serviço de encontro de ordens aplica e o que a blockchain efetivamente registra.
Comece por uma instrução e depois acompanhe os ativos
Mantenha 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?” Comprar seu token YES significa adquirir o ativo do resultado especificado; assinar uma ordem BUY apenas autoriza essa aquisição.
Usamos um mercado binário padrão do Conditional Tokens Framework (CTF) e unidades genéricas de garantia. Os exemplos de quantidades pressupõem seis casas decimais, recursos e permissões suficientes e ausência de custos de gas ou financiamento; as taxas aparecem separadamente quando indicadas.
As explicações abaixo usam padrões públicos de assinatura, exemplos públicos do CTF Exchange e fluxos hipotéticos de ativos. As carteiras, os tipos de ordens e as taxas compatíveis com cada plataforma devem ser consultados na documentação pública atual de integração desse serviço.
Três autorizações cumprem funções diferentes
Uma assinatura de ordem autoriza uma instrução específica de negociação. A autenticação da API identifica um solicitante autorizado perante um serviço. Uma assinatura de lote da carteira autoriza outro conjunto de chamadas da carteira, como definir uma autorização de gasto.
Uma credencial de API identifica um solicitante autorizado perante um serviço; ela não é a chave privada do participante e não substitui uma assinatura de ordem. O guia público de carteiras e autenticação da Polymarket apresenta um exemplo documentado de produto.
Objetos separados, verificações separadas. Um lote da carteira tem seu próprio nonce e prazo; esses campos não passam a fazer parte da ordem do sistema de negociação.
O EIP-712 define o cálculo de hash e a assinatura de mensagens estruturadas. Seu domínio pode vincular uma instrução a uma rede, nome de aplicação, versão e contrato verificador, impedindo que uma assinatura destinada a um domínio seja validada em outro.
O código público de assinatura do CTF Exchange V2 ilustra um domínio EIP-712 específico de aplicação. O nome ou a versão do domínio faz parte do contexto assinado; não comprova que outro sistema de negociação aceita a mesma mensagem. Os limites de reutilização também dependem do estado e das regras de validação do contrato real.
As quantidades contêm o preço
Na definição pública de ordem do CTF Exchange V2, a instrução assinada inclui token, lado, quantidades de maker e taker e identidades das contas, entre outros campos. A assinatura autoriza essa mensagem definida, não qualquer preço que a interface mostre depois.
Aqui, maker identifica a conta que fornece os ativos, mesmo quando sua ordem consome liquidez imediatamente. Esse nome de campo difere do papel de negociação maker, usado para uma ordem que fica no livro antes de outra negociar contra ela.
Em uma BUY, makerAmount é a garantia oferecida e takerAmount é a quantidade de cotas solicitada. Uma ordem que oferece 60 por 100 YES codifica um limite de 60 ÷ 100 = 0.60; em uma SELL que oferece 100 YES por 60, o preço é takerAmount ÷ makerAmount.
Não existe um campo de preço assinado independente que substitua essa proporção. Mudar o preço exibido sem reconstruir e assinar as quantidades correspondentes não altera as condições autorizadas.
Um timestamp pode indicar quando uma ordem foi criada sem ser um prazo de expiração efetivamente imposto. Uma integração precisa distinguir campos assinados de instruções ao serviço e verificar seu significado na especificação pública atual de ordens.
A validação decide se a ordem pode entrar no livro
Antes de enviar uma ordem, confira o ativo pretendido, o limite de preço, a quantidade, a conta e o tipo de ordem compatível. Verificações no cliente e uma confirmação de recebimento da API não substituem a liquidação bem-sucedida no contrato.
O incremento de preço, ou tick, é o intervalo permitido entre preços cotados. Consulte as especificações atuais publicadas para o mercado antes de assinar. Uma verificação no cliente, uma resposta do serviço e uma regra do contrato comprovam coisas diferentes; um mínimo exibido, sozinho, não comprova uma restrição on-chain.
Recursos e permissões são verificações diferentes: uma BUY precisa de garantia utilizável e autorização de gasto suficiente para o contrato de liquidação; uma SELL precisa dos tokens de resultado e de aprovação de transferência. Uma assinatura, sozinha, não fornece nenhum deles, e conferir o saldo na admissão não congela todas as alterações posteriores naquela conta.
Post-only indica que uma instrução pretende acrescentar interesse ao livro em vez de consumir liquidez imediatamente. Confira as combinações e o comportamento de rejeição documentados pela plataforma; o rótulo, sozinho, não define todas as implementações.
A validade da ordem, ou time-in-force, orienta o serviço de encontro de ordens sobre a quantidade não executada:
- GTC — good till cancelled: manter no livro a quantidade restante elegível até o cancelamento.
- GTD — good till date: permitir que permaneça no livro até uma expiração especificada.
- FAK — fill and kill: executar imediatamente a quantidade disponível e descartar o restante.
- FOK — fill or kill: exigir que toda a quantidade solicitada seja executável ou não executar nada.
Uma ordem que expira no serviço e um prazo assinado no contrato são compromissos diferentes. Verifique onde a especificação atual aplica a expiração e o que acontece com transações já enviadas. A presença de um campo em uma solicitação não estabelece, por si só, uma garantia contratual.
Um encontro de ordens ainda precisa de liquidação bem-sucedida
Considere estas etapas didáticas: assinada → aceita/no livro → contraparte encontrada → transação enviada → confirmada. Uma ordem pode ser rejeitada antes da admissão; uma única ordem aceita pode produzir vários encontros parciais e transações de liquidação. Esses rótulos explicam responsabilidades, não definem uma enumeração universal de estados de API.
Um encontro parcial deixa quantidade para encontros posteriores quando a validade da ordem permite. Uma liquidação que falhou exige conferir o resultado antes de qualquer nova tentativa.
O contrato público do CTF Exchange V2 ilustra o encontro autorizado de ordens e as verificações contratuais antes de movimentar ativos. Os exemplos de negociação direta, emissão e combinação do Artigo 4 explicam as movimentações possíveis e seus requisitos de recursos.
A transação é atômica: se uma transferência ou verificação necessária reverter, suas alterações de estado são desfeitas. Isso não desfaz outra transação que já teve sucesso, e uma transação revertida ainda pode consumir gas.
Um hash de transação identifica uma transação enviada, não uma compra bem-sucedida. Confira seu recibo e o estado de confirmação exigido pela rede escolhida. Até conhecer o resultado, a interface deve preservar essa incerteza em vez de informar ativos entregues.
Na interface do operador, mantenha separados o identificador da ordem, a quantidade com contraparte encontrada e a referência da transação. Se uma transação falhar ou permanecer incerta, confira seu resultado real antes de tentar novamente; mudar um rótulo local não movimenta ativos.
Execuções parciais consomem o ativo oferecido
Suponha que a BUY no livro ofereça 60 unidades de garantia por 100 YES e uma primeira execução receba 40 YES exatamente a 0.60. Sem taxas, ela consome 24 unidades de garantia, deixando 36 unidades de capacidade de garantia assinada, equivalentes a 60 YES pelo mesmo preço.
Uma SELL no livro que ofereça 100 YES por 60 unidades de garantia consome 40 YES nessa execução e recebe 24 de garantia. Sua quantidade de maker restante é de 60 cotas, não 36 unidades de garantia. As duas ordens ainda podem negociar 60 YES, mas seus contadores on-chain de quantidade restante usam ativos diferentes.
A mesma execução de 40 cotas, com unidades diferentes nos contadores. Execução exata no preço limite; taxas excluídas.
A aritmética pública do CTF Exchange V2 usa unidades-base inteiras. No modelo proporcional com divisão arredondada para baixo usado a seguir, a quantidade recebida é igual à quantidade fornecida × quantidade de taker assinada ÷ quantidade de maker assinada, arredondada para baixo. A conferência exata exige as regras de arredondamento da modalidade real.
Por exemplo, vender 1.000001 cotas de uma ordem assinada de 3 cotas por 1.8 unidades de garantia calcula 1,000,001 × 1,800,000 ÷ 3,000,000, arredondando para 600,000 unidades-base de garantia. Execuções pequenas e taxas exigem, portanto, as regras de arredondamento da implementação; multiplicar preços de tela arredondados não basta para uma conferência exata.
As taxas precisam de uma contabilização separada
Considere uma compra direta de 100 YES por 60 unidades de garantia e uma taxa hipotética de 0.60 para cada participante. O comprador precisa de 60.60 de garantia; o vendedor recebe 59.40. Os 1.20 restantes são o total de taxas, portanto todos os recursos do comprador estão contabilizados.
Taxas hipotéticas, não uma alíquota atual. Saída do comprador 60.60 = recebimento do vendedor 59.40 + taxas totais 1.20; 100 YES existentes passam ao comprador.
Neste exemplo explícito, a taxa da BUY é acrescentada aos recursos necessários do comprador e a taxa da SELL é descontada dos recebimentos. Cobranças, destinatários e arredondamento reais devem ser conferidos para a plataforma e a modalidade escolhidas; o exemplo não é uma tabela de taxas.
O cancelamento tem um limite
Uma solicitação para retirar uma ordem aberta diz respeito à sua quantidade restante não executada. Ela não reverte execuções concluídas. Trate a confirmação de cancelamento e qualquer transação de liquidação pendente como registros separados; confira ambos antes de reutilizar os recursos.
Se a liquidação já foi enviada, um cancelamento posterior no livro não pode prometer interrompê-la. Confira o resultado da transação antes de presumir que os ativos continuam disponíveis, sobretudo quando a ordem original teve execução parcial.
Cancelar o restante e liquidar um encontro anterior podem acontecer juntos. Nenhuma das proteções com espera reverte uma transação bem-sucedida.
Uma restrição mais ampla à conta não equivale a cancelar uma ordem. Controles de recuperação podem ter escopos, prazos e autoridades diferentes. Use o contrato publicado e a documentação de produto da conta real em vez de presumir que todo controle interrompe tudo imediatamente.
A Deposit Wallet tem um período separado de pausa e espera de emergência antes de saques de emergência ou revogações de aprovações. Nesse código, pausar a carteira, por si só, não desativa a execução de lotes ou a validação de assinaturas; não é um botão instantâneo para interromper negociações.
Nomes de versões não definem uma integração
A ordem CTF legada da Polymarket assinava taker, expiration, nonce e feeRateBps. Sua ordem separada do CTF Exchange V2 remove esses campos e acrescenta timestamp, metadata e builder; o preço continua sendo uma proporção entre quantidades.
O repositório V2 também remove fillOrder/fillOrders, mantendo o encontro de ordens pelo operador por matchOrders. Esse CTF Exchange V2 é distinto da arquitetura de posições Protocol V2 em polymarket-v2-external; a Kuest não herda automaticamente as atualizações de nenhum desses repositórios.
A ausência de expiração em uma estrutura de contrato não significa que um produto não tenha ordens com prazo. A documentação atual do ciclo de vida da Polymarket descreve GTD no produto; seu guia de posições distingue os registros CTF e Protocol V2. Confira a modalidade do mercado real antes de construir uma integração.
O que um operador Kuest deve informar
O guia público do operador da Kuest separa a aplicação do operador dos serviços compartilhados. Informe aos participantes o fluxo de conta compatível, a estimativa completa de taxas e os estados distintos de ordem aceita, contraparte encontrada e confirmação; esses são requisitos observáveis do produto, não detalhes de implementação.
A documentação pública de taxas da Kuest descreve a participação do operador nas taxas de negociação e uma divisão configurável com afiliados. Repartir uma taxa é diferente de cobrar um valor adicional sobre o valor nocional negociado. Use a configuração pública atual e os registros de liquidação para explicar o que o participante paga.
Para quem opera com marca própria, isso cria uma decisão concreta de integração: preservar a identidade correta do builder, mostrar a cobrança total real e conferir sua repartição nos registros de liquidação. Um código ou uma interface com marca própria, sozinhos, não garantem admissão, direito a uma taxa ou receita.
Lance seu próprio mercado de previsão com a Kuest com uma política de execução compreensível para os participantes: jurisdições da audiência pretendida, regras precisas do mercado e modalidade de resolução, tamanhos de negociação necessários, fluxo de carteira compatível, divulgação de taxas e estados separados de aceitação, encontro de ordens e confirmação.