人类对Codex的开发不足1%！
Ontem acabei de receber a API e gastei um pouco de tempo para fazer um script de ordens pendentes
Total de ativos iniciais da conta: 311.8u
Rodei a noite toda fazendo um volume de 8k de transações e ainda ganhei 1.31u
O custo de pontos assim equivale a ser negativo
A principal vantagem é que a liquidez da plataforma agora está simplesmente excelente
Fazer um script desses exige considerar muita coisa:
- Quais tarefas podem rodar em paralelo e quais ações precisam ser sequenciais?
A leitura pode ser em paralelo, mas o envio de ordens e o cancelamento, de preferência, devem ser sequenciais; caso contrário, é fácil acontecer de uma thread cancelar/duplicar a mesma ordem que acabou de ser enviada por outra thread
- Vale a pena separar threads para BUY e SELL?
BUY precisa varrer o mercado e o book, é mais lento; SELL precisa acompanhar as posições da conta, com resposta rápida. Separando, o SELL não fica preso na varredura completa do BUY
- Como desenhar o state local?
Não dá para depender apenas de open orders da API, porque o estado da exchange não é consistente em tempo real. Depois que uma ordem é criada com sucesso, o open orders pode levar alguns segundos para aparecer. O state local precisa assumir funções de deduplicação de curto prazo, prevenção de envio duplicado e evitar limpeza indevida
- Como lidar com eventual consistency?
Uma ordem recém-criada não pode ser considerada inválida só porque no próximo segundo o open orders ainda não aparece. Precisa configurar uma janela de espera, como 30-60 segundos, para evitar que a thread de sincronização da conta remova a nova ordem por engano
- Como obter o preço da ordem?
Yes/No, Over/Under — esses outcomes inversos são fáceis de calcular errado. Especialmente no SELL, o melhor é usar o bestAsk do outcome atual da posição, em vez de pegar cegamente o lado Yes do orderbook para fazer o complement
- Como lidar com a precisão das frações?
Exibição no front-end: 17.86. Isso não significa que você consegue vender de verdade 17.86. A quantidade ao enviar precisa ser truncada para baixo, não arredondada; caso contrário, pode gerar insufficient shares
- Como classificar exceções da API?
Mismatch de hash, saldo insuficiente, fração insuficiente, desconexão do outro lado, retorno truncado, atraso na sincronização de ordens — as formas de tratar são diferentes. Não dá para simplesmente ficar retry infinito
- Como escrever limites de controle de risco (risk control)?
Não vender a preço de mercado (market), não pegar (não consumir) ordens, post-only, limitar o intervalo do BUY, cancelar ordens de compra antes do início da partida — tudo isso precisa virar restrições rígidas no código
Não é que, tendo AI, você consiga fazer qualquer sistema que seja entregue de forma estável e consistente a longo prazo. É imprescindível, do ponto de vista de engenharia, fazer testes de estabilidade e aplicar controles de risco
Pessoal interessado, vamos trocar ideia～
@Predictdotfun
Ontem acabei de receber a API e gastei um pouco de tempo para fazer um script de ordens pendentes
Total de ativos iniciais da conta: 311.8u
Rodei a noite toda fazendo um volume de 8k de transações e ainda ganhei 1.31u
O custo de pontos assim equivale a ser negativo
A principal vantagem é que a liquidez da plataforma agora está simplesmente excelente
Fazer um script desses exige considerar muita coisa:
- Quais tarefas podem rodar em paralelo e quais ações precisam ser sequenciais?
A leitura pode ser em paralelo, mas o envio de ordens e o cancelamento, de preferência, devem ser sequenciais; caso contrário, é fácil acontecer de uma thread cancelar/duplicar a mesma ordem que acabou de ser enviada por outra thread
- Vale a pena separar threads para BUY e SELL?
BUY precisa varrer o mercado e o book, é mais lento; SELL precisa acompanhar as posições da conta, com resposta rápida. Separando, o SELL não fica preso na varredura completa do BUY
- Como desenhar o state local?
Não dá para depender apenas de open orders da API, porque o estado da exchange não é consistente em tempo real. Depois que uma ordem é criada com sucesso, o open orders pode levar alguns segundos para aparecer. O state local precisa assumir funções de deduplicação de curto prazo, prevenção de envio duplicado e evitar limpeza indevida
- Como lidar com eventual consistency?
Uma ordem recém-criada não pode ser considerada inválida só porque no próximo segundo o open orders ainda não aparece. Precisa configurar uma janela de espera, como 30-60 segundos, para evitar que a thread de sincronização da conta remova a nova ordem por engano
- Como obter o preço da ordem?
Yes/No, Over/Under — esses outcomes inversos são fáceis de calcular errado. Especialmente no SELL, o melhor é usar o bestAsk do outcome atual da posição, em vez de pegar cegamente o lado Yes do orderbook para fazer o complement
- Como lidar com a precisão das frações?
Exibição no front-end: 17.86. Isso não significa que você consegue vender de verdade 17.86. A quantidade ao enviar precisa ser truncada para baixo, não arredondada; caso contrário, pode gerar insufficient shares
- Como classificar exceções da API?
Mismatch de hash, saldo insuficiente, fração insuficiente, desconexão do outro lado, retorno truncado, atraso na sincronização de ordens — as formas de tratar são diferentes. Não dá para simplesmente ficar retry infinito
- Como escrever limites de controle de risco (risk control)?
Não vender a preço de mercado (market), não pegar (não consumir) ordens, post-only, limitar o intervalo do BUY, cancelar ordens de compra antes do início da partida — tudo isso precisa virar restrições rígidas no código
Não é que, tendo AI, você consiga fazer qualquer sistema que seja entregue de forma estável e consistente a longo prazo. É imprescindível, do ponto de vista de engenharia, fazer testes de estabilidade e aplicar controles de risco
Pessoal interessado, vamos trocar ideia～
@Predictdotfun
