Solanas geplante Kürzung der Kontoeinlagen um 90 % könnte ein Argument schwächen, SOL zu halten
Wichtige Erkenntnisse
- •Solanas erste Rent-Reduktion ging am 3. September in Epoche 1028 live und senkte den Reserveparameter von 6.960 auf 6.333 Lamports pro Byte – eine Verringerung von rund 9 %.
- •Der fünfstufige Plan nach SIMD-0437 zielt auf einen Endparameter von 696 Lamports pro Byte; der gesamte persistente Kontostatus müsste dann zehnfach wachsen, um dieselben Mindestreserven an $SOL wie zuvor zu halten.
- •Überschüssiges $SOL über dem neuen Minimum kann über die Instruktion WithdrawExcessLamports zurückgefordert werden, aber nur der Kontoeigentümer, die Mint-Authority oder das besitzende Programm können die Abhebung autorisieren – nicht zwingend die Partei, die die Einlage geleistet hat.
- •Die zweite Reduktion auf 5.080 Lamports pro Byte ist auf dem Testnet, die Mainnet-Aktivierung wird Mitte September erwartet; die letzten drei Schritte werden mit Agave 4.4 im November erwartet, abhängig von einer Statuswachstums-Überprüfung mit Rückfall auf den ursprünglichen Parameter.
- •Der Solana-Foundation-Forscher Umberto Natale stellte fest, dass 75,5 % der Kontoerstellungs-Ereignisse in der untersuchten Kohorte innerhalb derselben Transaktion geschlossen wurden – ein Hinweis darauf, dass Aktivitätsmetriken allein die persistente Speichernachfrage nicht messen.

Solanas geplante Kürzung der Kontoeinlagen um 90 % könnte ein Argument schwächen, SOL zu halten
Berechtigte Inhaber von Solana-Token-Konten können nun überschüssiges $SOL zurückfordern, das zuvor erforderlich war, um diese Konten offen zu halten. Grund dafür ist die erste Rent-Reduktion des Netzwerks, die am 3. September live ging. Für Unternehmen, die neue Konten finanzieren, verringert dieselbe Änderung das vorab benötigte Kapital für deren Erstellung.
Der Gesamtplan würde verändern, wie sich Kontenwachstum in gegen Speicherung gehaltenes $SOL übersetzt. Sollte Solana die vorgeschlagene 90%-Reduktion abschließen, müsste der gesamte persistente Kontostatus – einschließlich des Speicher-Overheads jedes Kontos – um das Zehnfache wachsen, um dieselben Mindestreserven an $SOL wie vor der Einführung zu erfordern. Die Adoption könnte sich daher erheblich ausweiten, während das für diesen Reservekanal benötigte Mindest-$SOL sinkt.
Der Tracker der Solana Foundation bestätigt, dass auf dem Mainnet derzeit nur die erste Reduktion von rund 9 % aktiv ist. Der Zehnfach-Vergleich bezieht sich auf das bedingte Endziel, während die erste Kürzung die Reserveanforderungen bereits gesenkt hat.
Solanas Rent-Reduktion und die 10×-Hürde
Solanas „Rent" ist eine Balance, die gegen Kontospeicherung gehalten wird. Sie ist in der Regel bei Schließung eines Kontos rückholbar und keine laufende Gebühr an Validatoren. Eine Senkung der erforderlichen Balance erlaubt es neuen Konten, mit weniger $SOL zu beginnen, und kann dazu führen, dass bestehende Konten mehr als ihr Minimum halten.
In Epoche 1028 am 3. September senkte Solana den Reserveparameter von 6.960 auf 6.333 Lamports pro Byte. Das Endziel des fünfstufigen Plans lautet 696.
Gemäß SIMD-0437, der Spezifikation zur Rent-Reduktion, entspricht dieses Minimum der Datengröße des Kontos plus 128 Byte Overhead, multipliziert mit dem aktuellen Lamports-pro-Byte-Parameter. Ein Standard-Token-Konto umfasst 165 Datenbytes, was einer effektiven Größe von 293 Bytes entspricht. SIMD steht für Solana Improvement and Design Proposal, den Mechanismus, über den Protokolländerungen spezifiziert und, wo zutreffend, per Validator-Abstimmung aktiviert werden.
Die Anwendung dieser Formel auf eine Million identischer Standard-Token-Konten ergibt die folgende Illustration:
Diese Werte sind berechnete Mindestanforderungen für eine feste Kontenpopulation, keine gemessenen Abhebungen. Die letzte Zeile setzt voraus, dass alle fünf Reduktionen aktiviert werden. Andere Kontengrößen würden andere Summen ergeben.
Das Million-Konten-Beispiel veranschaulicht Betriebskapital, kann aber keinen netzwerkweiten Angebotseffekt belegen. Seine bedingte finale Reduktion von 1.835,352 $SOL entspricht etwa 0,000314 % der rund 585,36 Millionen umlaufenden $SOL laut CryptoSlates Marktdaten vom 5. September. Der tatsächliche aggregierte Reservekanal würde eine breitere Konteninventur erfordern, unter Berücksichtigung von Kontengrößen, Balances und Rückholbarkeit.
Die Zehnfach-Schwelle ergibt sich aus derselben Beziehung. Bei einem Zehntel der ursprünglichen Reservequote wären zehnmal so viele rent-tragende Bytes nötig, um das aggregierte Minimum unverändert zu halten. Diese Messgröße erfasst den Gesamtbestand an persistentem Status, einschließlich Overhead pro Konto. Nutzerzahlen, Transaktionszahlen und $SOL-Preise sind eigene Messgrößen; der Zehnfach-Vergleich beschreibt allein die Speicheranforderungen.
Der aktive erste Schritt setzt eine kleinere Hürde: Rund 9,9 % mehr rent-tragender Status würden das ursprüngliche Minimum bei 6.333 Lamports pro Byte erhalten. Beide Vergleiche betreffen erforderliche Reserven – tatsächliche Kontobalances können über diesen Untergrenzen bleiben.
Bei Zahlungen entsteht diese Reserveanforderung hauptsächlich bei der Kontoeröffnung. Die Juli-Studie der Foundation zum Kontostatus erklärt, dass ein zugeordnetes Token-Konto normalerweise einem bestimmten Wallet und Token-Mint dient. Sobald es existiert, erfordern spätere Zahlungen im selben Token keine weitere Einlage zur Kontoerstellung. Mehr Zahlungen über bestehende Konten müssen daher keinen proportionalen Anstieg der Speicherreserven bewirken.
Die Abrufberechtigung entscheidet, wer das Kapital erhält
Der unmittelbare Nutzen ist der Zugang zu Kapital, das bereits on-chain liegt. Der Rückführungsratgeber der Foundation vom 3. September beschreibt eine Instruktion namens WithdrawExcessLamports, die $SOL über dem aktuellen Minimum bewegt, ohne ein Token-Konto zu schließen oder dessen Token-Balance zu verändern. Das Token-2022-Programm bietet dieselbe Instruktion.
Bei einem Token-Konto muss der Eigentümer die Abhebung autorisieren. Bei einem Mint kommt die Autorisierung von der Mint-Authority oder – sofern diese widerrufen wurde – von der Signatur des Mint-Kontos selbst. Konten im Eigentum benutzerdefinierter Programme erfordern, dass das besitzende Programm die Abhebungslogik bereitstellt und die zuständige Autorität prüft.
Das macht die Kontrolle über das Konto wirtschaftlich bedeutsam. Ein Zahlungsanbieter, der das Token-Konto eines Kunden finanziert hat, kann nicht davon ausgehen, dass die Zahlung der ursprünglichen Einlage ihm das Recht einräumt, den Überschuss zurückzufordern. Die zur Autorisierung der Abhebung berechtigte Partei kann eine andere sein als die, die das $SOL bereitgestellt hat.
Das Verschieben einer Überschussbalance erfordert eine autorisierte Transaktion, die das Minimum unangetastet lässt. Sie überträgt bestehendes $SOL zwischen Konten und erhält dabei die Gesamtmenge; sie gibt keine neuen Tokens aus. Der Ratgeber enthält kein aggregiertes Maß abgeschlossener Abhebungen oder nachfolgender Verkäufe.
Für künftiges Onboarding ist der Nutzen unmittelbarer: Wer ein Konto finanziert, braucht vorab weniger $SOL. Anbieter können potenziell mit demselben Kapital mehr Kundenkonten unterstützen, selbst wenn die Kunden selbst kein $SOL erwerben. Ob bestehender Überschuss erneut eingesetzt werden kann, hängt von den oben beschriebenen Autorisierungs- und Programmregelungen ab.
Wie lange diese Konten bestehen, bestimmt die fortlaufende Reserveanforderung. Die Brutto-Kontoerstellung kann einen sehr anderen Eindruck vermitteln als der Status, der tatsächlich on-chain verbleibt.
In seiner Analyse vom 20. Juli stellte der Solana-Foundation-Forscher Umberto Natale fest, dass 75,5 % der Kontoerstellungs-Ereignisse in der untersuchten Kohorte innerhalb derselben Transaktion geschlossen wurden. Die Beobachtungen wurden nicht nach Adresse dedupliziert, sodass wiederholte Erstellung und Schließung als separate Ereignisse zählen konnten.
Solche Workflows können Aktivität erzeugen, hinterlassen aber wenig persistenten Kontospeicher. Die Feststellung sagt nicht voraus, wie Nutzer auf die Reduktion im September reagieren werden. Die Studie warnt zudem, dass ihre schwachen, instabilen Korrelationen zwischen $SOL-Preisen und Kontoaktivität beschreibend sind und keine kausale Schätzung darüber darstellen, wie günstigeres Rent die Nachfrage verändert.
Ein aussagekräftiger Test der Politik wird daher persistente Kontobytes und die zugehörigen Mindestreserven neben der Aktivität verfolgen. Allein das Zählen neuer Konten kann nicht belegen, ob das Netzwerk die niedrigere Reservequote absorbiert hat.
$SOL-Nachfrage reicht über Kontoreserven hinaus
Andere Verwendungen von $SOL bestehen ebenfalls fort. Nach Solanas Gebührenregeln erfordern Transaktionen $SOL: Die Hälfte der Grundgebühr wird verbrannt, die andere Hälfte geht an den Validator, während die gesamte Priority Fee an den Validator geht. Gebührenzahlungen sind ein vom erstattbaren Kontoreserven getrennter Nachfragekanal. Mehr Aktivität könnte die Gebührennutzung erhöhen, aber der Durchsatz allein belegt weder die Höhe der Zahlungen der Nutzer noch die von ihnen gehaltenen Balances.
$SOL-Inhaber können zudem Stake an Validatoren delegieren, um zur Netzwerksicherheit beizutragen und für Rewards berechtigt zu werden. Zurückgeholtes Kapital könnte gestakt oder zur Finanzierung weiterer Konten genutzt werden. Das zitierte Material belegt keines dieser Ergebnisse als Folge der Kürzung, sodass diese Möglichkeiten keinen quantifizierten Ausgleich zu niedrigeren Reserveanforderungen liefern.
CryptoSlates aktuelle Analyse zu Aktivität und Gebührenökonomie untersuchte eine verwandte Unterscheidung: Netzwerknutzung und Tokenökonomie können sich unterschiedlich entwickeln. Die Rent-Reduktion liefert einen konkreten Grund, warum Wachstum weniger $SOL pro Einheit persistenten Status erfordern kann.
Stand 5. September ist die zweite Reduktion auf 5.080 Lamports pro Byte auf dem Testnet, die Mainnet-Aktivierung wird Mitte September erwartet. Die letzten drei Schritte werden mit Agave 4.4 im November erwartet. Jede Aktivierung bleibt von einer Überprüfung des Statuswachstums abhängig, und ein Fallback kann den ursprünglichen Parameter wiederherstellen. Das gestufte, bedingte Design spiegelt einen Trade-off wider, den Solana-Betreiber lange abgewogen haben: Niedrigere Reserveanforderungen machen Konten günstiger, doch schnelleres Statuswachstum erhöht die Speicherlast, die Validatoren und RPC-Anbieter tragen müssen.
Die nächsten Gateways werden bestimmen, wie weit die Kapitalersparnis reicht. Das Wachstum des persistenten Status und die tatsächliche Rückführung werden dann zeigen, wie viel dieser Ersparnis zu neuer Kontokapazität, wiederverwendbarem Betriebskapital oder reduziertem gegen Speicherung gehaltenem $SOL wird.