Solana-Governance: Eine umfassende Analyse

Praktische Erkenntnisse

• Governance-Abstimmungen auf Solana sind unverbindlich und beratend. Sie dienen als Signal für die Stimmung in der Community. Wenn Validatoren ihren Standpunkt vor der vollständigen Implementierung signalisieren können, gibt das der Entwicklung Orientierung und minimiert Konflikte. Die endgültige Entscheidung fällt, wenn Validatoren auswählen, welche Software sie ausführen. Vorschläge können sich selbst nach einer Abstimmung noch ändern. Letztlich bildet Governance einen Konsens ab, sie erzwingt ihn nicht.
• SOL-Token-Inhaber beteiligen sich indirekt, indem sie ihre gestakten SOL an Validatoren delegieren, deren Abstimmungsverhalten ihren Werten oder Präferenzen entspricht. Es handelt sich um ein Verhältniswahlsystem, in dem Validatoren als gewählte Vertreter gelten können. Solana-Staker delegieren ihren Stake an Validatoren. Die Stimmkraft jedes Validators basiert auf seinem delegierten Stake.
• Governance-Abstimmungen auf Solana werden mit SPL-Token durchgeführt. Validatoren erhalten Token proportional zu ihrem aktiven Stake und senden sie an bestimmte Adressen, die verschiedene Abstimmungsoptionen repräsentieren. Validatoren können ihre Stimmen frei auf mehrere Optionen verteilen. Nach der Abgabe sind Stimmen endgültig und können nicht geändert werden.
• Alle konsensbrechenden Protokoll-Updates werden über Feature Gates aktiviert. Dabei handelt es sich um nicht abwärtskompatible Hard Forks. Anders als bei Bitcoin oder Ethereum, wo ein Hard Fork bei Uneinigkeit zu einer dauerhaften Aufspaltung der Chain führen kann, stellt Solanas Ansatz sicher, dass Feature Gates clusterweit an einem bestimmten Slot aktiviert werden. Validatoren führen das Upgrade vorher durch und verhindern so Chain Splits.
• Mehrere wirtschaftliche Änderungen in Solanas früher Entwicklung – insbesondere die Einführung von Priority Fees mit einer Verbrennung von 50 % – wurden ohne formelle Governance-Abstimmungen umgesetzt, da das Governance-System zu diesem Zeitpunkt noch unausgereift war.
• Das aktuelle Governance-Abstimmungsmodell – ausschließlich Validatoren stimmen ab – wurde nach einer beratenden Abstimmung im Oktober 2023 eingeführt. Mehr als 170 Validatoren nahmen teil und repräsentierten 14,3 % des gesamten Stakes. Über 70 % dieses Stakes sprachen sich für Abstimmungen ausschließlich durch Validatoren als praktischsten und effizientesten Ausgangspunkt aus.
• Die jüngste Abstimmung über SIMD-228 erreichte mit 74,3 % eine Rekordbeteiligung. Gemessen an Teilnehmerzahl und Marktkapitalisierung war sie das größte Blockchain-Governance-Ereignis der Geschichte. 281 Millionen SOL (~35 Mrd. $) und mehr als 900 Validatoren gaben über 1.000 Stimmen ab. Erstmals beteiligten sich große Börsen-Validatoren wie Coinbase, Kraken und Bybit aktiv. Das unterstreicht das wachsende institutionelle Engagement bei Solana.
• Ein wiederkehrendes Problem im Governance-Prozess von Solana ist die begrenzte Rolle von Delegierenden bei Entscheidungen. Derzeit gibt es keinen formellen Mechanismus, über den Delegierende ihre Präferenzen äußern oder Entscheidungen von Validatoren überstimmen können. Dadurch können die Stimmen von Validatoren den Präferenzen ihrer Delegierenden widersprechen.
• Auch die Rolle eines festgelegten Quorums bei Solana-Governance-Abstimmungen gibt Anlass zur Sorge. In der Praxis können Quoren Fehlanreize schaffen: Teilnehmer halten ihre Stimmen strategisch zurück, um zu verhindern, dass ein Vorschlag den erforderlichen Schwellenwert erreicht. Dieses Verhalten zeigte sich bei den Abstimmungsmustern für SIMD-228.
• Das Solana Foundation Delegation Program delegiert 10 % aller gestakten SOL (41,01 Millionen) an 897 Validatoren und verstärkt damit deren Stimmkraft. Eine Analyse der jüngsten Abstimmung über SIMD-288 zeigt, dass der SFDP-Stake überwiegend gegen den Vorschlag eingesetzt wurde. Hätte dieser Stake stattdessen mit JA gestimmt, wäre der Vorschlag angenommen worden. Hätte sich der vom SFDP delegierte Stake enthalten, wäre der Vorschlag weiterhin gescheitert, aber knapper – mit 64,77 % statt der tatsächlichen 61,39 %.
• Es bleibt unklar, was eine Governance-Abstimmung erfordert. Im März 2025 wurde eine geplante Abstimmung über SIMD-218 (IVC) zurückgezogen, nachdem sich ein Konsens gebildet hatte, dass dafür keine Governance-Genehmigung nötig sei. Auch SIMD-123 war trotz seiner Annahme nicht eindeutig eine wirtschaftliche Änderung und hätte womöglich keine formelle Abstimmung erfordert.

Einführung

Governance ist ein entscheidender Bestandteil der Dezentralisierung. Sie beeinflusst alles – von Protokoll-Upgrades und Wirtschaftspolitik bis zum Verhalten von Validatoren und den Standards der Community. Ein gut funktionierendes Governance-System verbessert Transparenz, Fairness und Vertrauen. Schlechte Governance kann dagegen zu Verwirrung, Stillstand oder einer Zentralisierung von Macht führen.

Die Governance von Solana befindet sich noch in einer frühen Entwicklungsphase. Wie viele Blockchain-Netzwerke startete Solana nicht mit einem vollständig ausgereiften oder formalisierten Governance-Framework. Es entwickelte sich stattdessen schrittweise weiter, geprägt durch Praktiken der Community, technische Einschränkungen und gewonnene Erkenntnisse. Solanas Governance zu verfeinern, bleibt ein fortlaufender, iterativer Prozess.

Das Solana-Ökosystem umfasst verschiedene, sich überschneidende Interessengruppen: Token-Inhaber, Staker, Nutzer, Validatoren, RPC-Betreiber, Anwendungsentwickler und Entwickler des Kernprotokolls. Jede Gruppe bringt andere Perspektiven, Anreize und Ziele mit. In einigen Bereichen stimmen diese Anreize überein. Häufig gehen sie jedoch auseinander, besonders bei der Verteilung von Ressourcen, der Kontrolle über das Protokoll und der Wirtschaftspolitik.

In dezentralen Systemen geht es bei Governance ebenso sehr um sozialen Konsens wie um Code. Blockchains werden oft mit „Code ist Gesetz“ beschrieben. Die Geschichte zeigt jedoch: Wenn der Konsens der Community es verlangt, kann und wird sich der Code ändern. Deshalb sind das Design von Governance-Mechanismen und ihre langfristige Weiterentwicklung genauso wichtig wie die ursprüngliche technische Architektur.

Dieser Bericht soll die Struktur, Entwicklung und den aktuellen Stand der Governance auf Solana verdeutlichen. Er bietet einen umfassenden Überblick darüber, wie Entscheidungen im Netzwerk getroffen werden und wie sich dessen Governance von anderen Blockchain-Ökosystemen unterscheidet. Der Bericht gliedert sich in vier Hauptabschnitte:

• Elemente der Solana-Governance – Untersucht die Kernkomponenten des Governance-Prozesses von Solana, darunter SIMDs, Aktivierungen von Feature Gates und formelle On-Chain-Abstimmungen.
• Analyse der Governance-Abstimmungen – Ein detaillierter Überblick über alle bisherigen formellen Governance-Abstimmungen, einschließlich Ergebnissen, Abstimmungsverhalten und Beteiligungskennzahlen.
• Herausforderungen und Empfehlungen – Eine Untersuchung der zentralen Probleme des aktuellen Governance-Modells von Solana, ergänzt um konkrete Empfehlungen, wo dies sinnvoll ist.
• Vergleich mit alternativen Netzwerken – Ein Blick auf die Governance in den vergleichbaren Ökosystemen Cosmos und Ethereum. Dabei werden Praktiken hervorgehoben, die Verbesserungen auf Solana anregen könnten.

Der Bericht lässt sich am besten der Reihe nach lesen. Jeder Abschnitt ist jedoch eigenständig konzipiert und kann unabhängig gelesen werden.

Elemente der Solana-Governance

Die folgende Tabelle bietet einen Überblick über das Governance-System von Solana. Sie nutzt ein analytisches Framework, das aus dem Aufsatz Analyse der Entscheidungsfindung in der Blockchain-Governance von Schädler, Lustenberger und Spychiger (2023) abgeleitet wurde. Wir haben dieses Framework an die spezifischen Mechanismen und Dynamiken des Solana-Ökosystems angepasst.

Änderungen am Solana-Protokoll durchlaufen einen mehrstufigen Prozess, der von Art und Auswirkungen der Änderung abhängt. Entscheidend ist unter anderem, ob die Änderung den Konsens bricht, wie sie sich auf Interessengruppen auswirkt und wie umstritten oder komplex sie ist. Eine konsensbrechende Änderung ist jedes Protokoll-Update, durch das Nodes mit unterschiedlichen Softwareversionen den Zustand der Blockchain unterschiedlich bewerten. 

Die folgende Tabelle zeigt die typischen Schritte für Änderungen unterschiedlicher Größenordnung. Als „große Änderungen“ gelten Änderungen mit potenziellen wirtschaftlichen Auswirkungen.

Im Folgenden beschreiben wir die Abläufe für die Aktivierung von Feature Gates, SIMDs und Governance-Abstimmungen im Detail.

Aktivierung von Feature Gates

Die Kernentwicklerteams von Anza und Firedancer veröffentlichen regelmäßig neue Features, darunter Syscalls, native Programme und wirtschaftliche Änderungen, die den Konsens brechen. Diese Features werden entwickelt, in neue Versionen der Client-Software aufgenommen und standardmäßig hinter einem Feature Flag deaktiviert. Das Feature Gate Program, das kürzlich zu einem Core-BPF-Programm migriert wurde, erfasst jedes neue Feature als Account. Ein für jedes Feature Gate einzigartiger privater Schlüssel gehört dem Core Contributor, der diesem Feature Gate zugeordnet ist. Sobald genügend gestakte Validatoren auf die neue Version aktualisiert haben und diese als stabil gilt, wird der Schalter für das Feature in der Runtime manuell durch eine Instruction aktiviert. Das Feature geht dann zu Beginn der nächsten Epoche auf allen Nodes im Netzwerk live. Die genaue Reihenfolge und der Zeitpunkt der Aktivierungen lassen sich über den Zeitplan der Feature Gates verfolgen. Die Feature-Aktivierung ist clusterunabhängig. Aktivierungen erfolgen zuerst im Testnet, dann im Devnet und zuletzt im Mainnet. So kann Vertrauen in die neuen Versionen aufgebaut werden, bevor sie abschließend im Mainnet aktiviert werden.

Der „Version Floor“ ist die derzeit mindestens unterstützte Softwareversion eines Clusters. Wenn neue Feature Gates aktiviert werden, wird der Version Floor auf die Softwareversion angehoben, in der das Feature enthalten war. Neue Features werden auf Solana in einem regelmäßigen Rhythmus aktiviert, üblicherweise an Epochengrenzen während der üblichen Geschäftszeiten an Wochentagen. Während Versionswechseln werden Aktivierungen pausiert. Sie werden ungefähr zwei Epochen fortgesetzt, nachdem 95 % des Stakes auf eine neue Minor-Version aktualisiert haben, zum Beispiel von Version 2.2 auf 2.3.

Aktivierungen von Feature Gates sind nicht abwärtskompatible Hard Forks, die nur durch universelle Übernahme wirksam werden. Aktualisiert ein Validator nicht auf eine Version, die ein aktiviertes Feature Gate erkennt, kann er den globalen Zustand nicht weiter validieren und weicht vom Netzwerk ab.

Anders als bei Bitcoin oder Ethereum, wo ein Hard Fork bei Uneinigkeit zu einer dauerhaften Aufspaltung der Chain führen kann, stellt Solanas Ansatz sicher, dass Feature Gates clusterweit an einem bestimmten Slot aktiviert werden. Validatoren müssen vorher aktualisieren und verhindern so Chain Splits. Feature Gates sind also Hard Forks, weil sie Konsensregeln ändern. Sie können jedoch nicht zu konkurrierenden Chains führen.

Neue Client-Versionen enthalten außerdem viele Änderungen, die den Konsens nicht brechen, etwa Code-Refactorings und Effizienzoptimierungen. Für sie ist kein Feature Gate erforderlich.

Solana Improvement Documents (SIMDs)

Vorschläge in Form von Solana Improvement Documents (SIMDs) sind die formelle Dokumentation, die für jede wesentliche Änderung an den Kernkomponenten von Solana erforderlich ist. Als „wesentlich“ gelten Änderungen, die typischerweise das Netzwerkprotokoll, die Gültigkeit von Transaktionen oder die Interoperabilität verändern. Unwesentliche Änderungen wie kleinere Code-Refactorings oder objektive Leistungsverbesserungen benötigen keinen Vorschlag. Vorschläge sollten die Begründung für das Feature und genügend Dokumentation enthalten, um die Implementierung nachvollziehen zu können. 

Das Einreichen von SIMDs ist erlaubnisfrei. Die meisten werden jedoch von Entwicklern der Client-Teams eingereicht, die in Vollzeit an Verbesserungen des Kernprotokolls arbeiten.

Es gibt zwei Arten von Vorschlägen: 

• Standardvorschläge: betreffen Kernfunktionen von Solana, zum Beispiel Konsens, Netzwerk und API-Schnittstellen
• Metavorschläge: behandeln Prozesse oder Richtlinien außerhalb der Codebasis

SIMDs durchlaufen üblicherweise die Phasen Ideenprüfung, Entwurf, Review und Annahme. Ein formelles Review erfolgt öffentlich auf GitHub. Der Autor des Vorschlags ist dafür verantwortlich, Feedback relevanter Core Contributors aus den Client-Teams von Agave und Firedancer einzuholen. Diese entscheiden unter Berücksichtigung von Sicherheit, Abwägungen und Abwärtskompatibilität, ob der Vorschlag angenommen, überarbeitet oder zurückgezogen wird.

Autoren sind nicht verpflichtet, ihre Vorschläge zu implementieren. Im Allgemeinen wird dies jedoch empfohlen, da es die besten Chancen auf einen erfolgreichen Abschluss bietet. Angenommene Vorschläge enthalten häufig ein zugehöriges Tracking-Issue für die Implementierung des Features und müssen üblicherweise über den Feature-Gate-Mechanismus von Solana aktiviert werden. 

Nicht jede Aktivierung eines Feature Gates erfordert ein SIMD. Die meisten werden jedoch von einem begleitet, um Kontext, Begründung und eine standardisierte Aufzeichnung der vorgeschlagenen Änderung bereitzustellen.

Governance-Abstimmungen

SIMDs mit erheblichen Auswirkungen auf das Protokoll, insbesondere auf wirtschaftliche Parameter, erfordern Governance-Abstimmungen. Der Governance-Prozess von Solana wird von erfahrenen Mitgliedern der Validator-Community geleitet. Er konzentriert sich ausschließlich auf kritische Themen, um das Engagement aufrechtzuerhalten und Governance-Müdigkeit zu vermeiden. Deshalb finden pro Jahr nur wenige Abstimmungen statt.  

Governance-Abstimmungen dienen vor allem dazu, die Stimmung gegenüber vorgeschlagenen Änderungen zu erfassen. Wenn Validatoren ihren Standpunkt vor der vollständigen Implementierung signalisieren können, gibt das der Entwicklung Orientierung und minimiert Konflikte. Eine Änderung ohne breiten Konsens umzusetzen, könnte Reibungen verursachen – besonders wenn mehr als ein Drittel des Netzwerks die Übernahme ablehnt.

Die Abstimmung erfolgt mit SPL-Token. Dem Identity-Account jedes aktiven Validators werden Token proportional zu seinem in Lamports gemessenen aktiven Stake zugeteilt. Der Validator kann diese Token dann an bestimmte Adressen senden, die verschiedene Abstimmungsoptionen einschließlich einer Enthaltung repräsentieren. Validatoren können ihre Stimmen frei auf mehrere Optionen verteilen – zum Beispiel 80 % auf JA und 20 % auf NEIN. So können sie die unterschiedlichen Präferenzen ihrer Staker flexibel abbilden. Nach der Abgabe sind Stimmen endgültig und können nicht geändert werden.

In dieser Struktur beteiligen sich SOL-Token-Inhaber indirekt, indem sie ihre gestakten SOL an Validatoren delegieren, deren Abstimmungsverhalten ihren Werten oder Präferenzen entspricht. Es handelt sich um ein Verhältniswahlsystem, in dem Validatoren als gewählte Vertreter gelten können. Solana-Staker delegieren ihren Stake an Validatoren. Die Stimmkraft jedes Validators basiert auf seinem aktiven Stake.

Die Grenzen der On-Chain-Governance

toly 🇺🇸

@toly

@garious14 There is no “governance”. It’s just a signal to check if the proposed upgrade would cause a contentious fork. It has to come from validators.

17. März 2025, 3:56 PM

Governance auf Solana ist letztlich unverbindlich und beratend. In der Praxis findet die eigentliche Abstimmung statt, wenn Validatoren auswählen, welche Softwareversion sie ausführen. Governance-Abstimmungen können breite Unterstützung oder Ablehnung in der Community anzeigen. Sie zwingen Validatoren jedoch nicht, bestimmten Code zu übernehmen. Vorschläge können sich sogar nach der Abstimmung ändern. Validatoren behalten die volle Kontrolle darüber, was auf ihrer Infrastruktur läuft. Bei Governance geht es daher stärker darum, Konsens zu signalisieren, als Ergebnisse durchzusetzen.

Core Contributors wie Anza, Jump und Jito sowie Infrastrukturanbieter wie Helius und Triton üben in diesem Kontext erheblichen informellen Einfluss aus. Validatoren werden sich diesen Gruppen wahrscheinlich nicht widersetzen, da sie sonst Stake verlieren oder nicht mehr mit dem Netzwerk synchron sein könnten. Dadurch können diese Akteure das Ergebnis von Upgrades wirksam prägen – unabhängig davon, ob sie formelle Entscheidungsbefugnisse besitzen.

In einem Extremszenario, in dem Validatoren ein Upgrade ablehnen, könnte es zu einem Fork kommen. Der DAO Fork von Ethereum im Jahr 2016, aus dem Ethereum Classic hervorging, bleibt ein warnendes Beispiel. Während sich der Governance-Prozess von Solana weiterentwickelt, muss die Beziehung zwischen signalisierenden Abstimmungen, Software-Releases und der tatsächlichen Übernahme durch Validatoren klarer werden. Das schafft Transparenz und vermeidet das Restrisiko von Chain Splits.

Analyse der Governance-Abstimmungen

Solanas frühe Governance: 2020–2022

Solanas ursprünglicher Governance-Ansatz unterschied sich stark vom heutigen Framework. Die frühe Governance konzentrierte sich auf das Feature Proposal Program. Damit konnten Validatoren mithilfe Stake-gewichteter SPL-Token über Protokolländerungen abstimmen. Sobald ein neues Feature-Release aktiviert werden konnte, erhielten Validatoren Abstimmungs-Token proportional zu ihrem aktiven Stake. Indem sie diese Token innerhalb eines zweiwöchigen Zeitfensters an einen bestimmten Account zurücksendeten, konnten Validatoren der Aktivierung des vorgeschlagenen Features zustimmen. Sobald ein Schwellenwert von 67 % des Stakes erreicht war, wurde die Änderung in der folgenden Epoche direkt On-Chain aktiviert.

Das Feature Proposal Program wurde mehrfach für Governance-Abstimmungen von Validatoren im Testnet und Mainnet eingesetzt. Am bedeutendsten war die Aktivierung des aktuellen Inflationsplans.

Online-Aufzeichnungen dieser frühen Governance-Abstimmungen sind lückenhaft. Die ursprünglichen Solana-Foren wurden vom Netz genommen und sind nur noch als archivierte Versionen über die Wayback Machine zugänglich.

Dieser Mechanismus führte zwar ein gewisses Maß an On-Chain-Koordination ein, wurde jedoch weithin kritisiert. Validatoren konnten keine Ablehnung ausdrücken – nur JA-Stimmen wurden gezählt. Es gab keine formelle Möglichkeit, mit NEIN zu stimmen oder sich zu enthalten. Das System erzeugte außerdem sozialen Druck, Änderungen zu genehmigen, insbesondere wenn bereits erheblicher Entwicklungsaufwand in die Implementierung geflossen war. 

Noch wichtiger war, dass das System kein frühes Signal bot. Komplexe Features konnten somit entwickelt werden, ohne zu wissen, ob sie angenommen würden. Das führte zu Ineffizienz und verschwendeter Entwicklungszeit.

Insgesamt war das Feature Proposal Program ein wichtiger früher Schritt auf Solanas Weg zur Governance. Seine Einschränkungen prägten jedoch die Entwicklung der flexibleren Governance-Mechanismen, die heute eingesetzt werden.

Bemerkenswert ist, dass in dieser frühen Phase mehrere große wirtschaftliche Änderungen ohne formelle Governance-Abstimmungen umgesetzt wurden. Dazu zählt die Einführung von Priority Fees mit einer Verbrennung von 50 %. Das zeigt, wie wenig ausgereift das Governance-System damals noch war.

Solanas aktuelle Governance: seit 2023

Nach dem Feature Proposal Program entwickelte Solana sein heutiges System für Governance-Abstimmungen. Bisher fanden fünf offizielle Governance-Abstimmungen statt:

• Erste beratende Abstimmung im Oktober 2023
• SIMD-33 Timely Vote Credits im April 2024 von Bryan Ischo und Zantetsu, Shinobi Systems
• SIMD-96 Vollständige Priority Fee für Validatoren im Mai 2024 von Tao Zhu, Anza
• SIMD-123 Protokollinterne Verteilung von Block-Belohnungen von Justin Starry, Anza
• SIMD-228 Marktbasierter Emissionsmechanismus von Tushar Jain und Vishal Kankani, Multicoin Capital, Max Resnick, Anza im März 2025

Erste beratende Abstimmung

Eine entscheidende frühe Weichenstellung für das aktuelle Governance-Framework von Solana war die Frage, wer am Abstimmungsprozess teilnehmen sollte. Der Community wurden drei Optionen präsentiert:

1. Nur Validatoren stimmen ab, wobei die Stimmen nach Stake gewichtet werden
2. Validatoren und Stake-Accounts, wobei Delegierende die Stimme ihres Validators überstimmen können
3. Validatoren, Stake-Accounts und andere Interessengruppen wie RPC-Betreiber und Entwickler

An der beratenden Abstimmung nahmen mehr als 170 Validatoren teil, die 14,3 % des gesamten Stakes repräsentierten. Von dem Stake, der abstimmte, unterstützten über 70 % ein Modell, in dem nur Validatoren abstimmen. 24 % bevorzugten ein Modell mit Validatoren und Delegierenden. Für diese Abstimmung galt keine Mindestbeteiligung.

Abstimmungen ausschließlich durch Validatoren galten als praktischster und effizientester Ausgangspunkt, da die erforderliche Infrastruktur bereits vorhanden und in der Praxis erprobt war. Komplexere Systeme mit Delegierenden oder anderen Interessengruppen wurden für einen jungen Governance-Prozess als verfrüht und potenziell belastend angesehen. Die Community erkannte an, dass alternative Abstimmungsmodelle mit zunehmender Reife der Governance durch künftige Vorschläge eingeführt und verfeinert werden könnten.

Abstimmungsmuster der Governance

Seit der ersten beratenden Abstimmung gab es vier weitere Governance-Abstimmungen mit denselben drei Optionen: JA, NEIN und Enthaltung. Diese Optionen zeigen die Zustimmung zum vorgeschlagenen SIMD. Damit eine Abstimmung angenommen wird, müssen mindestens zwei Drittel der kombinierten JA- und NEIN-Stimmen dafür, also JA, sein. 

SIMD-33: Timely Vote Credits wurde mit überwältigender Unterstützung und 98,4 % JA-Stimmen angenommen. Diese unumstrittene Konsensänderung korrigierte falsch ausgerichtete Anreize. Sie beseitigte den Vorteil, den Validatoren zuvor durch verspätete Stimmen erhielten, und verbesserte so das Verhalten und die Fairness im Netzwerk.

SIMD-96: Vollständige Priority Fee für Validatoren wurde mit 77,7 % JA-Stimmen angenommen. Dieser wirtschaftliche Vorschlag sollte die Verarbeitung von Transaktionen über Nebenkanäle unattraktiv machen, indem 100 % der Priority Fees an Validatoren gehen. Das richtete die Anreize wirksam aus, war jedoch wegen eines moderaten Anstiegs der Inflation und einer wahrgenommenen Bevorzugung von Validatoren gegenüber SOL-Inhabern umstritten.

SIMD-123: Protokollinterne Verteilung von Block-Belohnungen wurde mit 74,91 % JA-Stimmen angenommen. Der Vorschlag führte einen optionalen, standardisierten Mechanismus ein, mit dem Validatoren Block-Belohnungen direkt an Staker verteilen können. Mehrere Validatoren taten dies bereits mit stärker manuellen Methoden. Die Aufnahme ins Protokoll löste jedoch eine Debatte über Wettbewerbsdruck aus. Es bestand die Sorge, dass die Provisionssätze für Block-Belohnungen in einem „Wettlauf auf null“ enden könnten.

SIMD-228: Marktbasierter Emissionsmechanismus wurde mit nur 61,39 % JA-Stimmen abgelehnt. Der Vorschlag sollte Solanas Inflationsrate stärker an die Staking-Beteiligung koppeln. Die Argumentation lautete, dass die aktuellen Emissionen zu hoch sind, nicht auf die Renditenachfrage reagieren und dazu führen, dass das Netzwerk zu viel für Sicherheit bezahlt.

Gegner äußerten Bedenken hinsichtlich der wirtschaftlichen Tragfähigkeit kleinerer Validatoren und der zusätzlichen Unsicherheit für Staking-Renditen. Die Abstimmung war äußerst umstritten. Sie löste umfassende Debatten aus und verdeutlichte die unterschiedlichen Ansichten zum langfristigen Wirtschaftsmodell von Solana.

Für Details zum Abstimmungsverhalten empfehlen wir die Open-Source-Dashboards zu SIMD-96, SIMD-123 und SIMD-228. Zusätzlich stellen wir eine Tabelle mit den hier verfügbaren Abstimmungsdaten bereit.

Für SIMD-228 und SIMD-123 galt ein Quorum von 33 % Stake-Beteiligung, einschließlich Enthaltungen. Frühere Vorschläge wie SIMD-96 und SIMD-33 hatten dagegen keine Mindestbeteiligung. Sie konnten unabhängig davon angenommen werden, wie viel des gesamten Stakes abstimmte.

Beteiligungsquoten

Die Beteiligung an Abstimmungen ist im Laufe der Zeit gestiegen. An der ersten beratenden Abstimmung im Oktober 2023 beteiligten sich nur 14,3 % des Stakes. Seitdem nahm die Beteiligung stetig zu. Den bisherigen Höhepunkt bildete die Abstimmung im März 2025 über SIMD-228, den marktbasierten Emissionsmechanismus, mit einer Beteiligung von 74,3 %. Bei den drei anderen bisherigen Abstimmungen war die Beteiligung relativ konstant und lag zwischen 51,2 % und 57,1 %.

Die Abstimmung über SIMD-228 war sowohl nach Teilnehmerzahl als auch nach repräsentierter Gesamtmarktkapitalisierung das größte Governance-Ereignis in der Geschichte der Kryptowährungen. Zum Zeitpunkt der Debatte war Solanas Marktkapitalisierung mit der von Bitcoin während der Blockgrößenkriege Mitte 2017 vergleichbar. Das unterstreicht die Bedeutung der Entscheidung. Insgesamt nahmen 281 Millionen SOL im Wert von 35 Milliarden US-Dollar an der Abstimmung teil. Mehr als 900 Validatoren gaben über 1.000 Stimmen ab. Besonders bemerkenswert: Große Börsen-Validatoren wie Coinbase, Kraken und Bybit beteiligten sich erstmals aktiv an Solanas On-Chain-Governance. Das signalisiert eine wachsende institutionelle Präsenz im Entscheidungsprozess des Netzwerks. Der jüngste Anstieg der Beteiligung, besonders durch Akteure aus den USA, könnte teilweise auch auf das günstigere regulatorische Klima für Blockchains unter der aktuellen Regierung zurückzuführen sein.

Probleme und Empfehlungen

Im nächsten Abschnitt untersuchen wir zentrale Herausforderungen bei Governance-Abstimmungen. Wo relevant, geben wir Empfehlungen, um Transparenz, Sicherheit und Effizienz zu verbessern.

Fehlende Beteiligung der Staker

Ein wiederkehrendes Problem im Governance-Prozess von Solana ist die begrenzte Rolle von Delegierenden bei Entscheidungen. Validatoren stimmen mit einer nach Stake gewichteten Governance-Macht über Vorschläge ab. Es gibt jedoch keinen formellen Mechanismus, über den Delegierende ihre Präferenzen äußern oder Entscheidungen von Validatoren überstimmen können. Dadurch können die Stimmen von Validatoren den Interessen ihrer Delegierenden widersprechen. Staker haben dann keine direkte Möglichkeit, das Ergebnis der Governance zu beeinflussen.

Validatoren mit Tausenden Delegierenden können individuelle Abstimmungspräferenzen nur schwer erfassen. Zudem beteiligen sich Staker üblicherweise nur wenig. Einige Validatoren gehen das Problem teilweise an, indem sie vor Abstimmungen ihre größten Delegierenden konsultieren und Stimmen anhand deren Präferenzen aufteilen. Andere experimentierten mit individuellen Tools, die das bestehende System für Token-Abstimmungen nachbilden. Sie geben ihren Stakern neue Governance-Token proportional zu deren Stake aus. Das bleibt jedoch eine Validator-spezifische Lösung und ist keine standardisierte Funktion für das gesamte Protokoll.

Gegner einer Beteiligung von Stakern argumentieren, dass die meisten Delegierenden keine technischen Experten sind, Governance-Entscheidungen selten genau verfolgen und nicht über das tiefe Verständnis der Blockchain-Mechanismen und Abwägungen verfügen, das fundierte Entscheidungen erfordern. Befürworter halten dagegen, dass die alleinige Abhängigkeit von Validatoren einen Interessenkonflikt schafft. Es sei unrealistisch zu erwarten, dass eine Mehrheit der Validatoren für Vorschläge stimmt, die dem Netzwerk nutzen, wenn diese Vorschläge ihren eigenen wirtschaftlichen Anreizen schaden.

Mögliche Verbesserungen sind bessere Kommunikationskanäle zwischen Validatoren und Delegierenden, etwa Governance-Dashboards, Tools zur Erfassung der Stimmung oder sogar Wallet-Benachrichtigungen bei Governance-Ereignissen. Ein späterer Abschnitt dieses Berichts greift das Thema erneut auf und untersucht den Ansatz des Cosmos-Ökosystems.

Herausforderungen im Governance-Diskurs

Effektive Governance in dezentralen Ökosystemen setzt klare Kommunikation mit hohem Informationsgehalt voraus. Während des jüngsten Vorschlags SIMD-288 schufen hitzige Debatten, persönliche Angriffe und Lagerbildung jedoch ein ungesundes Governance-Umfeld und behinderten letztlich produktive Diskussionen. Debatten über zentrale Vorschläge auf Solana können unter Ineffizienz und einem sinkenden Informationsgehalt auf verschiedenen Plattformen leiden. Technische Diskussionen auf GitHub und in den offiziellen Solana-Foren bieten strukturierte und durchdachte Debatten. Auf Discord und Twitter entwickeln sich sinnvolle Diskussionen jedoch gelegentlich zu Flamewars und persönlichen Angriffen. Das senkt die Gesamtqualität der Entscheidungsfindung.

Zudem beteiligen sich die meisten Teilnehmer erst in den letzten Tagen vor der Abstimmung, anstatt den gesamten Diskussionszeitraum zu nutzen. Eine frühere Beteiligung und besser strukturierte Governance-Zeitpläne könnten diese Probleme mindern. Wichtige Diskussionen sollten beispielsweise lange vor dem endgültigen Abstimmungsfenster stattfinden.

Governance-Calls erwiesen sich als effektiv. Sie ermöglichten direkten Austausch, schnelle Klarstellungen und boten weniger Gelegenheit für Trolling oder Irreführung. Eine stärkere Moderation, strukturierte Diskussionen und die Betonung faktenbasierter Analysen statt konfrontativer Auseinandersetzungen sind entscheidend für einen konstruktiven Governance-Prozess.

Bündelung von Governance-Vorschlägen

Governance-Entscheidungen sind oft am effektivsten, wenn über jeden Vorschlag einzeln abgestimmt wird. So können die Abstimmenden jedes Thema nach seinen eigenen Vorzügen bewerten. Ein zentrales Problem gebündelter Vorschläge ist unbewusste Voreingenommenheit: Wer zu einem Thema eine starke Meinung hat, lässt diese möglicherweise ungewollt in seine Haltung zu anderen, unabhängigen Themen einfließen. Das macht differenzierte Entscheidungen unwahrscheinlicher und könnte die Umsetzung ansonsten vorteilhafter Änderungen verhindern.

Ein weiteres Risiko: Durch die Bündelung steigt die operative Komplexität, wodurch Fehler wahrscheinlicher werden. Das zeigte sich bei der gemeinsamen Abstimmung über SIMD-228 und SIMD-123. Eine kleine Anzahl von Token, die für SIMD-123 bestimmt waren, wurde irrtümlich an die Enthaltungsadresse für SIMD-228 gesendet. Solche Fehler sind selten, verzerren aber Abstimmungsergebnisse und schwächen das Vertrauen in den Governance-Prozess.

Für die Bündelung von Vorschlägen spricht dagegen, dass mehrere Entscheidungen in weniger Abstimmungszeiträumen die Abstimmungsmüdigkeit verringern und eine höhere Beteiligung fördern können. Das kann das Engagement steigern, geht aber zulasten von Klarheit und Präzision bei Entscheidungen. Sind gebündelte Vorschläge komplex, benötigen sie außerdem häufig längere Diskussions- und Prüfungsphasen vor Beginn der Abstimmung. Nur so haben Abstimmende – insbesondere jene, die sich normalerweise erst in letzter Minute beteiligen – genügend Zeit, jede Komponente gründlich zu verstehen und zu bewerten.

Ein effektiverer Ansatz könnte sein, Governance-Vorschläge wann immer möglich zu trennen, damit jedes Thema unabhängig bewertet wird. Ist eine Bündelung nötig, sollte sie klar begründet werden.

Abstimmungsquoren

Die Rolle eines festgelegten Quorums bei Solana-Governance-Abstimmungen gibt Anlass zur Sorge. In der Praxis können Quoren Fehlanreize schaffen: Teilnehmer halten ihre Stimmen strategisch zurück, um zu verhindern, dass ein Vorschlag den erforderlichen Schwellenwert erreicht. Bei der jüngsten Abstimmung über SIMD-228 war dies besonders unter den NEIN-Wählern sichtbar. In den ersten beiden Abstimmungsepochen war eine Enthaltung für sie eine effektivere Strategie, als aktiv gegen den Vorschlag zu stimmen. 

Die Sichtbarkeit der laufenden Stimmenauszählung beeinflusst die Beteiligung. Manche Validatoren verzichten möglicherweise auf ihre Stimme, wenn das erwartete Ergebnis bereits ihrer Präferenz entspricht. Um die Manipulation des Quorums zu verhindern, könnte die Sichtbarkeit der Stimmen bis zum Ende des Abstimmungszeitraums verzögert werden.

Angesichts dieser Herausforderungen wächst die Unterstützung dafür, Anforderungen an das Quorum neu zu bewerten oder abzuschaffen. Das könnte eine direktere und transparentere Beteiligung an der Governance fördern.

Auswirkungen des SFDP

Zum Zeitpunkt der Erstellung dieses Berichts delegiert das Solana Foundation Delegation Program SOL an 897 Validatoren. Das entspricht 66 % aller aktiven Validatoren im Netzwerk. Insgesamt werden 41,01 Millionen SOL delegiert, also 10 % aller gestakten SOL. Vollständige Details zum Programm und seinen Delegationsstrategien findest du im früheren Bericht des Helius-Blogs über das SFDP.

Im aktuellen Governance-Modell wird die Stimmkraft der Validatoren im Programm faktisch verstärkt. Sie stimmen im Namen der Solana Foundation ab. Unsere interne Analyse und unser öffentliches Dashboard zur jüngsten Governance-Abstimmung über SIMD-288 bestätigen, dass der SFDP-Stake eine wichtige Rolle für Abstimmungsergebnisse spielt. Bei dieser Abstimmung wurde der SFDP-Stake überwiegend für NEIN-Stimmen gegen den Vorschlag eingesetzt. Hätte der vom SFDP kontrollierte Stake, der mit NEIN stimmte oder sich enthielt, stattdessen mit JA gestimmt, wäre der Vorschlag angenommen worden. Hätte sich der gesamte vom SFDP kontrollierte Stake neutral verhalten und enthalten, wäre der Vorschlag weiterhin gescheitert, aber knapper – mit 64,77 % statt der tatsächlichen 61,39 % bei erforderlichen 66,6 %.

Klare Kriterien für die Durchführung von Abstimmungen

Die Governance-Abstimmungen im März 2025 umfassten ursprünglich drei Vorschläge: SIMD-228, SIMD-123 und SIMD-218: Intermediate Vote Credits (IVC). IVC macht von Validatoren betriebene Mods überflüssig, die Abstimmungs-Credits für Tower BFT – Solanas Variante des pBFT-Konsensalgorithmus – optimieren. Dazu werden Credits für alle übergeordneten Blöcke automatisch nachgetragen, wenn Validatoren über einen untergeordneten Block abstimmen.

Während des Diskussionszeitraums bildete sich zunehmend ein Konsens, dass SIMD-218 keine Governance-Genehmigung benötigen sollte. Die Änderung galt weithin eher als Fehlerbehebung denn als wesentliche Protokolländerung, da sie das Upgrade Timely Vote Credits (TVC) lediglich verbesserte oder korrigierte. TVC hatte bereits eine Governance-Abstimmung bestanden und starke Unterstützung in der Community gezeigt. Eine informelle Umfrage unter Validatoren im Solana Tech Discord bestätigte diese Einschätzung mit nahezu einstimmiger Zustimmung.

Ingenieure von Anza wiesen außerdem darauf hin, dass SIMD-123: Protokollinterne Verteilung von Block-Belohnungen anders als vom Namen suggeriert keine wirtschaftliche Änderung war. Der Vorschlag führte eine optionale protokollinterne Methode ein, um Block-Belohnungen an Staker zu verteilen. Damit formalisierte er eine Praxis, die mehrere Validatoren bereits über alternative Methoden umsetzten, und standardisierte eine zuvor außerhalb des Protokolls stattfindende Aktivität.

Das wirft wichtige Governance-Fragen auf:

• Wer entscheidet, ob ein Vorschlag eine Abstimmung erfordert? Derzeit gibt es weder ein offizielles Gremium noch einen strukturierten Prozess, der festlegt, ob ein Vorschlag die Governance durchlaufen oder direkt umgesetzt werden sollte.
• Was eine „wesentliche Protokolländerung“ darstellt, bleibt unklar. Die Grenze zwischen einem routinemäßigen Upgrade und einer Änderung, die einen formellen Governance-Eingriff rechtfertigt, ist unscharf. Aktuelle Definitionen stützen sich stark auf den etwas vagen Begriff der „wirtschaftlichen Auswirkungen“.

Sicherheitsprobleme

Der aktuelle Abstimmungsprozess für Governance-Vorschläge nutzt das Drittanbieter-Tool solgov-distributor, das vom Community-Mitglied Laine entwickelt und gehostet wird. Dieses Tool ist ein Fork eines Merkle-basierten Token-Verteilers, den ursprünglich Jito entwickelt hat. Laine ist ein angesehenes Mitglied der Community. Die Abhängigkeit von einem extern kontrollierten Tool führt dennoch zu Vertrauensannahmen und Sicherheitsrisiken.

• Veränderbarkeit – Sowohl das Tool als auch seine Dokumentation sind veränderbar und können jederzeit einseitig geändert werden.
• Nutzung der Identity-Keypairs von Validatoren – Validatoren müssen die CLI erstellen und Token mit ihren hochsensiblen Validator-Identity-Keypairs beanspruchen. Jeder Prozess, der für den Zugriff auf derart kritische Zugangsdaten externe Software benötigt, birgt ein Sicherheitsrisiko.
• Abhängigkeit von einer einzelnen verantwortlichen Person – Ein offizieller Governance-Prozess sollte ohne formelle Sicherheitsgarantien oder unabhängige Audits keine kritischen Abhängigkeiten von externen Dritten haben.

Alternative Abstimmungsmechanismen

Es existiert bereits ein SPL-Tool für Feature-Vorschläge (Dokumentation hier), das ursprünglich für die On-Chain-Governance entwickelt wurde. Die jüngsten Governance-Prozesse nutzten diesen Ansatz jedoch nicht. Stattdessen kam solgov-distributor zum Einsatz. Das wirft die Frage auf, ob dieses zusätzliche Tool nötig war.

Das SPL-Token-System bietet grundsätzlich bereits eine native Methode, um Governance-Stimmkraft zu verteilen. Der Initiator des Prozesses könnte einfach SPL-Token an alle Validatoren verteilen. Diese könnten ihre Stimmen dann mit der standardmäßigen spl-token CLI abgeben, statt von einem externen Tool abhängig zu sein. Das würde unnötige Abhängigkeiten beseitigen und die Vertrauensminimierung des Abstimmungsprozesses verbessern.

Kommendes Tooling für On-Chain-Governance: SIMD-133

Das kommende SIMD-133: Get Epoch Stakes, dessen Aktivierung im Mainnet in Kürze geplant ist, führt neue Governance-Tools ein. Damit können Programme die Gewichtung von Stakes On-Chain abrufen. Derzeit kennen On-Chain-Programme weder die Verteilung des Stakes in der aktuellen Epoche noch die Menge des an die einzelnen Vote-Accounts delegierten Stakes.

Mit SIMD-133 können Governance-Programme über eine neue Sysvar On-Chain-Snapshots der Stake-Mengen von Validatoren erstellen. Externe oder manuelle Prozesse zur Verifizierung des Stakes werden damit überflüssig. Das vereinfacht den bestehenden Governance-Ablauf erheblich und beseitigt den Bedarf an einem manuellen Abgleich des Stakes.

Vergleich mit alternativen Netzwerken

Cosmos

Cosmos-SDK-Chains bieten ein auf Delegierende ausgerichtetes Governance-Modell. Staker können die Stimme ihres Validators direkt über verbreitete Wallets wie Keplr und Leap überstimmen. Ein Validator gibt zunächst eine Stimme mit dem vollen Gewicht seines Stakes ab. Delegierende, die anderer Meinung sind, können ihren Anteil am Stake jedoch einer anderen Abstimmungsoption zuweisen. Hält ein Validator beispielsweise 2 % des gesamten Stakes, aber ein Delegierender mit 1 % Stake-Gewicht widerspricht, kann dieser separat abstimmen. Dadurch sinkt die wirksame Stimme des Validators auf 1 %, während das andere 1 % einer anderen Option zugewiesen wird.

Dieses System stellt sicher, dass Delegierende immer das letzte Wort haben. Es schafft einen transparenten, nutzerfreundlichen und effizienten Governance-Prozess. Die Beteiligung an der Governance von Cosmos ist deutlich sichtbar. Abstimmungen sind direkt in Wallets und Block-Explorer integriert und dadurch für alle Interessengruppen leicht zugänglich.

Ein relevantes Beispiel für das unterschiedliche Abstimmungsverhalten von Stakern und Validatoren war die Abstimmung zur Halbierung von Cosmos ATOM (Vorschlag 848, Nov. 2023). Der Vorschlag sollte die maximale Inflationsrate auf 10 % senken:

• 94,93 % der Staker stimmten mit JA und unterstützten die Inflationsobergrenze.
• Nur 53,44 % der Validatoren stimmten mit JA, da viele ihre höheren Einnahmen erhalten wollten.

Diese Abweichung unterstreicht die Bedeutung der direkten Beteiligung von Stakern. Sie stellt sicher, dass Governance-Entscheidungen die allgemeine Stimmung der Community und nicht nur die Präferenzen von Validatoren widerspiegeln.

Das Governance-Modul von Cosmos ist auf Protokollebene integriert und stärkt damit seine Rolle als Kernfunktion der Blockchain. Bestimmte Governance-Entscheidungen können automatisch On-Chain ausgeführt werden. Das verbessert Transparenz und Rechenschaftspflicht. 

Dieses Modell bietet eine demokratische Governance-Struktur. Es hängt jedoch von aktiver Beteiligung ab und setzt voraus, dass Delegierende genug Zeit und Wissen für fundierte Entscheidungen haben. Cosmos bietet ein überzeugendes alternatives Governance-Framework, das Solana auf mögliche Verbesserungen untersuchen könnte.

Ethereum

Die Governance von Ethereum folgt einem sozialen Off-Chain-Prozess statt direkter Stake-basierter Abstimmungen. Der Entscheidungsprozess stützt sich hauptsächlich auf Ethereum Improvement Proposals (EIPs), Kernentwickler und den Konsens der Community.

Änderungen an Ethereum werden über EIPs vorgeschlagen, die den SIMDs von Solana entsprechen. Diese EIPs beschreiben neue Features, Standards oder Upgrades für das Ethereum-Protokoll. Ethereum Requests for Comments (ERCs) definieren Standards für Funktionen der Anwendungsebene, etwa ERC-20-Token und ERC-721-NFTs. Diese Vorschläge werden offen in Ethereum-Forschungsforen (Ethereum Magicians), auf bekannten Ethereum-Veranstaltungen wie Devcon, ETHDenver und ETHCC, auf GitHub und in Calls der Kernentwickler diskutiert. Die breitere Community beteiligt sich an der Governance, indem sie Vorschläge auf Plattformen wie Discord, Farcaster und X diskutiert.

Anders als Cosmos oder Solana nutzt Ethereum für Protokollentscheidungen keine Stake-basierte Governance oder Token-Abstimmungen. Seit Ethereums Umstellung auf Proof-of-Stake spielen Validatoren eine aktivere Rolle beim Konsens, stimmen aber nicht formell ab. Stattdessen entsteht durch technische Debatten und breite Unterstützung der Community ein grober Konsens. Ethereums Protokolländerungen hängen stark von den Kernentwicklern ab, die Ethereums Ausführungs- und Konsens-Clients wie Geth, Nethermind und Prysm pflegen.

Große Upgrades werden über Hard Forks aktiviert. Dafür müssen Validatoren und Node-Betreiber ihre Software aktualisieren. Validatoren setzen die Regeln des Netzwerks durch, indem sie entscheiden, ob sie neue Upgrades übernehmen. Ist eine vorgeschlagene Änderung umstritten und fehlt der Konsens, könnte sie in seltenen Fällen zu einer Aufspaltung der Chain führen. Beispiele dafür sind frühere Forks wie der DAO Fork (2016, Ethereum Classic) und in geringerem Maße Ethereums Umstellung auf Proof-of-Stake (2022, EthereumPoW).

Ethereums soziales Governance-Modell priorisiert technischen Konsens und Diskussionen in der Community gegenüber formellen Abstimmungsmechanismen. Das hat Ethereum flexibel und dezentral gehalten. Änderungen erfordern dadurch jedoch langwierige Diskussionen und soziale Koordination statt direkter Token-basierter Governance. Zudem gibt es für ETH-Inhaber oder Staker keine formelle Möglichkeit, über Vorschläge abzustimmen. Das begrenzt den direkten Einfluss der Nutzer.

Fazit

Das Governance-System von Solana entwickelt sich noch und wird durch praktische Experimente und Beiträge der Community geprägt. Dieser Bericht untersuchte seine Kernkomponenten – SIMDs, Feature-Aktivierungen und On-Chain-Abstimmungen. Außerdem bot er einen Überblick über alle bisherigen formellen Abstimmungen, zentrale Herausforderungen und Vergleiche mit ähnlichen Netzwerken wie Cosmos und Ethereum. 

Das Solana-Ökosystem basiert auf einer starken, von Engineering geprägten Kultur, die schnelle Iterationen und Umsetzung höher bewertet als langwierige Debatten. Die hohe Geschwindigkeit der Upgrades unterscheidet Solana von vielen vergleichbaren Netzwerken. Sie erzeugt jedoch auch Spannungen mit Governance-Modellen, die auf ausführliche Diskussionen in der Community und breite soziale Koordination setzen. Daraus entstehen besondere Herausforderungen, wenn Geschwindigkeit und inklusive Entscheidungen ins Gleichgewicht gebracht werden sollen.

Solanas Governance nimmt noch Gestalt an. Eines ist jedoch klar: Das Engagement der Community war noch nie so hoch. Da immer mehr Interessengruppen das Netzwerk aktiv mitgestalten, hat Solana die besondere Chance, ein Governance-Modell aufzubauen, das zu seinen Ambitionen, seiner Geschwindigkeit und seinem wachsenden Ökosystem passt.

Zusätzliche Ressourcen

• Messung der Dezentralisierung von Solana: Fakten und Zahlen - Helius-Blog
• Solana Governance Think Tank
• Blockchain-Governance: Programmierung unserer Zukunft - Fred Ehrsam