Bot de contratos de eventos: dos dados à conciliação

Um bot de contratos de eventos precisa de um registo de contratos

Comece com um registo explícito dos contratos que o bot pode considerar. Guarde o contexto da plataforma, o identificador de mercado, os identificadores de resultados, a unidade de liquidação e a referência das regras. Acrescente a hora do evento, o limite temporal da negociação e a fonte indicada no contrato. O registo deve distinguir uma publicação inicial de um valor revisto e manter a versão da correspondência usada em cada decisão.

Este registo é mais preciso do que um resultado de pesquisa que contém um título de mercado. Uma pesquisa automatizada pode descobrir um contrato candidato, mas a descoberta não deve autorizar silenciosamente a negociação. Dois mercados podem partilhar um título e usar limiares ou janelas de observação diferentes. Uma correspondência revista por uma pessoa ou um processo testado de correspondência de regras tem de estabelecer que os dados recebidos pelo bot respondem à pergunta que determina a liquidação do contrato.

Trate uma alteração à correspondência como um evento relevante do sistema. Se um campo anteriormente reconhecido ficar indisponível, o bot não deve escolher um campo com nome semelhante apenas porque mantém o processo em funcionamento. Se surgir um esclarecimento do contrato, preserve a interpretação antiga e registe a revisão da nova informação. Esse historial é necessário para compreender por que foi aberta uma posição anterior segundo pressupostos que podem mudar mais tarde.

O guia anterior da API de bots para mercados de previsão ajuda o leitor a identificar a ligação entre identificadores de contratos e ações na conta. Um registo não é apenas uma conveniência de programação. É o limite que impede que um sinal de um evento seja encaminhado para uma posição superficialmente semelhante mas economicamente diferente.

Mantenha a observação separada da interpretação

A camada de observação regista o que uma fonte comunicou e quando o sistema o recebeu. Não deve converter imediatamente cada atualização num sinal de negociação. Preserve a hora da fonte, a hora de receção, o identificador e o valor relevante exato. Se uma mensagem se repetir, assinale-a como a mesma observação em vez de uma segunda confirmação independente. Se as mensagens chegarem fora de ordem, preserve essa informação de ordenação em vez de substituir uma observação mais recente por uma mais antiga.

A camada de interpretação decide o que a observação significa para o contrato. Um relatório de que um índice é igual a 100,3 pode sustentar Sim para um limiar acima de 100,2, mas apenas se o relatório disser respeito à publicação, ao campo e ao tratamento de arredondamento corretos. Um título que diga que o índice superou expectativas é insuficiente quando o contrato pergunta por um valor absoluto. Um analisador tem de extrair o facto relevante para o contrato em vez de um sentimento geral positivo ou negativo.

Algumas entradas sustentam uma estimativa de probabilidade em vez de uma determinação factual direta. O programa deve identificar essa saída como previsão e manter a sua incerteza. Um valor de confiança devolvido por um modelo de linguagem ou classificador não é automaticamente uma probabilidade calibrada de o contrato pagar. Se a interpretação exigir um juízo jurídico ou factual novo, o sistema pode encaminhá-lo para revisão sem conceder ao modelo autoridade para criar exposição.

Uma vista de diagnóstico útil mostra a observação original ao lado da afirmação derivada. Quando um operador questiona uma decisão, deve conseguir examinar essa ligação sem a reconstruir a partir de um gráfico de preços. Isto também facilita isolar falhas de fontes: uma observação desatualizada, uma extração incorreta e uma previsão razoável mas malsucedida são problemas diferentes que exigem reparações diferentes.

Defina a autoridade de decisão do bot de contratos de eventos

A fase de recomendação propõe uma ação com contrato, lado, quantidade, limite de preço e motivo. A fase de autorização decide se a proposta respeita as restrições atuais da conta. Estas fases devem ser separadas mesmo num programa pequeno. Uma estratégia pode recomendar comprar quando a conta já está no seu limite de evento, quando outra ordem permanece por resolver ou quando o fluxo de mercado se tornou demasiado antigo para sustentar o preço proposto.

Um registo de autorização deve indicar os limites verificados. Podem incluir custo máximo de aquisição, exposição máxima por evento, número máximo de ordens abertas e a exigência de que a correspondência do contrato permaneça atual. O resultado é uma permissão delimitada com prazo de validade, não uma instrução indefinida para continuar a tentar até obter a quantidade desejada. Se as condições mudarem antes do envio, o executor deve pedir uma nova decisão ou recusar a ação.

Por exemplo, uma estratégia fictícia recomenda 100 unidades Sim com limite de compra de 0,56 $ e uma reserva adicional de 2 $ para encargos. O controlo de risco da conta permite no máximo 60 $ de compromisso para este evento. O compromisso máximo proposto é de 58 $, pelo que respeita essa restrição específica. Pode ainda falhar outra restrição, como uma ordem por resolver no mesmo mercado ou a falta de uma hora da fonte oficial.

A distinção torna-se especialmente importante quando um bot realiza várias tarefas. Um módulo de investigação pode acrescentar contratos a uma lista de acompanhamento, mas não deve obter permissão de negociação apenas porque partilha um processo com o executor. Um módulo de notificações pode alertar uma pessoa para uma diferença invulgar entre preços de compra e venda, mas esse alerta não autoriza uma nova estratégia. Permissões explícitas impedem que observações úteis se tornem instruções acidentais para a conta.

Reserve exposição antes de enviar seja o que for

A reserva de exposição do bot de contratos de eventos impede que várias decisões simultâneas gastem a mesma capacidade. Quando uma instrução é autorizada, reserve o seu custo máximo permitido e a exposição relevante ao evento antes de a enviar. Mantenha a reserva enquanto a ordem estiver aberta ou o seu resultado for incerto. Liberte apenas a parte que registos fidedignos estabeleçam já não poder ser executada.

Suponha que a ordem fictícia de 100 unidades começa a ser executada. Quarenta unidades são executadas a 0,54 $, custando 21,60 $ antes de encargos. Sessenta unidades permanecem abertas com limite de 0,56 $, representando até 33,60 $ de custo adicional de compra. Mantendo a reserva de 2 $ para comissões, o compromisso combinado é de 57,20 $. O preço inferior na parte executada reduz o compromisso face aos 58 $ iniciais, mas a parte não executada continua a ser uma possível posição futura.

Se o orçamento de caixa relevante da conta for de 100 $, esta reserva simplificada deixa 42,80 $ não comprometidos. Não deixa 78,40 $ apenas porque até agora só foram gastos 21,60 $. Esse valor maior ignoraria a ordem aberta e poderia permitir a outra estratégia consumir dinheiro já necessário para uma possível execução. Implementações reais têm também de conciliar comissões efetivas e qualquer comportamento de reserva específico da plataforma.

Use uma vista partilhada da exposição entre estratégias que negoceiam na mesma conta. Programas separados com contadores independentes podem acreditar, cada um, que a conta tem ampla capacidade. A discussão anterior sobre automação da negociação em mercados de previsão fornece contexto para coordenar estas responsabilidades. O sistema de reservas deve falhar de forma conservadora quando não consegue determinar se outra instrução continua capaz de ser executada.

Modele ordens como estados, não mensagens de sucesso

Um pedido de ordem pode estar preparado, enviado, reconhecido, em espera no livro, parcialmente executado, concluído, rejeitado, cancelado ou incerto. São estados conceptuais, não uma alegação de que todas as API usam exatamente esses nomes. Faça corresponder as respostas reais da plataforma a um modelo local documentado. Preserve a resposta original juntamente com a interpretação para que um erro do adaptador possa ser investigado mais tarde.

Uma resposta de rede bem-sucedida pode estabelecer que um pedido foi aceite sem estabelecer que a quantidade pretendida foi executada. Por outro lado, o prazo de resposta da rede pode esgotar-se depois de a plataforma aceitar uma ordem. O bot tem de evitar tratar cada sucesso como uma posição concluída e cada esgotamento do prazo como uma rejeição. Identificadores de ordens, registos de execuções e instantâneos da conta fornecem provas diferentes do que efetivamente ocorreu.

A atual documentação da Polymarket sobre o ciclo de vida das ordens distingue estados de ordens e de negociações. Essa distinção ilustra por que um único valor booleano local chamado concluído é insuficiente. Uma implementação tem de seguir os estados da sua plataforma e produto específicos, incluindo quaisquer estados intermédios de execução ou liquidação que permaneçam por resolver depois de ser comunicada uma correspondência.

O executor deve também preservar a instrução autorizada original. Se uma ordem for executada a um preço melhor, a posição resultante deve continuar rastreável à mesma permissão. Se a quantidade restante precisar de um preço superior, isso é uma nova decisão que exige autorização segundo as regras da estratégia. Aumentar discretamente um limite para concluir o objetivo transforma um executor controlado numa componente de estratégia não revista.

Os estados de recuperação do bot de contratos de eventos evitam exposição duplicada

Considere um envio cuja resposta nunca chega ao bot. O registo local sabe que uma tentativa foi enviada mas não sabe se se tornou uma ordem. O estado seguinte correto é incerto. Mantenha a reserva de exposição e examine a plataforma usando os identificadores suportados e registos de conta capazes de resolver a tentativa. Não crie uma ordem nova apenas porque falta a primeira resposta.

Suponha que a instrução original pediu 100 unidades. Os registos da conta revelam mais tarde 40 executadas e 60 ainda abertas. O bot pede o cancelamento do restante, mas outras 15 unidades são executadas antes de o cancelamento produzir efeito. A posição conciliada é de 55 unidades, com 45 unidades já não abertas quando o cancelamento é confirmado. Se o bot tivesse presumido que a tentativa original falhara e enviado outra ordem de 100 unidades, a sua exposição pretendida poderia ter sido substancialmente excedida.

A recuperação deve ser duradoura entre reinícios do processo. Grave o identificador da tentativa e a reserva antes do envio ou como parte do processo controlado de envio, segundo a conceção de consistência do sistema. Ao reiniciar, examine tentativas por resolver antes de aceitar novas recomendações para a mesma exposição. Um arranque limpo do programa não implica uma conta limpa. A plataforma pode ainda manter ordens criadas pelo processo anterior.

O guia de automação de contratos de eventos estende esta distinção ao processo envolvente de investigação e revisão. A recuperação não é apenas um pormenor de engenharia para falhas raras. Faz parte do controlo de exposição da estratégia porque a conta pode mudar enquanto o sistema local está desligado, a reiniciar ou à espera de resposta.

Construa um ciclo de conciliação independente da estratégia

Um processo de conciliação compara expectativas locais com registos fidedignos da conta. Deve funcionar mesmo quando não é gerado qualquer sinal novo. Compare ordens abertas, quantidades executadas, posições, encargos e saldos disponíveis usando identificadores e horas de observação consistentes. Uma discrepância deve produzir uma exceção explícita em vez de ser corrigida silenciosamente de forma a apagar o historial de como o modelo local se tornou incorreto.

Separe diferenças temporais habituais de discrepâncias sem explicação. Uma atualização de execução pode chegar antes da atualização correspondente do saldo, dependendo do percurso de comunicação da plataforma. O sistema pode permitir um estado temporário documentado enquanto espera por um instantâneo consistente. No entanto, uma discrepância que persista além do processo esperado deve bloquear nova exposição no âmbito afetado até ser explicada. O âmbito pode ser um mercado, uma conta ou todo o executor.

O registo de conciliação deve dizer que observações sustentam a posição atual. Um operador deve conseguir ver que 55 unidades resultam de duas execuções de 40 e 15, não de uma diferença inferida entre saldos arredondados. Mantenha os ajustes de comissões separadamente para que uma mudança de caixa não seja confundida com uma mudança de quantidade de contratos. Após a resolução, ligue o pagamento à posição efetiva restante e ao resultado final do contrato.

Os leitores que desenvolvem para uma interface de conta podem usar a discussão anterior sobre um bot de negociação pela API Kalshi para organizar os registos necessários. O princípio é independente da linguagem de implementação: a estratégia propõe o que deve acontecer, enquanto a conciliação estabelece o que aconteceu. Nenhuma função deve poder substituir provas em falta pelas suas próprias expectativas.

Dê limites adicionais a sistemas de várias componentes e de cotação

Um bot direcional consegue frequentemente expressar a exposição através de uma única posição. Um sistema de várias componentes precisa de acompanhar se a combinação pretendida está completa e o que resta se apenas algumas ordens forem executadas. Uma proposta de arbitragem de contratos de eventos depende de pagamentos compatíveis e execução viável. O bot deve representar cada componente e os resultados possíveis combinados em vez de registar um par como concluído quando a primeira ordem é aceite.

Reserve capacidade para componentes inacabadas e defina um tempo máximo ou uma condição para permanecer sem a componente complementar. Se a segunda componente ficar indisponível, o sistema precisa de uma resposta predefinida consistente com os limites de perda da conta. Essa resposta pode incluir cancelar ordens não executadas, reduzir a primeira posição ou manter uma exposição delimitada para revisão. Não deve presumir que qualquer cobertura a qualquer preço é automaticamente preferível a uma decisão ordenada.

Um sistema de cotação enfrenta outro desafio: ambos os lados podem permanecer ativos enquanto as execuções alteram o inventário. Um criador de mercado de contratos de eventos precisa, por isso, de permissões que tenham em conta o inventário e de uma vista fiável das cotações pendentes. Uma atualização de cotação que substitui uma ordem antiga tem de considerar qualquer intervalo em que ambas as instruções possam continuar ativas. A exposição bruta e líquida permitida do sistema deve refletir essa possibilidade.

Estas extensões ilustram por que uma função genérica de compra ou venda não é uma arquitetura completa de bot. Estratégias diferentes precisam de representações diferentes de trabalho incompleto. A base comum é autoridade explícita, identidade de ordem preservada e conciliação; a camada específica da estratégia descreve que combinações de execuções são aceitáveis e que provas são necessárias antes da ação seguinte.

Acompanhe os relógios que regem uma decisão

Um bot deve preservar vários relógios porque respondem a perguntas diferentes. A hora da fonte do evento descreve quando a informação foi publicada. A hora de receção descreve quando o processo local a obteve. A hora do livro descreve o estado do mercado usado na recomendação. A hora de autorização descreve quando a conta aprovou uma ação. Comprimir tudo num único campo temporal pode esconder uma observação desatualizada atrás de um evento recente de processamento.

Suponha que uma observação da fonte foi publicada às 9:00, chegou ao coletor às 9:01 e foi reproduzida após um reinício às 9:10. A reprodução é nova para o processo reiniciado, mas as provas subjacentes têm dez minutos. Uma regra de atualidade baseada apenas na hora de inserção local poderia permitir ao bot tratar a observação como atual. Preserve as horas originais e assinale explicitamente a reprodução para que a regra avalie o facto que foi concebida para limitar.

As comparações entre relógios também precisam de uma política para valores em falta ou inconsistentes. Se uma fonte não fornecer uma hora de publicação fidedigna, o sistema não deve inventá-la. Pode usar uma alternativa documentada com permissão mais restrita ou suspender ações que exigem provas temporais mais fortes. O objetivo é tornar visível a incerteza temporal no registo da decisão em vez de permitir que uma hora aparentemente precisa implique conhecimentos que o sistema não tem.

Teste com incidentes que alteram a conta

Um conjunto útil de testes centra-se em transições com consequências. Simule um prazo de resposta esgotado depois da aceitação, uma execução parcial durante o cancelamento, um instantâneo de mercado desatualizado e um reinício com uma ordem por resolver. Verifique se o bot preserva a reserva correta e recusa ações que poderiam exceder os limites. Um teste que apenas confirma que uma função devolve o valor atribuído dentro dela fornece poucas provas sobre estes percursos reais de falha.

Use um pequeno conjunto de incidentes reproduzíveis com registos esperados conhecidos. Para o exemplo de 100 unidades, o teste deve terminar com 55 executadas e 45 canceladas, sem um segundo envio de 100 unidades. O modelo de caixa deve refletir os preços efetivos de execução e os encargos em vez da estimativa máxima original. Outro teste pode omitir deliberadamente um evento de execução e exigir que a conciliação recupere a execução em falta através de uma consulta à conta.

Teste também a inatividade inofensiva. Quando a previsão está indisponível, a correspondência do contrato está por resolver ou o estado da conta é inconsistente, o resultado correto pode ser não colocar qualquer ordem. Um sistema avaliado apenas por envios bem-sucedidos pode premiar atividade e ignorar as decisões que impedem exposição indesejada. Registe por que uma ação foi recusada para que os operadores distingam uma pausa deliberada de uma avaria não detetada.

O bot só está pronto para uso mais alargado quando os seus registos tornam compreensíveis a operação habitual e a recuperação. Um operador deve conseguir identificar o contrato atual, as provas, a permissão, os compromissos abertos e a posição confirmada sem adivinhar. Essa transparência não demonstra uma vantagem de negociação, mas torna o comportamento do programa passível de revisão e dá à estratégia uma base fiável sobre a qual pode ser avaliada.