Cómo gestionar los límites de velocidad de la API de Binance: ¿Qué significa 'weight'?
Los límites de velocidad son el obstáculo más común en las estrategias cuantitativas. Explicamos las dos dimensiones del límite: weight (peso) y órdenes, y cómo implementar un retroceso elegante.
Los límites de velocidad (rate limits) son la trampa más común en las estrategias de trading cuantitativo. Primero, crea tu API Key en la web oficial de Binance y utiliza la app oficial de Binance para el monitoreo (para iOS, consulta el tutorial de instalación en iOS).
Dos sistemas de límites
La API de Binance tiene dos dimensiones de limitación independientes:
1. Weight (Peso)
Cada endpoint tiene un valor de "weight". La suma total por minuto no debe exceder el límite establecido.
| Nivel | Weight por minuto |
|---|---|
| Usuario estándar | 1200 |
| VIP 1 | 2400 |
| VIP 2 | 3600 |
| ... | Aumenta según nivel |
2. Order (Número de órdenes)
Restricciones adicionales específicas para los endpoints de creación de órdenes:
| Ventana de tiempo | Número de órdenes |
|---|---|
| 10 segundos | 100 |
| 1 día | 200,000 |
Superar cualquiera de estos límites resultará en una prohibición temporal de acceso.
Weight por cada endpoint
Valores comunes:
| Endpoint | Weight |
|---|---|
| Snapshot del mercado | 1 |
| Order Book (5 niveles) | 1 |
| Order Book (100 niveles) | 5 |
| Order Book (1000 niveles) | 50 |
| Velas (K-lines) | 1 |
| Crear orden | 1 |
| Cancelar orden | 1 |
| Información de cuenta | 10 |
Consultar un "deep order book" (1000 niveles) consume 50 de weight; solo puedes hacerlo 24 veces por minuto.
Cabeceras de respuesta (Headers)
Cada respuesta de la API incluye en sus cabeceras:
X-MBX-USED-WEIGHT-1M: Weight utilizado en el minuto actual.X-MBX-ORDER-COUNT-10S: Órdenes creadas en los últimos 10 segundos.
Monitorea estos valores para reducir la velocidad antes de chocar con el límite.
Consecuencias de exceder el límite
- Error 429: Bloqueo temporal. Debes esperar unos segundos.
- Error 418: Bloqueo por IP. Si ignoras el 429 y sigues enviando peticiones, serás baneado permanentemente o por un periodo prolongado.
Tras un error 418, la IP puede quedar bloqueada desde 24 horas hasta varios días. No intentes forzar las peticiones.
Retroceso elegante (Backoff)
import time
while True:
try:
result = api_call()
weight_used = int(headers.get('X-MBX-USED-WEIGHT-1M', 0))
if weight_used > 1000:
time.sleep(10) # Reducir velocidad de forma preventiva
return result
except RateLimitError:
time.sleep(60) # Esperar un minuto si recibimos un 429
Trucos para reducir el consumo de weight
1. Reducir los niveles de profundidad
Si solo necesitas 5 niveles del libro de órdenes, no solicites 1000. La diferencia de weight es de 50 veces.
2. Sustituir por WebSockets
El precio, el libro de órdenes y las velas se pueden recibir en tiempo real mediante WebSockets (WS). Los WebSockets no consumen weight.
3. Endpoints por lotes (Batch)
Usa /api/v3/batchOrders para enviar 5 órdenes de una vez. Es más eficiente que realizar 5 peticiones individuales.
4. Caché
Almacena durante unos segundos los datos que no necesiten una actualización de milisegundos.
Ventajas de WebSockets
| Datos | REST Weight | WebSockets |
|---|---|---|
| Precios | 1 por petición | Push en tiempo real, 0 weight |
| Libro de órdenes | 1-50 | Push continuo |
| Velas (K-lines) | 1 | Push continuo |
Estrategia ideal:
- Usa WS para flujos de datos en tiempo real (consumo de weight cero).
- Usa REST solo para la ejecución de órdenes (compras/ventas).
Dispersión por subcuentas
El uso de múltiples API Keys (de diferentes subcuentas) permite distribuir el consumo de weight.
Estrategia:
- Key de cuenta principal para ejecutar órdenes.
- Keys de subcuentas para consultar datos de mercado.
- Esto multiplica la capacidad total de weight disponible.
Mejora de límites con niveles VIP
A mayor nivel VIP:
- El límite de weight por minuto aumenta considerablemente.
- Se amplían las cuotas para endpoints específicos.
- A veces, esta ventaja es más valiosa que el propio ahorro en comisiones.
Solo con subir a VIP 1 ya duplicas tu capacidad de weight.
Código de monitoreo
class RateMonitor:
def __init__(self):
self.last_weight = 0
self.alert_threshold = 1000
def update(self, headers):
used = int(headers.get('X-MBX-USED-WEIGHT-1M', 0))
if used > self.alert_threshold:
print(f"ALERTA: Consumo elevado {used} / 1200")
self.last_weight = used
Errores comunes
1. Usar solo REST en bucles
Hacer consultas de saldo y de velas cada vez que envías una orden disparará tu weight. Usa WebSockets.
2. No gestionar excepciones
Si recibes un error 429 y no haces un "sleep", Binance detectará el comportamiento agresivo y te lanzará un error 418 de baneo de IP.
3. Compartir IP con varias Keys
Aunque las Keys sean distintas, el límite por IP también existe. Varias Keys desde la misma IP pueden compartir el conteo.
4. Ignorar las cabeceras de respuesta
No monitorizar el weight es como conducir a ciegas; solo te das cuenta del problema cuando chocas con el baneo.
Pruebas previas
- Ejecuta pruebas de alta frecuencia en la Testnet para ver cuándo saltan los errores 429.
- Implementa alertas en tu sistema real para avisar cuando el weight se acerque al umbral crítico.
Preguntas frecuentes
P: ¿Cuánto tiempo dura un bloqueo 429? R: Generalmente de unos segundos a un par de minutos. No envíes ninguna petición durante ese tiempo.
P: ¿Cuánto dura un bloqueo 418? R: De 1 hora a 24 horas. En casos extremos, hasta 7 días.
P: ¿Se puede apelar un baneo por velocidad? R: Puedes contactar con soporte, pero rara vez se retira. Lo mejor es esperar.
P: ¿El weight se comparte entre todos los endpoints? R: Sí. Todas las peticiones suman para el límite total de 1200 por minuto (para usuarios estándar).
P: ¿El límite de órdenes es por IP o por cuenta? R: Es por cuenta. Cambiar de IP no servirá de nada si usas la misma cuenta.
Lecturas recomendadas
Los límites de velocidad no son un problema si los conoces. Monitoriza tu weight y nunca te quedarás fuera del mercado.