TrajectoryRL ha rilasciato il validatore v0.7.8 l'8 novembre 2026, attivando per impostazione predefinita l'impostazione BURN ALL delle emissioni in una pull request integrata. Su Bittensor Subnet 11 (SN11), ogni weight tick punta ora il 100% del peso dei miners all'owner UID 74, ignorando il vincitore della fusion-policy in carica. Poiché SN11 brucia l'emissione riciclata dei miners, quella quota viene distrutta invece di essere pagata.

La modifica è arrivata nel repository pubblico trajectoryRL con il tag di release v0.7.8, e la stessa commit aggiorna la versione del validatore. Gli operatori possono ripristinare i pesi normali del vincitore solo impostando BURN_ALL=0.

Come BURN ALL modifica i weight tick

Nel normale percorso di incentivi di SN11, i validatori leggono il vincitore canonico della piattaforma e chiamano set_weights. Il miner in carica riceve quindi l'intera quota dei miners. Secondo la documentazione del meccanismo di incentivo del progetto, il meccanismo bruciava già a favore dell'owner UID quando nessun posto era assegnato. Il nuovo flag BURN_ALL estende quel percorso di burn a ogni tempo, la finestra ricorrente in cui i validatori scrivono i pesi sulla chain, anche quando un vincitore resta in carica.

Nel codice, il valore predefinito è esplicito. Il flag di burn è attivo per impostazione predefinita e il loader dell'ambiente tratta un BURN_ALL non impostato come "1". Quando il flag è attivo, il weight tick imposta l'UID 74 con peso 1.0 e salta il ramo del vincitore. Gli unit test nella pull request integrata bloccano questo comportamento: la modalità burn scrive solo l'owner UID 74, la modalità burn disattivata scrive il vincitore, e l'impostazione predefinita resta attiva.

I maintainer affermano che il burn deve essere collettivo. Yuma Consensus, il meccanismo di Bittensor per aggregare i pesi dei validatori, ignora il peso di un validatore su se stesso, quindi la riga dell'UID 74 da sola non può sostenere il burn. Ogni validatore che esegue la nuova immagine deve impostare gli stessi pesi. Una volta pubblicata l'immagine, si prevede che Watchtower la scarichi per i validatori della community che si aggiornano automaticamente.

Perché un burn on-chain conta per una competizione di AI

Bittensor è una rete AI decentralizzata le cui subnet specializzate competono per quote di TAO, il token nativo della rete. TrajectoryRL è Bittensor Subnet 11. I miners inviano fusion policy che instradano il lavoro degli agenti tra modelli open-weight su Engy, e i validatori valutano quei pacchetti in sandbox. La dichiarazione di prodotto della Stagione 2 è che la policy in carica diventi un auto routing distribuibile. Il compito della chain in questo ciclo è ristretto ed economico: è il livello pesi-ed-emissioni che decide di chi viene pagato l'alpha, il token proprio della subnet.

L'AI è l'oggetto conteso, non il burn stesso. Le fusion policy decidono quali modelli rispondono, in quale ordine e sotto un tetto di costo misurato. I validatori continuano a valutare gli scenari e possono ancora assegnare un vincitore sulla piattaforma. Ciò che v0.7.8 cambia è il canale di pagamento dopo che quel posto esiste. Vincere la corsa delle fusion policy non comporta più, per impostazione predefinita, la raccolta del flusso di emissione dei miners.

Seguiamo un tempo sotto la nuova impostazione predefinita. La piattaforma nomina comunque un vincitore in carica, e il demone del validatore continua a tickare. Invece di scrivere l'UID di quel vincitore nei pesi della chain, scrive l'owner UID 74 al 100%. Con la modalità recycle-or-burn di SN11 impostata su Burn, quella quota dei miners viene distrutta. La pull request afferma anche un effetto collaterale che il team dichiara di aver già osservato su SN53 prima del lancio: quando la quota dei miners è interamente bruciata, la quota di SN11 dell'emissione complessiva di TAO tende a zero, compresi l'iniezione nel pool e gli acquisti on-chain. I dividendi dei validatori e la quota dell'owner, secondo gli autori, restano invariati.

Cosa è dimostrato, e cosa no

Ciò che la fonte primaria dimostra è un'impostazione predefinita del software e un'impostazione di burn della subnet dichiarata. La release, il flag di configurazione, il ramo del loop dei pesi e la costante dell'owner UID sono tutti nell'albero pubblico. Le affermazioni che i validatori convergeranno, che Watchtower completerà il rollout e qualsiasi calo esatto della quota TAO in tempo reale vanno trattate come esiti operativi, poiché dipendono da chi esegue l'aggiornamento e da ciò che la chain mostra dopo che i pesi sono stati registrati.

La motivazione resta un'inquadratura del progetto. La pull request spiega il problema di coordinamento (self-weight masking) e cita il precedente SN53. Da sola non dimostra per quanto tempo il burn resterà attivo, se i validatori con eval continueranno a spendere nelle sandbox mentre i pagamenti ai miners sono oscurati, o quando BURN_ALL=0 tornerà. Sono fatti da verificare in seguito.

Per i lettori interessati ad AI e blockchain, la questione chiave è la separazione tra classifica e ricompensa. Una subnet può continuare a valutare le policy degli agenti mentre il percorso di emissione dei miners punta a un sink di burn. Competizione, valutazione e assegnazione del prodotto possono continuare, ma il pagamento al vincitore della fusion policy in carica no, sotto questa impostazione predefinita, finché gli operatori non disattivano il flag o la flotta diverge. L'esperimento si affianca ad altri progetti AI decentralizzati che riscrivono il significato di stake o client, come il percorso di 0G dagli asset staked ai crediti di compute AI.

Il modello mentale è semplice: l'emissione BURN ALL di TrajectoryRL non è una nuova regola di punteggio. È una policy di pesi predefinita che reindirizza la quota dei miners all'owner UID 74 affinché la chain la bruci. Ciò da osservare è se i validatori della community convergeranno effettivamente su v0.7.8, se la quota TAO di SN11 si comprimerà come dichiarato, e se la policy auto di Engy in carica varrà ancora la pena di essere difesa quando il stipendio del miner è volutamente vuoto.

Fonte: Live Bitcoin News