Um bot de arbitragem de contratos de eventos precisa de gerir o período em que uma combinação proposta é apenas parcialmente real. Um scanner pode identificar preços que parecem atrativos em conjunto, mas uma conta recebe ordens e execuções individuais. Uma ordem pode ser aceite enquanto outra é rejeitada. Um cancelamento pode chegar depois de uma execução adicional. Uma resposta pode desaparecer apesar de a plataforma ter aceite o pedido. O bot tem de descrever esses estados sem fingir que o par pretendido já existe.
O problema central de conceção é coordenar sob incerteza. Reserve a capacidade necessária para ambas as componentes, preserve as suas identidades e meça a exposição que resta quando não avançam em conjunto. Os exemplos fictícios aqui usam pagamentos binários de um dólar explicitamente compatíveis. Ilustram controlos de execução, não uma alegação de que uma negociação real entre plataformas possa ser concluída atomicamente ou de que uma arbitragem aparente não tenha risco.
As reservas do bot de arbitragem de contratos de eventos começam com um par aprovado
O motor de execução deve receber uma definição revista do par em vez de dois nomes de mercados vagamente relacionados. Essa definição inclui cada contexto de plataforma, identificador de contrato, lado do resultado, versão das regras e relação entre pagamentos. Deve também declarar que resultados excecionais foram considerados e que condições invalidam a correspondência. Um par de contratos cujo significado continua por resolver pertence à investigação, não à fila de casos prontos do executor.
A instrução candidata acrescenta quantidades atuais, tetos de preço, estimativas de comissões e horas de observação. Indica o custo combinado máximo aceitável e o montante de exposição sem par que a conta está preparada para tolerar. São limites distintos. Um par pode ser comportável se concluído, enquanto a sua primeira componente cria demasiada exposição direcional temporária para a conta. Ambas as perguntas precisam de resposta antes de se enviar qualquer ordem.
Use um identificador duradouro de caso para ligar a definição, a recomendação, a autorização e as ordens finais. Cada componente deve também ter a sua própria identidade estável de instrução. O identificador do par explica por que as ordens pertencem ao mesmo conjunto; os identificadores das componentes permitem ao sistema investigar um envio individual. Nenhum deve ser substituído apenas porque um pedido de rede esgota o prazo de resposta ou um processo reinicia.
O artigo anterior sobre um bot de arbitragem em mercados de previsão fornece a relação mais ampla entre uma oportunidade detetada e um processo de negociação. Esta conceção começa no ponto em que a análise dos pagamentos já foi revista. A sua função é assegurar que a combinação efetiva da conta permanece visível à medida que as ordens passam por estados diferentes.
Reserve fundos locais e capacidade de risco partilhada
Suponha que um par fictício exige 500 unidades de A Sim a um máximo de 0,37 $ e 500 unidades de B Não a um máximo de 0,60 $. Pressuponha que as regras fazem de uma unidade de cada um um pagamento combinado de um dólar nos resultados modelados. Os montantes de compra totalizariam 185 $ e 300 $. Com comissões hipotéticas de 3 $ e 4 $, o custo total de aquisição é de 492 $, restando 8 $ abaixo do pagamento pressuposto de 500 $.
O bot precisa de 188 $ disponíveis para A e de 304 $ para B segundo esses pressupostos. Se as componentes usarem contas separadas, a existência de 492 $ algures na carteira global é insuficiente. Cada conta precisa da sua própria capacidade utilizável antes da execução. A reserva deve incluir os encargos adequados e qualquer margem adicional de recuperação escolhida pelo operador. Essa margem é uma política de controlo, não parte do lucro projetado a menos que seja efetivamente gasta.
Ao nível da carteira, reserve a exposição relevante ao evento bem como o dinheiro. Vários pares candidatos podem depender todos do mesmo evento ou da mesma plataforma da segunda componente. Permitir que cada caso reserve fundos independentemente sem verificar limites partilhados pode criar uma acumulação excessiva de primeiras componentes inacabadas. Um serviço comum de risco ou outro método consistente de coordenação tem de impedir que esses casos reclamem a mesma capacidade restante.
As reservas devem persistir durante a incerteza. Uma ordem rejeitada com confirmação fidedigna pode libertar o montante não usado. Uma ordem cuja resposta falta não pode. Um reinício do processo deve recarregar reservas por resolver antes de aceitar novos casos. Caso contrário, o programa pode parecer ter um orçamento novo enquanto as contas ainda contêm compromissos criados durante a sessão anterior.
Escolha deliberadamente uma sequência de execução
Enviar ambas as componentes quase ao mesmo tempo reduz algum atraso de sequência, mas não garante aceitação ou execução simultâneas. Enviar uma componente primeiro pode simplificar a coordenação, mas cria um período de exposição direcional conhecida. Um sistema deve escolher a sequência com base na liquidez observada, no comportamento da plataforma e na exposição permitida da conta, e depois avaliar os resultados dessa escolha em vez de a tratar como um pormenor de implementação.
Uma tentação comum é executar primeiro a componente mais difícil. Isso pode ser razoável para um processo testado, mas continua a precisar de uma resposta definida se a componente mais fácil desaparecer. Outra abordagem usa uma ordem em espera no livro para um lado e reage às suas execuções. Isto pode melhorar um preço cotado de entrada aumentando a probabilidade de o preço complementar mudar antes da resposta. A medida relevante é a combinação concluída e os seus casos inacabados.
Instruções de execução de uma única ordem não criam uma transação entre plataformas. Por exemplo, uma instrução de tudo ou nada pode restringir uma componente numa plataforma que a suporte, mas não força outra plataforma a executar a ordem correspondente. A documentação da Polymarket sobre o ciclo de vida das ordens descreve vários comportamentos de ordens individuais. O bot tem de verificar o comportamento efetivamente suportado para cada componente e evitar estender uma garantia local ao par inteiro.
Documente a sequência escolhida no registo do caso. Registe quando cada autorização foi criada, quando cada pedido foi enviado e que informação estava disponível antes do segundo envio. Estas provas permitem comparar mais tarde políticas de sequenciação. Sem elas, um par bem-sucedido pode ocultar a mesma fragilidade temporal que causa uma execução parcial dispendiosa no caso seguinte.
Acompanhe quantidades em cada fase
Para cada componente, distinga quantidades pedidas, aceites, executadas, canceladas e ainda incertas. Estes números respondem a perguntas diferentes. A quantidade pedida expressa intenção. A quantidade executada estabelece uma posição. A quantidade aberta ainda pode aumentar essa posição. A quantidade incerta representa exposição que o sistema local ainda não resolveu. Combiná-las numa única percentagem concluída pode esconder a direção e a dimensão do risco restante.
Uma quantidade emparelhada é o montante para o qual as posições necessárias foram efetivamente adquiridas em proporções compatíveis. No exemplo simples de um para um, se A tiver 500 executadas e B tiver 300, a quantidade emparelhada é 300 e a quantidade de A sem correspondência é 200. Se um pagamento mais complexo exigir uma proporção diferente, o cálculo de correspondência tem de seguir essa proporção revista em vez de presumir igualdade.
Mantenha o cálculo de quantidades independente dos saldos de caixa. Uma mudança de saldo pode incluir comissões, transferências ou negociações sem relação, pelo que é um mau substituto de registos de execuções. Guarde o identificador, lado, quantidade e preço de cada execução e elimine a duplicação de entregas repetidas da mesma execução. Um evento reproduzido deve confirmar informação existente em vez de criar uma segunda entrada de posição.
O guia anterior de um bot de arbitragem Kalshi pode ajudar a enquadrar registos do lado da conta para uma implementação específica de plataforma. A regra geral é que a conclusão do par tem de ser derivada das quantidades efetivas das componentes. Uma cotação combinada positiva, um lote enviado ou dois pedidos reconhecidos não conseguem estabelecer por si só a posição concluída.
As execuções parciais do bot de arbitragem de contratos de eventos criam uma nova decisão
Continue o exemplo fictício com todas as 500 unidades de A executadas a 0,37 $, mas apenas 300 unidades de B executadas a 0,60 $. Os montantes de compra são 185 $ e 180 $, totalizando 365 $ antes de encargos. Trezentas unidades formam pares completos, custando 291 $ antes de encargos. As restantes 200 unidades de A custam 74 $ e têm exposição direcional. O resultado líquido projetado original de 8 $ para 500 pares completos já não descreve este estado da conta.
O bot deve deixar de avaliar o caso apenas pela pontuação original da oportunidade. Precisa agora de uma decisão de recuperação usando cotações atuais e limites explícitos. Podem ser adquiridas outras 200 unidades de B dentro de um custo total autorizado? Podem as unidades de A sem correspondência ser vendidas dentro de uma perda permitida? É permitida a retenção temporária e durante quanto tempo? Cada opção deve usar a posição efetiva existente e quantidades executáveis atuais.
Suponha que a regra escrita do operador permite reduzir A sem correspondência a uma oferta de compra não inferior a 0,34 $ depois de se confirmar o cancelamento da ordem restante de B. Vender 200 unidades de A a esse preço produz 68 $. A conta detém depois 300 pares completos, que pagam 300 $ segundo os pressupostos do exemplo. As receitas combinadas são de 368 $ face ao montante de compra de 365 $, restando 3 $ antes de encargos. Se os encargos totais efetivos deste percurso forem de 5 $, o resultado final é uma perda de 2 $.
Essa perda não demonstra que a aritmética de um par totalmente concluído de 492 $ estivesse errada. Mostra que a execução pretendida não ocorreu e que a recuperação teve um custo. O registo deve preservar ambos os cálculos. Avaliar apenas pares favoráveis concluídos e excluir casos parciais recuperados exageraria a utilidade da política de execução.
Recomende e ganhe USDC
Recomende e ganhe USDCO nosso programa de afiliados paga em tempo real.
Um envio sem resposta dentro do prazo tem de manter a sua identidade
Quando um pedido esgota o prazo de resposta, o bot sabe que a comunicação local falhou. Não sabe necessariamente se a plataforma aceitou a ordem. Passe a componente para um estado incerto, mantenha a sua reserva e consulte registos suportados de ordens e da conta. Use os identificadores originais de cliente ou plataforma quando disponíveis. Se esses registos não resolverem imediatamente a tentativa, a incerteza permanece parte do cálculo de exposição.
Não crie uma ordem nova apenas porque a quantidade desejada ainda não está visível na posição local. A ordem original pode estar em espera no livro, parcialmente executada ou à espera numa fase de processamento específica da plataforma. Uma segunda instrução pode duplicar a quantidade pretendida. Num sistema emparelhado, isto pode produzir uma componente executada em excesso mesmo depois de o outro lado estar concluído, transformando um caso nominalmente correspondente de novo em exposição direcional.
A recuperação do bot de arbitragem de contratos de eventos precisa de uma condição de escalamento. Após um período definido ou um erro específico, o sistema pode desativar novos casos na conta afetada e pedir revisão do operador. Esta é uma resposta de controlo a provas em falta, não uma declaração de que a plataforma perdeu a ordem. O registo deve indicar exatamente o que permanece desconhecido e que consultas ou instantâneos da conta foram examinados.
Quando a tentativa for finalmente resolvida, atualize o caso original em vez de o esconder atrás de um registo de substituição. Se foi rejeitada, liberte a reserva não usada. Se foi executada, incorpore as execuções e recalcule a quantidade emparelhada. Se permanecer aberta, decida se deve ser mantida ou cancelada usando o estado atual do caso. Todos os resultados devem preservar a ligação à autorização original.
O cancelamento e a substituição precisam do seu próprio limite
Cancelar uma ordem não inverte execuções que já aconteceram. Também não estabelece que nenhuma execução ocorreu enquanto o pedido de cancelamento seguia o seu percurso. O bot deve continuar a monitorizar a componente até ter provas fidedignas suficientes para determinar a quantidade final executada e a quantidade já incapaz de ser executada. Libertar a reserva completa imediatamente após enviar um cancelamento pode subestimar o compromisso da conta.
Uma ordem de substituição introduz um problema semelhante. Se a ordem antiga ainda puder estar ativa, enviar de novo a quantidade pretendida completa pode duplicar temporariamente o montante capaz de ser executado. O executor precisa de uma política documentada de substituição consistente com o comportamento efetivo da plataforma. Essa política pode exigir confirmação antes da substituição ou reservar recursos para qualquer sobreposição suportada. Nunca deve apoiar-se no facto de a interface local esconder a ordem antiga como prova de que a plataforma a removeu.
No exemplo de 500 versus 300, suponha que outras 40 unidades de B são executadas durante o cancelamento. A quantidade emparelhada passa a 340 e A sem correspondência desce para 160. Uma venda de recuperação de 200 unidades de A baseada no instantâneo anterior corrigiria o caso em excesso, deixando exposição excedente a B. A decisão de recuperação tem, por isso, de usar um estado conciliado de quantidades ou considerar explicitamente a incerteza restante.
O artigo relacionado sobre um bot de negociação em mercados de eventos examina interrupções e mudanças programadas de forma mais ampla. A execução emparelhada acrescenta um requisito específico: uma ação de controlo numa componente pode mudar o que deve acontecer na outra. O sistema tem de coordenar essas atualizações através do estado partilhado do caso em vez de deixar cada componente operar como um programa de negociação sem relação.
Preserve um orçamento de recuperação sem perseguir a conclusão
Um orçamento de recuperação define quanto custo ou perda adicional o sistema pode aceitar para reduzir uma exposição inacabada. Deve ser distinto do limiar de entrada original. A conta pode aceitar racionalmente uma perda limitada após uma execução parcial para evitar manter um risco de evento maior, mas essa permissão deve ser explícita. Caso contrário, um bot pode justificar quase qualquer preço alegando que está a concluir uma arbitragem.
Defina o orçamento em termos que o operador possa rever: custo máximo de aquisição sem correspondência, custo adicional máximo de conclusão, perda máxima permitida de redução e condições que exigem juízo humano. Um teto de preço para a segunda componente pode ser recalculado a partir do custo efetivo da primeira e do resultado permitido. O cálculo deve incluir encargos efetivos já incorridos e estimativas conservadoras para a ação restante.
Um orçamento não é uma instrução para gastar a margem inteira. Compare alternativas disponíveis usando quantidades executáveis atuais. Se o cancelamento e uma pequena redução restaurarem uma posição aceitável, o sistema não precisa de forçar a conclusão da dimensão original. Se nenhuma alternativa respeitar os limites aprovados, faça uma pausa e exponha claramente a posição por resolver. O risco restante da conta deve ser visível mesmo quando o bot não o consegue resolver automaticamente.
A discussão anterior sobre um bot de arbitragem automatizada Polymarket oferece contexto para esta separação entre deteção e ação controlada. A lógica de recuperação merece o seu próprio conjunto de dados de avaliação porque é invocada em condições diferentes das de uma entrada habitual. O comportamento que funciona em instantâneos calmos pode falhar quando a liquidez desaparece precisamente no momento em que a primeira componente é executada.
O inventário pode acumular-se entre vários casos
Um bot pode operar muitos pares ao mesmo tempo, mas a conta experiencia o inventário combinado. Dois casos inacabados podem deixar exposição ao mesmo resultado mesmo quando os identificadores dos pares diferem. Agregue posições e compromissos abertos por evento e por cenário adverso relevante. Não pressuponha que registos separados de casos criam limites independentes de risco.
Um criador de mercado de contratos de eventos usa inventário para moldar decisões posteriores de cotação. Um bot emparelhado beneficia da mesma consciência quando componentes inacabadas permanecem na conta. Novos casos podem reduzir um desequilíbrio existente, aumentá-lo ou criar uma exposição diferente sob resultados excecionais. O controlo de risco deve avaliar a carteira resultante em vez de tratar cada par proposto como automaticamente neutro.
Se o bot também participar em criação de mercado de contratos de eventos, as suas cotações em espera pertencem ao mesmo modelo de exposição. Uma cotação criada para fornecer liquidez pode ser executada enquanto o motor de arbitragem reserva capacidade para uma segunda componente. Orçamentos separados que se ignoram podem ambos passar localmente e falhar ao nível da conta. Reservas partilhadas e conciliação consistente são necessárias mesmo quando as estratégias têm objetivos diferentes.
A conciliação periódica deve comparar o modelo local combinado com posições, ordens e encargos fidedignos. Um caso só pode ser marcado como operacionalmente encerrado quando as suas ordens estão resolvidas e a posição restante está corretamente atribuída. Se uma posição residual deliberada for transferida para outra estratégia, registe essa transferência de responsabilidade. Remover o caso de um ecrã não deve remover o seu risco do registo.
Teste os casos que mudariam a decisão
Use reproduções de incidentes que exercitem coordenação, não apenas envio bem-sucedido de ordens. Um teste deve aceitar A e rejeitar B. Outro deve executar parcialmente B durante um cancelamento. Um terceiro deve entregar a mesma execução duas vezes. Um quarto deve reiniciar o processo depois de um pedido enviado mas antes de a resposta ser registada. O resultado esperado deve especificar quantidades, reservas, próximas ações permitidas e qualquer pausa necessária.
Para o caso trabalhado de execução parcial, verifique a aritmética independentemente: 365 $ gastos, 68 $ recuperados pela redução de 200 unidades de A sem correspondência, 300 $ recebidos dos pares compatíveis restantes e 5 $ de encargos efetivos pressupostos produzem uma perda de 2 $. O teste não deve identificar o caso como um par rentável de 500 unidades apenas porque essa era a recomendação original. Deve preservar a razão pela qual o resultado difere do plano.
Teste também a decisão de não começar. Rejeite um par com regras incompatíveis, fundos locais insuficientes, profundidade desatualizada ou estado de conta por resolver. Estas recusas fazem parte do comportamento pretendido do bot. Um sistema que passa apenas testes de execução ativa pode continuar inseguro porque nunca demonstrou respeitar as condições em que a execução deve ser suspensa.
A revisão final deve conseguir reconstruir cada caso desde a relação aprovada entre pagamentos até ao resultado conciliado da conta. Um bot de componentes emparelhadas é útil quando torna explícitas combinações incompletas, limita as suas consequências e preserva provas suficientes para explicar a recuperação. Esse é o padrão prático de automação num processo em que dois preços atrativos não garantem duas negociações concluídas.