Il piano di Solana di ridurre del 90% i depositi degli account potrebbe indebolire un motivo per detenere SOL
Punti chiave
- •La prima riduzione della rendita di Solana è entrata in vigore all'epoca 1028 il 3 settembre, tagliando il parametro di riserva da 6.960 a 6.333 lamport per byte, circa il 9%.
- •Il piano in cinque fasi ai sensi di SIMD-0437 punta a un parametro finale di 696 lamport per byte, il che significa che lo stato persistente totale degli account dovrebbe crescere di dieci volte per mantenere le stesse riserve minime di $SOL di prima.
- •Il $SOL in eccesso sopra il nuovo minimo può essere recuperato tramite l'istruzione WithdrawExcessLamports, ma solo il proprietario dell'account, la mint authority o il programma proprietario possono autorizzare il prelievo — non necessariamente la parte che ha finanziato il deposito.
- •La seconda riduzione a 5.080 lamport per byte è su testnet con il mainnet atteso a metà settembre, e le ultime tre tappe sono attese con Agave 4.4 a novembre, subordinate alla revisione della crescita dello stato e a un fallback al parametro originario.
- •Il ricercatore della Solana Foundation Umberto Natale ha rilevato che il 75,5% degli eventi di creazione di account nel gruppo studiato si chiudeva entro la stessa transazione, indicando che le sole metriche di attività non misurano la domanda di archiviazione persistente.

Il piano di Solana di ridurre del 90% i depositi degli account potrebbe indebolire un motivo per detenere SOL
I titolari idonei di account di token su Solana possono ora recuperare il $SOL in eccesso precedentemente necessario per mantenere aperti quegli account, in seguito alla prima riduzione della rendita della rete, entrata in vigore il 3 settembre. Per le aziende che finanziano nuovi account, la stessa modifica riduce il capitale iniziale necessario per crearli.
Il piano completo modificherebbe il modo in cui la crescita degli account si traduce in $SOL detenuto a garanzia dell'archiviazione. Se Solana completasse la riduzione proposta del 90%, lo stato persistente totale degli account — compreso l'overhead di archiviazione di ciascun account — dovrebbe crescere di dieci volte per richiedere le stesse riserve minime di $SOL precedenti al rollout. L'adozione potrebbe quindi espandersi notevolmente mentre il minimo di $SOL necessario per questo canale di riserva diminuisce.
Il tracker della Solana Foundation conferma che solo la prima riduzione, di circa il 9%, è attualmente attiva sul mainnet. Il confronto del decuplo si applica all'obiettivo finale condizionale, mentre il taglio iniziale ha già ridotto i requisiti di riserva.
La riduzione della rendita di Solana e la soglia del 10×
La "rendita" di Solana è un saldo trattenuto a garanzia dell'archiviazione dell'account. È generalmente recuperabile alla chiusura dell'account, anziché una bolletta continua pagata ai validatori. Abbassare il saldo richiesto consente ai nuovi account di aprirsi con meno $SOL e può lasciare gli account esistenti con più del loro minimo.
All'epoca 1028, il 3 settembre, Solana ha ridotto il parametro di riserva da 6.960 a 6.333 lamport per byte. L'obiettivo finale del piano in cinque fasi è 696.
Ai sensi di SIMD-0437, la specifica della riduzione della rendita, il minimo equivale alla dimensione dei dati dell'account più 128 byte di overhead, moltiplicato per l'attuale parametro di lamport per byte. Un account di token standard contiene 165 byte di dati, con una dimensione effettiva di 293 byte. SIMD sta per Solana Improvement and Design proposal, il meccanismo con cui le modifiche di protocollo vengono specificate e, ove applicabile, attivate mediante voto dei validatori.
Applicando tale formula a un milione di account di token standard identici si ottiene la seguente illustrazione:
Queste cifre sono requisiti minimi calcolati per una popolazione fissa di account, non prelievi misurati. L'ultima riga presuppone l'attivazione di tutte e cinque le riduzioni. Dimensioni diverse degli account produrrebbero totali diversi.
L'esempio del milione di account illustra il capitale operativo, ma non può stabilire un effetto di offerta a livello di rete. La sua riduzione finale condizionale di 1.835,352 $SOL rappresenta circa lo 0,000314% degli circa 585,36 milioni di $SOL in circolazione indicati dai dati di mercato di CryptoSlate del 5 settembre. Il canale di riserva aggregato effettivo richiederebbe un inventario di account più ampio, tenendo conto delle dimensioni degli account, dei saldi e della recuperabilità.
La soglia del decuplo deriva dalla stessa relazione. A un decimo del tasso di riserva originario, servirebbero dieci volte più byte soggetti a rendita per mantenere invariato il minimo aggregato. Tale misura copre il totale dello stato persistente, incluso l'overhead per account. Il numero di utenti, il numero di transazioni e i prezzi del $SOL sono misure separate; il confronto del decuplo descrive esclusivamente i requisiti di archiviazione.
Il primo passo attivo pone una soglia più contenuta: circa il 9,9% di stato in più soggetto a rendita preserverebbe il requisito minimo originario a 6.333 lamport per byte. Entrambi i confronti riguardano le riserve richieste — i saldi effettivi degli account possono rimanere sopra tali livelli minimi.
Per i pagamenti, la domanda di riserve sorge principalmente all'apertura degli account. Lo studio di luglio della Foundation sullo stato degli account spiega che un account di token associato serve normalmente a un determinato wallet e a un determinato token mint. Una volta esistente, i pagamenti successivi nello stesso token non richiedono un altro deposito di creazione dell'account. Più pagamenti tramite account esistenti quindi non devono produrre un aumento proporzionale delle riserve di archiviazione.
L'autorità di prelievo decide chi ottiene il capitale
Il beneficio immediato è l'accesso a capitale già on-chain. La guida al recupero del 3 settembre della Foundation descrive un'istruzione chiamata WithdrawExcessLamports, che sposta il $SOL sopra il minimo corrente senza chiudere un account di token né modificarne il saldo di token. Il programma Token-2022 offre la stessa istruzione.
Per un account di token, il proprietario deve autorizzare il prelievo. Per un mint, l'autorizzazione viene dalla mint authority, oppure dalla firma del mint stesso se tale autorità è stata revocata. Gli account di proprietà di programmi personalizzati richiedono che il programma proprietario fornisca la logica di prelievo e verifichi l'autorità pertinente.
Ciò rende il controllo dell'account economicamente significativo. Un fornitore di pagamenti che ha finanziato l'account di token di un cliente non può presumere che il pagamento del deposito originario gli dia il diritto di recuperare l'eccesso. La parte autorizzata al prelievo può differire dalla parte che ha fornito il $SOL.
Lo spostamento di un saldo in eccesso richiede una transazione autorizzata che lasci intatto il minimo. Trasferisce $SOL esistente tra account conservando il totale; non emette nuovi token. La guida non fornisce alcuna misura aggregata dei prelievi completati o delle vendite successive.
Per l'onboarding futuro, il beneficio è più diretto: chi finanzia un account necessita di meno $SOL iniziale. I fornitori possono potenzialmente supportare più account cliente con lo stesso capitale, anche quando i clienti stessi non acquistano $SOL. Se l'eccesso esistente possa essere riutilizzato dipende dalle disposizioni di autorità e programma descritte sopra.
Quanto a lungo quegli account sopravviverà determinerà il requisito di riserva continuativo. La creazione lorda di account può dare un'impressione molto diversa dallo stato che effettivamente rimane on-chain.
Nella sua analisi del 20 luglio, il ricercatore della Solana Foundation Umberto Natale ha rilevato che il 75,5% degli eventi di creazione di account nel gruppo analizzato si chiudeva entro la stessa transazione. Le osservazioni non erano deduplicate per indirizzo, quindi creazioni e chiusure ripetute potevano contare come eventi separati.
Tali flussi di lavoro possono generare attività lasciando tuttavia poco spazio di archiviazione persistente. Il risultato non prevede come gli utenti risponderanno alla riduzione di settembre. Lo studio avverte inoltre che le sue correlazioni deboli e instabili tra i prezzi del $SOL e l'attività degli account sono descrittive, non una stima causale di come una rendita più economica modifichi la domanda.
Un test utile della politica seguirà quindi i byte di account persistenti e le loro riserve minime associate insieme all'attività. Contare solo i nuovi account non può stabilire se la rete ha assorbito il tasso di riserva più basso.
La domanda di $SOL va oltre le riserve degli account
Anche gli altri usi del $SOL continuano. Secondo le regole delle commissioni di Solana, le transazioni richiedono $SOL: metà della commissione di base viene bruciata e metà va al validatore, mentre l'intera commissione di priorità va al validatore. Il pagamento delle commissioni è un canale di domanda separato rispetto alle riserve di account rimborsabili. Più attività potrebbe aumentare l'uso delle commissioni, ma il solo throughput non stabilisce quanto pagano gli utenti o i saldi che conservano.
I detentori di $SOL possono inoltre delegare stake ai validatori per contribuire a proteggere la rete e diventare idonei alle ricompense. Il capitale recuperato potrebbe essere messo in stake o usato per finanziare più account. Il materiale citato non stabilisce alcuno dei due esiti come conseguenza del taglio, quindi queste possibilità non offrono alcun offset quantificato alla riduzione dei requisiti di riserva.
La recente analisi di CryptoSlate su attività ed economia delle commissioni ha esaminato una distinzione correlata: l'utilizzo della rete e l'economia del token possono muoversi in modo diverso. La riduzione della rendita aggiunge un motivo specifico per cui la crescita può richiedere meno $SOL per unità di stato persistente.
Al 5 settembre, la seconda riduzione, a 5.080 lamport per byte, è su testnet, con il mainnet atteso a metà settembre. Le ultime tre tappe sono attese con Agave 4.4 a novembre. Ogni attivazione rimane subordinata alla revisione della crescita dello stato, e un meccanismo di fallback può ripristinare il parametro originario. Il design scaglionato e condizionale riflette un compromesso che gli operatori di Solana valutano da tempo: requisiti di riserva più bassi rendono gli account più economici, ma una crescita più rapida dello stato aumenta il carico di archiviazione che validatori e provider RPC devono sostenere.
Le prossime soglie determineranno fin dove arriva il risparmio di capitale. La crescita dello stato persistente e il recupero effettivo mostreranno quindi quanto di quel risparmio diventa nuova capacità di account, capitale operativo riutilizzabile o minore $SOL detenuto a garanzia dell'archiviazione.