Um algoritmo de negociação na Polymarket deve ser suficientemente específico para que dois revisores consigam aplicar as suas regras às mesmas provas e compreender por que agiu ou se absteve. Uma frase como comprar resultados subavaliados descreve uma aspiração. Não identifica a informação, a previsão, o preço, a quantidade ou as condições da conta que produzem uma decisão.
Este guia desenvolve um algoritmo hipotético para fins de investigação. Diz respeito a uma família fictícia de votações agendadas de nomeação e pergunta se uma atualização pública específica do procedimento acrescenta informação útil. O exemplo é deliberadamente restrito para que as suas alegações possam ser testadas. Não é uma estratégia demonstrada nem uma recomendação para negociar esses eventos.
O contexto da plataforma é a Polymarket International, com a Polymarket US tratada separadamente. Todas as probabilidades, quantidades, preços, comissões e limiares abaixo são inventados. Pressupõem-se pagamentos simples de 1 $ ou 0 $ para a aritmética. Regras efetivas dos mercados, restrições atuais de negociação e autorização da conta regeriam qualquer implementação real.
Comece o algoritmo de negociação na Polymarket com uma hipótese
A hipótese informativa refutável é que uma atualização especificada do procedimento melhora previsões da aprovação final de uma nomeação num horizonte definido, para além de uma referência simples que utiliza informação já disponível. A alegação pode falhar se a atualização não acrescentar valor preditivo, chegar demasiado tarde ou disser respeito a uma condição diferente do resultado do contrato.
Defina precisamente a atualização. Neste contexto inventado, é a publicação de uma ordem de trabalhos finalizada da votação que inclui a nomeação indicada. Um rumor sobre a ordem de trabalhos ou uma republicação inalterada não são elegíveis. O algoritmo estuda se esse facto processual altera a probabilidade de aprovação; não pressupõe que inclusão garante sucesso.
O guia anterior de estratégia de negociação na Polymarket explica por que uma estratégia precisa de uma hipótese efetiva de vantagem. Uma especificação de algoritmo da Polymarket deve conservar essa hipótese para que revisões posteriores possam ser avaliadas face à pergunta original de investigação, em vez de redefinir retroativamente sucesso depois de ver resultados.
Defina a família elegível de contratos
O universo de investigação deve conter contratos com uma definição consistente de resultado e horizonte. Para a família inventada de nomeações, Sim exige uma aprovação final registada pelo órgão nomeado antes de um prazo especificado. Contratos sobre proposta de nomeação, recomendação de comissão ou tomada de posse são excluídos.
Registe as regras e a fonte exatas de cada contrato elegível. Títulos semelhantes são insuficientes. Se um contrato contar uma reconsideração posterior enquanto outro não, a diferença pode exigir exclusão ou um modelo separado. A alegação restrita do algoritmo depende de comparar resultados equivalentes.
A elegibilidade é decidida antes de inspecionar o resultado final. Caso contrário, a investigação pode remover discretamente casos difíceis que enfraquecem o desempenho aparente. Preserve contratos rejeitados e os seus motivos, incluindo regras ambíguas, fontes indisponíveis e estruturas de eventos não suportadas. Este registo explica o domínio em que a alegação do algoritmo está efetivamente a ser avaliada.
Fixe o horizonte de decisão
O algoritmo hipotético avalia a primeira atualização verificada da ordem de trabalhos dentro de uma janela definida de investigação anterior à votação. Regista a hora efetiva de receção e conclui a sua previsão antes de inspecionar uma nova cotação executável para a decisão. O horizonte faz parte da especificação, não é uma escolha feita depois de observar movimentos de preços.
Uma atualização posterior pode ser mais fácil de interpretar, mas deixar menos oportunidade. Um teste histórico tem de utilizar o momento em que o processo poderia efetivamente agir, incluindo atraso de recolha e cálculo. Não pode combinar provas tardias com um preço anterior que existia antes de as provas serem recebidas.
Escolha uma idade máxima para a proposta e identifique o que a faz expirar. Uma ordem de trabalhos alterada, uma nova declaração oficial ou um prazo de decisão ultrapassado podem invalidar a proposta antiga. O programa deve então produzir uma nova versão de investigação ou abster-se, em vez de continuar a submeter uma instrução cuja base informativa já não se aplica.
Preserve dados de entrada antes de prever
O registo dos dados de entrada deve identificar documento, versão, hora de publicação se conhecida, hora de receção e campos processuais extraídos. Deve distinguir o facto da fonte da interpretação acrescentada pelo algoritmo. A conclusão bem-sucedida de um analisador não prova que selecionou a nomeação ou versão correta da ordem de trabalhos.
Para cada atualização aceite, preserve provas suficientes para um revisor reproduzir a classificação. Se um campo obrigatório estiver em falta ou for ambíguo, o algoritmo deve devolver uma observação por resolver. Não deve preencher a lacuna com um valor provável apenas para manter ativo o ciclo de negociação.
O registo dos dados de entrada também apoia avaliação posterior de mudanças da fonte. Se a autoridade mudar a estrutura dos documentos, o comportamento histórico do modelo pode já não se aplicar. Um registo preciso permite identificar essa quebra, em vez de atribuir uma falha de análise a uma mudança súbita das probabilidades dos eventos.
Defina a previsão e a sua referência
O algoritmo precisa de uma probabilidade estimada para o resultado exato do contrato, não apenas de uma pontuação de que a linguagem da ordem de trabalhos parece favorável. Desenvolva a correspondência utilizando uma amostra histórica apropriada e depois avalie-a em eventos posteriores que não foram utilizados para escolher a regra.
A referência deve utilizar informação disponível no mesmo horizonte. Pode ser uma frequência histórica simples ou uma estimativa especificada do mercado, consoante a pergunta de investigação. Preserve a referência antes de comparar resultados para que a avaliação não selecione depois um adversário fácil.
Para os dados numéricos de teste abaixo, pressuponha que o modelo produz uma probabilidade central de 0,61 e um cenário de tensão de 0,56. São dados inventados para verificar a aritmética da decisão, não estimativas empíricas. O valor de tensão não é um limite estatístico de confiança, salvo se um procedimento separado validado o estabelecer como tal.
Defina a margem de custos antes de olhar para resultados
A regra hipotética exige que a probabilidade do cenário de tensão exceda o custo total máximo pressuposto por unidade em pelo menos 0,04 $ para o pagamento simples de um dólar. É um limiar escolhido de investigação, não prova de que uma margem de quatro cêntimos compensa todas as incertezas.
Suponha que o preço máximo de compra é de 0,51 $ e a margem de comissões é de 0,01 $ por unidade. O custo total máximo pressuposto é de 0,52 $. Com uma probabilidade de tensão de 0,56, a margem modelada é de 0,04 $ por unidade, cumprindo exatamente a regra inventada.
Registe por que o limiar foi escolhido e avalie a sua sensibilidade sem selecionar o melhor valor na amostra final de teste. Se a regra só parecer útil numa margem finamente ajustada, essa fragilidade merece atenção. Um algoritmo transparente deve expor a contrapartida entre seleção mais rigorosa, menos oportunidades e incerteza da previsão.
Leia o livro depois de a previsão estar pronta
A comparação executável deve utilizar uma observação do livro disponível depois de a previsão e as verificações de autorização poderem ocorrer. Preserve ofertas de compra e venda, profundidade e hora de receção. Um ponto médio apresentado não é o custo de compra para a quantidade pretendida.
A documentação do livro de ordens da Polymarket explica a distinção entre preços apresentados e lados executáveis. Para os dados inventados de teste, pressuponha que são oferecidas dez unidades a 0,48 $ e quinze a 0,50 $. Vinte e cinco unidades estão visíveis dentro do limite de 0,51 $, mas os limites da conta determinarão a dimensão efetiva da proposta.
Se o livro estiver desatualizado, incompleto ou mudar antes da submissão, aplique a regra especificada de revalidação. O algoritmo não deve utilizar uma cotação antiga favorável como motivo para alargar o seu limite. Um preço novo pode remover a oportunidade modelada mesmo quando a previsão do evento não muda.
Combine consistentemente as restrições de quantidade
A quantidade proposta deve satisfazer todas as restrições aplicáveis. Na conta inventada, o limite do evento é de quarenta unidades, com doze já detidas e oito possíveis de uma ordem ativa. Isto deixa espaço para vinte unidades adicionais. A profundidade visível de vinte e cinco unidades não se sobrepõe ao limite da conta.
O orçamento disponível de compromisso para a nova intenção é de 10,40 $. Ao custo máximo pressuposto de 0,52 $ por unidade, suporta vinte unidades. A profundidade, a capacidade do evento e o orçamento de custos permitem, portanto, uma proposta de vinte unidades nestes dados de teste.
Utilize unidades exatas e requisitos atuais do mercado ao implementar o cálculo. Uma quantidade fracionária permitida ou dimensão mínima de ordem podem afetar o resultado válido. O guia de ferramentas de negociação na Kalshi oferece uma comparação útil de responsabilidades de investigação e cálculo, enquanto as restrições efetivas das ordens têm de continuar específicas do mercado da Polymarket considerado.
Calcule o custo esperado dos dados de teste
Para vinte unidades, o livro observado fornece dez a 0,48 $ e dez a 0,50 $. O custo de compra é de 4,80 $ mais 5 $, ou 9,80 $ antes de comissões. Com a comissão pressuposta de um cêntimo por unidade, a estimativa total é de 10,00 $. O custo médio pressuposto é de 0,50 $.
Sob a probabilidade central de 0,61, o pagamento esperado modelado é vinte vezes 0,61 $, ou 12,20 $. A diferença esperada modelada é de 2,20 $. Sob o cenário de tensão de 0,56, o pagamento esperado é de 11,20 $, deixando 1,20 $ face à estimativa total observada.
A autorização continua a utilizar o compromisso máximo pressuposto de 10,40 $, não a estimativa observada inferior. Essa distinção preserva o limite de preço se o livro mudar dentro do limite aprovado. Todos estes cálculos dependem dos pressupostos hipotéticos de previsão e comissões; estabelecem consistência interna, não uma alegação de lucro realizado.
Especifique o comportamento do tempo de vida da ordem
O algoritmo de exemplo utiliza uma instrução imediata que aceita execução parcial e cancela o resto, sujeita ao comportamento documentado atual da plataforma e aos parâmetros permitidos. Não deixa uma nova ordem em espera depois da janela de decisão. Essa escolha faz parte da política de exposição do algoritmo.
A documentação do ciclo de vida das ordens da Polymarket identifica FAK como executar a quantidade disponível e cancelar o remanescente. Uma variante de ordem em espera seria uma especificação diferente porque poderia adquirir exposição depois de a observação e a previsão iniciais envelhecerem.
Registe o tipo efetivo com a intenção. Um revisor posterior deve conseguir determinar se quantidade não executada continuou a ser um compromisso. O algoritmo não deve inferir que cada execução parcial exige comprar mais tarde o montante em falta; uma compra posterior precisaria de uma nova proposta sob provas e estado atuais da conta.
Preserve o registo de aceitação da regra de decisão
O registo de aceitação da regra de decisão liga dados de entrada, previsão, livro, imagem da conta e autorização. Deve declarar que condições passaram e as condições exatas permitidas para sair do processo. Guarde-o de forma persistente antes de submeter uma ordem para que a recuperação não dependa de memória ou de um estado perdido do ecrã.
Um candidato rejeitado merece o mesmo registo estrutural com um motivo conciso. Exemplos incluem incompatibilidade contratual, dados desatualizados, margem inadequada, profundidade insuficiente ou capacidade esgotada. Estes motivos revelam se a hipótese produz oportunidades utilizáveis na prática.
O guia anterior de algoritmos de negociação em mercados de previsão explica conceção e testes ao longo destas etapas. Manter o registo de aceitação separado do resultado eventual impede que um resultado favorável valide retroativamente uma decisão que não satisfazia a regra na altura.
Concilie uma execução parcial
Suponha que a ordem imediata hipotética de vinte unidades executa oito a 0,48 $ e sete a 0,50 $. O custo de compra é de 3,84 $ mais 3,50 $, ou 7,34 $. Com uma comissão total pressuposta de 0,15 $, o custo total é de 7,49 $. Cinco unidades pedidas continuam não executadas e são canceladas sob o comportamento escolhido.
A conta detém agora vinte e sete unidades: as doze originais mais quinze adquiridas. A ordem ativa anterior de oito unidades continua um compromisso possível separado, elevando a exposição potencial ao evento para trinta e cinco unidades sob a política simples de quantidade. As cinco canceladas deste novo pedido não continuam ativas.
Uma confirmação de receção do pedido, por si só, é insuficiente para estabelecer esse estado final. O algoritmo deve acompanhar as provas relevantes de ordens e negociações e conciliar a conta. Se o resultado da submissão for desconhecido, conserve a reserva apropriada e investigue antes de considerar outro candidato para a mesma capacidade.
Declare a política de invalidação e saída
Uma regra de decisão precisa de um plano para o que acontece depois da entrada. O exemplo pode ser avaliado sob uma política de manter até à resolução, uma política de saída baseada em provas ou uma política de revisão temporal, mas essas escolhas não devem ser misturadas depois de os resultados serem conhecidos.
Para esta especificação de investigação, pressuponha uma revisão agendada sempre que a ordem de trabalhos oficial muda e nenhuma saída automática apenas porque o preço apresentado muda. A revisão verifica se a correspondência original com o contrato e os pressupostos da previsão continuam aplicáveis. Qualquer venda exige as suas próprias verificações de custo e autorização.
Uma avaliação hipotética acima do custo de entrada não garante uma saída realizável para toda a posição. A conta deve utilizar ofertas de compra disponíveis e custos aplicáveis ao avaliar uma venda. Igualmente, uma avaliação desfavorável não identifica, por si só, se a previsão, a execução ou a liquidez do mercado é responsável pela mudança.
Avalie previsões e ordens separadamente
A avaliação das previsões deve incluir cada estimativa elegível registada, incluindo candidatos rejeitados por preço ou capacidade. A avaliação da execução deve incluir ordens efetivas, execuções, comissões e casos por resolver. Estas populações sobrepõem-se, mas servem objetivos diferentes.
Um modelo pode melhorar a precisão da previsão sem produzir qualquer margem utilizável depois de custos. Um processo de execução pode seguir perfeitamente a regra enquanto a hipótese subjacente falha. Registos separados permitem ao investigador identificar que alegação precisa de revisão, em vez de tratar cada resultado como uma única medida de qualidade do algoritmo.
O guia de algoritmos de negociação na Kalshi desenvolve outro exemplo específico de plataforma de uma vantagem informativa refutável. O método transferível é preservar a hipótese e testá-la prospetivamente, mantendo distintas definições contratuais, convenções de preços e mecanismos da conta.
Divida a avaliação pelo evento subjacente
Contratos relacionados de um processo de nomeação devem ficar juntos ao separar dados de desenvolvimento e avaliação. Caso contrário, o modelo pode efetivamente aprender pormenores de um evento num subconjunto e receber crédito por prever contratos estreitamente relacionados noutro.
Comunique o número de eventos subjacentes, bem como o número de observações contratuais. Cinquenta limiares ou prazos ligados a algumas nomeações não fornecem cinquenta demonstrações independentes da hipótese informativa. As suas relações devem fazer parte da conceção da avaliação.
Utilize testes cronológicos quando a utilização pretendida são eventos futuros e conserve uma amostra posterior para avaliar escolhas feitas durante o desenvolvimento. Uma mistura aleatória pode esconder mudanças nos processos das fontes ou no comportamento do mercado. A avaliação deve assemelhar-se à sequência efetiva em que o algoritmo aprenderia e agiria.
Teste os pressupostos sob tensão sem reescrever a regra
A análise de sensibilidade deve variar pressupostos plausíveis como atraso de receção, estimativas de comissões, profundidade disponível e incerteza da previsão. O objetivo é compreender fragilidade, não procurar indefinidamente a versão que produz o melhor resultado histórico.
Para os dados inventados de teste, um custo total superior ou uma probabilidade de tensão inferior podem remover a margem necessária. Um orçamento disponível menor pode reduzir a quantidade. Um atraso da fonte pode fazer expirar inteiramente a proposta. O algoritmo deve produzir consistentemente essas decisões alteradas a partir das suas condições declaradas.
A discussão anterior sobre se os bots de mercados de previsão são lucrativos salienta testes justos. Aplique esse critério preservando casos perdedores e rejeitados, incluindo interrupções operacionais. Uma avaliação que pressupõe disponibilidade perfeita e execuções favoráveis responde a uma pergunta diferente de saber se o processo completo é útil na prática.
Defina quando a hipótese falhou
Uma especificação refutável deve declarar que provas enfraqueceriam ou terminariam a alegação de investigação. Exemplos incluem ausência de melhoria face à referência em eventos posteriores, descalibração persistente, uma vantagem aparente que desaparece sob tempos realistas ou uma definição alterada da fonte que quebra a relação original.
Não exija uma falha dramática para justificar revisão. Uma deterioração gradual da qualidade dos dados ou uma proporção crescente de candidatos rejeitados podem revelar que as condições operacionais mudaram. Inversamente, alguns resultados adversos podem ser compatíveis com uma previsão probabilística razoável e não devem desencadear automaticamente mudanças descontroladas dos parâmetros.
Escreva o calendário de revisão e os critérios de decisão antes de examinar a amostra final. O valor do algoritmo está em parte em produzir provas que o possam refutar. Uma regra que explica cada perda depois de acontecer enquanto muda as suas condições deixou de ser a alegação específica que a avaliação pretendia testar.
Mantenha um algoritmo distinto de uma carteira
Acrescentar um segundo modelo, uma estratégia de cotação ou outra família de eventos cria um problema de coordenação da carteira. A regra original deve conservar a sua própria identidade e registo de avaliação para que a sua contribuição possa ser compreendida. Os limites partilhados da conta têm de incluir todos os compromissos resultantes.
O guia de algoritmos de negociação na Polymarket examina exposição sobreposta entre vários métodos. Nomes diferentes não estabelecem riscos independentes, sobretudo quando vários algoritmos utilizam a mesma fonte ou negoceiam resultados relacionados. A expansão deve, por isso, seguir uma revisão separada da conta e da avaliação.
Preserve a especificação restrita mesmo que o sistema mais amplo cresça. Deve continuar possível reconstruir o que este algoritmo, por si só, propôs, por que se absteve e como as suas ordens efetivas diferiram das decisões pretendidas. Sem essa separação, resultados agregados podem esconder um componente fraco atrás de outro bem-sucedido sem relação.
Torne mensurável o algoritmo de negociação na Polymarket
Uma especificação completa liga uma hipótese refutável a provas elegíveis, um horizonte fixo, uma previsão, um limiar de custos e uma ação delimitada da conta. Também declara como são tratadas execução parcial, incerteza, invalidação e avaliação. Cada parte contribui para uma decisão que pode ser reproduzida e contestada.
Comece por testar o registo e a aritmética com casos inventados como o daqui. Depois avalie a alegação informativa em observações reais apropriadamente separadas antes de tirar conclusões sobre utilidade. Mantenha claramente identificados factos derivados da fonte, estimativas do modelo e limiares escolhidos de política.
O algoritmo está pronto para revisão séria quando consegue explicar tanto ação como abstenção. O seu sucesso não é produzir sempre uma ordem. É que o processo faz uma alegação precisa, aplica-a consistentemente sob restrições realistas e preserva provas suficientes para determinar se essa alegação resiste ao contacto com eventos posteriores.