Un pagamento crypto può sembrare semplice: un mittente trasmette una transazione, il destinatario la vede arrivare e il pagamento appare completato. Sulle blockchain, tuttavia, “finale” può significare cose diverse a seconda della rete, del wallet o dell’exchange coinvolto e del livello di rischio che il destinatario è disposto ad accettare. La distinzione diventa importante quando le tempistiche contano, per esempio per payout, trasferimenti tramite bridge, pagamenti in negozio, stipendi, fatture dei fornitori o movimenti di tesoreria di importo elevato.

La finalità indica il punto in cui il processo di consenso della blockchain sottostante non invertirebbe realisticamente una transazione in condizioni normali e gli asset non sono più esposti a rollback o finestre di contestazione. Sulle reti proof-of-work come Bitcoin, la finalità è probabilistica: la fiducia aumenta man mano che altri blocchi vengono aggiunti dopo la transazione, ma il rischio di riorganizzazione non scende mai a zero assoluto. Nei sistemi proof-of-stake con checkpoint, la finalità può avvicinarsi a un modello deterministico una volta che la rete raggiunge uno stato giustificato e finalizzato. Per bridge e reti layer-2, gli utenti devono inoltre considerare il regolamento verso la chain di base.

In termini pratici, gli utenti Bitcoin considerano in genere le conferme aggiuntive come un aumento della sicurezza. Le transazioni Ethereum possono essere incluse rapidamente, mentre la finalità di protocollo richiede attualmente circa un quarto d’ora. Solana offre pre-conferme molto rapide e il suo aggiornamento Alpenglow pianificato punta a una finalità inferiore al secondo. Le reti layer-2 possono fornire ricevute locali istantanee, ma il loro regolamento completo dipende dalla finalizzazione del layer-1 o da finestre di contestazione. Esercenti e tesorieri hanno quindi bisogno di regole scritte che varino in base a chain, importo e rischio della controparte.

Anche block explorer, wallet, processori di pagamento ed exchange possono usare etichette di stato diverse per la stessa transazione. Un “confermato” visibile all’utente o un saldo accreditato può riflettere una policy interna anziché la garanzia di regolamento più forte disponibile dalla chain sottostante. È per questo che le regole di finalità sono rilevanti sul piano operativo: determinano quando spedire le merci, quando accreditare i depositi, quando considerare pagati gli stipendi e quando riconciliare un trasferimento di tesoreria.

Cosa significa finalità sulle diverse blockchain

La finalità non è uno standard universale unico. La prima grande categoria è la finalità probabilistica, in cui la probabilità di una riorganizzazione della chain diminuisce man mano che ulteriori blocchi confermano una transazione. La probabilità può diventare molto bassa, ma non è matematicamente pari a zero. La seconda categoria è la finalità deterministica, o forte. In questo modello, una volta raggiunta una soglia richiesta, non ci si aspetta che il protocollo riscriva la storia senza un intervento sociale straordinario.

Un working paper del Fondo Monetario Internazionale descrive la distinzione in termini simili. I sistemi senza un limite massimo alle risorse rilevanti per il consenso, come i sistemi proof-of-work, forniscono un regolamento probabilistico. I design che fissano le risorse e utilizzano soglie o checkpoint possono offrire garanzie più forti. Questa distinzione è particolarmente rilevante per le infrastrutture dei mercati finanziari tokenizzate, dove la certezza operativa è importante. Il paper dell’FMI è disponibile qui: Fondo Monetario Internazionale.

In pratica, la soglia di finalità corretta dipende dalla tolleranza al rischio. Una caffetteria potrebbe accettare un pagamento Bitcoin a zero conferme da cinque dollari. Un dipartimento di tesoreria che sposta importi a sette cifre normalmente non userebbe la stessa soglia. Sia il modello di consenso del protocollo sia il contesto aziendale del destinatario determinano quando un pagamento dovrebbe essere trattato come finale.

Standard di conferma per Bitcoin ed Ethereum

Bitcoin non ha un numero ufficiale di conferme che renda un pagamento irreversibile. Nel tempo, sei conferme sono diventate una norma di settore ampia perché riducono il rischio di double-spend a un livello che molte aziende considerano accettabile per le transazioni ordinarie. Questo non elimina il rischio. Grandi miner, mempool volatili e Replace-by-Fee possono ancora influire sulla gestione delle transazioni. La soglia appropriata dipende dal contesto: da una a tre conferme possono essere usate per piccoli pagamenti retail, sei o più per pagamenti di importo maggiore, e conferme aggiuntive possono essere richieste quando il rischio della controparte è sconosciuto.

Ethereum funziona diversamente. Con l’attuale comportamento Gasper e Casper-FFG della rete, le epoche vengono finalizzate con una cadenza che si traduce in un tempo alla finalità di circa 16-17 minuti. La ricerca sugli stakeholder del team Ethereum Consensus colloca il dato a circa 1.000 secondi. La stessa ricerca osserva che molti stakeholder ritengono che ridurre la finalità a meno di un minuto, idealmente a decine di secondi, migliorerebbe la sicurezza dei bridge e renderebbe più fluide le esperienze utente di layer-2 e pagamenti. La ricerca di Ethereum Consensus è disponibile qui: Ethereum Consensus.

Di conseguenza, una transazione Ethereum può spesso essere inclusa entro pochi secondi se il mittente paga il gas di mercato, ma l’inclusione non equivale alla piena finalità di protocollo. Gli esercenti che richiedono una garanzia più forte dovrebbero calibrarsi sulla finalità, non solo sull’inclusione in un blocco. Gli exchange spesso usano le proprie soglie di conferma per i depositi, bilanciando il rischio di frode con l’attrito per gli utenti.

Solana e l’aggiornamento di finalità Alpenglow

Solana offre già pre-conferme rapide che possono sembrare istantanee agli utenti, ma la finalità a livello di protocollo storicamente è rimasta indietro rispetto a questa esperienza front-end. La revisione del consenso Alpenglow è progettata per ridurre questo divario. Secondo la Solana Foundation, Alpenglow punta a un tempo alla finalità di circa 150 millisecondi, rispetto all’attuale finalità TowerBFT di circa 12,8 secondi e a una latenza di pre-conferma di circa 400 millisecondi. Il rollout sta procedendo su devnet e testnet, con la migrazione mainnet legata ai rilasci del client Agave e prevista tra il Q3 e il Q4 2026. I dettagli sono disponibili qui: Solana Foundation.

C’è anche una modifica correlata alla governance e alle operazioni dei validatori. I validatori Solana possono registrare chiavi pubbliche BLS su mainnet, e l’attivazione del feature gate Validator Admission Ticket era programmata per la settimana del 20 luglio 2026. VAT escluderà dal consenso i validatori senza una chiave BLS registrata, limiterà i validatori ammessi a 2.000 e, dopo la migrazione completa ad Alpenglow, imporrà una commissione di 1,6 SOL per epoca. Lo scopo dichiarato è stabilizzare la partecipazione al consenso e preparare il nuovo design di finalità. I dettagli della Solana Foundation sono disponibili qui: Solana Foundation.

Se Alpenglow sarà implementato come delineato, la differenza tra “confermato in un wallet” e “regolato in modo irreversibile” potrebbe ridursi a un arco temporale percepibile dagli utenti come tempo reale. Sarebbe una situazione diversa dall’attesa di più minuti per il regolamento. Inciderebbe anche sul modo in cui bridge e market maker gestiscono inventario e rischio su Solana.

Reti layer-2 e bridge

Le reti layer-2 aggiungono un ulteriore livello di complessità. Un utente può ricevere una ricevuta istantanea o quasi istantanea su un L2, ma ci sono due orologi di regolamento: la finalità locale sull’L2 e la finalità del regolamento quando lo stato dell’L2 viene pubblicato sulla chain di base e considerato finale su di essa. Gli optimistic rollup hanno spesso finestre di contestazione che durano giorni. Questo può essere accettabile per molte applicazioni, ma conta quando gli utenti trasferiscono fondi fuori tramite bridge o cercano di allineare il regolamento finale con un obbligo off-chain.

Gli zero-knowledge rollup usano prove che possono essere regolate sul layer 1 in minuti, anche se le policy di batching e le condizioni della rete possono allungare la tempistica. In entrambi i casi, se un modello di rischio dipende dalla finalità del layer-1, una ricevuta L2 non dovrebbe essere trattata come la fine del processo. Per i bridge tra reti layer-1 diverse, gli operatori devono capire come un bridge definisce la finalità e se attende checkpoint o più conferme prima di coniare asset sulla chain di destinazione.

Lo sforzo di ricerca di Ethereum per ridurre la finalità a decine di secondi non riguarda solo l’esperienza utente. Mira anche a rendere l’intero stack L2 e dei bridge più sicuro e più facile da analizzare per sviluppatori e team di rischio. La ricerca del core team è disponibile qui: Ethereum Consensus.

Confronto pratico della finalità

Nessuna singola tabella cattura ogni sfumatura di rete, e le tempistiche possono cambiare con aggiornamenti software, congestione, condizioni dei validatori o design dei bridge. La panoramica seguente è indicativa, non una garanzia. Gli operatori dovrebbero verificare la documentazione di rete aggiornata e applicare le proprie soglie di rischio.

Per ulteriore contesto sulle garanzie economiche dietro queste categorie, l’inquadramento dell’FMI secondo cui i design a risorse fisse e soglie forniscono una finalità più forte rispetto ai design proof-of-work a risorse aperte è un riferimento utile: Fondo Monetario Internazionale.

Controlli di regolamento per esercenti e tesorerie

Le organizzazioni che accettano crypto per beni, stipendi o fatture dei fornitori dovrebbero usare una checklist scritta invece di affidarsi a valutazioni informali. La checklist dovrebbe essere adattata in base a blockchain, dimensione della transazione, asset e controparte.

Primo, confermare che chain e asset siano corretti. I depositi sulla chain sbagliata possono non essere semplicemente ritardati; possono andare persi. Secondo, attendere la soglia specificata nella policy. Per esempio, una policy potrebbe consentire una conferma Bitcoin per un caffè di basso valore, tre conferme per un pagamento di media entità e sei o più per trasferimenti di importo maggiore. Per Ethereum, i destinatari che necessitano di una garanzia forte dovrebbero considerare la finalizzazione anziché la sola inclusione.

Terzo, controllare i rischi legati alla mempool. Su Bitcoin, Replace-by-Fee può sostituire una transazione non confermata. Gli esercenti non dovrebbero spedire merci sulla base di pagamenti a zero conferme a meno che il loro modello di rischio lo consenta esplicitamente. Quarto, monitorare gli eventi della chain. Bug dei client, interruzioni di rete o problemi dei validatori possono influire sulla fiducia nei blocchi successivi. Quinto, quando è coinvolto un bridge, aggiungere alla tempistica il passaggio di regolamento del bridge. Gli asset sulla chain di destinazione non dovrebbero essere automaticamente considerati finali solo perché la chain di origine mostra una conferma.

Le organizzazioni dovrebbero inoltre documentare chi è autorizzato a concedere eccezioni e per quali importi. Se un’azienda si affida a processori di pagamento di terze parti, dovrebbe chiedere quale evento il processore considera finale: inclusione, finalizzazione della chain o un modello di rischio interno. La risposta dovrebbe essere ottenuta per iscritto.

Rischi tra inclusione e regolamento

L’inclusione non equivale al regolamento finale. Sulle reti proof-of-work, una sequenza sfortunata nella produzione dei blocchi può causare una breve riorganizzazione che riporta una transazione nella mempool. Se le commissioni aumentano, la transazione può restare in sospeso più a lungo, e un mittente che usa Replace-by-Fee può tentare di superarla con una transazione conflittuale.

Sulle chain proof-of-stake, la finalizzazione normalmente blocca rapidamente la storia, ma interruzioni dei validatori o bug dei client possono ritardare o bloccare temporaneamente la finalizzazione. In rari casi, le comunità blockchain hanno usato il coordinamento sociale per annullare o aggirare un bug o un exploit. Tali eventi sono straordinari, ma restano parte dell’insieme dei rischi reali.

Per le reti layer-2, la superficie di rischio è più ampia. I sequencer possono ordinare le transazioni prima di provare o pubblicare successivamente un batch sul layer 1. Nella maggior parte dei casi il processo funziona come previsto. Tuttavia, le organizzazioni che necessitano della finalità del layer di base per ragioni contabili, di audit o regolamentari dovrebbero pianificare questo ritardo invece di considerare l’interfaccia L2 equivalente al regolamento L1.

Wallet, exchange e custodian

La policy di finalità di un provider può essere più rigorosa della meccanica della blockchain. Gli exchange centralizzati fissano soglie di conferma per bilanciare prevenzione delle frodi e comodità degli utenti. Possono trattenere più a lungo i prelievi da asset appena listati. I custodian istituzionali spesso richiedono più conferme rispetto alle piattaforme retail e possono sospendere gli accrediti durante periodi di instabilità della rete.

La self-custody cambia la responsabilità. L’utente o l’azienda decide quando una transazione è finale, ma si assume anche il rischio di impostare soglie troppo basse. Per le organizzazioni che operano su larga scala, un motore di policy che segnala i depositi di grandi dimensioni per periodi di attesa più lunghi può ridurre i problemi operativi.

Errori comuni

Un errore comune è trattare l’inclusione come finalità. Vedere una transazione in un blocco può farla sembrare completata, ma su molte reti non è ancora bloccata. Gli operatori dovrebbero mantenere regole separate per inclusione e finalità.

Un altro errore è ignorare il regolamento del bridge. I token trasferiti tramite bridge possono apparire rapidamente, ma se un bridge si basa su un regolamento ritardato o su ipotesi di sicurezza più leggere, resta un rischio aggiuntivo. Gli operatori dovrebbero monitorare sia le conferme della chain di origine sia la policy del bridge.

Un terzo errore è applicare lo stesso numero di conferme a ogni situazione. Sei conferme Bitcoin possono essere adatte a un tipo di pagamento e insufficienti per un altro. Le soglie dovrebbero variare in base alla dimensione della transazione e alla controparte. I pagamenti Bitcoin a zero conferme possono essere accettabili per importi minimi se supportati da strumenti adeguati e limiti di rischio, ma questo approccio non dovrebbe estendersi automaticamente ai pagamenti più grandi. Replace-by-Fee ha cambiato il calcolo del rischio per l’accettazione informale delle zero conferme.

Gli operatori dovrebbero anche monitorare le notizie su client e validatori. Un bug importante di un client o una modifica del set di validatori può incidere temporaneamente sulle normali ipotesi di tempistica. Infine, le aziende non dovrebbero confondere un’esperienza utente L2 rapida con il regolamento L1. Un segno di conferma rapido può essere utile per l’usabilità, ma potrebbe non bastare per bilancio, audit o finalità regolamentari quando è richiesta una garanzia L1.

Domande frequenti

Bitcoin a zero conferme è mai accettabile?

Alcuni esercenti accettano pagamenti Bitcoin a zero conferme per importi molto piccoli e clienti noti quando usano strumenti anti-double-spend e limiti di rischio rigorosi. Resta un rischio calcolato. Con Replace-by-Fee e la variabilità della mempool, i limiti dovrebbero essere stretti e circoscritti ai casi in cui perdere pochi dollari non causerebbe danni significativi.

Le stablecoin si regolano più velocemente delle chain su cui operano?

No. Un trasferimento USDC su Ethereum segue le tempistiche di Ethereum. Un trasferimento USDC su Solana segue le tempistiche di Solana. L’asset non si muove più velocemente del consenso della chain di base. Le policy dell’emittente, le blacklist o i freeze sono un livello separato e non rendono più rapido il regolamento delle transazioni.

Alpenglow di Solana renderà i pagamenti finali in meno di un secondo per tutti?

La finalità di protocollo sotto il secondo è l’obiettivo descritto dalla pagina di upgrade della Solana Foundation. La consegna dipende dai rilasci dei client e dal rollout su mainnet. Solana appare già rapida a livello di esperienza utente, mentre Alpenglow intende avvicinare il processo di regolamento sottostante a quell’esperienza. Il piano è disponibile qui: Solana Foundation.

Pagare gas più alto rende più rapida la finalità di Ethereum?

Un gas più alto può accelerare l’inclusione della transazione. Non modifica la cadenza di finalizzazione del protocollo Ethereum. Per una garanzia forte, il parametro di riferimento è inclusione più finalizzazione, non solo la rapidità con cui una transazione appare in un blocco.

Le chain proof-of-stake sono immuni dalle riorganizzazioni dopo la finalità?

Le chain proof-of-stake con design a checkpoint sono pensate per rendere le inversioni dopo la finalità straordinariamente improbabili senza guasti su larga scala dei validatori o coordinamento sociale. Questo è uno dei principali punti di forza della finalità con checkpoint. Il rischio comunque non è letteralmente pari a zero, e gli operatori in genere trattano le riorganizzazioni post-finalità come casi limite al di fuori delle normali operazioni.

Quante conferme servono per un pagamento Bitcoin di alto valore?

Non esiste un numero universale. Molte aziende usano sei conferme come base e aumentano il requisito per trasferimenti a sette cifre o controparti sconosciute. La soglia dovrebbe scalare con il valore della transazione, i controlli antifrode e il costo di un’eventuale inversione.

Cosa sono il Validator Admission Ticket e le modifiche alle chiavi BLS di Solana?

Il Validator Admission Ticket escluderà dal consenso i validatori che non registrano una chiave BLS, limiterà il set ammesso a 2.000 e, dopo la migrazione ad Alpenglow, imporrà una commissione di 1,6 SOL per epoca. La modifica è progettata per stabilizzare la partecipazione dei validatori e supportare il nuovo percorso di finalità. I dettagli sono disponibili qui: Solana Foundation.

Disclaimer: Questo articolo è fornito esclusivamente a scopo informativo. Non è offerto né inteso per essere utilizzato come consulenza legale, fiscale, d’investimento, finanziaria o di altro tipo.