Na data que escrevo este artigo tem quase 14 anos que desenvolvo bots/robôs. Eu não comecei com bot cripto, mas sim robôs de busca, os webcrawlers e webscrappers. Só mais tarde, em 2017, quando comecei a investir em cripto passei a criar robôs para este mercado. No entanto, para fins deste artigo uma comparação é inevitável a qualquer tipo de robô que você venha a desenvolver: limites.
Sempre que automatizamos um processo cujos seus criadores tinham como objetivo o uso manual, acabamos esbarrando em algum tipo de limite. Às vezes esse limite é físico, pois o servidor onde está a aplicação não aguenta tantas requisições quanto seu bot deseja fazer. Às vezes esse limite é lógico, os administradores da aplicação não querem ninguém abusando da mesma para não prejudicar o sistema como um todo. O fato é: o seu bot tende a ser limitado de alguma forma ou de outra e se quiser manter ele funcionando, precisa respeitar estes limites.
Então se você está trabalhando em um projeto de bot grande ou de plataforma de bots que automatiza trades na Binance, tenho certeza que este artigo vai te ajudar bastante. Para bots pequenos e integrações simples, geralmente não há com o que se preocupar.
Se preferir, você pode assistir ao vídeo abaixo ao invés de ler, o conteúdo é o mesmo.
#1 – Quais são os limites da Binance?
Existem dois tipos de limites na Binance: os explícitos e os implícitos. Por limites explícitos entenda os que estão descritos claramente na documentação dela. Dizem respeito ao máximo de requests por minuto, ao máximo de conexões de streams, etc. Já os implícitos são mais difíceis de lidarmos e se encaixam nas diretrizes de “fair use” (uso justo) deles, ou seja, é algo mais subjetivo e definido pelos recursos de machine learning que eles possuem para analisar requisições de usuários. Assim, mesmo que você esteja atendendo a todos os limites explícitos, se você abusar pra valer, ainda existe um risco pequeno de bloqueios.
Obviamente trabalharemos nos limites explícitos que estão documentados sempre juntos às APIs e streams que deseja usar.
Um primeiro ponto é que todos os limites de requests são baseados no IP que fez a requisição. Nunca é usado o usuário, API Key ou conta como base de controle, mas sim o IP. Abusos pontuais dos limites geram advertências de IP (erro 429) enquanto que abusos constantes ou reincidentes implicam em bloqueio temporário do IP (erro 418) por minutos até dias, dependendo da violação. Essas regras mudam para limites de ordens (falarei mais tarde pois é uma subcategoria).
Um segundo ponto é que os limites de APIs são diferentes entre os mercados (Spot e Futures) e também diferentes dos limites de streams (websockets). Tratarei cada um desses grupos em separado, mais adiante.
Para monitorar como está seu uso dos limites de request pode sempre consultar o HTTP Header X-MBX-USED-WEIGHT que é retornado em cada resposta bem sucedida. Em caso de erro, pode usar o HTTP Header Retry-After para saber quando poderá usar a API novamente. Agora se quiser monitorar o limite de ordens enviadas, pode usar o HTTP Header X-MBX-ORDER-COUNT que é enviado junto à resposta de ordens ou ainda usando o endpoint GET /api/v3/rateLimit/order (Spot) ou GET /fapi/v1/rateLimit/order (Futures).
E por fim, é importate frisar que os limites da Testnet (ambiente de teste) podem ser diferentes dos limites de produção, sendo que abaixo me foquei neste último. Agora vamos ver em mais detalhes como funcionam os limites de cada mercado (Spot x Futures) e canal (API x stream).
#2 – Limites da API Binance Spot
Então vamos começar pelos limites de APIs Spot que são baseados em número de requests mas também em peso de request (request weight) por minuto.
- peso de request por minuto (Spot): 6000
- número de requests a cada 5 minutos (Spot): 61.000
- número de ordens por segundo (Spot): 10
Note que os dois últimos são bem diretos e simples de entender, pois são um número máximo em determinado bloco de tempo. Agora o primeiro pode gerar a dúvida: mas o que é “peso de request”?
Cada request consome uma quantidade de recursos diferente no servidor da Binance, por isso, possuem um “peso” diferente atribuído. Assim, com o limite atual, você consegue fazer 6000 requests de peso 1 por minuto, mas apenas 600 de peso 10, por exemplo. A tabela abaixo traz o peso de algumas chamadas como exemplo, sendo que a tabela completa encontra-se na documentação oficial (bem como os pesos atualizados):
| Endpoint Spot | Peso/req |
| GET /api/v3/exchangeInfo | 20 |
| GET /api/v3/trades | 25 |
| GET /api/v3/klines | 2 |
| GET /api/v3/avgPrice | 2 |
| POST /api/v3/order | 1 |
| GET /api/v3/order | 4 |
| DELETE /api/v3/order | 1 |
| GET /api/v3/allOrders | 20 |
| GET /api/v3/account | 20 |
| GET /api/v3/myTrades | 20 |
Alguns endpoints possuem peso variável, conforme os parâmetros que você passar na requisição. Por exemplo, se você passa um symbol, o peso será x, mas se passar dois symbols, o peso será y. Abaixo mais uma tabela, desta vez com exemplos apenas de endpoints que consomem peso variável (resumi algumas explicações, consulte a tabela oficial para o valor completo):
| Endpoint Spot | Peso/req |
| GET /api/v3/depth | 5/100 linhas do book (arredonde para cima) |
| GET /api/v3/ticker/24hr | 80 para todos symbols ou 2 para apenas um |
| GET /api/v3/ticker/tradingDay | 4/symbol |
| GET /api/v3/ticker/price | 2/um ou 4/todos |
| GET /api/v3/ticker/bookTicker | 2/um ou 4/todos |
| GET /api/v3/openOrders | 6/um ou 80/todos |
Assim, sempre for pensar em alguma funcionalidade Spot, seja no seu bot ou integração, sempre é bom dar uma verificada nesses limites e o quanto você planeja usá-lo, para não cair em algum tipo de advertência ou bloqueio, como citado anteriormente.
Quer aprender a usar as APIs de Binance Spot? Este tutorial é um bom começo.
#3 – Limites das streams Binance Spot
Agora vamos falar das streams de spot. O objetivo principal das streams da Binance é fornecer dados em tempo real, desonerando inclusive as APIs que são muito mais custosas de manter. Sendo assim, raramente você vai enviar algum comando (request) para o servidor de streams além da própria conexão em si. Ainda assim, o primeiro limite que você saber é o relacionado a conexões: você não pode, a partir de um mesmo IP, realizar mais de 300 tentativas de conexão a cada 5 minutos.
Além das tentativas de conexão em si, uma vez conectado o cliente de websocket deve enviar um comando de subscribe, para “assinar” uma stream de fato e passar a receber seus dados. Existe um limite de comandos que você pode enviar que é 5/segundo. Ou seja, se estiver construindo uma plataforma de bots, cuidado para não conectar todos seus clientes ao mesmo tempo ou terá problemas. Um número excedente de requests irá gerar desconexão ou um possível bloqueio de IP se for reincidente.
Outro limite diz em relação às streams combinadas, um recurso que te permite usar uma mesma conexão para receber dados de diferentes streams. Seu limite é de 1024 assinaturas de streams por conexão.
E por fim, os últimos limites relacionados ao uso das streams Binance Spot é o de tempo de conexão. A cada 3 minutos a Binance testa se sua conexão ainda está ativa, caso contrário o desconecta depois de 10 minutos sem resposta, ou seja o limite de inatividade é 10 minutos. E o tempo máximo de conexão, independente se ativa ou não, é de 24h.
Repare que como os limites de streams tem muito mais a ver com conexões do que com a quantidade de dados recebidos, elas são uma excelente opção para os dados ATUAIS da exchange, podendo render uma excelente economia em relação a chamadas de API que consomem peso de request.
Quer aprender a usar as streams de Binance Spot? Este tutorial é um bom começo.
#4 – Limites da API Binance Futures
Uma vez que você entenda como funcionam os limites de API para Binance Spot, você já entendeu como funcionam para Binance Futures também. O que vai mudar essencialmente são os valores em si, não apenas do peso dos endpoints, como os limites totais. Sendo bem prático (valores obtidos da API oficial):
- peso de request por minuto (Futures): 2400
- número de ordens por minuto (Futures): 1200
- número de ordens a cada 10 segundos (Futures): 300
Repare um ponto curioso, o limite de ordens de futuros é maior, mas o de requests em geral, menor. No entanto, isso não significa necessariamente que você pode fazer menos requests em Futures, já que o peso de cada endpoint é menor que os de spot.
Alguns exemplos de endpoints populares e seus pesos são (lista completa na documentação oficial):
| Endpoint Futures | Peso/req |
| GET /fapi/v1/exchangeInfo | 1 |
| GET /fapi/v1/trades | 5 |
| GET /fapi/v1/historicalTrades | 20 |
| GET /fapi/v1/premiumIndex | 1 |
| GET /fapi/v1/openInterest | 1 |
| POST /fapi/v1/order | 0 |
| GET /fapi/v1/order | 1 |
| DELETE /fapi/v1/order | 1 |
| DELETE /fapi/v1/allOpenOrders | 1 |
| GET /fapi/v1/openOrder | 1 |
| GET /fapi/v1/allOrders | 5 |
| GET /fapi/v2/balance | 5 |
| GET /fapi/v2/account | 5 |
| POST /fapi/v1/leverage | 1 |
| POST /fapi/v1/marginType | 1 |
| GET /fapi/v2/positionRisk | 5 |
Da mesma forma que em Spot, também temos aqui alguns endpoints com peso variável, de acordo com filtros passados (ou não). Abaixo alguns exemplos:
| Endpoint Futures | Peso/req |
| GET /fapi/v1/depth | de 2 a 20, dependendo do limit |
| GET /fapi/v1/klines | 1/100 velas |
| GET /fapi/v1/ticker/24hr | 1/um symbol ou 40/todos |
| GET /fapi/v1/ticker/price | 1/um symbol ou 2/todos |
| GET /fapi/v1/ticker/bookTicker | 2/um symbol ou 5/todos |
| GET /fapi/v1/openOrders | 1/um symbol ou 40/todos |
Assim, sempre for pensar em alguma funcionalidade Futures, seja no seu bot ou integração, sempre é bom dar uma verificada nesses limites e o quanto você planeja usá-lo, para não cair em algum tipo de advertência ou bloqueio, como citado anteriormente.
Quer aprender a usar as APIs de Binance Futures? Este tutorial é um bom começo.
#5 – Limites das streams Binance Futures
Agora vamos falar das streams de futures, que nãoão fogem muito da mecânica de limites de spot. Primeiramente vale reforçar que aqui temos o mesmo limite máximo de tempo de conexão que é 24h, independente se estiver ativa ou não. Enquanto isso, as conexões inativas são desconectadas a cada 10 minutos, igual à spot também (testes a cada 3 minutos).
Já o limite de comandos (como o subscribe) é de 10 por segundo, o dobro de spot. Infelizmente quando o assunto é aproveitar uma mesma conexão para várias streams (streams combinadas), o limite é muito inferior: apenas 200 (5x menor que spot).
Quer aprender a usar as streams de Binance Futures? Este tutorial é um bom começo.
E com isso entendo que passei pelos principais pontos relacionados a limites de uso das APIs e streams da Binance, tanto de Spot quanto de Futures.
Até a próxima!
Olá, tudo bem?
O que você achou deste conteúdo? Conte nos comentários.