Bot de negociação Sim e Não: mantenha lado, preço e comissões claros

A correspondência de lados do bot de negociação Sim e Não começa pelos identificadores

Guarde explicitamente o identificador do contrato e cada identificador de resultado. Uma designação como Sim só tem significado dentro de um contrato específico. Dois mercados vizinhos podem ambos ter um resultado Sim e referir limiares, datas ou fontes diferentes. A correspondência deve ligar a condição da estratégia ao resultado exato que o executor enviará, com uma referência de regras com versão que explique a relação.

Mantenha comprar e vender como campos separados de ação. Uma compra acrescenta a posição selecionada e consome a caixa ou garantia necessária segundo os mecanismos efetivos da conta. Uma venda reduz ou altera de outra forma a posição segundo o modelo suportado da plataforma. Não pressuponha vendas a descoberto irrestritas nem presuma que um complemento económico pode sempre ser expresso através da mesma ação operacional.

Por exemplo, uma recomendação para comprar 120 unidades Não deve permanecer uma compra Não no registo da instrução. O sistema pode também calcular a sua exposição direcional equivalente a Sim para análise de risco, mas essa vista derivada não deve substituir a identidade efetiva da ordem. Se o adaptador a converter silenciosamente numa venda Sim, pode criar uma instrução que a conta não consegue suportar ou um percurso de caixa diferente do aprovado pela verificação de risco.

O guia anterior de compra automática de participações Sim e Não na Polymarket fornece contexto para seleção de resultados. Um teste robusto de correspondência deve usar intencionalmente nomes de contratos semelhantes e lados opostos. O objetivo é demonstrar que o bot seleciona o resultado e a ação aprovados, não apenas que produz um preço aparentemente plausível.

Mantenha distintas cotações observadas e derivadas

Uma plataforma pode comunicar diretamente os livros dos dois resultados ou expor uma representação da qual se deriva uma oferta de venda do lado oposto. O bot deve documentar essa correspondência e manter a observação original. Uma cotação derivada deve identificar lado de origem, preço, quantidade e hora que a sustentam. Isto permite ao revisor examinar a transformação quando a ação efetiva da conta parece surpreendente.

A documentação do livro de ordens da Kalshi descreve listas de ofertas de compra Sim e Não com relações complementares de ofertas de venda. Num exemplo padrão de um dólar, uma oferta de compra Sim de 0,33 $ corresponde a uma oferta de venda Não de 0,67 $. Essa relação pode informar um cálculo de compra Não, mas não torna cada valor Sim apresentado numa entrada adequada. Um ponto médio ou uma última negociação antiga não são o mesmo que a oferta de compra atual do lado oposto.

Preserve profundidade juntamente com preço. Se a oferta de compra de origem suportar apenas 40 unidades, a oferta de venda derivada suporta essa quantidade nesse nível, não uma compra ilimitada. Quantidade adicional exige níveis adicionais e um novo cálculo do custo médio. Um adaptador que derive o preço correto mas associe a quantidade errada pode ainda criar uma recomendação inexata.

O guia relacionado de software de negociação de cotações examina dados normalizados mais amplamente. Um formato interno útil deve identificar tipo e origem da observação. A normalização só torna valores comparáveis quando preserva os factos necessários para os interpretar; eliminar informação de lado ou hora pode tornar uma estrutura limpa de dados menos verdadeira do que a resposta bruta.

Preserve a precisão de preço e quantidade

Trate preços e quantidades segundo as unidades documentadas e a precisão permitida da plataforma atual. Não pressuponha que todos os mercados usam cêntimos inteiros ou contratos inteiros. Uma cadeia decimal que representa dólares não deve ser lida como um inteiro de cêntimos, e um campo de quantidade não deve ser arredondado apenas porque uma interface apresenta menos algarismos. O adaptador precisa de uma regra explícita de conversão com testes nas fronteiras relevantes.

Use aritmética adequada a dinheiro e à precisão exigida. Representações binárias de vírgula flutuante podem produzir pequenos artefactos de arredondamento, pelo que a implementação deve usar uma abordagem decimal ou de ponto fixo verificada quando adequado. O requisito importante é conversão e arredondamento determinísticos segundo as regras efetivas da plataforma. Uma técnica específica de programação não basta a menos que a sua saída tenha sido verificada face a preços e quantidades suportados.

O bot deve distinguir arredondamento de apresentação de arredondamento de ordens. Mostrar um preço com duas casas decimais por legibilidade não autoriza enviar esse valor arredondado se o limite efetivamente permitido ou pretendido diferir. Do mesmo modo, uma quantidade reduzida para satisfazer um incremento deve ser refletida na autorização e no cálculo de exposição. O arredondamento silencioso pode alterar a economia ou deixar uma posição residual inesperada.

A discussão anterior da API de negociação Kalshi ajuda a identificar a necessidade de adaptadores específicos da plataforma. Os testes de aceitação devem incluir valores perto de incrementos permitidos, quantidades mínimas e limites da conta. Um bot que funciona apenas com números redondos conhecidos não demonstrou conseguir preservar corretamente toda a gama de entradas suportadas.

A contabilização de comissões do bot Sim e Não começa antes do envio

Estime encargos para o lado, preço, quantidade e papel de execução efetivamente considerados usando termos atuais específicos do mercado. Guarde a estimativa separadamente do encargo final comunicado pela conta. A estimativa informa a permissão; o encargo efetivo determina o registo final. Uma diferença de comissões deve ser explicável sem reescrever a recomendação original como se tivesse tido previsão perfeita.

Suponha que o bot fictício propõe comprar 120 unidades Não a uma oferta de venda executável de 0,67 $. O custo de compra é de 80,40 $. Pressuponha encargos estimados de aquisição de 1,60 $, produzindo um compromisso total de 82 $. Segundo o pagamento habitual declarado, uma vitória Não paga 120 $ e produz um ganho de 38 $, enquanto uma perda Não produz uma perda de 82 $. Estes números devem aparecer com os seus pressupostos em vez de uma percentagem genérica de lucro.

A autorização da conta deve reservar o custo máximo permitido de compra e uma margem suficiente para encargos. Se a ordem puder ser executada em vários níveis até um teto de preço, use o compromisso máximo relevante em vez de apenas a primeira oferta de venda observada. As comissões também podem comportar-se de forma diferente em execuções parciais ou papéis alterados de execução, pelo que a política deve considerar a tabela efetiva em vez de pressupor um montante universal por unidade.

A documentação atual de comissões da Polymarket usa parâmetros específicos do mercado. Isso é motivo para verificar a tabela aplicável, não para copiar um valor predefinido para todos os bots. Os 1,60 $ hipotéticos acima são uma entrada educativa e não descrevem o encargo de uma plataforma identificada para essa quantidade ou preço.

Um registo completo de ordem liga intenção a provas

Os registos de ordens de um bot de negociação Sim e Não devem preservar recomendação, autorização, tentativa de envio, identidade da ordem na plataforma e execuções subsequentes. A recomendação explica por que a ação foi considerada. A autorização delimita o que a conta pode fazer. O registo de envio estabelece o que foi enviado. As execuções estabelecem o que alterou a conta. Manter estas fases separadas facilita localizar erros.

Cada tentativa precisa de uma identidade duradoura. Se uma resposta se perder, o bot pode investigar essa tentativa em vez de criar uma ordem nova sem explicação. Guarde lado, ação, quantidade e limite de preço originais com a tentativa. Um processo de recuperação não deve ter de os reconstruir a partir de um instantâneo posterior da posição ou da memória de um operador sobre uma designação no painel.

Os registos de execuções precisam de identificadores estáveis de execução, quantidades efetivas, preços e encargos. A entrega repetida de uma execução não deve aumentar a posição duas vezes. Uma ordem parcialmente executada deve manter o compromisso não executado até ser concluída, rejeitada ou cancelada com provas suficientes. A vista de risco da conta depende tanto de unidades confirmadas como de unidades que ainda podem chegar.

Um bot de negociação em mercados binários usa estes registos para manter exposição delimitada e contabilização da liquidação. O adaptador Sim e Não acrescenta uma responsabilidade específica: cada registo tem de preservar que resultado era detido e que ação o criou ou reduziu. Uma quantidade correta do lado errado continua a produzir o pagamento possível errado.

Uma saída tem de usar a oferta de compra do lado detido

Continue a compra Não fictícia com custo total de 82 $. Suponha que a conta considera mais tarde vender todas as 120 unidades Não a uma oferta de compra executável de 0,63 $. As receitas brutas de venda seriam de 75,60 $. Com um encargo pressuposto de saída de 1,20 $, as receitas líquidas seriam de 74,40 $, produzindo uma perda de 7,60 $ face ao custo de aquisição. O cálculo usa a oferta de compra Não porque a conta está a vender Não.

Usar diretamente a oferta de venda Sim como preço de venda seria errado sem a transformação adequada revista. O bot deve obter ou derivar o preço da ação efetiva, verificar a quantidade disponível e aplicar a estimativa atual de encargos. Uma função auxiliar partilhada chamada obter preço é perigosa se quem a usa não conseguir especificar se precisa de oferta de venda para compra, oferta de compra para venda ou referência não executável.

Uma recomendação de saída deve também declarar se encerra toda a posição ou apenas parte. Vender 60 das 120 unidades deixa 60 unidades Não com pagamento contingente. O bot não deve marcar o contrato como sem posição apenas porque a instrução de saída foi aceite. Execuções confirmadas de venda determinam a quantidade restante e qualquer parte aberta continua a fazer parte do estado futuro possível da conta.

O artigo relacionado de um bot de negociação de cotações explica como formatos de cotação podem ser normalizados antes da avaliação. Essa conversão não substitui a seleção do livro que considera a ação. Um preço corretamente convertido para comprar um lado continua a ser a entrada errada para calcular o que a conta receberia ao vendê-lo.

Os limites que consideram o lado precisam de interpretação por cenários

Os limites de risco podem usar quantidades, compromisso de caixa ou perdas possíveis, mas a correspondência entre posições e cenários tem de respeitar o contrato. Para lados complementares exatos de uma pergunta binária padrão, quantidades iguais Sim e Não podem formar um pagamento emparelhado segundo as regras declaradas. Quantidades desiguais deixam exposição residual. Entre contratos diferentes, uma compensação aparente Sim e Não pode não existir.

Suponha que uma conta detém 120 unidades Não e 80 unidades Sim no mesmo contrato fictício. No modelo simples, 80 unidades formam pares e 40 unidades Não permanecem direcionais. Se Sim ganhar, a conta recebe 80 $; se Não ganhar, recebe 120 $. Os custos de aquisição e os encargos determinam o resultado líquido em cada caso. Uma quantidade líquida de menos 40 pode resumir a diferença direcional, mas não deve substituir as posições brutas nem o historial de caixa.

As quantidades brutas importam operacionalmente porque vender ou gerir cada lado pode exigir ações e inventário separados. Um painel de risco que apresenta apenas exposição líquida pode esconder o montante de capital comprometido em ambos os lados. Também pode ocultar que ordens continuam ativas e capazes de alterar o equilíbrio. Mantenha posições brutas, quantidade emparelhada e exposição residual disponíveis para revisão.

O guia anterior da API de bots Polymarket oferece contexto para registos de conta específicos de resultados. O bot deve explicar qualquer medida líquida derivada em termos de posições efetivas e relações verificadas de pagamento. Um modelo de risco torna-se pouco fiável quando um número conveniente com sinal é tratado como prova de uma compensação que os termos contratuais não sustentam.

Ordens desconhecidas têm de manter o lado original

Se o pedido de compra Não esgotar o prazo de resposta, o bot deve preservá-lo como uma compra Não incerta com a sua quantidade e limite de custo originais. Não deve responder enviando uma venda Sim apenas porque as duas ações podem estar economicamente relacionadas num modelo simplificado. Essa mudança introduz uma nova ação na conta e pode exigir inventário, permissões e tratamento de caixa diferentes.

Investigue a tentativa original através de registos suportados de ordens e da conta. Se tiver sido parcialmente executada, incorpore as unidades Não confirmadas e mantenha qualquer parte restante por resolver. Se tiver sido rejeitada, liberte a reserva não usada adequada. Se permanecer aberta, decida se a mantém ou cancela segundo a estratégia atual. Estas decisões devem usar a identidade original e provas efetivas da conta.

Uma corrida entre cancelamento e execução pode alterar o equilíbrio entre lados. Suponha que 50 unidades Não estão confirmadas quando é pedida a retirada e outras 15 são executadas antes de o cancelamento terminar. A posição é de 65 unidades Não, não 50. Se o bot já tiver enviado uma compensação baseada na quantidade anterior, a carteira resultante precisa de nova conciliação. O sistema não deve forçá-la à exposição líquida pretendida editando um campo de resumo.

Teste estes casos com uma conta inicial deliberadamente assimétrica, como uma pequena posição Sim e um pedido maior de compra Não. Isto torna erros de lado mais fáceis de detetar do que um teste que começa do zero em todos os campos. O resultado esperado deve especificar posições brutas, caixa e pagamento possível, não apenas uma quantidade final com sinal.

Concilie comissões e liquidação sem perder o rasto de auditoria

Após a execução, substitua encargos estimados nos cálculos de desempenho por encargos efetivos da conta mantendo a estimativa original para revisão. Se for mais tarde confirmado um encargo adicional de aquisição de 0,20 $ no exemplo de saída, o custo total de aquisição sobe de 82 $ para 82,20 $. Com as mesmas receitas líquidas de venda de 74,40 $, a perda passa a 7,80 $. O ajuste deve ter uma fonte e hora identificáveis.

Na liquidação, use a quantidade final restante de cada lado. Uma posição Não inteiramente vendida não tem pagamento Não restante, mesmo que a previsão original se revele correta mais tarde. Uma posição parcialmente vendida liquida apenas as unidades retidas. O registo final deve ligar resultado oficial, quantidades detidas, montantes creditados e qualquer tratamento excecional especificado pelo contrato.

Distinga uma previsão alterada de uma correção contabilística. Uma estimativa nova não altera a caixa já paga e um ajuste de comissão não muda o resultado sobre o qual o contrato pergunta. Os registos do bot devem permitir representar ambas as mudanças sem corromper a outra. Esta separação ajuda o revisor a compreender por que valor projetado e desempenho final diferem.

Se a conta não conciliar, preserve a discrepância e limite nova atividade afetada até ser compreendida. Uma diferença sem explicação não deve ser escondida num ganho ou perda diversos apenas para encerrar o caso. Pequenas discrepâncias podem revelar um problema repetido de conversão de unidades ou execução duplicada que se tornaria relevante numa dimensão maior.

Compare encargos estimados e efetivos por ação

Uma revisão de comissões deve identificar se uma diferença veio de preço, quantidade, papel na execução ou tabela incorreta. Suponha que o bot estimou um encargo para uma compra inteiramente imediata, mas parte da ordem ficou em espera antes de ser executada. O tratamento efetivo depende das regras atuais da plataforma e do mercado. O registo deve preservar como cada execução foi classificada em vez de atribuir a todas as unidades o mesmo papel com base na intenção original.

A comparação também precisa de uma unidade consistente. Um encargo expresso como montante de caixa não deve ser comparado diretamente com uma percentagem do pagamento máximo ou uma margem por unidade. Converta explicitamente cada medida e mantenha o valor original comunicado. Isto ajuda a distinguir um erro genuíno do modelo de custos de uma apresentação que usa denominadores diferentes.

Se a estimativa era conservadora e os encargos efetivos foram menores, liberte a reserva não usada apenas depois de os registos relevantes sustentarem essa decisão. Não comunique a reserva não usada como rendimento. Era capacidade retida para um possível custo, não dinheiro ganho através de negociação. Esta distinção impede que o desempenho aparente do bot melhore apenas porque a estimativa inicial era deliberadamente cautelosa.

Teste o adaptador com quatro ações e dois resultados

Um conjunto útil de aceitação inclui comprar Sim, vender Sim, comprar Não e vender Não onde cada ação for permitida pela conta efetiva. Para cada uma, verifique lado selecionado do livro, quantidade, efeito na caixa e posições restantes. Aplique depois ambos os resultados habituais de resolução e confirme o pagamento resultante. Isto cobre comportamento com mais consequências do que demonstrar repetidamente uma compra Sim bem-sucedida.

Acrescente testes de uma cotação derivada do lado oposto, profundidade insuficiente, uma mudança de comissão e uma execução atrasada. Os registos esperados devem preservar a observação bruta e a interpretação normalizada. Se uma conversão usar um menos a oferta de compra oposta, verifique a correspondência de preço e quantidade. Se o mercado usar incrementos mais finos, inclua valores que falhariam num pressuposto de cêntimos inteiros.

O bot concluído deve tornar possível uma declaração simples para cada ação: esta conta comprou ou vendeu esta quantidade deste resultado a estes preços efetivos, segundo esta permissão, com estes encargos e esta exposição restante ao pagamento. Essa clareza é o propósito da automação que considera o lado. Mantém os cálculos de probabilidade do software ligados às posições e fluxos de caixa que a conta efetivamente detém.