Solana SIMD 547: Eine ressourcenbasierte Grundgebühr, die vollständig verbrannt wird – potenziell mit täglichen Verbrennungen von über 1.500 SOL
Solana SIMD 547: Eine ressourcenbasierte Grundgebühr, die vollständig verbrannt wird – potenziell mit täglichen Verbrennungen von über 1.500 SOL
Solanas Design mit „niedrigen Gebühren, hohem Durchsatz“ hat dazu beigetragen, dass es zu einem primären Ort für On-Chain-Handel, Verbraucheranwendungen und Echtzeitzahlungen geworden ist. Aber mit zunehmender wirtschaftlicher Aktivität im Netzwerk, stellt sich im breiteren Kryptomarkt immer wieder die Frage: Sollte SOL mehr Wert aus ressourcenintensiver Nutzung ziehen, ohne die Benutzererfahrung zu beeinträchtigen, die Solana überhaupt wettbewerbsfähig gemacht hat?
Ein neuer Community-Vorschlag, SIMD 547, untersucht eine mögliche Antwort: eine ressourcenbasierte Grundgebühr einzuführen, die auf „Kosteneinheiten“ basiert und diese Gebühr vollständig verbrennt. Die Idee gewinnt an Aufmerksamkeit, da sie direkt die Solana-Tokenomics anspricht – insbesondere die Lücke zwischen der derzeit relativ geringen Gebührenverbrennung und der laufenden Emission des Netzwerks.
Im Folgenden wird der Vorschlag erläutert, warum er wichtig ist und welche Auswirkungen er auf Entwickler, Händler und alltägliche Benutzer haben könnte.
1) Warum sich die Solana-Gebührenverbrennung heute „zu klein“ anfühlt
Nach dem aktuellen Gebührenmodell von Solana setzen sich die Transaktionskosten grob wie folgt zusammen:
- Grundgebühr (signaturbasiert; derzeit 5.000 Lamports pro Signatur) plus
- Prioritätsgebühr (optional; festgelegt über Anweisungen für das Rechenbudget). Wenn eine Transaktion fehlschlägt, werden trotzdem Gebühren erhoben. Siehe die Dokumentation zur Solana-Gebührenstruktur. (solana.com)
Für die Tokenomics entscheidend ist:
- 50 % der Grundgebühr werden verbrannt, die anderen 50 % gehen an den validierenden Blockproduzenten.
- 100 % der Prioritätsgebühr gehen an die Validierer (nichts davon wird verbrannt). Details sind ebenfalls in derselben Dokumentation zur Gebührenstruktur zusammengefasst. (solana.com)
In der SIMD 547-Diskussion argumentiert der Vorschlagende, dass die aktuelle Verbrennung durch Grundgebühren wirtschaftlich winzig ist. Bei hohen Durchsatzannahmen wird geschätzt, dass durch den Grundgebührenmechanismus etwa 648 SOL pro Tag verbrannt werden – vernachlässigbar im Vergleich zur zitierten Inflationsrate von rund 60.000 SOL pro Tag. (github.com)
Diese Lücke ist die Motivation: Wenn SOL die Netzwerkaktivität widerspiegeln soll, wünschen sich einige Community-Mitglieder, dass die Verbrennungsdynamik des Protokolls stärker mit dem tatsächlichen Ressourcenverbrauch skaliert, nicht nur mit Signaturen.
2) Was SIMD 547 vorschlägt (in einfacher Sprache)
Der Kernvorschlag von SIMD 547 ist unkompliziert:
- Jeder Transaktion wird bereits eine geschätzte „Kosten“ basierend auf mehreren Ressourcendimensionen (nicht nur Rechenleistung) zugewiesen.
- Eine neue Grundgebühr wird basierend auf diesen Kosten berechnet, zu einem Preis von: 0,1 Lamport pro angeforderter Kosteneinheit, und 100 % davon werden verbrannt. (github.com)
Zur schnellen Auffrischung: Ein Lamport ist die kleinste Einheit von SOL (1 Lamport = 0,000000001 SOL). Siehe Solanas Terminologie-Referenz für Lamports. (solana.com)
„Kosteneinheiten“ vs. „Recheneinheiten“
Viele Benutzer sind mit Recheneinheiten vertraut, da sie bei der Optimierung von Prioritätsgebühren erscheinen. Die „Kosten“ in Solanas Planer sind jedoch breiter gefasst: Sie berücksichtigen Elemente wie Schreibsperren und die Datengröße geladener Konten, nicht nur die Rechenleistung. Dies spiegelt sich in der Erklärung der Gebühren und der Planung des Protokolls in der Dokumentation zur Gebührenstruktur wider (siehe die Verwendung von „Kosten“ bei der Transaktionsplanung). (solana.com)
Im SIMD 547-Thread betont der Autor auch, dass Kosteneinheiten Rechenleistung plus andere implizit angeforderte Ressourcen (geladene Daten, Heap, Schreibsperren und mehr) umfassen. (github.com)
3) Erwartete Auswirkungen auf die Verbrennung: „Bedeutend, aber keine Zauberei“
Einer der am meisten diskutierten Punkte ist, wie viel zusätzliches SOL tatsächlich verbrannt würde.
Im Thread teilte ein Community-Mitglied aktuelle Aggregationen der angeforderten Recheneinheitenlimits pro Tag und kam zu dem Schluss, dass der Mechanismus bei aktuellen Nutzungsniveaus wahrscheinlich zu einer zusätzlichen Verbrennung von etwa 1.500–1.800 SOL pro Tag führen würde, mit der Möglichkeit von mehr während Spitzenlastzeiten. (github.com)
Dies ist materiell mehr als die aktuelle Grundgebührenverbrennung, aber immer noch nicht ausreichend, um Solana unter normalen Bedingungen allein in einen zuverlässig deflationären Vermögenswert zu „verwandeln“ – insbesondere wenn höhere Gebühren die Nachfrage reduzieren. Dieser Kompromiss steht im Mittelpunkt der Debatte.
4) Wer zahlt mehr? Maker vs. Kleinanleger (und warum sich der Vorschlag darum kümmert)
Ein wichtiges Designziel ist es, die High-Frequency-Marktstruktur nicht zu beeinträchtigen, während für ressourcenintensivere Transaktionen mehr berechnet wird.
In der Ausarbeitung von SIMD 547 argumentiert der Vorschlagende, dass viele High-Frequency-Updates (oft mit Makern/Oracle-Updates verbunden) tendenziell relativ wenige Kosteneinheiten anfordern, sodass die zusätzliche Gebühr auf eine Steigerung im niedrigen einstelligen Prozentbereich bei diesen Arbeitsabläufen begrenzt werden könnte. (github.com)
Für gewöhnliche Benutzer, die derzeit Transaktionen mit niedrigen oder keinen Prioritätsgebühren einreichen, kann der relative Anstieg jedoch dramatisch aussehen. Der Thread enthält Beispiele, die dreistellige prozentuale Sprünge zeigen, darunter ein Szenario mit einem +639%-Anstieg beim Übergang von einer Transaktion mit minimaler Gebühr zu einer, die auch die neue ressourcenbasierte Verbrennungsgebühr zahlt. (github.com)
Praktisches Fazit
- Wenn Sie bereits auf Prioritätsgebühren angewiesen sind (z. B. für den Wettbewerbshandel), kann die inkrementelle Auswirkung prozentual gering sein.
- Wenn Sie typischerweise „billige“ Transaktionen senden (insbesondere in Kontexten mit geringer Dringlichkeit), kann Ihre Kostenempfindlichkeit höher sein.
Deshalb ist der Vorschlag umstritten: Er verbessert die Wertabschöpfung für SOL-Inhaber durch Verbrennung, aber er könnte auch die „günstige Standard“-UX verändern, die viele Benutzer mit Solana verbinden.
5) Die Alpenglow-Abhängigkeit: Warum das Timing wichtig ist
SIMD 547 wird nicht als etwas dargestellt, das sofort eingeschaltet werden kann.
In der Diskussion wird ausdrücklich darauf hingewiesen, dass die Kosten für die Validator-Abstimmung bis zur Aktivierung von Alpenglow wichtig sind und der Mechanismus nach Alpenglow aktiviert werden soll. (github.com)
Alpenglow selbst ist ein wichtiger Vorschlag zur Neugestaltung des Konsenses, formalisiert als SIMD 0326. Der Vorschlag ersetzt den aktuellen Konsens auf Basis von Proof-of-History + TowerBFT durch Alpenglow (Votor) für bessere Leistung und Widerstandsfähigkeit. Siehe das SIMD 0326 Dokument. (github.com)
Daher ist SIMD 547 in der Praxis am besten als Teil einer umfassenderen Roadmap zu verstehen: zuerst den Konsens und die Abstimmungsmechanismen ändern, dann die Tokenomics-Regler neu justieren, die unter den heutigen Annahmen schmerzhaft wären.
6) Offene Fragen, die die Community wahrscheinlich diskutieren wird
Selbst Unterstützer stimmen in der Regel zu, dass die Details wichtig sind. Basierend auf dem Thread und Solanas aktuellen Gebührenmechanismen ist mit Debatten über Folgendes zu rechnen:
- Angefragte vs. genutzte Ressourcen: Die Berechnung auf Basis der „angefragten Kosten“ ist einfach und vorhersehbar, kann aber falsch konfigurierte Transaktionen überladen (ähnlich wie Prioritätsgebühren von angeforderten CU-Limits abhängen). (solana.com)
- UX auf App-Ebene: Wallets und dApps benötigen möglicherweise eine bessere Gebührenschätzung und klarere Aufschlüsselungen („wie viel ist Verbrennung, Trinkgeld, Grundgebühr?“).
- Spam- und DoS-Ökonomie: Eine stärkere Verbrennung könnte bestimmte missbräuchliche Muster abschrecken, aber sie kann auch legitime, hochkomplexe Anwendungsfälle (DeFi-Routing, fortgeschrittene Programminteraktionen) benachteiligen.
- Tokenomics vs. Adoption: In den Jahren 2025–2026 lag der Branchentrend in Richtung nachhaltigerer Gebührenmärkte und klarerer Wertabschöpfung – aber Netzwerke, die übers Ziel hinausschießen, können Aktivität zu Alternativen verlagern.
Für Leser, die die primäre Diskussion verfolgen möchten, ist der ursprüngliche SIMD 547 Community-Thread der beste Ausgangspunkt. (github.com)
7) Was Benutzer und Entwickler jetzt tun können
Auch wenn SIMD 547 noch diskutiert wird und nicht aktiv ist, ist dies ein guter Zeitpunkt zur Vorbereitung:
Für dApp-Teams
- Überprüfen Sie Transaktionen, die routinemäßig hohe Limits „zur Sicherheit“ anfordern. Die Dokumentation von Solana erklärt, wie sich Prioritätsgebühren von angeforderten Grenzen für Recheneinheiten in der Dokumentation zur Gebührenstruktur ableiten. (solana.com)
- Verfolgen Sie, wie oft Ihre Benutzer auf „keine Prioritätsgebühr“-Flows angewiesen sind; diese sind am stärksten von einer neuen obligatorischen Verbrennungskomponente betroffen.
Für Händler und Power-User
- Wenn Sie Automatisierung betreiben, modellieren Sie Gebühren als (Basisgebühr für Signaturen + Prioritätsgebühr + potenzielle ressourcenbasierte Verbrennung), anstatt die Verbrennung als Rundungsfehler zu behandeln.
- Wenn Sie Aktionen stapeln, überlegen Sie, ob weniger, aber schwerere Transaktionen weniger attraktiv werden als granularere Interaktionen.
Für alle: Selbstverwahrung zählt weiterhin
Debatten über Gebührenmechanismen und Tokenomics führen tendenziell zu mehr On-Chain-Experimenten (neues Routing, neue MEV-Strategien, neue Bots). Das ist auch die Zeit, in der Phishing und bösartige Genehmigungen sprunghaft ansteigen.
Wenn Sie SOL langfristig halten oder häufig mit Solana DeFi interagieren, kann eine Hardware-Wallet wie OneKey helfen, indem sie private Schlüssel offline hält und explizite Transaktionsgenehmigungen erfordert – nützlich, wenn die Transaktionszusammensetzung (und Gebührenaufschlüsselungen) komplexer werden.
Fazit
SIMD 547 ist ein auf Tokenomics fokussierter Vorschlag, der versucht, eine schwierige Balance zu finden: die SOL-Verbrennung so zu erhöhen, dass sie mit dem Ressourcenverbrauch skaliert, während eine pauschale Gebührenerhöhung vermieden wird, die Validierer und die High-Frequency-Liquiditätsbereitstellung stören könnte.
Wenn er wie vorgeschlagen umgesetzt wird, schätzen Community-Schätzungen, dass er bei aktuellen Nutzungsniveaus etwa 1.500–1.800 SOL pro Tag zusätzliche Verbrennung einbringen könnte – im Verhältnis zur Emission immer noch moderat, aber nicht mehr vernachlässigbar. (github.com)
Vorerst ist der wichtigste Punkt nicht die genaue Zahl – sondern die Richtung: Solana erforscht aktiv, wie Netzwerkressourcen, Gebührenmärkte und die Wertabschöpfung von SOL aufeinander abgestimmt werden können, wahrscheinlich parallel zu größeren Protokolländerungen wie Alpenglow. (github.com)
