Crypto Marktdaten Methodik

Beobachtete Daten im Vergleich zu Schätzungen

Beobachtete Daten bedeutet, dass ein Börsenereignis oder ein Marktwert aus einer verbundenen öffentlichen Quelle stammt. Abgeleitete Daten bedeutet, dass TradingHub einen Score, eine Normalisierung, eine Aggregation oder eine Distanz aus diesen Eingaben berechnet hat. Schätzung wird verwendet, wenn ein Rechner oder eine Ausweichannahme einen Wert modelliert, anstatt ein von der Börse bestätigtes Ergebnis zu melden.

TradingHub sollte einen nicht verfügbaren Datenstrom nicht stillschweigend durch Null ersetzen, da Null ein gültiger Marktwert ist. Panels zeigen daher Verbindungs-, veraltete, nicht verfügbare oder eingeschränkte Deckungszustände an, wenn die Anwendung keinen aktiven Anspruch unterstützen kann.

Normalisierung, Aktualität und Ausweichregeln

Die Finanzierungssätze werden mit ihrem standortspezifischen Abrechnungsintervall gespeichert und nur dann normalisiert, wenn ein Vergleich explizit einen Tages- oder Jahreswert anfordert. Die Kontraktmengen mit offenem Interesse werden nur dann in vergleichbare Nominalwerte umgerechnet, wenn der Kontraktmultiplikator und mark price verfügbar sind. TradingHub stellt ungleiche Einheiten nicht so dar, als wären sie identisch.

Live-Panels unterscheiden zwischen den Zuständen „Laden“, „Live“, „Veraltet“ und „Nicht verfügbar“. Eine zwischengespeicherte Beobachtung kann mit ihrem letzten Aktualisierungszeitpunkt als veraltet angezeigt werden; sie wird nicht als „Live“ umbenannt. REST-Fallbacks werden nur für unterstützte öffentliche Endpunkte verwendet und ersetzen niemals einen Echtzeit-Stream durch erfundene Ereignisse.

Liquidationsterminologie

Die Liquidationsaktivität des Terminals basiert auf Beobachtete ausgeführte LiquidationenBörsen veröffentlichen nicht den exakten zukünftigen Liquidationspreis jeder offenen Position. Jedes Produkt, das zukünftige Liquidationscluster prognostiziert, muss die versteckte Hebelwirkung und die Einstiegsverteilungen schätzen. TradingHub stellt diese Unterscheidung explizit dar.

Liquidation Map · Modell 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.

Fast, Balanced und Structural sind eigene Parametrisierungen, keine umbenannten Presets. Sie nutzen Halbwertszeiten von 8, 18 und 42 Stunden, zunehmend breitere Einstiegsunsicherheit, unterschiedliche Distanzstrafen sowie Horizonte von 6, 12 und 24 Stunden. Trigger und Pools melden den Konsens aller Modi. Der Signal-Schwellenwert entfernt schwache Zellen und Cluster, erzeugt aber keine stärkere Exposition.

Binance und Bybit öffentliche historische OI-Werte werden für den sichtbaren Bereich schrittweise geladen. OKX öffentliche historische OI-Werte auf Instrumentenebene werden nicht beansprucht, wenn sie nicht verfügbar sind; OKX die Historie wächst nur aus den vom Browser angezeigten Snapshots. Die kombinierte Ansicht normalisiert jeden Standort vor der Aggregation anhand seines eigenen OI. Die Wärmeintensität ist eine relative Modellkonzentration, sofern der Benutzer nicht die absolute Sitzungsskala auswählt. Der nächstgelegene signifikante Cluster wird als Trigger angezeigt, während der stärkste signifikante Cluster auf derselben Seite separat als dominanter Pool dargestellt wird; einer wird nicht durch den anderen ersetzt. Die Liquidationsbilanz beschreibt die Exposition unterhalb und oberhalb der Marke und ist innerhalb eines schmalen Ungleichgewichtsbereichs explizit neutral. Historische Tooltip-Distanzen verwenden den Schlusskurs der Kerze zum betrachteten Zeitpunkt, während die Live-Triggerdistanz die aktuelle Marke verwendet. Zonenlebenszyklus, konservativ kalibriertes Modellvertrauen, Perzentil-Clusterrang und Standortzusammensetzung werden aus der verfügbaren Modellhistorie abgeleitet; USD Werte sind Szenariobereiche und keine beobachteten Positionswerte. Das Profil verwendet nur die neuesten Modellspalten und trennt modellierte Long- und Short-Exposure.

Die Vorwärtsvalidierung beginnt erst, nachdem der Browser einen Live-Trigger erkennt, der durch mindestens zwei Modellhorizonte bestätigt wird. Eine Vorhersage wird gespeichert, bevor nachfolgende Kerzen ausgewertet werden, läuft am ausgewählten Modellhorizont ab und wird erst dann als getestet markiert, wenn eine spätere Kerze die aufgezeichnete Preisspanne schneidet. Der nachfolgende Modellstatus kann sie als teilweise oder vollständig verbraucht klassifizieren; ein unberührter Ablauf wird ungültig. Die Aktualisierungsrate wird zurückgehalten, bis mindestens 30 Vorhersagen aufgelöst wurden. Die Ergebnisse sind lokal im Browser und werden niemals aus bereits bekannten Verlaufsdaten nachträglich aktualisiert. Browser-Zonenwarnungen sind optional, werden nach Standort gefiltert und dedupliziert.

Limit: Dieses Modell kann keine privaten Einstiegspreise, Hebelwirkung, Margin-Modus, Sicherheiten, Wartungsstufen oder einzelne Positionen beobachten. Preiscluster und Szenariobereiche sind analytische Annäherungen und keine Börsenliquidationsaufträge, Prognosen oder Handelssignale. Lokale Forward-Validierungsstatistiken stellen keine globale Performanceaussage dar.

Latenz und Wiederverbindungen

Browser-Netzwerk, die Verbindung des Benutzers und die vorgelagerte Börseninfrastruktur können die Übertragungslatenz beeinflussen. TradingHub überwacht den Quellstatus und stellt ausgefallene Streams wieder her. Eine Wiederverbindung kann eine vorübergehende Lücke in den Beobachtungen verursachen; Die Schnittstelle sollte diesen Zustand melden, anstatt eine ununterbrochene Abdeckung zu suggerieren.

Methodik der Markets-Datenbank

Identität: jede Kryptowährung besitzt eine dauerhafte TradingHub-ID und genau eine kanonische Projektseite. Netzwerke und verifizierte Token-Verträge gehören zum selben Projekt. Frühere Namen, Ticker und Slugs bleiben auffindbar; alte URLs werden dauerhaft auf die aktuelle kanonische Seite umgeleitet.

Preis und Chart: die Preis- und Chart-Ingestion ist anbieterunabhängig. Für jedes Projekt bzw. jeden Markt werden konfigurierte Quellen mit expliziten Prioritäten und Zuordnungen verwendet; die Laufzeit prüft geeignete Quellen in Prioritätsreihenfolge, validiert Antworten und bewahrt die Provenienz. Keine Börse ist architekturweit eine universelle Primärquelle. Fällt ein Anbieter aus, kann die nächste konfigurierte Quelle verwendet werden, ohne die öffentliche Bedeutung des Assets zu verändern. Historische Kurse stammen aus realen Kerzendaten der Börsen-APIs. D1 bewahrt den letzten gültigen Snapshot und Chart auf. Fallen beide Quellen aus, werden die Daten als veraltet gekennzeichnet und nicht durch Nullwerte ersetzt.

Marktkapitalisierung, Angebot und Volumen: für jedes kanonische Markets/Radar-Asset ist eine eigene geprüfte P1-Angebotsquelle festgelegt: Protokoll, Blockchain/Explorer, Emittenten-/Foundation-API oder eine andere projektspezifische Quelle mit definiertem Lese- bzw. Berechnungsverfahren. CoinGecko wird nur als P2-Fallback verwendet, wenn die Primärquelle ausfällt; CoinPaprika und CoinLore gehören nicht zur normalen P1/P2-Supply-Kette. Tatsächlich verwendete Quelle, URL und Fallback-Priorität werden zusammen mit dem validierten Cache gespeichert. Die Marktkapitalisierung wird aus dem aktuellen TradingHub-Preis und einer verlässlichen Umlaufmenge berechnet.

Handelsplätze und Verträge: unterstützte CEX-Adapter werden erst nach Bestätigung des Instruments durch die Börse als API-verifiziert gekennzeichnet. Jede zusätzliche CEX oder DEX kann manuell mit einer eindeutigen Markt-URL gepflegt werden; sie bleibt sichtbar als manueller Eintrag, wird nie als API-verifiziert dargestellt und erhält keine erfundenen Preis- oder Volumendaten. Token-Verträge werden nur nach Prüfung angezeigt; native Assets besitzen keinen Token-Vertrag.

Aktualisierung: öffentliche Lesezugriffe liefern sofort den letzten gültigen D1-Snapshot. Preis-Snapshots werden alle 3 Minuten aktualisierbar, CEX-Listings alle 6 Stunden verifiziert, die geprüfte Umlaufmenge alle 12 Stunden aktualisiert und Chart-Bereiche 15 Minuten zwischengespeichert. Verteilte Refresh-Sperren verhindern doppelte Upstream-Aufrufe, unveränderte normalisierte Werte werden nicht erneut geschrieben und der Health-Status wird nur bei einer Zustandsänderung persistiert. Die Erkennung erzeugt ausschließlich Admin-Kandidaten und veröffentlicht kein Projekt automatisch. Die Aufnahme in den Radar erfolgt immer manuell und ist weder Bewertung noch Empfehlung.

Eine konfigurierte Quelle wird erst nach der Validierung verwendet. Leere HTML-Felder übernehmen keine Zahlen anderer Kennzahlen; Aggregatordaten auf einer Explorer-Seite gelten nicht als primäre Blockchain-Belege. Widersprüchliche Angebotsmengen und veraltete Zeitstempel werden abgelehnt. Eine fehlgeschlagene Abfrage ersetzt einen noch aktuellen Primärwert nicht durch Aggregatordaten. Jeder Vermögenswert wird nach 12 Stunden erneut geprüft; die Verarbeitung wird bei weiteren Besuchen in Gruppen von sechs Werten fortgesetzt. Aktualisierungen erfolgen auf Anfrage, nicht nach einem garantierten Zeitplan.