NotizieCryptoIl primo ciclo di governance di Solana mette ai voti offerta, commissioni e controllo della rete

Il primo ciclo di governance di Solana mette ai voti offerta, commissioni e controllo della rete

Autore: Coindoo·

Punti chiave

  • [SGP-0001](https://github.com/solana-foundation/solana-governance-proposals/pull/3) stabilirebbe una Costituzione di Solana e permetterebbe ai singoli delegatori di sovrascrivere il voto del proprio validator tramite gli account di controllo.
  • [SGP-0002](https://github.com/solana-foundation/solana-governance-proposals/pull/4) propone di raddoppiare il tasso annuo di disinflazione di SOL dal 15% al 30%, mantenendo il limite finale dell’inflazione all’1,5%.
  • La curva di disinflazione accelerata è stimata ridurre l’emissione prevista di SOL di circa 18,9 milioni di token in sei anni.
  • [SGP-0003](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0553-resource-fee-burn.md) sostituirebbe la commissione base fissa di Solana con una fee di inclusione di 2.500 lamport più una resource fee dinamica completamente bruciata.
  • Se tutte e tre le proposte venissero approvate, l’economia dei validator dipenderebbe di più da fee di inclusione, priority tips, MEV e dal valore di mercato di SOL, ma i cambiamenti richiederebbero comunque ulteriori fasi di sviluppo e attivazione prima di entrare in vigore.
Il primo ciclo di governance di Solana mette ai voti offerta, commissioni e controllo della rete

Tre voti, un’unica questione economica

Solana ha aperto il suo primo ciclo formale di governance, sottoponendo all’ecosistema tre questioni strutturali in votazioni ponderate per stake che proseguiranno fino al 27 agosto. La scheda riguarda la ratifica di una costituzione ufficiale per istituire la governance onchain, il raddoppio della velocità con cui viene ridotta l’inflazione e la sostituzione della commissione base fissa della rete con oneri dinamici legati alle risorse.

Ogni proposta ha un proprio titolo, ma insieme delineano un unico compromesso: se Solana possa contenere in modo aggressivo le emissioni di token e aumentare i burn giornalieri delle commissioni senza erodere i margini di profitto che mantengono online i node operator e preservano la decentralizzazione. Gli esiti determineranno la governance politica della rete, il suo budget di sicurezza e il costo di lungo periodo per acquistare blockspace.

Una costituzione che concede ai delegatori un veto diretto

SGP-0001, la proposta di Costituzione di Solana, definisce le regole organizzative per la governance a livello di rete e attiva i processi costruiti attorno al protocollo di voto onchain svmgov.

Per gli staker quotidiani, il cambiamento più rilevante è la sovranità del voto. Nel quadro proposto, lo stake delegato segue per default il voto del validator, ma i singoli staker possono sovrascrivere manualmente tale scelta tramite i propri account di controllo. In questo modo i validator istituzionali non possono decidere unilateralmente gli esiti per tutti i SOL delegati loro.

Il potere di voto resta ponderato per stake, il che significa che i grandi detentori di token continuano ad avere un’influenza significativa. Anche così, i delegatori otterrebbero finalmente un meccanismo formale per dissociarsi quando un validator vota contro le loro preferenze di rendimento o le loro aspettative sulle commissioni di rete. In pratica, il ciclo di governance diventa più di una manifestazione simbolica di consenso: è una delle prime occasioni per Solana di mostrare come il coordinamento onchain possa funzionare su larga scala senza concentrare completamente le decisioni nelle mani dei validator.

Secondo l’FAQ ufficiale sulla governance, le Solana Governance Proposals fungono da segnali direzionali ponderati per stake. Stabilisono se la comunità favorisca un cambiamento di politica, lasciando i dettagli tecnici a successivi Solana Improvement Documents (SIMDs).

Una disinflazione più rapida, con lo stesso limite minimo del 1,5%

SGP-0002 chiede alla rete di raddoppiare il tasso annuo di disinflazione di SOL dal 15% al 30%. Il limite finale dell’inflazione resterebbe fissato all’1,5%, ma la rete raggiungerebbe quel minimo molto prima — all’incirca nel 2029 invece che nel 2032.

Le simulazioni collegate alla proposta stimano che questa curva accelerata rimuoverebbe circa 18,9 milioni di SOL dall’emissione prevista nell’arco di sei anni, un taglio sostanziale all’espansione futura dell’offerta che si inserisce nelle discussioni precedenti su come Solana potrebbe rallentare la crescita dell’offerta di SOL.

Una minore emissione è direttamente interessante per i detentori di token che cercano scarsità, ma comprime anche i rendimenti da staking derivanti dalla nuova coniazione. La proposta lascia invariati commissioni degli operatori, mance MEV e priority fees, ma i validator vedranno un flusso minore di SOL appena emesso, poiché il ritmo di minting si riduce più rapidamente. Gli elettori stanno valutando un equilibrio semplice: accettare una crescita più contenuta dei rendimenti da staking in cambio di un’offerta circolante complessivamente più stretta, con i tempi di questo cambiamento ora definiti dal voto di governance anziché lasciati a un dibattito astratto.

Una struttura delle fee in due parti che riscrive la remunerazione dei validator

SIMD-0553, sostenuta da SGP-0003, sostituisce la commissione base fissa delle transazioni di Solana con una struttura tariffaria a due componenti. Ogni transazione pagherebbe una fee di inclusione fissa di 2.500 lamport direttamente al leader del blocco, a cui si aggiunge una resource fee dinamica scalata in base a memoria, cicli di esecuzione e stato dei dati richiesti dalla transazione. Tale resource fee viene interamente bruciata, mentre le priority fees restano al leader del blocco.

Il design fa sì che le transazioni ad alto consumo computazionale paghino in modo proporzionale per il carico effettivo imposto all’hardware dei validator: un semplice trasferimento wallet-to-wallet e l’esecuzione di un contratto smart pesante non condividerebbero più lo stesso costo base fisso.

La criticità strutturale sta nel modo in cui la fee viene calcolata. Le resource fees vengono applicate alla capacità che una transazione richiede, non a quella che utilizza effettivamente, perciò le applicazioni che allocano in eccesso la memoria di calcolo pagheranno penalità più alte. Inoltre, poiché queste resource fees bruciate vengono distrutte in modo permanente, nessun costo aggiuntivo confluisce nei conti dei validator come ricavo operativo. Questo è rilevante perché il design delle fee non influisce solo sui costi per gli utenti; incide anche sulla combinazione di incentivi che aiuta a pagare la partecipazione alla rete e l’infrastruttura.

Minore emissione e burn elevati ridefiniscono l’economia della sicurezza

Le tre proposte operano come un sistema interconnesso. SGP-0002 riduce il flusso di nuovo SOL che entra nell’ecosistema, SGP-0003 dirotta una quota maggiore delle commissioni di transazione verso burn permanenti invece che verso la remunerazione degli operatori, e SGP-0001 offre ai delegatori una via semplice per sovrascrivere i validator contrari a questi cambiamenti.

Se tutte e tre venissero approvate, Solana si muoverebbe verso un modello di offerta più restrittivo e i margini dei validator dipenderebbero molto di più dalle fee di inclusione dei blocchi, dalle mance di priority, dalle opportunità MEV e dal valore di mercato di SOL stesso. Questi aggiustamenti non eliminano la redditività dei validator — la fee di inclusione garantisce che i leader dei blocchi ricevano un compenso per la costruzione di base del blocco — ma ridefiniscono il punto di partenza economico: ridurre l’emissione di nuova offerta mentre si richiede all’attività di rete di finanziare una quota maggiore dei costi di sicurezza in corso. Per questo il voto ha attirato attenzione oltre la sola meccanica di governance; tocca il rapporto tra politica monetaria, generazione di fee ed economia operativa del funzionamento di un validator.

L’approvazione segnala intenzione, non esecuzione immediata del codice

Nessuno dei tre voti modificherà immediatamente il codice del protocollo al momento dell’approvazione. Una Solana Governance Proposal approvata concede ai core developer un mandato per procedere con l’implementazione; i SIMDs sottostanti devono comunque completare sviluppo tecnico, integrazione con i client software, audit su testnet e la procedura finale di attivazione su mainnet.

Questa realtà operativa conta soprattutto per i cambiamenti economici. Approvare una disinflazione più rapida non altera la curva dell’inflazione nel primo giorno, e approvare fee basate sulle risorse non cambia istantaneamente i prezzi delle transazioni. L’esito segnala ai team di ingegneria core che la rete sostiene ufficialmente il passaggio verso quei meccanismi target, lasciando i parametri finali di esecuzione — tassi di scalatura delle fee, feature flag, calendari di rilascio dei client ed epoch di attivazione — da definire nel codice nei prossimi mesi.

Cosa osservare prima della chiusura della finestra di voto

  • Volume di override dei delegatori: quanti staker si discostano dalla posizione del validator assegnato.
  • Partecipazione totale dello stake: metriche complessive di affluenza su tutte e tre le questioni di governance.
  • Divisioni nel voto dei validator: se i node operator sostengono la riduzione dell’offerta mentre votano contro le regole di burn delle fee.
  • Annunci sulla roadmap degli sviluppatori: come i team di ingegneria delineano le tempistiche di implementazione dopo il voto.

Questo ciclo di voto va oltre la semplice scarsità del token, perché rappresenta un test in tempo reale della capacità di Solana di ristrutturare la propria politica monetaria e il proprio motore di fee mantenendo solvibili i node operator, informati gli utenti e coinvolti attivamente nella governance i delegatori.