Seraphis e Jamtis: la prossima evoluzione del protocollo Monero

Quando il Monero Research Lab ha integrato in sordina il primo ramo della libreria Seraphis sottoposto ad audit nel fork di testing, a fine 2025, ha confermato quello che chi segue il protocollo monitorava ormai da quasi quattro anni: Monero si sta preparando alla riscrittura più profonda del proprio livello transazionale da quando RingCT è stato rilasciato nel 2017. Seraphis non è un aggiornamento incrementale. Sostituisce per intero il protocollo delle transazioni, le prove crittografiche che proteggono l'anonimato del mittente e lo schema di indirizzi che gli utenti vedono dal portafoglio. Jamtis, il livello di indirizzamento progettato per appoggiarsi a Seraphis, manda in pensione il formato dei sottoindirizzi che da mezzo decennio è la spina dorsale di ogni wallet Monero.

Questa guida analizza entrambi: cosa sono, perché i ricercatori che hanno guidato il lavoro (koe, jberman, UkoeHB) ci hanno investito migliaia di ore, cosa cambia nella vita quotidiana di chi usa XMR e in che modo un servizio no-KYC come MoneroSwapper gestisce la migrazione senza costringere il cliente a reimparare da capo come effettuare pagamenti privati. Se avete mai inviato o ricevuto XMR, l'indirizzo che avete usato sarà prima o poi deprecato. Capire l'aggiornamento adesso costa meno che rincorrerlo il giorno dell'attivazione.

Perché Monero aveva davvero bisogno di Seraphis

Il protocollo transazionale attuale di Monero è una stratificazione di patch. La prova alla base, CLSAG, ha sostituito MLSAG nel fork di ottobre 2020 riducendo la dimensione delle ring signature di circa il 25%, ma opera ancora su un anello fisso di sedici esche campionate fra gli output recenti. Sedici-su-tanti sembra robusto a prima vista, eppure euristiche statistiche, analisi temporali e il cosiddetto attacco EAE (eve-alice-eve) erodono l'anonimato del mittente nei modelli avversariali più forti. Dal 2019 sono stati pubblicati diversi articoli peer-reviewed che mostrano come un analista ben finanziato, con visibilità ampia sulla mempool, possa de-anonimizzare in chiave probabilistica una frazione non trascurabile degli output.

Il problema della fungibilità complica ulteriormente il quadro. Ogni anello CLSAG include una spesa reale e quindici esche, ma quelle esche sono a loro volta output di transazioni precedenti. Se due transazioni si citano a vicenda come esche e l'analisi della catena riesce a escludere una delle possibilità, la probabilità rispetto all'altra si fa più nitida. Il sistema è robusto in aggregato, ma perde colpi ai margini. Seraphis chiude questa falla allargando in modo drastico l'insieme di anonimato e ristrutturando la prova in modo che appartenenza e proprietà siano disaccoppiate.

• Insieme di anonimato più ampio: Seraphis è progettato per supportare prove di appartenenza su 128 o 256 output (o anche di più, a seconda della curva e del sistema di prova scelti all'attivazione), invece dei soliti 16. La matematica scala in modo logaritmico con la dimensione della prova, quindi 128-su-tanti costa solo marginalmente più byte rispetto al 16-su-tanti di CLSAG.
• Separazione netta dei livelli: oggi una singola prova CLSAG mette insieme "possiedo uno di questi output" e "non l'ho già speso". Seraphis separa le due cose in una prova di appartenenza e una prova di composizione. Ciascuna può essere ottimizzata, sottoposta ad audit e aggiornata in modo indipendente.
• Chirurgia sulla view key: la view key attuale espone ogni output in ingresso a chiunque la possieda. Commercialisti, exchange e consulenti fiscali ricevono tutti lo stesso flusso. Seraphis introduce view key a livelli, così l'utente può concedere accesso in sola lettura alle ricevute senza esporre i resti e gli auto-trasferimenti.
• Prove modulari: l'architettura di Seraphis tratta le prove di appartenenza come componenti intercambiabili. L'obiettivo attuale è FCMP++ (Full-Chain Membership Proofs Plus Plus), che renderebbe ogni output presente sulla catena una potenziale esca. Si passerebbe a un salto di livello rispetto ai sedici attuali.

Niente di tutto questo significa che CLSAG sia rotto oggi. Significa che lo spazio di progettazione è andato avanti, la crittografia accademica è maturata e la cultura di ricerca di Monero rifiuta di accontentarsi del "abbastanza buono" quando c'è sul tavolo qualcosa di "dimostrabilmente migliore". Il prezzo è la complessità ingegneristica e una transizione che dura anni; il vantaggio è una postura di privacy che reggerà l'urto del prossimo decennio di strumenti di analisi.

Come Seraphis ridisegna le transazioni

Seraphis è un protocollo transazionale, non una singola primitiva. Per capire cosa cambia conviene ripercorrere quello che succede oggi quando inviate XMR, mettendo in contrasto ogni passaggio con l'equivalente sotto Seraphis. Le differenze sono sottili lato utente ma profonde sotto il cofano.

Da CLSAG a prove di composizione e appartenenza

Con CLSAG il wallet pesca quindici esche dalla catena, costruisce un anello di sedici e firma una prova che afferma che uno di quei sedici è vostro e che non l'avete speso due volte. Con Seraphis il wallet costruisce due prove distinte. Una prova di composizione dice "possiedo legittimamente uno specifico output di questo insieme, ed ecco la key image corrispondente che dimostra che non l'ho ancora speso". Una prova di appartenenza dice "l'output a cui faccio riferimento esiste in questo insieme di anonimato più ampio sulla catena". Le due prove sono legate crittograficamente ma generate in modo indipendente, ed è ciò che permetterà in futuro di allargare l'insieme di anonimato senza dover ridisegnare l'intero formato delle transazioni.

Anche le key image vengono ripensate. Quella attuale è derivata in modo deterministico dalla one-time output key e dalla spend key — una costruzione elegante, ma da anni al centro di ricerche su casi limite. Seraphis introduce un nuovo formato di key image compatibile in avanti con FCMP++, il sistema di prove di appartenenza che, nelle speranze dei ricercatori Monero, permetterà un giorno di estendere l'insieme di anonimato a tutto lo UTXO set della catena.

Carrot: il livello di codifica degli output

Carrot è lo schema di codifica degli output disegnato in parallelo a Seraphis. Mentre gli output di oggi usano uno stealth address derivato dalla public view key del destinatario e da un segreto condiviso specifico della transazione, gli output Carrot aggiungono campi nuovi: view-balance key, marcatori interno-vs-esterno, indizi di forward secrecy. In pratica la scansione del wallet diventa più veloce (perché gli output interni — i resti che vi inviate da soli — possono essere identificati senza decifrare l'intero contenuto) e l'audit tramite view key diventa più sicuro (perché l'auditor vede solo ciò che l'utente autorizza esplicitamente).

Carrot codifica inoltre per default la "protezione Janus". Un attacco Janus si verifica quando un mittente malevolo costruisce un output che gli permetterà di dimostrare in seguito quale di due indirizzi del destinatario ha ricevuto i fondi. Il protocollo attuale di Monero mitiga il problema con un controllo lato sottoindirizzi, ma Carrot cala la prevenzione direttamente nel formato dell'output, eliminando un'intera classe di bug a livello crittografico anziché a livello di policy del wallet.

Dimensione delle transazioni e commissioni

I critici chiedono spesso se Seraphis significhi transazioni più grandi e commissioni più alte. Risposta onesta: nel breve termine probabilmente sì, in modo moderato; sul lungo periodo probabilmente no. Le prove iniziali di Seraphis sono più grandi di CLSAG, forse da 1,5 a 2 volte a seconda della configurazione scelta all'attivazione. Ma la dimensione dinamica del blocco di Monero fa scalare le commissioni con la congestione e non con il puro conteggio in byte, e Bulletproofs+ ha già compresso aggressivamente le range proof nel 2022. Quando FCMP++ atterrerà e l'insieme di anonimato si estenderà alla scala dell'intera catena, il costo in byte per unità di privacy crollerà rispetto a oggi.

Jamtis: il livello di indirizzamento che vedrete davvero

Seraphis è il motore. Jamtis è il cruscotto. La maggior parte degli utenti non leggerà mai una prova di composizione, ma ogni utente prima o poi copia e incolla un indirizzo Monero. Jamtis riprogetta quell'indirizzo — e le chiavi che gli stanno dietro — in modo che i guadagni di privacy di Seraphis si riflettano nel modo in cui wallet, exchange e merchant interagiscono con la rete.

Gli indirizzi Monero attuali sono 95 caratteri in base58 che iniziano con "4" per gli indirizzi primari mainnet o con "8" per i sottoindirizzi. Codificano una public spend key e una public view key, e poco altro. Gli indirizzi Jamtis sono di lunghezza paragonabile o leggermente diversa (il formato finale è ancora in via di stabilizzazione a livello di protocollo) ma codificano molta più struttura: un indice dell'indirizzo, un flag per il tipo di indirizzo (principale, per exchange, integrato, o "ausiliario") e tag di autenticazione che prevengono certe forme di phishing e di sostituzione.

La gerarchia delle view key merita un'attenzione particolare perché risolve un problema reale. Oggi, se affidate la vostra view key a un commercialista, vede ogni output che avete mai ricevuto — compresi i resti delle vostre spese, i pagamenti che vi fate fra sottoindirizzi vostri e qualsiasi entrata ausiliaria. Jamtis vi consente di concedere solo lo specifico livello che serve all'auditor. Una "find-received" key rivela i pagamenti in ingresso senza importi. Una "view-incoming" key rivela gli importi in ingresso ma non i resti. Una "view-balance" key rivela il saldo spendibile ai fini di compliance senza scoprire le singole transazioni. Solo la "view-all" key, che l'utente conserva privatamente, vede tutto.

Per servizi come MoneroSwapper, che devono confermare il deposito di un cliente senza apprendere la sua storia di portafoglio più ampia, la nuova struttura a livelli si traduce in integrazioni più pulite e in maggiore privacy garantita per impostazione predefinita. Il servizio di swap può verificare che "avete inviato l'importo concordato all'indirizzo concordato" senza avere alcuna visibilità sul saldo complessivo del cliente, sui suoi pattern di resto o su altre entrate. La cosa conta perché ogni byte di metadati che un servizio attento alla privacy non raccoglie è un byte che non potrà essere oggetto di richiesta della Guardia di Finanza, che non potrà essere esfiltrato in un data breach e che non potrà essere estorto con tecniche di social engineering.

Se un aggiornamento di privacy si può riassumere in una sola frase, è quasi sicuramente troppo semplice. Seraphis e Jamtis insieme sono un sistema: prove, codifica, indirizzi, gerarchia delle chiavi e UX del wallet che si muovono in modo coordinato. Vanno trattati come un pacchetto, non come una lista di feature.

Percorso di migrazione: come preparare il portafoglio

Al momento in cui scriviamo l'hard fork Seraphis non ha ancora una data fissata; il Monero Research Lab e il core team sono volutamente prudenti sulle date di attivazione, e preferiscono il "pronto quando è pronto" alle scadenze da calendario. I fork passati di Monero hanno dato agli utenti dai due ai sei mesi di preavviso, e Seraphis cadrà quasi certamente nella parte alta di quell'intervallo vista la complessità. Ecco una checklist pratica di preparazione che vale a prescindere dalla settimana esatta dell'attivazione.

1. Verificate il formato del seed. Se il vostro wallet usa ancora il seed legacy a 25 parole, valutate la migrazione a un wallet basato su Polyseed a 16 parole prima dell'aggiornamento. Polyseed è compatibile in avanti con i percorsi di derivazione Jamtis; il seed legacy richiederà invece un passaggio di conversione lato wallet al momento del fork.
2. Aggiornate il software del wallet almeno due volte prima del fork. I team della GUI ufficiale Monero, della CLI, di Feather Wallet e di Cake Wallet rilasciano in genere più versioni preparatorie. Tenete d'occhio le release notes ufficiali di Monero e il changelog del vostro wallet nel mese che precede l'attivazione: non affidatevi solo all'aggiornamento automatico, perché alcuni wallet pretendono una conferma manuale per i major update.
3. Provate un ripristino completo da seed su un dispositivo di scorta. Prima di qualsiasi upgrade importante di protocollo, il controllo del rischio di gran lunga più prezioso è verificare che il seed scritto a mano ripristini effettivamente i fondi. Tirate su una CLI Monero pulita o un Feather Wallet su una macchina separata, ripristinate da seed e controllate che il saldo coincida. Fatelo due volte. Fatelo ogni sei mesi anche fuori dai cicli di upgrade.
4. Identificate e riducete la proliferazione dei sottoindirizzi. Chi ha usato decine di sottoindirizzi per ragioni organizzative (uno per controparte, uno per merchant, eccetera) avrà una migrazione un filo più articolata. Consolidare i fondi su un numero ridotto di sottoindirizzi prima del fork — etichettando con cura ciascuno nel wallet — rende il modello mentale post-fork molto più semplice.
5. Documentate le condivisioni di view key. Se avete condiviso la view key con un commercialista, un exchange o uno strumento di audit, mettete per iscritto chi ce l'ha e perché. Dopo l'attivazione di Jamtis vi conviene rinegoziare quei rapporti per passare alle nuove chiavi a livelli al posto della view key piena legacy.
6. Attenzione alle istruzioni "post-fork sweep". In passato alcuni upgrade di Monero hanno richiesto agli utenti di effettuare lo "sweep" degli output dal vecchio formato a quello nuovo prima che diventassero spendibili. Il core team Monero pubblicherà istruzioni esplicite se per Seraphis sarà necessario; non agite sulla base di voci da forum o social.

Per chi usa servizi di swap no-KYC l'impatto operativo è di solito minimo. Un servizio ben progettato astrae la transizione di protocollo: gli si dà l'indirizzo, lui restituisce XMR e gestisce in background sia i formati di output pre-Seraphis sia quelli Seraphis. MoneroSwapper, ad esempio, tratta la versione di protocollo dell'indirizzo di destinazione come una decisione di routing e non come una complicazione che ricade sul cliente. Gli utenti possono continuare con lo stesso flusso che hanno sempre usato.

Un esempio pratico: ricevere uno swap nel nuovo modello

Immaginiamo uno scenario tipico di metà 2026, ipotizzando che Seraphis sia attivo. Un utente da Milano vuole convertire Bitcoin in Monero senza KYC. Si collega a un servizio di swap come MoneroSwapper, incolla il proprio indirizzo Jamtis di ricezione (generato da un wallet aggiornato come Feather o come la GUI ufficiale Monero) e invia Bitcoin all'indirizzo di deposito che gli viene fornito.

Dietro le quinte il servizio di swap fa transitare i Bitcoin attraverso la propria pool di liquidità, acquisisce Monero e costruisce una transazione Seraphis che invia l'importo concordato all'indirizzo Jamtis dell'utente. La transazione include una prova di composizione, una prova di appartenenza che pesca da un insieme di anonimato di 128 output (o più) e un output codificato con Carrot che il wallet dell'utente sa identificare in un'unica passata di scansione. L'utente vede i fondi nel proprio wallet entro la consueta finestra di conferma di 10-20 minuti.

Cosa è cambiato dal punto di vista dell'utente? Nulla di visibile. Cosa è cambiato sotto il cofano? L'insieme di anonimato è cresciuto di un ordine di grandezza, la codifica degli output resiste agli attacchi Janus a livello di protocollo e il servizio di swap non ha mai ricevuto una chiave che gli permettesse di apprendere alcunché sulla restante attività Monero dell'utente. Il sistema ha fatto più lavoro di privacy, in modo trasparente. È esattamente l'obiettivo di un upgrade di protocollo ben eseguito: invisibile per chi lo usa, dimostrabilmente più solido per chi lo analizza.

Per chi arriva da fuori dall'ecosistema Monero — bitcoiner curiosi sul tema privacy o nuovi adopter di privacy coin — l'era Seraphis sarà con tutta probabilità il primo contatto. Non sapranno mai com'era la vita con ring signature a sedici, esattamente come gli utenti di oggi raramente ricordano i tempi pre-RingCT in cui gli importi delle transazioni erano pubblici on-chain. È così che dovrebbero apparire gli upgrade di protocollo: un miglioramento silenzioso che diventa la nuova normalità.

Cosa cambia per chi vive in Italia

Una nota dedicata agli utenti italiani: Seraphis non modifica gli obblighi fiscali su XMR. La normativa di riferimento resta quella aggiornata dalla Legge di Bilancio 2023 — che ha inquadrato esplicitamente le cripto-attività come categoria a sé ai fini dell'IRPEF — e i successivi chiarimenti dell'Agenzia delle Entrate. Le plusvalenze derivanti dallo swap di Bitcoin in Monero restano imponibili al verificarsi della cessione, l'imposta di bollo sostitutiva si applica al controvalore detenuto al 1° gennaio, e il monitoraggio fiscale nel quadro RW prosegue invariato a prescindere dal protocollo sottostante. Le view key a livelli di Jamtis non vi esentano da nulla: vi danno semplicemente più controllo su cosa mostrare al consulente quando preparate la dichiarazione. Se condividete oggi una view key piena con il commercialista, dopo l'attivazione di Jamtis vi conviene passare a una "view-incoming" o "view-balance" — vede ciò che serve per la dichiarazione, non ciò che non serve.

FAQ

Quando si attiveranno Seraphis e Jamtis sulla mainnet Monero?

Non è stata annunciata una data certa. Il Monero Research Lab e il core team ribadiscono che l'attivazione dipende dal completamento degli audit crittografici, dall'hardening della libreria, dall'integrazione nei principali wallet e da almeno un ciclo completo di testnet. Le stime pubbliche dei contributor a fine 2025 oscillavano fra fine 2026 e metà 2027, ma la cultura del progetto rifiuta esplicitamente le scadenze a calendario per gli upgrade critici per la sicurezza. Per la tempistica autorevole seguite le release notes ufficiali di Monero e i verbali delle riunioni del Monero Research Lab.

Il mio indirizzo Monero attuale funzionerà ancora dopo l'aggiornamento?

Sì, per un periodo di transizione. Gli hard fork di Monero hanno storicamente incluso una gestione degli indirizzi retrocompatibile, in modo che i fondi inviati a indirizzi legacy arrivino comunque a destinazione. Sul lungo termine i wallet incoraggeranno la migrazione agli indirizzi Jamtis ed è possibile che, in futuro, i nuovi wallet smettano del tutto di generare indirizzi legacy. Non c'è un rischio di "scadenza" immediato sui fondi detenuti negli indirizzi attuali, ma intorno alla data del fork vorrete aggiornare il software del vostro wallet.

Seraphis cambia la tail emission o lo schedule di emissione di Monero?

No. Seraphis è un upgrade di protocollo al livello transazionale. Non tocca la politica monetaria. La tail emission di 0,6 XMR per blocco prosegue invariata. La curva di emissione totale, le dinamiche del block reward e l'algoritmo proof-of-work RandomX sono tutti separati da Seraphis e non vengono toccati dall'aggiornamento.

Seraphis romperà la compatibilità con i wallet hardware come Trezor e Ledger?

I produttori di wallet hardware dovranno aggiornare il firmware per supportare i nuovi formati di prova e i nuovi percorsi di derivazione delle chiavi. Storicamente sia Trezor sia Ledger hanno rilasciato aggiornamenti del firmware Monero in sincronia con i tempi degli hard fork, anche se a volte con qualche settimana o mese di ritardo. Chi si affida a wallet hardware non dovrebbe aggiornare il firmware del dispositivo alla cieca il giorno del fork: meglio attendere conferma esplicita dal produttore che il nuovo firmware supporta la versione attiva del protocollo Monero, mantenendo nel frattempo la possibilità di un fallback su wallet software per la finestra di transizione.

Come si confronta Seraphis con l'approccio di altri progetti di privacy?

Zcash usa zk-SNARK per transazioni completamente schermate, che offrono in teoria una privacy più forte ma in passato hanno richiesto una cerimonia di trusted setup e hanno conosciuto un'adozione molto più bassa (la maggior parte del volume Zcash resta trasparente). Le catene Mimblewimble come Grin usano un modello radicalmente diverso basato sull'aggregazione degli output, che sacrifica parte dell'auditabilità in cambio di compattezza. Seraphis resta dentro il modello di Monero — ring signature e stealth address — ma spinge il design al suo massimo pratico. Il compromesso è complessità ingegneristica in cambio di nessun trusted setup e di un'esperienza utente in continuità con il Monero di oggi.

Posso ricevere swap su indirizzi Jamtis tramite MoneroSwapper prima dell'attivazione del fork?

No, perché gli indirizzi Jamtis non sono ancora generabili dai wallet in produzione. Una volta attivato il protocollo e una volta che i principali wallet (la GUI Monero, Feather, Cake Wallet) avranno introdotto il supporto a Jamtis, i servizi di swap accetteranno il nuovo formato di indirizzo accanto a quelli legacy per tutta la durata della finestra di transizione. Fino ad allora il vostro indirizzo Monero attuale continua a funzionare normalmente per qualsiasi attività di swap.

Conclusione

Seraphis e Jamtis rappresentano l'impegno di Monero a stare un passo avanti rispetto alla curva dell'analisi, anziché rincorrerla. L'aggiornamento non è appariscente, non produrrà una narrazione di pump dei prezzi e non cambierà in modo eclatante quello che la persona media fa con XMR nella vita di tutti i giorni. Quello che farà è alzare in modo significativo il pavimento di privacy della rete, dare agli utenti un controllo più granulare su cosa rivelano e a chi, e gettare le fondamenta crittografiche del prossimo decennio di sviluppo Monero. Se detenete XMR o lo usate per pagamenti privati nella vita quotidiana, prendetevi i prossimi sei-dodici mesi per aggiornare il formato del seed, rinfrescare le buone abitudini di aggiornamento del wallet e verificare la procedura di ripristino. Quando il fork arriverà, vorrete che sia un non-evento. Per iniziare a usare Monero oggi con un servizio di swap senza KYC e senza registrazione che gestirà in modo trasparente la transizione a Seraphis, passate da MoneroSwapper e convertite le vostre cripto in XMR in pochi minuti.