Crypto Datos de mercado Metodología

Datos observados frente a estimaciones

Datos observados significa que se recibió un evento de intercambio o valor de mercado de una fuente pública conectada. Datos derivados significa que TradingHub calculó una puntuación, normalización, agregación o distancia a partir de esas entradas. Estimación se utiliza cuando una calculadora o una suposición de reserva modela un valor en lugar de informar un resultado confirmado por la bolsa.

TradingHub no debería reemplazar silenciosamente una fuente no disponible con cero porque cero es un valor de mercado válido. Por lo tanto, los paneles exponen estados de conexión, obsoletos, no disponibles o de cobertura reducida cuando la aplicación no puede admitir una reclamación activa.

Normalización, frescura y reglas de reserva

Las tasas de financiación se almacenan con su intervalo de liquidación específico del lugar y se normalizan solo cuando una comparación solicita explícitamente una cifra diaria o anualizada. Las cantidades de contratos de interés abierto se convierten a valores nocionales comparables solo cuando el multiplicador del contrato y mark price están disponibles. TradingHub no presenta unidades diferentes como si fueran idénticas.

Los paneles en vivo distinguen los estados de carga, en vivo, obsoleto y no disponible. Una observación en caché puede mostrarse como obsoleta con su hora de última actualización; no se vuelve a etiquetar como en vivo. Las alternativas REST se utilizan solo para puntos finales públicos compatibles y nunca reemplazan una transmisión en tiempo real con eventos inventados.

Terminología de liquidación

La actividad de liquidación del terminal se basa en liquidaciones ejecutadas observadas. Las bolsas no publican el precio exacto de liquidación futura de cada posición abierta. Cualquier producto que proyecte grupos de liquidación futuros debe estimar el apalancamiento oculto y las distribuciones de entrada. TradingHub mantiene esa distinción explícita.

Liquidation Map · Modelo 1.9

The map combines public perpetual-futures candles, open interest, mark price, funding context and observed executed liquidations. The model always runs on a canonical 5-minute candle series; the selected candle timeframe changes chart display only and cannot move modeled liquidation levels. Positive OI changes are distributed across explicit 5×, 10×, 20×, 25×, 50× and 100× leverage cohorts and a bounded entry-price uncertainty range. Nearby modeled levels are consolidated into bounded price clusters without discarding their underlying exposure. The heat layer renders each cluster as a hard rectangular price band across discrete OI time buckets, using a fine stepped intensity scale with no Gaussian halo, bilinear interpolation or temporal cross-fade. This preserves clear price-level separation without adding positions or inventing history. Remaining modeled exposure is reduced when OI contracts, price crosses a modeled level or an observed liquidation occurs nearby.

Los modos Rápido, Equilibrado y Estructural son parametrizaciones independientes, no simples preajustes visuales renombrados. Utilizan periodos de exposición de 8, 18 y 42 horas, una incertidumbre de entrada progresivamente mayor, diferentes penalizaciones por distancia de disparo y horizontes de evaluación de 6, 12 y 24 horas. Cada disparo y grupo en tiempo real informa ahora del consenso entre horizontes mediante la ejecución independiente del motor de estado para los tres modos. El control del umbral de señal elimina las celdas de baja intensidad relativa y excluye los clústeres débiles de la selección; no genera una exposición más fuerte.

Binance y Bybit el OI histórico público se carga progresivamente para el rango visible. OKX el OI histórico público a nivel de instrumento no se reclama cuando no está disponible; OKX el historial crece solo a partir de instantáneas observadas por el navegador. La vista combinada normaliza cada mercado con respecto a su propio OI antes de la agregación. La intensidad del calor es una concentración relativa del modelo, a menos que el usuario seleccione la escala absoluta de la sesión. El clúster significativo más cercano se presenta como un disparador, mientras que el clúster significativo más fuerte del mismo lado se presenta por separado como el pool dominante; uno no sustituye al otro. El balance de liquidación es una exposición descriptiva por debajo y por encima de la marca y es explícitamente neutral dentro de una banda de desequilibrio estrecha. Las distancias históricas de la información sobre herramientas utilizan el cierre de la vela en el momento inspeccionado, mientras que la distancia del disparador en vivo utiliza la marca actual. El ciclo de vida de la zona, la confianza del modelo calibrada de forma conservadora, el rango del clúster percentil y la composición del mercado se derivan del historial del modelo disponible; las cifras USD son rangos de escenarios en lugar de valores de posición observados. El perfil utiliza solo las columnas del modelo más recientes y separa la exposición modelada larga y corta.

La validación hacia adelante comienza solo después de que el navegador observa un disparador en vivo confirmado por al menos dos horizontes del modelo. Una predicción se almacena antes de que se evalúen las velas subsiguientes, expira en el horizonte del modelo seleccionado y se marca como probada solo cuando una vela posterior intersecta su banda de precio registrada. El estado subsiguiente del modelo puede clasificarla como parcialmente consumida o consumida; una expiración no tocada se invalida. La tasa de contacto se retiene hasta que se resuelvan al menos 30 predicciones. Los resultados son locales al navegador y nunca se rellenan retroactivamente a partir del historial ya conocido. Las alertas de zona del navegador son opcionales, filtradas por proximidad y deduplicadas.

Límite: Este modelo no puede observar precios de entrada privados, apalancamiento, modo de margen, garantía, niveles de mantenimiento o posiciones individuales. Los grupos de precios y los rangos de escenarios son aproximaciones analíticas, no órdenes de liquidación de intercambio, un pronóstico o una señal de negociación. Las estadísticas locales de validación hacia adelante no son una afirmación de rendimiento global.

Latencia y reconexiones

La red del navegador, la conexión del usuario y la infraestructura de intercambio ascendente pueden afectar la latencia de entrega. TradingHub monitorea el estado de la fuente y reconecta los flujos fallidos. Una reconexión puede crear una brecha temporal en las observaciones; La interfaz debería informar esa condición en lugar de implicar una cobertura ininterrumpida.

Metodología de la base de datos Markets

Identidad: cada criptomoneda tiene un identificador permanente de TradingHub y una sola página canónica. Las redes y los contratos verificados pertenecen al mismo proyecto. Los nombres, símbolos y slugs anteriores siguen siendo localizables; las URL antiguas redirigen a la página canónica actual.

Precio y gráfico: la ingesta de precio y gráfico es independiente del proveedor. Cada proyecto/mercado utiliza fuentes configuradas con prioridades y mapeos explícitos; el runtime prueba las fuentes elegibles en orden de prioridad, valida las respuestas y conserva su procedencia. Ningún exchange es la fuente primaria universal de la arquitectura. Si falla un proveedor, puede utilizarse la siguiente fuente configurada sin cambiar el significado público del activo. El historial procede de velas reales de las API de los exchanges. D1 conserva el último snapshot y gráfico válidos; si fallan ambas fuentes, los datos se marcan como desactualizados y nunca se sustituyen por cero.

Capitalización, oferta y volumen: cada activo canónico de Markets/Radar tiene una fuente de oferta primaria P1 revisada de forma explícita: protocolo, blockchain/explorador, API del emisor/fundación u otra fuente específica del proyecto con un método de lectura o cálculo definido. CoinGecko se utiliza únicamente como fallback P2 cuando falla esa fuente primaria; CoinPaprika y CoinLore no forman parte de la cadena normal P1/P2 de oferta. El origen realmente utilizado, su URL y la prioridad del fallback se guardan junto con la caché validada. La capitalización se calcula multiplicando el precio actual de TradingHub por una oferta circulante fiable.

Mercados y contratos: los adaptadores CEX compatibles se etiquetan como verificados por API solo cuando el exchange confirma el instrumento. Cualquier CEX o DEX adicional puede añadirse manualmente con una URL explícita del mercado; se muestra siempre como listado manual, nunca como verificado por API y sin precio o volumen inventados. Los contratos se muestran únicamente después de verificarse; los activos nativos no tienen contrato de token.

Actualización: las lecturas públicas sirven de inmediato el último snapshot válido de D1. Los snapshots de precio pueden actualizarse cada 3 minutos, la verificación de listados CEX cada 6 horas, la oferta circulante revisada cada 12 horas y los rangos del gráfico permanecen en caché durante 15 minutos. Los bloqueos distribuidos evitan refresh duplicados, los valores normalizados sin cambios no se vuelven a escribir y el estado de health solo se persiste cuando cambia. La detección crea candidatos visibles solo en la administración y nunca los publica automáticamente. La inclusión en Radar es siempre manual y no constituye una puntuación ni una recomendación.

Una fuente configurada solo se acepta tras validarla. Los campos HTML vacíos no toman cifras de otras métricas; los datos de un agregador publicados por un explorador no se consideran evidencia primaria de la cadena. Se rechazan las ofertas incoherentes y las marcas de tiempo obsoletas. Un intento fallido no sustituye una observación primaria vigente por datos de un agregador. Cada activo se revalida cada 12 horas; el trabajo continúa en lotes de seis activos en visitas posteriores. Las actualizaciones dependen de las solicitudes, no de un horario garantizado.