Software de arbitragem da Kalshi: concilie cada componente

Especifique o conjunto e a conta inicial

O conjunto fictício contém 100 unidades de cada um dos resultados Amber, Blue e Copper. Exatamente um resultado tem de ganhar segundo as regras estipuladas, pelo que um conjunto concluído de quantidades iguais tem um pagamento normal de 100 $. A conta inicial não tem posições relacionadas e dispõe de capital permitido suficiente para as instruções definidas. Estes pressupostos devem aparecer no registo de teste, em vez de permanecerem implícitos.

Identifique cada mercado e direção separadamente. Os nomes ajudam uma pessoa a ler o exemplo, mas identificadores estáveis determinam o que o software submete e concilia. O mapeamento deve ligar as regras analisadas dos contratos ao instrumento exato usado em cada ordem. Uma descrição geral correta não protege a conta se um identificador apontar para um evento vizinho.

Indique também o custo máximo de compra permitido e qualquer montante de recuperação autorizado. A auditoria deve saber que ações foram autorizadas antes de avaliar se o software as seguiu. Se a ferramenta inventar uma ordem de conclusão maior depois de uma execução parcial, um resultado final favorável não estabelece que respeitou a permissão original.

O guia anterior de um bot de arbitragem de contratos de eventos descreve responsabilidades de reserva e conciliação. Este ensaio transforma-as em provas observáveis: que compromisso existia, que registo o provou e quando a aplicação tinha justificação para alterar a capacidade disponível da conta.

A conciliação começa com execuções únicas

Suponha que Amber executa 100 unidades a 0,22 $, por 22 $, e Blue executa 100 a 0,31 $, por 31 $. Copper executa apenas 60 a 0,42 $, por 25,20 $. A despesa total de compra é de 78,20 $ antes de encargos. Pressuponha encargos de aquisição confirmados de 1,80 $ nesta etapa, dando um custo total de 80 $.

A conta tem 60 conjuntos completos de três resultados, mais 40 unidades Amber e 40 Blue excedentárias. Uma vitória de Amber ou Blue paga 100 $; uma vitória de Copper paga 60 $. Face ao montante completo de 80 $, esses ramos normais produzem um ganho de 20 $ ou uma perda de 20 $. Esta é a exposição atual correta sob os pressupostos indicados.

O software deve preservar as identidades individuais das execuções e calcular quantidades a partir de execuções únicas. Repetir a notificação da execução de Copper não pode transformar 60 em 120. Se a ferramenta eliminar duplicados apenas por carimbo temporal ou preço, execuções distintas podem ser fundidas ou uma repetida pode ser contada duas vezes. Identidades estáveis da plataforma e significados documentados de sequência são as provas relevantes.

O artigo relacionado de negociação lucrativa na Kalshi explica por que os resultados da conta têm de ser separados das previsões. Aqui, a mesma distinção aplica-se dentro da transação: um conjunto pretendido aparentemente lucrativo não descreve uma conta cujo resultado mais fraco paga atualmente apenas 60 $.

Teste aceitação de ordem sem execução

Forneça uma resposta de ordem aceite para a quantidade Copper restante sem uma execução confirmada. A aplicação deve registar a instrução aceite e o seu compromisso possível, mas não deve aumentar as quantidades detidas apenas porque a resposta foi bem-sucedida. Uma ordem em espera e uma posição executada têm consequências financeiras diferentes.

Forneça depois uma rejeição. A ferramenta deve conservar a tentativa rejeitada e a razão, deixando inalteradas as quantidades efetivamente detidas. Só pode libertar uma reserva na medida em que a resposta de referência fidedigna estabeleça que não resta compromisso. Uma mensagem local de erro com resultado externo incerto é um caso diferente e não deve usar a mesma regra de libertação.

Esta distinção deve ser visível na interface. Um revisor deve conseguir ver quantidade pretendida, quantidade confirmada e quantidade adicional possível sem abrir registos brutos. Se as três forem incorporadas numa percentagem de progresso, o operador pode confundir um plano aceite com uma posição concluída.

O guia anterior da API de bots da Kalshi fornece contexto para interpretar interfaces efetivas da conta. A auditoria deve usar os estados e registos documentados do produto atual, em vez de pressupor que um campo familiar de sucesso tem o mesmo significado em todos os endpoints ou versões de software.

Saldos cancelados precisam de uma quantidade final

Suponha que a primeira ordem Copper era de 100 unidades e que o remanescente de 40 unidades é cancelado após a execução de 60. O registo final da ordem deve mostrar 60 executadas e 40 canceladas sob os pressupostos do teste. A conta continua a deter as 60 unidades adquiridas; o cancelamento não desfaz a compra concluída nem devolve o seu custo.

Execute um ramo separado de corrida com o cancelamento, em que mais dez unidades Copper são executadas antes de o cancelamento produzir efeitos. A quantidade final detida torna-se 70 e o remanescente cancelado torna-se 30. O software deve atualizar o custo usando a execução tardia efetiva e não deve preservar a expectativa anterior de 60 unidades apenas porque o botão local de cancelar foi premido primeiro.

A comunicação atrasada de uma execução anterior é diferente de uma nova execução depois de uma ordem estar definitivamente cancelada. O registo contabilístico deve preservar a hora de execução e a hora de receção quando disponíveis. Isto permite ao avaliador explicar por que um registo acabado de receber pode legitimamente alterar uma posição, embora a ordem externa já não esteja ativa.

O teste deve também distinguir uma ordem imediata de execução parcial cujo saldo não executado cancela automaticamente de uma ordem persistente em espera. Tratar ambas como quantidade restante ativa pode distorcer reservas e desencadear recuperação inadequada. A ação seguinte correta segue a validade efetiva da ordem e o resultado de referência fidedigno.

Uma tentativa desconhecida deve sobreviver a um reinício

Simule agora um pedido de conclusão cuja resposta se perde. O pedido pode ter falhado antes de chegar à plataforma, criado uma ordem ativa ou sido executado. O software deve preservar a identidade da tentativa e a exposição máxima possível enquanto investiga. Uma nova ordem independente não é uma repetição inofensiva quando a primeira tentativa já pode existir.

Reinicie a aplicação durante esta incerteza. O seu estado recuperado deve conservar a tentativa por resolver antes de aceitar novas recomendações que afetem a conta. Se o reinício apagar a incerteza apenas por apagar a memória local, a conta pode exceder a quantidade pretendida enquanto o painel parece ordenado.

Uma visão útil de recuperação identifica a tentativa original, os registos verificados e as possibilidades restantes. Deve explicar se a conta ainda pode receber execuções e que capacidade continua reservada. Uma faixa genérica de erro de ligação não fornece informação suficiente para autorizar outra componente de forma responsável.

O artigo anterior de automatização de negociação em mercados de previsão aborda a sincronização como responsabilidade da conta. Numa auditoria de arbitragem, essa responsabilidade é especialmente visível porque uma componente desconhecida pode alterar o pagamento mínimo de todo o conjunto.

Mantenha as convenções atuais dos campos no adaptador

Uma auditoria deve incluir quantidades fracionárias e precisão de preço suportadas pelo mercado efetivo. Não deve pressupor que todos os montantes chegam como cêntimos inteiros ou contratos inteiros. Preserve valores brutos e unidades documentadas para um revisor distinguir erros de análise de ajustes genuínos da conta.

A documentação da Kalshi sobre ponto fixo descreve as representações atuais de preços e quantidades. A aplicação deve validar os incrementos permitidos do mercado e conservar precisão suficiente para conciliação. Um ecrã pode arredondar para facilitar a leitura enquanto o registo contabilístico subjacente preserva os montantes efetivos usados pela plataforma.

A direção também exige a convenção atual da interface. Um preço canónico de ordem ou execução não deve ser complementado apenas porque a direção é Não, e uma resposta do livro deve ser interpretada segundo a sua escala documentada. O adaptador deve expor que representação recebeu e que representação normalizada usa o resto do sistema.

Um exemplo prático de aceitação fornece um registo bruto conhecido e pede o seu significado económico por palavras: que exposição a resultado mudou, em quanto e com que efeito efetivo no dinheiro? Passar um validador de esquema não basta se os valores foram interpretados no lado ou na escala de unidades errados.

Concilie uma conclusão que altera a estimativa original

Volte ao ramo com 60 unidades Copper e um remanescente confirmado como cancelado. Uma conclusão recentemente autorizada adquire as 40 em falta a 0,46 $, custando 18,40 $. A despesa total de compra torna-se 96,60 $. Pressuponha que os encargos confirmados de toda a sequência totalizam 2,40 $, pelo que o montante completo é de 99 $.

A conta detém agora 100 unidades de cada resultado. Sob a estrutura normal estipulada, o pagamento final é de 100 $, independentemente de qual dos três ganha, produzindo um resultado líquido de 1 $. Esse número resulta de execuções e encargos efetivos. Não deve substituir no histórico nem a estimativa original do candidato nem os cenários residuais anteriores; cada um descreve uma etapa diferente.

A aplicação deve atribuir as alterações. As últimas 40 unidades Copper custaram mais do que o preço inicialmente apresentado, e os encargos totais aumentaram após a conclusão. Uma explicação útil liga esses factos à diferença concluída menor, em vez de apresentar um montante inexplicado de desvio de execução que combina causas sem relação.

O artigo relacionado de negociação lucrativa na Polymarket examina registos de desempenho noutro contexto de conta. O princípio contabilístico transfere-se: só o percurso executado pertence ao resultado realizado, enquanto alternativas consideradas e estimativas preliminares permanecem provas separadas sobre a decisão.

As provas de liquidação têm de corresponder à posição

Um resultado real conhecido não é, por si só, uma conciliação concluída da conta. A aplicação deve ligar a determinação oficial do mercado à posição efetiva restante e ao pagamento creditado. Deve preservar um estado pendente quando o resultado é conhecido, mas os registos relevantes da conta ainda não chegaram.

A referência da Kalshi sobre liquidação descreve a liquidação de posições líquidas e assinala que o momento pode depender do mercado e do processo da fonte. Uma auditoria deve inspecionar a representação efetiva da conta, em vez de pressupor que todos os direitos conceptuais aparecem como saldos independentes de tokens ou seguem mecanismos de conversão de outra plataforma.

Para o conjunto fictício concluído, o recebimento normal esperado é de 100 $. Se a exportação mostrar apenas 60 $, investigue se algumas quantidades foram vendidas, uma execução foi omitida, o conjunto nunca foi concluído ou os registos de liquidação ainda estão incompletos. Não force o registo contabilístico a 100 $ apenas porque a estratégia pretendia esse pagamento.

A liquidação excecional precisa do seu próprio teste suportado quando aplicável. Uma ferramenta avaliada apenas em casos de um dólar ou zero não deve alegar que concilia todas as famílias possíveis de contratos. O âmbito operacional pode excluir percursos excecionais não testados até os registos e cálculos necessários terem sido verificados.

Trate uma saída parcial como ação separada da conta

Um conjunto pode mudar depois da aquisição. Suponha que, num ramo fictício separado, a conta vende 20 unidades Amber antes da liquidação. As quantidades resultantes são 80 Amber, 100 Blue e 100 Copper. O mínimo normal de pagamento torna-se 80 $, enquanto a venda cria as suas próprias receitas e encargos. A afirmação original de pagamento de quantidades iguais já não descreve a posição restante.

O software deve ligar a redução a execuções efetivas de venda, não apenas diminuir o total de uma posição. Um revisor precisa de ver por que a quantidade mudou e para onde foi o dinheiro correspondente. Sem essa ligação, um ajuste manual inexplicado pode parecer uma saída legítima e esconder um erro de ingestão ou mapeamento.

O resultado económico concluído deve combinar receitas líquidas efetivas de venda com o pagamento posterior e todos os custos de aquisição. Não deve contar novamente as unidades vendidas na liquidação. Este é um caso de auditoria particularmente útil porque um painel pode mostrar a quantidade final correta enquanto uma calculadora separada de desempenho continua a usar a quantidade originalmente pretendida.

Mantenha este ramo separado do exemplo sem saída. Misturar passos de cenários alternativos pode tornar cálculos individualmente corretos inconsistentes como narrativa. Um registo de teste bem concebido identifica o ramo e preserva que ações ocorreram efetivamente nele.

O histórico de auditoria deve explicar os ajustes

Ajustes tardios de comissões, execuções corrigidas ou mapeamentos manuais devem ter registos rastreáveis. A aplicação pode atualizar um total derivado, mas a auditoria deve preservar a razão, a fonte e a hora da alteração. Um registo contabilístico final que reescreva silenciosamente entradas anteriores não pode explicar o que o operador sabia quando tomou uma decisão.

Suponha que o resultado líquido fictício de 1 $ é seguido de um encargo adicional confirmado de 0,20 $. O resultado corrigido torna-se 0,80 $. O relatório da conta deve identificar o novo encargo e o seu efeito. Não deve reclassificar o valor original de 1 $ como erro se esse valor refletia corretamente os registos disponíveis antes do ajuste.

O mesmo princípio aplica-se a um duplicado descoberto. Remova o seu efeito das quantidades derivadas, conservando provas de que a mensagem duplicada ocorreu e de como foi identificada. Isto ajuda a distinguir um problema de entrega de dados de um problema de execução na plataforma e impede que o mesmo erro reapareça depois de uma reprodução.

Um fluxo de correção deve exigir provas adequadas à alteração. Editar manualmente uma quantidade até coincidir com o total esperado da estratégia não é conciliação. O total esperado é uma hipótese a investigar; os registos de referência fidedignos da conta estabelecem o que a conta efetivamente fez.

Exporte provas suficientes para reconstrução independente

O avaliador deve conseguir reproduzir a sequência resolvida a partir de uma exportação com identidades dos contratos, autorizações, tentativas de ordem, identidades únicas de execução, quantidades, preços, encargos e registos de liquidação. Cada linha precisa de um tipo e estado claros. Uma única coluna de transação que misture planos, execuções e pagamentos convida à dupla contagem acidental.

Verifique primeiro a sequência parcial de 100, 100 e 60: 78,20 $ de compras, 1,80 $ de encargos e o intervalo correto de pagamentos dependentes do resultado. Acrescente depois a conclusão de 40 unidades e verifique 96,60 $ de compras, 2,40 $ de encargos totais e um pagamento normal de 100 $. Estas respostas conhecidas facilitam localizar omissões ou registos duplicados.

Preserve a precisão e defina campos que incluem comissões. Se um custo exportado já inclui encargos, outro revisor não deve ter de adivinhar se precisa de os acrescentar novamente. Do mesmo modo, a mesma execução comunicada por duas interfaces deve conservar uma identidade de execução, em vez de aparecer como duas linhas de atividade sem relação.

O guia relacionado sobre como ganhar dinheiro na Polymarket aborda por que rendimento aparente pode desaparecer sob contabilidade completa. Nesta auditoria, o requisito prático é mais restrito: a exportação tem de sustentar o mesmo resultado líquido que a aplicação apresenta, com uma explicação clara de todas as diferenças face ao plano original.

Teste recusa e funcionamento apenas de leitura

Uma auditoria de software deve incluir candidatos que não podem ser autorizados. Forneça um com mapeamento de contrato em falta, outro com profundidade desatualizada e um terceiro que exceda a capacidade restante da conta depois dos compromissos abertos. O resultado esperado é uma recusa específica sem nova tentativa externa de ordem. Uma diferença apresentada atrativa não deve contornar essas condições.

Teste também a ferramenta apenas com permissão de investigação. Pode classificar candidatos e estimar custos dentro do acesso a dados suportado, mas não deve sugerir execução ou lucro concluído. Uma simulação deve continuar visivelmente distinta de um registo da conta. A falta de autoridade para negociar é um âmbito operacional definido, não uma razão para fabricar execuções bem-sucedidas.

Inspecione os diagnósticos em busca de credenciais. O avaliador precisa de identificadores, carimbos temporais e provas, não de segredos capazes de alterar a conta. Uma exportação ou um relatório de erro deve apoiar a revisão sem conceder nova permissão de negociação. Este é um critério prático de qualidade quando várias pessoas precisam de inspecionar o mesmo ensaio.

Uma recusa deve explicar como a condição pode ser resolvida quando adequado. Uma cotação desatualizada precisa de nova observação; um contrato não suportado precisa de um mapeamento analisado; capacidade insuficiente precisa de uma decisão sobre a conta. Um botão genérico para repetir não pode tratar responsavelmente estas falhas diferentes como a mesma interrupção temporária.

Defina o âmbito aceite a partir dos resultados

No fim do ensaio, indique que estruturas de contratos, percursos de ordens e casos de liquidação foram efetivamente avaliados. Uma ferramenta que trate corretamente a sequência fictícia de três resultados pode ainda não suportar outro produto, liquidação excecional ou ambiente de conta. A decisão de aceitação deve ser suficientemente específica para impedir que essas provas sejam estendidas a uma afirmação universal.

Registe constatações por resolver pela sua consequência financeira. Uma verificação de duplicados em falta pode exagerar quantidades detidas. Um registo fraco de cancelamento pode representar mal o capital disponível. Uma exportação de liquidação incompleta pode impedir a revisão do desempenho. Estes efeitos concretos são mais úteis do que uma classificação ampla que esconde o que o operador ainda tem de tratar manualmente.

O software de arbitragem da Kalshi pode ser revisto quando a história da conta permanece coerente em todas as transições. O conjunto autorizado torna-se tentativas distintas, as tentativas produzem execuções únicas, as execuções produzem posições efetivas e a liquidação produz dinheiro verificado. Uma auditoria que siga essa cadeia dá ao utilizador uma base concreta para limitar o papel da ferramenta e confiar apenas nos resultados que as suas provas podem sustentar.