Anza ha abilitato la Transaction V1 sulla testnet di Solana il 1° settembre, offrendo alla rete un'ultima prova dell'upgrade in vista del lancio sulla mainnet previsto per il 9 settembre. Secondo Solana Compass, la modifica consente di elaborare in un'unica transazione atomica carichi di lavoro crittografici e DeFi che in precedenza dovevano essere frammentati su più transazioni.

Lavori prima divisi ora in una sola chiamata

Il cambiamento più evidente è l'aumento dello spazio. La dimensione massima di una transazione Solana serializzata è passata da 1.232 byte a 4.096 byte — un aumento di 3,3 volte — con effetto alla epoca 1025 della testnet. Il limite di 1.232 byte risaliva alla prima progettazione del protocollo Solana, e V1 rappresenta la prima volta che il limite viene innalzato a livello di formato del messaggio da quando V0 ha introdotto le Address Lookup Tables come soluzione parziale alla pressione sulle dimensioni.

Secondo la pagina dedicata all'aggiornamento delle transazioni di grandi dimensioni della Solana Foundation, le dimensioni maggiori rendono possibile implementare prove a conoscenza zero, transazioni multisig di grandi dimensioni e vari schemi di firma che in precedenza non potevano rientrare in una singola transazione. Il risultato è un numero minore di transazioni da elaborare, costi inferiori per le firme e nessuna necessità di attendere una catena di conferme. Gli schemi di firma BLS, le transazioni riservate e le configurazioni multisig dovrebbero beneficiare dell'upgrade.

Due proposte sono centrali per il miglioramento: SIMD-0296 innalza il limite di dimensione della transazione da 1.232 a 4.096 byte, mentre SIMD-0385 definisce il formato del messaggio V1 e sposta la configurazione della transazione nel messaggio stesso.

Meno di un giorno dopo l'attivazione, l'amministratore delegato di Anza Brennan Watt ha pubblicato su X segnalando una transazione di grandi dimensioni sull'esploratore della testnet con il messaggio: "ATTENTION: large transactions have hit the testnet."

Perché una transazione batte un bundle

L'atomicità è importante perché gli sviluppatori hanno talvolta aggirato il vecchio limite di dimensione di Solana utilizzando i bundle di Jito. SIMD-0296 documenta esplicitamente quella soluzione alternativa e osserva che i bundle privi di atomicità a livello di protocollo, a differenza di una singola transazione nativa.

Secondo la documentazione di Jito, i bundle possono contenere fino a cinque transazioni elaborate in sequenza su base all-or-nothing. Tuttavia, i bundle operano nel block engine di Jito e competono tra le mance dei validatori. Una transazione V1, al contrario, è una singola transazione nativa Solana che porta con sé la garanzia di atomicità a livello di transazione propria di Solana.

Per gli sviluppatori DeFi, questo semplifica la costruzione di percorsi di swap, prove e altre operazioni multi-step: se l'intera operazione rientra in una transazione V1, essa riesce o viene annullata come un'unica transazione nativa invece di dipendere da un bundle.

Cosa ottiene la DeFi oltre ai byte extra

V1 modifica anche la struttura della transazione stessa. Mentre le transazioni Legacy e V0 gestiscono le priority fee e le richieste di risorse tramite istruzioni ComputeBudget, SIMD-0385 sposta queste impostazioni nella configurazione della transazione V1, rendendo più facile per i validatori identificare le esigenze di risorse senza dover scansionare l'elenco delle istruzioni.

V1 elimina inoltre le Address Lookup Tables (ALT), che V0 utilizzava per accorciare gli indirizzi degli account. Secondo l'analisi della Foundation sul compromesso ALT di V1, V1 inserisce invece gli indirizzi inline, semplificando l'input dei validatori rispetto all'approccio di V0, che consumava più byte nella conversione degli indirizzi nelle applicazioni ricche di account.

Il beneficio pratico per i router e gli aggregatori DEX è maggiore spazio per percorsi atomici complessi. Il miglioramento non è però senza limiti: il limite di Solana di 64 account distinti per transazione rimane invariato, quindi le applicazioni che fanno un uso intenso di account possono comunque incontrare quel tetto, anche se la capacità in byte non è più il vincolo.

L'upgrade arriva mentre Solana si spinge più a fondo nella finanza on-chain. Il report di Galaxy su Solana per il Q2 2026 mostra una crescente attività nelle stablecoin, azioni tokenizzate e asset del mondo reale. Secondo Galaxy, il potenziale futuro di Solana dipenderà in larga misura dalla capacità di utilizzare questi asset in prestiti, collateralizzazione, margine e rendimento — non solo in emissione o trading. I dati di DeFiLlama su Solana indicano una forte presenza DeFi sulla piattaforma.

I tempi coincidono inoltre con la fase di upgrade di Agave 4.2. Come riportato in precedenza da Cryptopolitan, il piano di riduzione dei costi graduale avrebbe dovuto generare risparmi di circa il 90% e ridurre i tempi di elaborazione da 500 a 200 millisecondi, a beneficio degli emittenti di stablecoin, dei fornitori di wallet e dei sistemi di pagamento.

Gli operatori RPC hanno una settimana per aggiornarsi

V1 è opt-in, quindi le transazioni Legacy e V0 continuano a funzionare. La questione aperta è se l'infrastruttura che legge il traffico V1 sia pronta.

Anza ha richiesto ai fornitori RPC di eseguire l'aggiornamento ad Agave v4.2.2 o v4.3.0-beta.3. La checklist di migrazione Helius per Agave 4.2 avverte che i consumer RPC che non dichiarano la conformità V1 possono riscontrare errori di chiamata, come getBlock, quando è coinvolta una transazione V1.

Il rollout è iniziato con i test locali di V1 il 24 agosto, seguiti dalla conferma della data mainnet del 9 settembre il 29 agosto. V1 è stata abilitata sulla testnet il 1° settembre all'epoca 1025, con l'attivazione sulla mainnet prevista per il 9 settembre.

L'ultimo ciclo sulla testnet serve come fase preparatoria finale per fornitori RPC, indicizzatori, wallet, SDK e piattaforme di analisi in vista del lancio sulla mainnet.