Nei registri dei reward di Solana non compare più la commissione applicata dal validatore a ogni pagamento: chi fa staking vede quanti SOL sono arrivati, ma da quel registro non può ricavare quale fee sia stata trattenuta. La modifica nasce dalla pull request #12588 di Agave, integrata blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">il 20 maggio 2026 e attivata dall’aggiornamento SIMD-0232. Il fornitore di staking P2P.org fa risalire l’effetto all’8 settembre in un rapporto pubblicato il 30 ottobre, CryptoSlate ne ha scritto il 1° novembre e la lettura dei dati di mainnet porta alla stessa data.
È un problema di trasparenza, non un addebito eccessivo. Nei documenti consultati nessun validatore è nominato né accusato di aver trattenuto troppo. Il calcolo dei reward usa ancora la commissione e gli importi vengono scritti come prima. Dal registro è sparita l’aliquota, e nient’altro.
Che cosa mostra ancora il registro dei reward e che cosa non mostra più
Nel codice di Agave il campo commission_bps diventa opzionale nelle strutture dei reward del runtime e resta vuoto quando la funzione custom_commission_collector è attiva. Un commento nel codice precisa che dopo l’attivazione di SIMD-0232 sarà sempre vuoto e potrà essere eliminato in una pulizia successiva. La pull request dice con chiarezza che la modifica arriva all’esterno: lo stesso campo alimenta la risposta RPC getBlock e il messaggio blockSubscribe di Geyser.
Gli importi, commission_lamports e stake_reward, non cambiano. Restano quindi registrate sia la somma pagata al validatore sia quella pagata al delegante. La percentuale che le lega invece no, e la pull request è stata pubblicata senza issue collegata e senza nota di migrazione. Un campo vuoto non significa che il validatore non abbia applicato alcuna commissione, come sottolinea anche CryptoSlate.
Per chi parte da zero: fare staking su Solana vuol dire delegare i propri SOL a un validatore, che trattiene una percentuale dei reward da inflazione. Quell’aliquota era scritta accanto a ogni pagamento e i software di terze parti potevano semplicemente leggerla.
Il campo è stato rimosso di proposito
La rimozione è stata voluta e discussa in pubblico. SIMD-0232 permette ai validatori di indicare account collettori distinti per i ricavi dei blocchi e per la commissione sull’inflazione. L’autore, Justin Starry di Anza, lascia invariato il calcolo della commissione sull’inflazione, mentre il testo non dice nulla sui campi RPC e di reportistica.
L’autore della pull request, buffalojoec, sostiene che un’unica aliquota riportata perde senso in un reward accumulato, una volta che i collettori possono essere combinati a piacere. Il revisore AshwinSekar concorda: in quel contesto riportarla «non ha molto senso».
I reward di staking sono stati l’unico punto di discussione. Il revisore joncinque ha chiesto se non convenisse mantenere l’aliquota lì, dato che su un reward di stake «non ci saranno combinazioni» finché non arriverà il multi-stake. L’autore preferiva toglierla ovunque e joncinque ha approvato comunque: «Se siamo sicuri di non voler riportare questi dati per gli stake, per me va bene!». Nella revisione l’autore ha anche osservato che il campo «non fa parte del consenso», quindi svuotarlo non cambia ciò su cui i validatori si accordano.
La condivisione dei ricavi dei blocchi prevista da SIMD-0123 è un lavoro a parte e non c’entra con il problema. La sua issue di tracciamento, la #13538, era ancora aperta il 1° novembre e, nella pull request collegata #13503, un revisore ha notato che block_reward «è sempre zero qui».
La data dell’8 settembre indicata da P2P.org trova riscontro on-chain
«Dall’8 settembre Solana ha smesso di registrare l’aliquota di commissione applicata ai reward di ogni epoca», scrive P2P.org. Il file di SIMD-0232 riporta lo stato «Activated» ma non indica epoca né data; la risposta sta nella chain. L’account della funzione custom_commission_collector mostra l’attivazione allo slot 445.392.000, il primo dell’epoca 1031, con un timestamp delle 17:11 UTC dell’8 settembre.
I dati dei reward cambiano nello stesso punto. Il 1° novembre una query a un server RPC pubblico di Solana, con getBlock e getInflationReward, ha dato questo esito. Due blocchi del pagamento del 7 settembre, per l’epoca 1029, riportavano commissionBps nei reward di staking, e lo stesso valeva per il reward del maggior validatore per stake (700, cioè il 7%). Due blocchi del pagamento dell’8 settembre, per l’epoca 1030, non avevano quel campo su circa 6.000 reward, e anche le voci dello stesso validatore per le epoche 1030, 1031, 1032 e 1072 ne erano prive. È un campione, non un audit completo, ma coincide con P2P.org sulla data e sul fatto che siano coinvolti sia i registri di voto sia quelli di staking.
P2P.org ha anche un servizio da vendere. Il suo rapporto, firmato da André Caldeira, dice che l’azienda ha ricostruito i propri dati attorno alle transazioni, dichiara una corrispondenza del 99,9% con i suoi dati di snapshot su milioni di account e chiude rinviando i lettori al proprio servizio di reportistica sui reward. Non fornisce alcun metodo per quella cifra e non è stato possibile verificarla. Sul punto centrale il rapporto è pacato: «La commissione viene applicata come prima e gli importi dei reward continuano a quadrare».
Secondo P2P.org la modifica è arrivata senza annunci, le guide di migrazione di terze parti hanno continuato a mostrare il vecchio formato, l’azienda se ne è accorta alla prima epoca interessata e ha sollevato la questione con la Solana Foundation e con Anza. Non risulta alcuna risposta pubblica da parte di nessuna delle due.
Commissione dei validatori Solana: che cosa possono verificare oggi gli staker
Le due liste che seguono sintetizzano le fonti citate in questo pezzo.
Si può verificare:
- I SOL ricevuti da ciascun account di stake, a partire dall’importo e dal saldo successivo al pagamento riportati nel registro dei reward.
- La commissione che un validatore imposta in questo momento, tramite il metodo RPC
getVoteAccounts. - Le impostazioni passate della commissione, ripercorrendo lo storico delle transazioni di un vote account o usando uno strumento che lo conserva.
Dal solo registro dei pagamenti non si può verificare:
- L’aliquota applicata a un dato reward. Ora va ricostruita dallo storico, e secondo P2P.org questo significa ricostruire anche la delega di allora.
- Come si ripartiscono gli importi quando più vote account condividono un collettore. Per P2P.org quelle somme aggregate non si possono più scomporre.
CryptoSlate elenca strumenti per la via dello storico, ciascuno con i propri limiti. Il Validator History Program di Jito documenta fino a 512 epoche per validatore, ma un valore conservato non dimostra da solo di coincidere con l’aliquota ritardata che sta dietro a un certo pagamento. Il parser di snapshot di Marinade pubblica la data di riferimento di ogni valore ed è un metodo di ricostruzione, senza promessa di copertura completa dell’archivio. Il metodo APY di Trillium aggira l’aliquota mostrata e misura la crescita degli account di stake dall’epoca 1070. Nessuno di questi strumenti è stato provato.
Secondo P2P.org i dati precedenti all’8 settembre sono intatti, il che si accorda con le voci dell’epoca 1029 lette sulla chain. Non risultano segnalazioni di exchange, custodian o strumenti fiscali che abbiano smesso di funzionare.
Una seconda lacuna: l’aliquota visibile può non essere quella in vigore
Un problema affine si trova altrove e va tenuto distinto. Secondo SIMD-0249, che i partecipanti alla discussione confermano attivo su mainnet, i reward dell’epoca E vengono calcolati all’inizio di E+1 con la commissione registrata all’inizio di E-1. Il ritardo dà ai deleganti il tempo di andarsene dopo una variazione di aliquota. Significa però anche che il numero mostrato da una dashboard può non essere quello applicato.
L’issue #16135, aperta il 18 ottobre da ax-x2, afferma che getVoteAccounts può mostrare una commissione allo 0% mentre Agave usa per l’epoca corrente un’aliquota salvata del 100%. L’issue descrive uno schema: portare la commissione al 100% verso la fine di un’epoca, riportare il valore live allo 0% dopo lo snapshot, e ripetere. Resta un’ipotesi. Non risultano casi in cui sia avvenuto, e CryptoSlate precisa che l’esempio dell’issue non individua alcun episodio osservato e non dimostra addebiti eccessivi.
A luglio l’utente GitHub ripatel-fd ha esteso la preoccupazione nella discussione #583 del repository dei SIMD: «Gli utenti non dispongono di un’API RPC per vedere la commissione effettiva in corso e i collettori di un vote account».
| Data (2026) | Evento |
|---|---|
| 20 maggio | Integrata la pull request #12588 di Agave |
| 16 luglio | Aperta la discussione #583 sullo stato nascosto della commissione |
| 8 settembre | I registri dei reward smettono di riportare l’aliquota secondo P2P.org; funzione attiva dall’epoca 1031, alle 17:11 UTC, secondo i dati on-chain |
| 18 ottobre | L’issue #16135 chiede la commissione effettiva nell’RPC |
| 30 ottobre | P2P.org pubblica il rapporto sul terzo trimestre |
Diverse soluzioni sul tavolo, nessuna ancora in produzione
L’issue #16135 propone di aggiungere a getVoteAccounts l’opzione facoltativa includeCommissionContext, che restituirebbe l’aliquota effettiva con epoca e slot. Il 1° novembre non aveva assegnatari, commenti né pull request collegate.
Nella discussione #583, SIMD-0511 salverebbe on-chain lo stato di commissione e collettore per ogni epoca, e un altro partecipante ha proposto un campo provvisorio nel vote account. A luglio Justin Starry e joncinque preferivano rilasciare entrambi i SIMD così come scritti e intervenire in seguito. L’ultimo commento, del 5 ottobre, vede joncinque proporre un nuovo SIMD per usare gli indirizzi dei collettori in tempo reale, che non eliminerebbe del tutto le cache.
Per chi detiene token di liquid staking su Solana, o delega direttamente, nelle fonti nulla lascia pensare a una variazione di ciò che viene pagato. La vicenda è distinta dall’incidente del validatore Solflare di fine ottobre.
Tra gli elementi da seguire nel quarto trimestre, P2P.org indica una fonte supportata per le aliquote storiche applicate, oppure uno standard di reportistica.