Michael JohnsonFünfzehn Mining-Betreiber, ASIC-Hersteller und Mining-Pools haben vereinbart, Integrationen mit dem offenen Mining Development Kit (MDK) zu entwickeln und zu unterstützen, teilte Tether am 24. Oktober 2026 mit. Für die Branche ist dies ein Versuch, ein praktisches Problem zu lösen: Unterschiedliche Hardware und Softwaresysteme sollen über eine gemeinsame Ebene verbunden werden, damit Anwendungen mit wiederverwendbaren Integrationen auf sie zugreifen können.
Im Zentrum der Architektur stehen Workers: Adapter, die die Schnittstelle einer bestimmten Hardware, eines Pools oder eines Systems in das MDK-Format übersetzen. Die Beteiligten behalten ihre bestehenden Technologien und entscheiden selbst, welche Funktionen sie über einen Adapter bereitstellen. Für Anwendungsentwickler bedeutet dieser Ansatz, dass eine Integration mit der gemeinsamen Ebene genügt, statt mit jedem Hersteller einzeln.
Was genau angekündigt wurde
Tether nannte Beteiligte aus drei Gruppen: Betreiber von Mining-Anlagen, Hardwarehersteller und Mining-Pools. Zu den aufgeführten Unternehmen zählen Bitdeer, BITMAIN, Canaan, Foundry Digital, MicroBT und OCEAN. Der angekündigte Beitrag besteht in der Entwicklung und Unterstützung eigener Workers. Die Ankündigung legt weder einen gemeinsamen Zeitplan für die Fertigstellung der Adapter fest noch bestätigt sie, dass jeder davon bereits in einer Produktionsumgebung läuft.
Im MDK-Repository wird das Projekt als Node.js-SDK für Infrastrukturüberwachung, die Verwaltung von Geräten und Containern, die Erfassung von Telemetriedaten und die Entwicklung von Anwendungen beschrieben. Die Architektur ist in Kern, Workers und Werkzeuge für die Benutzeroberfläche gegliedert. Das Gateway verbindet die Geschäftslogik mit dem Kern, der Daten von den Workers empfängt und ihnen Befehle übermittelt. Das Projekt umfasst außerdem einen MCP-Server.
Warum Mining eine gemeinsame Schnittstelle braucht
In einer Anlage können Maschinen verschiedener Hersteller und Softwaresysteme mit jeweils eigenen Protokollen gleichzeitig zum Einsatz kommen. Jede neue Integration erhöht den Umfang der individuellen Entwicklungsarbeit und erschwert die Überwachung des gesamten Geräteparks. Ein Worker fungiert als Übersetzer zwischen einem bestimmten System und einer Anwendung: Ein Überwachungstool kann beispielsweise die gemeinsame Ebene ansprechen, während der Adapter die Anfrage in die Schnittstelle der ausgewählten Hardware übersetzt.
Diese Struktur ist für die Automatisierung nützlich, unabhängig davon, ob ein Betreiber KI einsetzt. Zunächst ermöglicht eine gemeinsame Schnittstelle, Daten zu erfassen und zulässige Befehle einheitlich zu senden; darauf aufbauend lassen sich dann Regeln oder agentische Anwendungen entwickeln. Tether zufolge läuft der eigene QVAC-Mining-Agent bereits auf MDK. Das ist ein von dem Unternehmen angeführtes Integrationsbeispiel, keine veröffentlichte Messung der Auswirkungen auf Energieverbrauch, Ausfallzeiten oder Mining-Rentabilität.
Was Entwickler jetzt prüfen können
Am 24. Oktober wies das Repository Version 0.11.0 aus und kennzeichnete MDK zugleich als aktiv entwickeltes Projekt, das noch nicht als stabil gilt. Für eine praktische Bewertung lässt sich der Demo-Stack aus dem Repository starten: Die README beschreibt Varianten mit Kern, Workers, simulierten Geräten, Gateway-API und Benutzeroberfläche. In der Demo nutzen die Workers reale Verbindungs- und Telemetriepfade, verbinden sich jedoch mit lokalen Simulationen; die Telemetriewerte sind synthetisch. So können Entwickler die Architektur und die Erstellung von Integrationen prüfen, ohne den Betrieb an echter Mining-Hardware zu bewerten.
In der Ankündigung nannte Tether Ende 2026 als Zieltermin für die stabile Version 1.0. Für Teams, die MDK bewerten, ist es sinnvoll, zunächst zu prüfen, ob die benötigten Workers vorhanden sind und welche Befehle und Daten sie bereitstellen, und anschließend die Ausfallsicherheit mit der eigenen Hardware gesondert zu testen. Laut README und Repository-Status von MDK befindet sich die öffentliche API vor Version 1.0 noch in Entwicklung. Integrationen sollten daher mögliche Änderungen berücksichtigen.
Die Erklärung der 15 Unternehmen ist vor allem als Koordination rund um eine gemeinsame Schnittstelle bedeutsam: Der Nutzen von MDK für Betreiber wird davon abhängen, wie umfassend die Beteiligten ihre Adapter implementieren und unterstützen. Entwickler können den Code bereits jetzt untersuchen und Architekturszenarien testen; die angekündigte stabile Version 1.0 bleibt vorerst ein Ziel für Ende des Jahres.