Ich habe Zahlen für DUSK gezogen und bin dabei länger an einer Zeile hängen geblieben, als ich vorhatte — Gebrannt (24h): 22,163.29 $DUSK gegen Rewards Paid (24h): 149,388.84. Block #4,314,618, Epoch #1,998, @Dusk , die Kette summt gleichmäßig in ihrem üblichen ~10s-Takt.
Das sind ungefähr 15 % des täglichen Reward-Pools, einfach … weg. Nicht weil jemand einen Burn-Button für die Optik gedrückt hat. Es ist in der Art eingebaut, wie Block-Rewards aufgeteilt werden — der Generator bekommt 70 % plus bis zu 10 % mehr, aber nur, wenn genug Komitee-Credits in das Zertifikat gelangen. Was nicht rechtzeitig attestiert wird, rollt nicht zu irgendeinem von uns weiter. Es brennt.
Also ist die Burn-Rate kein Stellrad zur Supply-Steuerung, das das Team für einen Schlagzeilen-Spin nutzt. Es ist ein Live-Readout, wie gut das Voting-Komitee Block für Block tatsächlich koordiniert. Hoher Burn in einem bestimmten Abschnitt = mehr verpasste Attestierungen als üblich, nicht „mehr Deflation, mehr bullisch“.
Hmm — irgendwie kippt das die Einordnung, mit der ich reingegangen bin. Ich ging davon aus, Burn sei ein bewusst eingesetzter Knappheitshebel. In der Praxis ist es eher ein Indikator für die Konsensgesundheit, der ein Tokenomics-Kostüm trägt. Allerdings bin ich noch nicht sicher, wie eng diese 24h-Zahl mit echter Validator-Uptime zusammenhängt, im Vergleich zu normalem Iterations-Overhead. Hat das jemand gegen epoch-über-epoch Wechsel/Churn gegengeprüft?
#dusk $DUSK @Dusk
Das sind ungefähr 15 % des täglichen Reward-Pools, einfach … weg. Nicht weil jemand einen Burn-Button für die Optik gedrückt hat. Es ist in der Art eingebaut, wie Block-Rewards aufgeteilt werden — der Generator bekommt 70 % plus bis zu 10 % mehr, aber nur, wenn genug Komitee-Credits in das Zertifikat gelangen. Was nicht rechtzeitig attestiert wird, rollt nicht zu irgendeinem von uns weiter. Es brennt.
Also ist die Burn-Rate kein Stellrad zur Supply-Steuerung, das das Team für einen Schlagzeilen-Spin nutzt. Es ist ein Live-Readout, wie gut das Voting-Komitee Block für Block tatsächlich koordiniert. Hoher Burn in einem bestimmten Abschnitt = mehr verpasste Attestierungen als üblich, nicht „mehr Deflation, mehr bullisch“.
Hmm — irgendwie kippt das die Einordnung, mit der ich reingegangen bin. Ich ging davon aus, Burn sei ein bewusst eingesetzter Knappheitshebel. In der Praxis ist es eher ein Indikator für die Konsensgesundheit, der ein Tokenomics-Kostüm trägt. Allerdings bin ich noch nicht sicher, wie eng diese 24h-Zahl mit echter Validator-Uptime zusammenhängt, im Vergleich zu normalem Iterations-Overhead. Hat das jemand gegen epoch-über-epoch Wechsel/Churn gegengeprüft?
#dusk $DUSK @Dusk
