Gestern habe ich ganz beiläufig den Explorer nach $DUSK Zahlen durchgesehen. Nichts Besonderes geplant. Dann haben mich diese beiden Zahlen völlig gestoppt:
24h Burned: 22,163 $DUSK
24h Rewards Paid: 149,388 $DUSK
Fast 15 % der täglichen Rewards sind einfach verschwunden.
Ich saß da eine Minute und dachte: „Okay, also verbrennt das Team Tokens, um Knappheit zu erzeugen, richtig? Klassischer Move.“
Aber dann bin ich tiefer eingestiegen, wie die Rewards auf @Dusk tatsächlich funktionieren.
Der Block-Generator bekommt feste 70 %. Außerdem gibt es zusätzliche 10 %, die nur ausgezahlt werden, wenn genug Komitee-Stimmen (Credits) rechtzeitig in der Bescheinigung auftauchen. Was von diesen 10 % nicht beansprucht wird, weil die Attestationen unvollständig sind? Das geht an niemanden. Es verbrennt. Automatisch.
Kein Button. Keine Marketing-Ankündigung. Kein „Wir haben beschlossen, heute zu verbrennen.“
Es ist einfach das Protokoll, das sagt: „Wenn das Abstimmungskomitee in diesem Block nicht vollständig koordiniert ist, verschwindet dieses zusätzliche Stück.“
Also ist die Burn-Rate nicht wirklich ein Tokenomics-Regler, den das Team dreht. Eher wie ein Live-Health-Check, wie gut die Bereitsteller tatsächlich auftauchen und gemeinsam abstimmen.
Hoher Burn auf einem Abschnitt = mehr verpasste Attestationen.
Niedriger Burn = Komitees machen ihre Arbeit sauber.
Ich bin auf der Suche nach einer Knappheits-Erzählung reingekommen. Was ich gefunden habe, war ein Konsens-Performance-Messgerät, das Tokenomics-Kleidung trägt.
Trotzdem neugierig, wie eng das wirklich mit der echten Validator-Uptime zusammenhängt – im Vergleich zu nur normalem Komitee-Overhead über die Zeit. Beobachtet sonst noch jemand die Burn- vs. Rewards-Zahlen über Epochen hinweg?
#dusk
24h Burned: 22,163 $DUSK
24h Rewards Paid: 149,388 $DUSK
Fast 15 % der täglichen Rewards sind einfach verschwunden.
Ich saß da eine Minute und dachte: „Okay, also verbrennt das Team Tokens, um Knappheit zu erzeugen, richtig? Klassischer Move.“
Aber dann bin ich tiefer eingestiegen, wie die Rewards auf @Dusk tatsächlich funktionieren.
Der Block-Generator bekommt feste 70 %. Außerdem gibt es zusätzliche 10 %, die nur ausgezahlt werden, wenn genug Komitee-Stimmen (Credits) rechtzeitig in der Bescheinigung auftauchen. Was von diesen 10 % nicht beansprucht wird, weil die Attestationen unvollständig sind? Das geht an niemanden. Es verbrennt. Automatisch.
Kein Button. Keine Marketing-Ankündigung. Kein „Wir haben beschlossen, heute zu verbrennen.“
Es ist einfach das Protokoll, das sagt: „Wenn das Abstimmungskomitee in diesem Block nicht vollständig koordiniert ist, verschwindet dieses zusätzliche Stück.“
Also ist die Burn-Rate nicht wirklich ein Tokenomics-Regler, den das Team dreht. Eher wie ein Live-Health-Check, wie gut die Bereitsteller tatsächlich auftauchen und gemeinsam abstimmen.
Hoher Burn auf einem Abschnitt = mehr verpasste Attestationen.
Niedriger Burn = Komitees machen ihre Arbeit sauber.
Ich bin auf der Suche nach einer Knappheits-Erzählung reingekommen. Was ich gefunden habe, war ein Konsens-Performance-Messgerät, das Tokenomics-Kleidung trägt.
Trotzdem neugierig, wie eng das wirklich mit der echten Validator-Uptime zusammenhängt – im Vergleich zu nur normalem Komitee-Overhead über die Zeit. Beobachtet sonst noch jemand die Burn- vs. Rewards-Zahlen über Epochen hinweg?
#dusk
