Footprint cross-exchange

Fuentes de datos

Cuatro feeds de exchanges, solo streams públicos de profundidad. No se requieren API keys.

• Perpetuos USDT-M de Binance. WebSocket de diff-stream más una instantánea REST en arranque en frío, ambos en el endpoint de futuros. Libro L2 local validado por número de secuencia, top 1.000 niveles publicados por activo.
• Perpetuos lineales V5 de Bybit. WebSocket público, orderbook.<tier>.<SYMBOL>. Tier 200 para todos los activos, el más profundo que acepta el stream lineal. Frame de instantánea al suscribir, deltas con u incremental monótono, una resuscripción fuerza una nueva instantánea ante huecos de secuencia.
• SWAP V5 de OKX. Canal público books (400 niveles, sin auth), los 400 publicados. Instantánea más frames de update encadenados por seqId / prevSeqId de cada entrada. Consideramos las variantes tick-by-tick pero requieren un nivel de fees VIP que no tenemos; ver Limitaciones.
• Perpetuos de Hyperliquid. Suscripción WebSocket pública l2Book. El exchange limita cada frame a 20 niveles crudos, así que el daemon abre suscripciones paralelas por activo con nSigFigs progresivamente más gruesos. BTC, ETH, SOL, BNB, HYPE y ZEC usan tres franjas (crudo / 4 / 3); XRP añade una franja exterior nSigFigs=2 y llega a cuatro; DOGE y ENA llegan a cinco, sumando esa franja exterior más otra de nSigFigs=5 / mantissa=2 que sostiene su propio libro. El agregador combina todas las franjas en una sola contribución de Hyperliquid al publicar; la UI muestra un único venue.
• Activos cubiertos. BTC, ETH, SOL, BNB, XRP, DOGE, HYPE, ZEC, ENA.

Normalización: precios y cantidades

La agregación cross-exchange solo funciona cuando todas las fuentes hablan las mismas unidades. Dos ajustes ocurren al ingestar, antes de que algo llegue al agregador.

Cantidad en moneda base. Binance y Bybit devuelven cantidades en la moneda base directamente (BTC para el perpetuo BTC-USDT, etc.). OKX devuelve el tamaño en contratos, donde un contrato es ctVal unidades de la moneda base. Para BTC-USDT-SWAP ctVal = 0,01; para DOGE-USDT-SWAP es 1000. El feed de OKX resuelve ctVal del endpoint público de instrumentos al arrancar y aplica el multiplicador en cada nivel antes de publicar. Sin este paso, la profundidad de DOGE se leería 1000× más profunda en la vista cross-exchange.

Precio en buckets por activo. Cada exchange usa un tamaño de tick ligeramente distinto; el agregador redondea los precios hacia abajo al borde de bucket más cercano para que los ticks adyacentes entre exchanges se fusionen en el mismo muro. Buckets primarios por activo:

btc:  $1,0
eth:  $0,10
sol:  $0,01
bnb:  $0,02
xrp:  $0,0002
doge: $0,00002
hype: $0,005
zec:  $0,1
ena:  $0,00002

Un tamaño de bucket por activo

En cada ciclo la profundidad cruda se bucketiza en un tamaño de bucket por activo, el bucket primario de la tabla de arriba. Las celdas del footprint usan el mismo tamaño, así que un muro y los trades impresos contra él comparten fila.

Para BTC eso significa un bucket de $1 (granularidad fina, denso cerca del precio medio). La misma lógica escala por activo: ETH usa $0,10 y DOGE $0,00002.

Agregación: suma + desglose por exchange

Para cada bucket, el agregador suma cantidades a través de las cuatro fuentes y conserva la contribución por exchange junto al total. Eso permite a la UI renderizar una sola fila de muro más un desglose apilado al pasar el cursor, sin un round-trip extra.

for src in (binance, bybit, okx, hyperliquid):
    for (price, qty_base) in src.depth.bids:
        bucket = floor(price / BUCKET_SIZE) × BUCKET_SIZE
        bid_buckets[bucket].total      += qty_base
        bid_buckets[bucket].by[src]    += qty_base
    # asks: igual, luego ordena por precio ascendente
top_bids = sorted(bid_buckets, by price desc)[:600]
top_asks = sorted(ask_buckets, by price asc)[:600]

El payload de salida incluye la lista de fuentes y las mejores cotizaciones por exchange por separado. No exponemos un único mejor bid/ask consolidado; ver Limitaciones.

Cadencia y resolución de spoofs

El agregador publica a 10 Hz (una instantánea cada ~100 ms). Los feeds de productores escriben hasta ~20 Hz, pero el límite efectivo es la tasa de push del exchange (~50 a 100 ms nativo).

Con celdas de 100 ms en el gráfico footprint, los muros y spoofs aparecen así:

• Spoof ≥ 100 ms → 1 celda visible (detección de borde).
• Spoof ≥ 200 ms → 2 celdas visibles (fiable).
• Spoof ≥ 500 ms → 5 celdas, se lee como una mota vertical clara.
• Muro de varios segundos → mancha horizontal a través de muchas celdas.

Los spoofs sub-100 ms no se detectan. Eso requeriría canales tick-by-tick (TBT), y ninguno de los cuatro venues nos da uno a nuestro nivel de acceso.

Alineación temporal

Cada productor extrae el timestamp de evento del exchange de su stream de profundidad nativo (el campo E de Binance, el ts de nivel superior de Bybit, el ts por entrada de OKX, el time de Hyperliquid, que es también el campo que sellan sus frames de operaciones) y lo propaga junto al tiempo de publicación del propio productor.

En el agregador cada instantánea expone el timestamp de evento por fuente y el skew cross-exchange (máximo menos mínimo de los tiempos de evento entre las fuentes OK). El tsde la instantánea del mapa se mantiene como el momento de polling del agregador para que la línea temporal esté uniformemente espaciada; el skew se muestra en el tooltip cuando es ≥ 100 ms (rojo a partir de 300 ms), de modo que el “consenso” en una sola celda queda acotado de forma honesta.

Skew típico observado: < 100 ms en estado estable; picos a 300 a 500 ms en momentos de estrés de la base donde el feed de un venue se retrasa brevemente. Sin esta atribución, un muro colocado en Binance a T+0 y en Bybit a T+200 ms se leería como un único consenso instantáneo, que no lo es.

Gestión de fuentes desactualizadas

Cada productor escribe su clave de fuente con un TTL de 60 segundos más un timestamp. El agregador computa la edad por fuente en cada ciclo y excluye cualquier fuente con más de 60 segundos de la vista combinada; la fuente excluida sigue apareciendo en el array sources con estado stale, de forma que el frontend muestra un indicador degradado.

En el frontend: las pastillas de fuente del toolbar muestran color y estado, y el mapa continúa con las fuentes restantes. Un estado stale persistente suele significar que el productor sufrió un reset del watchdog o que el WebSocket se cayó sin reconectar limpio, y la página se degrada de forma visible en lugar de silenciosa.

Limitaciones y trampas conocidas

• Sin un mejor bid/ask consolidado. La base cross-exchange es normal: el perpetuo de BTC en Binance suele cotizar entre 5 y 15 dólares por encima o por debajo del mismo instrumento en Bybit y OKX. Una unión ingenua del top de libro se invierte durante esos periodos (mejor bid agregado mayor que mejor ask agregado). El widget muestra los muros agregados y las mejores cotizaciones por exchange por separado para evitar esa trampa, y resalta una banda violeta de inversión solo cuando la brecha supera el 0,10 % del precio medio (configurable con ?inv_bps=N en la URL).
• Cobertura de profundidad. El agregador publica hasta 600 bins por lado y ninguno a más del 5 % del precio medio, y los streams de historia que alimentan la clasificación de muros guardan solo los 60 bins por lado más cercanos al medio. Los anclajes de números redondos a ±2 % del precio medio quedan muy por fuera de esos 60 bins, así que los muros ahí son estructuralmente invisibles para esta metodología.
• Latencia sub-100 ms. El agregador hace polling a 10 Hz; las tasas de push de los exchanges topan en ~50 a 100 ms en los canales públicos gratuitos. Las variantes tick-by-tick de OKX (books-l2-tbt, books50-l2-tbt) requieren un nivel de fees superior que no tenemos; la suscripción devuelve code 64003. Bybit y Binance no publican un canal tick-by-tick gratuito comparable para futuros.
• 1.000 niveles ≠ libro profundo. El productor más profundo, Binance, alimenta hasta 1.000 niveles crudos por lado (OKX 400, Bybit 200). En BTC, con su tick de 0,10 dólares, eso cubre aproximadamente 100 dólares desde el medio, un 0,15 %, y más allá el libro fusionado son solo las franjas gruesas de Hyperliquid; en pares más tranquilos los libros de los exchanges llegan más lejos. Los muros de los exchanges más profundos del libro simplemente no están en el feed independientemente del tamaño de bucket.
• El skew cross-exchange es real. El mapa de calor renderiza celdas a intervalos uniformes de 100 ms, pero la instantánea subyacente de cuatro venues para cada celda puede abarcar hasta cross_exchange_skew_msen tiempo de evento, típicamente < 100 ms, ocasionalmente 200 a 500 ms. El tooltip lo muestra cuando es relevante; trátalo como el piso de granularidad temporal.

Versionado

Lanzamiento inicial v1.0.0 el 2026-05-08 (agregación a 4 Hz, 50 niveles). v2.0.0 el 2026-05-09: se sube a 10 Hz, 200 niveles, vistas multi-bucket ($1 + $5 por activo), alineación por timestamp de evento por fuente con exposición del skew cross-exchange. v2.1.0 el 2026-05-21: se añade Hyperliquid como cuarta fuente vía suscripciones l2Book multi-resolución (el tope crudo de 20 niveles es demasiado corto por sí solo; las franjas con nSigFigs más gruesos extienden el alcance mientras mantienen granularidad nativa cerca del medio). v3.0.0 el 2026-05-23: se rebrand de la metodología del gráfico footprint cross-exchange a metodología footprint tras el retiro de la UI M2 del heatmap. El sustrato (fuentes, normalización, alineación) no cambia — el footprint init aggregator lee las mismas claves `prod:agg:<asset>:history`. Las variantes multi-bucket (`prod:agg:<asset>:b<size>:*`) se descartaron al mismo tiempo (el heatmap era su único consumidor). v3.1.0 el 2026-09-02: se corrigen los conteos de venues que quedaron obsoletos tras la incorporación de Hyperliquid (cobertura de profundidad, disponibilidad tick-by-tick y el alcance de la instantánea por celda ahora dicen cuatro venues, no tres), se nombra el timestamp de evento de Hyperliquid en la alineación temporal, y la tabla de franjas de Hyperliquid se actualiza con HYPE y la franja nSigFigs=5 / mantissa=2 propia de DOGE. Los cambios materiales en la ruta de cómputo suben la versión y actualizan la fecha publicada. Los cambios cosméticos no.