Liquid Staking und LSTs auf Solana

Einführung

Dieser Beitrag untersucht die grundlegende Struktur von Liquid Staking Tokens (LSTs) auf Solana. Mit LSTs können Nutzer die Liquidität ihrer gestakten Assets freisetzen. Werden Token auf einer Proof-of-Stake-Blockchain (PoS) gestakt, sind sie normalerweise für einen bestimmten Zeitraum gesperrt. Im Gegenzug für die Absicherung des Netzwerks erhalten Nutzer Rewards. Diese Staking-Rewards können Gebühren, andere MEV-Erträge und Emissionen umfassen, also einen Transfer von Nicht-Stakern an Staker.

Dieser Staking-Mechanismus ist für die wirtschaftliche Sicherheit entscheidend, macht die gestakten Assets jedoch illiquide und schränkt ihren Einsatz für andere Finanzaktivitäten im Ökosystem ein. Staking reduziert den frei verfügbaren Bestand, indem Token im Protokoll gesperrt werden. Das schafft Anreize für die Entwicklung und Nutzung von LSTs, die die Kapitaleffizienz erhöhen. Token-Inhaber können so Staking-Rewards verdienen und gleichzeitig liquide bleiben.

Dieser Beitrag untersucht außerdem, wie sich diese Konstruktionen von Ethereum unterscheiden und welche weiteren Aspekte bei LST-Konstruktionen auf Solana zu beachten sind.

LST-Konstruktionen auf Solana

Solana nutzt einen protokollinternen Delegated-Proof-of-Stake-Mechanismus (DPoS). Nutzer zahlen SOL in Stake-Pools ein, die von verschiedenen einzelnen Validatoren betrieben werden. Die Staking-Betreiber können dann eigene LSTs ausgeben, die durch die delegierten SOL gedeckt sind. So erhalten Nutzer sofortige Liquidität für ihren Stake.

Stake-Pool-LSTs

LSTs basieren auf Stake-Pools, die das SPL-Stake-Pool-Programm nutzen. Nutzer zahlen SOL in diese nicht verwahrenden Pools ein. Der Stake wird anschließend auf eine Auswahl qualifizierter Validatoren verteilt. Im Gegenzug erhalten die Teilnehmer ein LST wie JitoSOL von Jito.

Jeder Stake-Pool verfolgt eine eigene Strategie für die Delegation von Stake. Jito priorisiert beispielsweise Validatoren, die seinen Client ausführen. Dadurch maximiert Jito die MEV-Erträge und verteilt den Stake gemäß seinen Kriterien auf die 100 leistungsstärksten Validatoren neu.

Wir können die Übertragung von Stake zwischen den Beteiligten eines bestimmten Stake-Pools als Bilanzen darstellen. Lies sie von links nach rechts und von oben nach unten:

1. Ein Staker/Delegator zahlt 10 SOL direkt in einen Stake-Pool ein und erhält ein LST-Guthaben namens „spSOL“ („Stake-Pool-SOL“). Dieses Guthaben repräsentiert seinen Anspruch auf die Rückgabe der eingezahlten 10 SOL.
2. Der Stake-Pool verfügt nun über 10 SOL. In diesem Beispiel delegiert er 5 SOL an „Stake Pool Validator 1“ und die anderen 5 SOL an „Stake Pool Validator 2“. Der Stake-Pool erhält insgesamt 10 vSOL („Validator-SOL“) – 5 vSOL von jedem Validator. Obwohl dieser Anspruch nicht in einem tatsächlichen Token abgebildet ist, repräsentiert er einen virtuellen Anspruch auf die Rückgabe der eingezahlten SOL.
3. „Stake Pool Validator 1“ und „Stake Pool Validator 2“ staken jeweils ihre 5 SOL und übernehmen Aufgaben bei Ausführung und Konsens. Sie erhalten vom Solana-Protokoll virtuelle „sSOL“. Diese repräsentieren ihren Anspruch auf die eingezahlten SOL. Auch sie sind nicht in einem Token abgebildet, veranschaulichen aber, wie das Protokoll Rückgaben nachverfolgt.

Beachte, dass dies der einfachste Fall ohne Gebühren oder Slashing ist. Derzeit gibt es auf Solana kein programmatisches Slashing. Einige LSTs erheben jedoch Gebühren.

Validator-LSTs

Validator-LSTs erleichtern es Projekten, LSTs für einen einzelnen Validator auszugeben. Dadurch entsteht rund um ein bestimmtes, von einem Validator ausgegebenes LST ein Gefühl der Gruppenzugehörigkeit.

Validator-LSTs funktionieren ähnlich wie ein Stake-Pool, mit dem Unterschied, dass es nur einen einzigen Validator gibt:

1. Ein Staker/Delegator zahlt 10 SOL direkt in einen Stake-Pool ein und erhält ein LST-Guthaben namens „v_lstSOL“ („Validator-LST-SOL“). Dieses Guthaben repräsentiert seinen Anspruch auf die Rückgabe der eingezahlten 10 SOL.
2. Der Stake-Pool-Manager delegiert anschließend an den einzigen Validator im Pool. Er zahlt die 10 SOL beim Validator ein und erhält virtuelle „vSOL“.
3. Der Validator verfügt nun über 10 SOL. Da er am Konsens teilnimmt, zahlt er 10 SOL in Solana ein. Vom Solana-Protokoll erhält der Validator virtuelle „sSOL“, die seinen Anspruch auf die eingezahlten SOL repräsentieren.

In beiden Fällen delegieren Staker SOL an Validatoren, die Validatoren übernehmen Validierungsaufgaben und ein Teil der SOL-Rewards geht an die Staker. Validator-LSTs haben keine Gebühren für das Einzahlen von Stake, keine Auszahlungsgebühren und keine Verwaltungsgebühren.

Technisch sind Validator-LSTs schlanker. Sie reduzieren die Gesamtzahl der Stake-Accounts erheblich und verkürzen damit die Zeit, die zur Berechnung der Rewards für Stake-Accounts benötigt wird. Außerdem können Validator-LSTs Anreiz- oder Treueprogramme anbieten: Laine hat kürzlich Block-Rewards und Priority Fees per Airdrop an laineSOL-Inhaber verteilt. Dadurch erzielten laineSOL-Inhaber einen hohen APY. Tensor kann Nutzern ermöglichen, Gebote mit tensorSOL statt mit SOL abzugeben und so Erträge aus offenen Orders zu erzielen. Dadurch könnte Tensor seinen Nutzern zusätzliche Punkte gewähren und ein Lotteriesystem ohne Verlustrisiko betreiben, bei dem jede tensorSOL-Zahlung die Chance bietet, einen Teil der angesammelten Staking-Rewards zu gewinnen.

Mechanik von LST-Token

Ähnlich wie bei Ethereum können LST-Token entweder Reward-tragend oder rebasingbasiert funktionieren. Verschiedene LSTs wählen unterschiedliche Modelle, um Rewards an Staker weiterzugeben, unter anderem wegen möglicher Steuervorteile. Derzeit gibt es auf Solana keine rebasingbasierten LSTs.

Nutzung von LSTs auf Solana

Auf Ethereum stammt der weitaus größte Teil des gestakten ETH aus LSTs, darunter stETH, rETH und cbETH. stETH macht ~70 % des gesamten LST-Marktes aus.

Auf Solana machen LSTs weniger als 5 % des gesamten gestakten Betrags aus. Jito und Marinade halten 35 % beziehungsweise 42 % des LST-Marktes.

Diese unterschiedliche Nutzung von LSTs lässt sich auf mehrere Gründe zurückführen:

• Die Nutzung von LSTs auf Ethereum ist stark pfadabhängig. Der Merge hatte großen Einfluss auf das heutige Gleichgewicht bei der LST-Nutzung. Starke, sich gegenseitig verstärkende Netzwerkeffekte und die Akzeptanz konzentrierten sich auf die ein bis drei Liquid Staking Tokens, die sich durchsetzten. So entstand ein sich selbst verstärkender Schwungradeffekt der „Geldähnlichkeit“.
• LSTs bieten noch nicht genügend Onchain-Nutzen. Nutzer reagieren sehr sensibel auf eine mögliche Verringerung der Gewichtung als Sicherheit in Solana DeFi, auch wenn dies unwahrscheinlich ist.
• Für große Inhaber, darunter Institutionen und Privatpersonen, sind die Anreize höher, einen eigenen Validator und stake-gewichtete Dienste zu betreiben. Wegen möglicher rechtlicher Haftung entscheiden sie sich für Staking ohne externen Stake. Große SOL-Accounts oder Konglomerate mit hohem, wahrscheinlich zuvor gesperrtem Stake nehmen lieber nicht am LST-Staking teil. Stattdessen betreiben sie aus rechtlichen, regulatorischen oder anderen Gründen eigene Validatoren und erhalten die entsprechenden Staking-Rewards.
• Solana-Nutzer sind mit der Struktur von LSTs noch nicht besonders vertraut.

LSTs und DeFi

In PoS-Netzwerken konkurrieren hohe Kreditzinsen in DeFi oft direkt mit Staking. Das kann die Netzwerksicherheit beeinträchtigen, weil Staker ihren Stake rationalerweise abziehen, um auf DeFi-Kreditplattformen höhere Renditen zu erzielen. Dies zeigt sich bei Chains wie Cosmos, die aufgrund der hohen Staking-Renditen im gesamten Ökosystem lange in einem schwierigen Kreislauf mit begrenzter DeFi-Aktivität gefangen waren, was sich jedoch bald ändern könnte. Damit DeFi auf Cosmos an Bedeutung gewinnt, muss es diese Staking-Renditen übertreffen. Das setzt eine hohe und oft nicht nachhaltige Messlatte. Ein liquider und aktiver LST-Markt kann dieses Problem abmildern. Staker können dann gleichzeitig am Staking und Lending teilnehmen, was die Anreize für Angriffe reduziert. 

Solana DeFi verzeichnet seit den Airdrops von Jito und Jupiter einen deutlichen Anstieg bei Volumen, Aktivität und Aufmerksamkeit. Solche Airdrops bilden oft den Ausgangspunkt für interessantere gemeinsam genutzte Zustände, wenn Aktivität, Interesse und die Anzahl der Assets wachsen. Werden alle gestakten SOL in einem System mit gemeinsam genutztem Zustand wie Solana freigesetzt, ermöglicht das eine vielfältigere native DeFi-Wirtschaft.

Das LST-Ökosystem auf Solana steckt noch in den Kinderschuhen. Dennoch wird es wahrscheinlich eine deutlich längere Verteilung kleinerer LSTs als auf Ethereum geben, vor allem wegen der zunehmenden Beliebtheit von Validator-LSTs.

Sanctum und die lange Verteilung von Solana-LSTs

Validator-LSTs sind fungibel, worauf wir später näher eingehen. Sie fungieren als Wrapper für dieselben Stake-Accounts und repräsentieren einen Anspruch auf die entsprechende Menge gestakter SOL.

Mit Validator-LSTs kann jeder Validator eigene validatorspezifische LSTs ausgeben. Eines der ersten Teams, das an dieser Zukunft mit „unendlich vielen LSTs“ arbeitet, ist Sanctum. Die Sanctum Reserve stellt einen großen Pool liquider SOL (> 200.000 SOL) bereit. Damit lässt sich jedes LST sofort unstaken, indem der Stake-Account des Nutzers gegen die entsprechende Menge SOL an Sanctum übertragen wird, abzüglich einer Gebühr für die zweitägige Unbonding-Phase. Das Sanctum-Team hat außerdem den Sanctum Router entwickelt. Er ermöglicht den Tausch von LSTs über den Offchain-Router von Jupiter. Bald soll zudem Sanctum Infinity erscheinen. Dadurch lässt sich jedes beliebige LST sofort unstaken, gegen andere LSTs eintauschen und mit minimalen Gebühren in jeden anderen Token wechseln.

LST-Konstruktionen auf Ethereum

Nicht alle Protokolle verfügen über einen nativen Delegationsmechanismus wie Solana. Die folgenden Konstruktionen sind auf Ethereum am weitesten verbreitet:

Genehmigungspflichtige Node-Betreiber (z. B. stETH)

stETH wird von der Lido DAO ausgegeben. Sie verwaltet die Verteilung und den Betrieb der gestakten Assets über eine ausgewählte Gruppe von ~30 genehmigungspflichtigen Node-Betreibern. Dieses Modell ist genehmigungspflichtig und unbesichert. Die Node-Betreiber werden anhand strenger Kriterien sorgfältig ausgewählt, müssen jedoch keine Sicherheiten hinterlegen. Dadurch entsteht ein Prinzipal-Agent-Problem. Der an den LIDO-Pool delegierte Stake wird gleichmäßig auf diese Betreiber verteilt. Dieser Ansatz setzt auf das Vertrauen, dass die geprüften Betreiber die Netzwerksicherheit ohne zusätzliche finanzielle Garantien gewährleisten. Lido repräsentiert derzeit ~31 % des gesamten gestakten Ethereum.

Genehmigungsfreie Node-Betreiber (z. B. rETH)

RocketPool bietet eine genehmigungsfreie Gruppe von Node-Betreibern. Jeder kann Validator werden, sofern er die Anforderungen an die Besicherung erfüllt. Dieses Modell demokratisiert den Zugang zum Betrieb einer Node, verlangt für die Teilnahme jedoch die Hinterlegung von Sicherheiten. Um eine vollständige Validator-Node mit 32 ETH zu betreiben, muss ein Betreiber konkret 8 ETH aus eigenen Mitteln und zusätzlich RPL-Token im Wert von 2,4 ETH hinterlegen. RPL ist der native Token von RocketPool. Mit insgesamt 10,4 ETH qualifiziert sich der Betreiber dafür, 24 ETH aus dem Pool zu erhalten.

Dieses Modell soll Prinzipal-Agent-Effekte verringern, bei denen die Parteien, die Risikokapital bereitstellen, und die Betreiber unterschiedliche Akteure sind.

Zentralisierte Node-Betreiber (z. B. cbETH)

Über Coinbase oder andere zentralisierte Anbieter können Nutzer ihre ETH direkt bei der Plattform staken. Die Plattform übernimmt den Betrieb der erforderlichen Nodes. Außerdem können Nutzer onchain auf Liquidität für cbETH zugreifen. Dieses Modell priorisiert Benutzerfreundlichkeit und Zugänglichkeit, da Nutzer Coinbase die betrieblichen Komplexitäten des Stakings anvertrauen.

Weitere Überlegungen

Stake-Pool-Programme werden durch eine Multisig kontrolliert. Die Staker-Autorität, bei der es sich um ein einzelnes Schlüsselpaar handeln kann, kontrolliert einige Aspekte der Stake-Delegation. Sie kann jedoch nur eine deutlich begrenztere Anzahl von Aktionen ausführen. Projekte wie Stakenet wollen die Staker-Autorität dezentralisieren, indem sie sie statt an ein einzelnes Schlüsselpaar an ein Programm delegieren. Die Staker-Autorität kann Stake an andere bestehende Validatoren delegieren und Gebühren erhöhen. Eine Gebührenerhöhung tritt frühestens nach einer Epoche in Kraft. Außerdem ist begrenzt, um wie viel der Manager die Gebühren erhöhen kann.

Derzeit gibt es auf Solana kein programmatisches Slashing, anders als bei anderen Chains wie Ethereum. Dadurch gibt es weniger Angriffsvektoren, über die der Delegationsempfänger oder Betreiber mit dem delegierten Stake böswillige Aktionen ausführen könnte. Die Betreiber der jeweiligen Validator-LSTs sind stark eingeschränkt und können den delegierten Stake nicht stehlen, da die Nutzer Eigentümer ihrer gestakten SOL bleiben. Dennoch müssen zusätzliche Aspekte berücksichtigt werden, falls Solana künftig programmatisches Slashing unterstützt. Ethereum untersucht derzeit Lösungen wie zweistufiges Staking, um einige Auswirkungen dieses Prinzipal-Agent-Problems beim Slashing abzumildern.

Fazit

In diesem Beitrag haben wir untersucht, wie die aktuelle Implementierung von Solana-LSTs in der Praxis funktioniert. Außerdem haben wir Solanas native Delegation und das zugehörige LST-Modell dem Modell von Ethereum gegenübergestellt.

Die Nutzung von LSTs auf Solana und Ethereum unterscheidet sich deutlich. Der LST-Markt auf Solana ist noch relativ jung. Wenn der Nutzen von LSTs wächst und Nutzer sich besser mit ihrer Struktur auskennen, wird auf Solana mehr nativer DeFi-Zustand entstehen.

Vielen Dank an FP Lee von Sanctum und Jon Charbonneau für ihr Feedback und die Durchsicht.