TrajectoryRL Validator v0.7.8 verbrennt Miner-Auszahlungen standardmäßig auf Bittensor Subnet 11
Wichtige Erkenntnisse
- •TrajectoryRL hat am 8. November 2026 den Validator v0.7.8 mit standardmäßig aktiviertem BURN_ALL-Flag veröffentlicht und leitet 100 % der Miner-Gewichtung auf Owner UID 74 auf Bittensor Subnet 11 um.
- •Unter dem neuen Standard erhält der sitzende Fusion-Policy-Gewinner keine Miner-Emission, da die Recycle-or-Burn-Einstellung von SN11 den umgeleiteten Anteil vernichtet.
- •Betreiber können die normalen Gewinner-Auszahlungen nur durch explizites Setzen von BURN_ALL=0 wiederherstellen, da der Environment-Loader ein nicht gesetztes Flag als aktiviert behandelt.
- •Der Burn erfordert kollektive Übernahme, weil Yuma Consensus die Eigen-Gewichtung eines Validators ignoriert – jeder Validator muss übereinstimmende Gewichtungen setzen, damit der Burn auf UID 74 wirksam wird.
- •Das Team berichtet mit Verweis auf einen SN53-Präzedenzfall, dass das vollständige Verbrennen des Miner-Anteils den TAO-Emissionsanteil von SN11 gegen null drückt, während Validator-Dividenden und der Owner-Anteil unberührt bleiben.

TrajectoryRL hat den Validator v0.7.8 am 8. November 2026 veröffentlicht und aktiviert seine BURN ALL-Emissions-Einstellung damit standardmäßig in einem gemergten Pull Request. Auf Bittensor Subnet 11 (SN11) richtet jeder Gewichtungs-Tick nun 100 % der Miner-Gewichtung auf Owner UID 74 und ignoriert dabei den sitzenden Fusion-Policy-Gewinner. Da SN11 recycelte Miner-Emission verbrennt, wird dieser Miner-Anteil vernichtet statt ausgezahlt.
Die Änderung ist im öffentlichen trajectoryRL-Repository als Release-Tag v0.7.8 gelandet, und derselbe Commit erhöht die Validator-Version. Betreiber können die normalen Gewinner-Gewichtungen nur wiederherstellen, indem sie BURN_ALL=0 setzen.
Wie BURN ALL die Gewichtungs-Ticks verändert
Unter dem normalen Anreizpfad von SN11 lesen Validatoren den kanonischen Gewinner der Plattform und rufen set_weights auf. Der sitzende Miner erhält dann den vollen Miner-Anteil. Laut der Dokumentation zum Anreizmechanismus des Projekts wurde der Burn auf das Owner UID bereits durchgeführt, wenn kein Sitz existierte. Das neue BURN_ALL-Flag erstreckt diesen Burn-Pfad auf jedes Tempo, das wiederkehrende Fenster, in dem Validatoren Gewichtungen auf die Chain schreiben, selbst während ein Gewinner sitzt.
Im Code ist der Standard explizit. Das Burn-Flag ist standardmäßig aktiviert, und der Environment-Loader behandelt ein nicht gesetztes BURN_ALL als "1". Wenn das Flag aktiv ist, setzt der Gewichtungs-Tick UID 74 mit Gewicht 1.0 und überspringt den Gewinner-Zweig. Unit-Tests im gemergten Pull Request fixieren dieses Verhalten: Der Burn-Modus schreibt nur Owner UID 74, bei ausgeschaltetem Burn-Modus wird der Gewinner geschrieben, und der Standard bleibt aktiviert.
Die Maintainer sagen, der Burn müsse kollektiv erfolgen. Yuma Consensus, Bittensors Mechanismus zur Aggregation von Validator-Gewichtungen, ignoriert die Gewichtungen eines Validators auf sich selbst, daher kann UID 74 die eigene Zeile den Burn nicht allein tragen. Jeder Validator, der das neue Image ausführt, muss dieselben Gewichtungen setzen. Sobald das Image veröffentlicht ist, wird erwartet, dass Watchtower es für Community-Validatoren mit automatischen Updates zieht.
Warum ein Chain-Burn für einen KI-Wettbewerb relevant ist
Bittensor ist ein dezentrales KI-Netzwerk, dessen spezialisierte Subnets um Anteile an TAO, dem nativen Token des Netzwerks, konkurrieren. TrajectoryRL ist Bittensor Subnet 11. Miner reichen Fusion-Policies ein, die Agenten-Arbeit über Open-Weight-Modelle auf Engy verteilen, und Validatoren bewerten diese Pakete in Sandboxes. Der Produktanspruch von Season 2 ist, dass die sitzende Policy zu einsatzfähigem Auto-Routing wird. Die Aufgabe der Chain in diesem Kreislauf ist eng und ökonomisch: Sie ist die Gewichts- und Emissionsschicht, die entscheidet, wessen Alpha, der eigene Token des Subnets, ausgezahlt wird.
Die KI ist der umstrittene Gegenstand, nicht der Burn selbst. Fusion-Policies entscheiden, welche Modelle antworten, in welcher Reihenfolge und unter einer bemessenen Kostenobergrenze. Validatoren bewerten weiterhin Szenarien und können weiterhin einen Gewinner auf der Plattform setzen. Was v0.7.8 ändert, ist die Auszahlungsleitung, nachdem dieser Sitz existiert. Der Gewinn des Fusion-Rennens führt unter dem Standard nicht mehr dazu, dass der Miner-Emissionsstrom eingesammelt wird.
Verfolgt man ein Tempo unter dem neuen Standard: Die Plattform benennt weiterhin einen sitzenden Gewinner, und der Validator-Daemon tickt weiterhin. Statt die UID dieses Gewinners in die Chain-Gewichtungen zu schreiben, schreibt sie Owner UID 74 mit 100 %. Da der Recycle-or-Burn-Modus von SN11 auf Burn eingestellt ist, wird dieser Miner-Anteil vernichtet. Der Pull Request nennt zudem einen Nebeneffekt, den das Team laut eigener Angabe bereits vor dem Launch auf SN53 beobachtet hat: Wenn der Miner-Anteil vollständig verbrannt wird, fällt der Anteil von SN11 an der breiteren TAO-Emission gegen null, einschließlich Pool-Injektionen und Chain-Käufen. Validator-Dividenden und der Owner-Anteil bleiben laut den Autoren unberührt.
Was belegt ist – und was nicht
Was die Primärquelle belegt, ist ein Software-Standard und eine angegebene Subnet-Burn-Einstellung. Das Release, das Config-Flag, der Gewichts-Loop-Zweig und die Owner-UID-Konstante liegen alle im öffentlichen Baum. Die Behauptungen, dass Validatoren konvergieren werden, dass Watchtower den Rollout abschließen wird, und jeder exakte TAO-Anteils-Rückgang in Echtzeit sollten als operative Ergebnisse behandelt werden, da sie davon abhängen, wer das Upgrade durchführt und was die Chain nach dem Setzen der Gewichtungen zeigt.
Die Motivation bleibt Projekt-Deutung. Der Pull Request erklärt das Koordinationsproblem (Self-Weight-Masking) und verweist auf den SN53-Präzedenzfall. Er beweist für sich genommen nicht, wie lange der Burn aktiviert bleibt, ob Validatoren mit aktivierter Evaluation weiterhin in Sandboxes investieren, während die Miner-Auszahlung dunkel ist, oder wann BURN_ALL=0 zurückkehrt. Das sind nachgelagerte Fakten.
Für KI- und Blockchain-Leser liegt der Kern in der Trennung von Ranking und Belohnung. Ein Subnet kann Agenten-Policies weiter bewerten, während der Miner-Emissionspfad auf ein Burn-Ziel gerichtet ist. Wettbewerb, Evaluation und Produkt-Setzung können weiterlaufen, aber eine Auszahlung an den sitzenden Fusion-Gewinner kann unter diesem Standard nicht erfolgen, bis Betreiber das Flag abschalten oder die Flotte auseinandergeht. Das Experiment reiht sich ein in andere DeAI-Projekte, die neu definieren, wozu ein Stake oder ein Client dient, wie etwa 0Gs Weg von gestakten Assets zu KI-Compute-Credits.
Das mentale Modell ist einfach: TrajectoryRLs BURN ALL-Emission ist keine neue Bewertungsregel. Es ist eine Standard-Gewichtungs-Policy, die den Miner-Anteil zu Owner UID 74 umleitet, damit die Chain ihn verbrennt. Beobachtet werden sollte, ob Community-Validatoren tatsächlich auf v0.7.8 konvergieren, ob der TAO-Anteil von SN11 wie behauptet schrumpft und ob die sitzende Engy-Auto-Policy noch Verteidigung wert ist, wenn die Miner-Paycheck absichtlich leer bleibt.
Quelle: Live Bitcoin News