Stellar Protocol 30 Bell: voto sulla mainnet il 23 novembre, sulla testnet il 3

I validatori di Stellar voteranno Protocol 30, nome in codice Bell, il 23 novembre 2026 alle 17:00 UTC, cioè alle 18:00 in Italia. Prima c’è una votazione di prova sulla testnet di Stellar, il 3 novembre 2026 alle 17:00 UTC (le 18:00 in Italia). La Stellar Development Foundation (SDF), che coordina l’aggiornamento, indica entrambe le date nella guida all’upgrade Bell, aggiornata il 20 ottobre, e nel suo annuncio definisce il calendario «soggetto a modifiche».

Bell è un aggiornamento per sviluppatori e infrastrutture, non un evento legato al token per chi possiede XLM, la criptovaluta di Stellar. Riunisce tre Core Advancement Proposals (CAP): indirizzi contratto «muxed» con un nuovo formato che inizia per W, verifiche di firme post-quantistiche dentro gli smart contract e tempi di chiusura del ledger registrati al millisecondo. A chi detiene XLM non viene chiesto di scambiare, migrare o riscuotere nulla.

Stellar Protocol 30: il calendario dal rilascio di Core v30 al voto sulla mainnet

Il software è arrivato prima dei voti. Stellar Core v30.0.0, il software dei nodi che i validatori eseguono, è stato rilasciato in versione stabile il 16 ottobre 2026. Le versioni stabili del resto dell’infrastruttura e degli SDK sono seguite tra il 16 e il 23 ottobre, e la guida prevede che ogni componente sia disponibile entro il 23 ottobre.

Stellar non cambia protocollo a un blocco prestabilito. I validatori predispongono i propri nodi con un orario di aggiornamento e votano; se un numero sufficiente è d’accordo, la rete passa alla nuova versione. La SDF pubblica solo gli orari dei voti, non il momento esatto in cui le regole di Protocol 30 diventano effettive dopo un voto favorevole. Gli aggiornamenti sullo stato vanno sul canale #protocol-next del Discord degli sviluppatori Stellar, e la guida ricorda a chi gestisce i sistemi che testare le proprie integrazioni prima di ogni voto è compito suo.

Cosa cambia con Bell: tre CAP

CAP-84: indirizzi contratto muxed, il nuovo formato W

Un indirizzo di contratto può ora essere abbinato a un ID a 64 bit. Un solo smart account può così custodire i fondi di molti clienti, ciascuno con il proprio ID, senza bisogno di un contratto per ogni cliente. In un trasferimento tramite lo Stellar Asset Contract, l’ID viene registrato nel campo to_muxed_id dell’evento. La forma testuale usa un nuovo prefisso Strkey, W, assegnato in SEP-23. Stellar classico aveva già indirizzi account muxed che iniziano per M; W porta la stessa idea ai contratti.

L’ambito è volutamente ristretto. Solo le destinazioni possono portare l’ID e per ora solo la funzione transfer li accetta; mint e transfer_from sono rimandate. Una funzione di contratto che si aspetta un indirizzo semplice rifiuta un indirizzo W, quindi gli sviluppatori che vogliono riceverli devono dichiarare il tipo muxed.

È la modifica che con più probabilità si vedrà in un’app. Qualsiasi software che controlla la validità di un indirizzo deve accettare gli indirizzi W, altrimenti gli utenti si vedranno rifiutare un indirizzo corretto.

CAP-87: firme post-quantistiche, ma solo dentro i contratti

CAP-87 aggiunge tre host function a Soroban, la piattaforma di smart contract di Stellar, per verificare firme ML-DSA ai livelli di sicurezza ML-DSA-44, ML-DSA-65 e ML-DSA-87. ML-DSA è lo schema di firma post-quantistico standardizzato dal NIST statunitense come FIPS 204. Un account contratto personalizzato può quindi pretendere una firma resistente ai computer quantistici prima di muovere i fondi. La SDF definisce questo passo il primo elemento onchain del suo Quantum Preparedness Plan.

I limiti contano, e la Fondazione li dichiara apertamente: Bell non rende Stellar post-quantistica. Le firme delle transazioni e le chiavi master degli account restano su Ed25519, uno schema a curve ellittiche che un computer quantistico abbastanza potente potrebbe in teoria violare. Un firmatario nativo resistente ai computer quantistici per gli account classici è rimandato a un protocollo futuro. Bell dà uno strumento a chi costruisce contratti; un normale wallet firma esattamente come prima.

CAP-88: tempi di chiusura del ledger in millisecondi

Ogni ledger porterà un tempo di chiusura in millisecondi, grazie a due nuovi tipi di valore nell’intestazione del ledger. Il vecchio campo closeTime continua a riportare secondi interi, arrotondati per difetto. Anche i limiti temporali delle transazioni, le condizioni dei claimable balance e il timestamp letto dai contratti Soroban restano in secondi interi. L’effetto visibile è che due ledger possono ora chiudersi nello stesso secondo, quindi il codice non deve presumere che «un ledger dopo» significhi «almeno un secondo dopo».

L’obiettivo è la velocità futura, non quella di oggi. Secondo l’annuncio della SDF, Protocol 28 «Adapter» ha portato a settembre i tempi di chiusura sulla mainnet da circa 5,7 secondi a 5 secondi. Bell da solo non scende sotto i 5 secondi. Elimina il limite di un ledger al secondo, in modo che gli aggiornamenti futuri possano farlo.

Chi deve intervenire prima dell’upgrade Bell di Stellar

La guida divide il lavoro per tipo di destinatario. Per chi usa gli SDK è netta: l’aggiornamento «non è opzionale in questo ciclo», con scadenze al 3 novembre per le integrazioni sulla testnet e al 23 novembre per la mainnet. Gli SDK più vecchi potrebbero non riuscire a decodificare i ledger di Protocol 30.

• Le app che gestiscono indirizzi devono accettare la variante W nel proprio codice; l’SDK aggiornato la interpreta, ma la logica di validazione scritta dall’app non cambia da sola.
• Chi gestisce Stellar Core, Horizon, RPC e Galexie installa le versioni di Protocol 30, pubblicate come immagini Docker, pacchetti Debian e sorgenti.
• Indexer, block explorer, strumenti di analisi e decoder XDR personalizzati devono aggiornare le definizioni XDR prima dell’upgrade, altrimenti la decodifica della nuova intestazione del ledger fallirà.
• I validatori eseguono Stellar Core v30.0.0; il comando per predisporre i nodi al voto del 23 novembre viene condiviso in anticipo attraverso i canali dei validatori.
• Wallet, on-ramp e off-ramp ed emittenti di asset passano all’ultimo SDK prima del voto sulla mainnet e gestiscono gli indirizzi W nella validazione, nella visualizzazione, nella memorizzazione e nella logica dei trasferimenti.
• Exchange e custodian aggiornano SDK e infrastruttura e supportano i prelievi verso indirizzi contratto muxed. La SDF suggerisce anche di valutare gli indirizzi W rispetto agli indirizzi M per i depositi dei clienti.

Per i team dei contratti l’elenco è più leggero. I contratti esistenti continuano a funzionare senza modifiche. Gli indirizzi muxed e le verifiche ML-DSA sono opzionali e richiedono di ricompilare con l’SDK Soroban di Protocol 30; la SDF chiede ai team di rivedere qualsiasi ipotesi del loro codice sui timestamp dei ledger.

Cosa devono fare i possessori di XLM

Nulla, per quanto risulta dai documenti della Fondazione. Né la guida né l’annuncio descrivono alcun passaggio per i possessori: nessuno scambio di token, nessun nuovo indirizzo, nessuna migrazione. CryptoTicker legge l’aggiornamento allo stesso modo e aggiunge che i vecchi indirizzi restano validi e che nessuno deve spostare XLM.

Quello che un possessore può notare è indiretto. Un wallet o un exchange non aggiornato potrebbe rifiutare un indirizzo W, oppure sospendere depositi e prelievi su Stellar attorno al voto. Nelle fonti che abbiamo letto il 23 ottobre non era stata annunciata alcuna finestra di manutenzione degli exchange. La nostra guida ai wallet crypto spiega la differenza tra un conto custodial, in cui è la piattaforma a occuparsi degli aggiornamenti, e un wallet in self-custody, dove aggiornare l’app spetta a te.

Gli upgrade di Stellar: Yardstick, Adapter e ora Bell

Bell mantiene l’intervallo che Stellar ha usato quest’anno: 20 giorni tra il passaggio sulla testnet e il voto sulla mainnet. Protocol 26 «Yardstick» è arrivato sulla testnet il 16 aprile 2026 ed è andato al voto sulla mainnet il 6 maggio, entrambi alle 17:00 UTC, secondo la guida della SDF per quell’upgrade. Ha introdotto, tra le altre modifiche, un modo per i validatori di congelare voci del ledger compromesse (CAP-77), l’aritmetica a 256 bit con controlli (CAP-82), più funzioni crittografiche BN254 (CAP-80) e miglioramenti allo Stellar Asset Contract (CAP-73).

La guida ad Adapter (Protocol 28) fissava un voto sulla testnet il 27 agosto e un voto sulla mainnet il 16 settembre 2026 alle 17:00 UTC. Il suo CAP-83 aggiungeva un tipo di valore per il ledger vuoto, e la guida presentava il rilascio come un passo per far chiudere i ledger più in fretta e con minore variabilità.

Altre informazioni sulla rete, sul suo modello di consenso e sul token XLM sono nella nostra pagina su Stellar (XLM).

Meridian a Lisbona, poi il voto sulla testnet

Il calendario mette Bell subito dopo il principale appuntamento dell’ecosistema. Meridian 2026, la conferenza di Stellar a Lisbona, si tiene il 28 e 29 ottobre, tra la fine della finestra di rilascio e il voto sulla testnet del 3 novembre.

La parte quantistica alimenta un dibattito che va ben oltre Stellar. Nove società crypto hanno lanciato a ottobre una Quantum Alliance per mettersi d’accordo su cosa debba significare «resistente ai computer quantistici». Stellar parte dal livello dei contratti e rimanda il modello base degli account, così chi sviluppa può provare account post-quantistici senza che tutti gli utenti cambino chiavi.

Cosa non si sa ancora

Il momento esatto in cui le nuove regole diventano effettive dopo il voto del 23 novembre non è stato pubblicato. Prima del voto nessuno può dire se i validatori troveranno l’accordo al primo tentativo, e la SDF può ancora spostare le date. I piani specifici degli exchange, compresa un’eventuale pausa dei trasferimenti di XLM, non erano stati annunciati nelle fonti che abbiamo letto il 23 ottobre 2026. La prossima data fissa è il voto sulla testnet del 3 novembre alle 17:00 UTC, le 18:00 in Italia.