In sintesi, una banca può emettere una stablecoin o un deposito tokenizzato utilizzando tecnologia blockchain o di registro distribuito (DLT) combinata con smart contract, integrazione con i sistemi contabili di core, controlli di identità e conformità, custodia, strumenti per la privacy e connettività di regolamento. La principale scelta architetturale sta tra una rete privata permissionata, una blockchain pubblica o una blockchain dedicata controllata dall'istituzione.

Una Avalanche L1 corrisponde al terzo modello: l'istituzione può operare una rete sovrana con proprie politiche di validazione e di transazione, mantenendo al contempo una connettività nativa con l'ecosistema Avalanche più ampio.

Una distinzione chiave inquadra l'intero tema: la blockchain in sé non determina se uno strumento sia legalmente una stablecoin o un deposito tokenizzato. Questo dipende dall'emittente, dalla tutela legale, dalle garanzie, dal modello di rimborso e dalla normativa applicabile.

Punti chiave

• I depositi tokenizzati sono passività di deposito bancario commerciale rappresentate su infrastrutture programmabili, mentre le stablecoin sono token emessi separatamente, progettati per mantenere un valore stabile, ciascuno con proprie garanzie e struttura normativa.
• L'emissione richiede più di un semplice contratto token: le istituzioni necessitano anche di integrazione con i registri, controlli KYC/AML, custodia, privacy, verificabilità, processi di rimborso e interoperabilità.
• Le Avalanche L1 consentono alle istituzioni di configurare a livello di rete la partecipazione dei validatori, l'accesso alle transazioni, il deployment dei contratti e i parametri delle commissioni di rete.
• Encrypted ERC (eERC) può aggiungere saldi e importi di trasferimento riservati, inclusa una capacità opzionale di revisione, ma è uno standard token distribuibile e non una funzionalità automatica di ogni Avalanche L1.
• ANZ ha testato una rete Avalanche controllata dall'istituzione in un flusso di regolamento di asset tokenizzati cross-chain, dimostrando l'architettura senza che ciò implichi che ANZ abbia lanciato un prodotto stablecoin pubblico su Avalanche.

Qual è la differenza tra una stablecoin e un deposito tokenizzato?

Entrambi gli strumenti possono rappresentare denaro su infrastrutture blockchain, ma si tratta di strumenti finanziari diversi. La Banca dei Regolamenti Internazionali (BIS) descrive i depositi tokenizzati come depositi bancari commerciali rappresentati su un registro programmabile o tokenizzato. Rimangono passività della banca commerciale emittente e dovrebbero trasferibili o rimborsabili alla pari con i depositi ordinari.

La struttura legale ed economica della posizione conta più del formato del token. Uno smart contract tecnicamente identico potrebbe rappresentare strumenti molto diversi a seconda di chi deve la passività, come funziona il rimborso e quali regole si applicano.

Quale stack tecnologico serve a un istituto finanziario per emettere denaro digitale?

Emettere denaro onchain richiede uno stack produttivo integrato, non soltanto uno smart contract. In pratica, le istituzioni necessitano di almeno sette livelli.

1. Integrazione con il registro di core. La rappresentazione onchain deve rimanere sincronizzata con i registri autorevoli dell'istituzione relativi a depositi, riserve o tesoreria. L'emissione e il rimborso richiedono quindi collegamenti controllati con i sistemi bancari e contabili di core.

2. Contratti di emissione e rimborso. Gli smart contract o logiche di registro equivalenti definiscono l'emissione, i trasferimenti, il burning/rimborso e i permessi amministrativi. I ruoli dovrebbero essere progettati intorno alla governance istituzionale, alla separazione dei compiti e alla gestione delle chiavi.

3. Rete blockchain o DLT. La rete registra proprietà e trasferimenti. Può trattarsi di un registro privato, di una rete consorziale, di una blockchain pubblica condivisa, di una catena permissionata o di una blockchain dedicata controllata dall'istituzione.

4. Controlli di identità e conformità. KYC, AML, screening delle sanzioni, allowlisting degli indirizzi, monitoraggio delle transazioni e controlli legalmente richiesti di congelamento o restrizione devono collegare il livello onchain ai processi di conformità dell'istituzione.

5. Infrastruttura di custodia e wallet. L'istituzione e i suoi clienti necessitano di una gestione sicura delle chiavi, autorizzazione delle transazioni, processi di recupero e controlli operativi.

6. Privacy e verificabilità. Le istituzioni possono aver bisogno di saldi o importi di transazione riservati, preservando l'accesso per revisori autorizzati, autorità di regolamentazione e funzioni di controllo interno.

7. Interoperabilità e connettività di regolamento. Lo strumento diventa più utile quando può interagire con altre banche, infrastrutture di pagamento, asset tokenizzati e reti blockchain senza costringere ogni partecipante su un unico registro. Ciò significa anche che le decisioni di interoperabilità incidono su governance e progettazione operativa, non solo sulla messaggistica tecnica: i partecipanti necessitano di permessi, processi di regolamento e responsabilità definiti attraverso i sistemi collegati.

Quali modelli blockchain stanno usando gli istituti finanziari?

Non esiste una singola architettura di settore. Le implementazioni e i progetti pilota attuali coprono tre modelli principali.

1. Reti private controllate dall'istituzione. Il Tokenized Deposit Service di HSBC è un esempio. HSBC dichiara che i clienti idonei possono convertire i depositi in token digitali e trasferire fondi da wallet a wallet in tempo reale, 24/7, tra le sedi HSBC partecipanti. Il servizio è costruito su una blockchain privata HSBC con permessi di livello enterprise. Questo modello massimizza il controllo istituzionale, ma la connettività oltre l'ambiente della banca richiede integrazioni aggiuntive.

2. Emissione su blockchain pubblica. Il JPM Coin di J.P. Morgan (JPMD) è un esempio. J.P. Morgan dichiara che il suo token di deposito denominato in USD è disponibile per i clienti istituzionali su Base, una rete Ethereum Layer 2. Questo colloca il token direttamente in un ambiente onchain pubblico, ma la banca non controlla la rete Base sottostante.

3. Reti dedicate controllate dall'istituzione e connesse a un ecosistema più ampio. Un terzo modello offre all'istituzione un proprio ambiente blockchain e una propria politica di validazione, preservando un percorso verso la connettività interchain. Le Avalanche L1 sono progettate per questa architettura.

Cos'è una Avalanche L1?

Una Avalanche1 è una rete sovrana nell'ecosistema Avalanche con un proprio insieme di validatori e regole configurabili. Le Avalanche L1 erano precedentemente note come Subnet. Invece di collocare l'applicazione di un'istituzione su blockspace condiviso, un'organizzazione può gestire una rete dedicata e definire come vengono gestiti validatori, accesso alle transazioni, deployment degli smart contract e commissioni.

Le Avalanche L1 possono utilizzare un ambiente di esecuzione compatibile EVM, consentendo ai team di lavorare con i familiari strumenti Ethereum e con applicazioni basate su Solidity. La documentazione Avalanche descrive anche la comunicazione nativa cross-L1 tramite Avalanche Interchain Messaging (ICM).

In che modo una Avalanche L1 può supportare una stablecoin o un deposito tokenizzato emesso da una banca?

I requisiti istituzionali pertinenti si traducono in una combinazione di controlli di rete delle Avalanche L1 e capacità distribuibili a livello applicativo. Perché è importante: alcune regole di partecipazione possono essere applicate dalla rete stessa, e non solo da un sito web, un'interfaccia wallet o un contratto applicativo. Questo può essere prezioso quando un'istituzione necessita di un ambiente di esecuzione controllato con validatori noti e transattori approvati.

Come può un istituto finanziario limitare il proprio token ai clienti verificati?

Su una Avalanche L1 basata su EVM, la Transaction AllowList può limitare quali indirizzi sono autorizzati a inviare transazioni. Un tipico flusso istituzionale si svolgerebbe così:

1. Il cliente completa i normali processi di onboarding e i controlli KYC/AML dell'istituzione.
2. L'indirizzo blockchain del cliente viene verificato e associato all'identità o al conto approvato.
3. L'indirizzo viene aggiunto all'insieme consentito.
4. L'indirizzo approvato può inviare transazioni alla L1.
5. Se l'autorizzazione viene revocata, l'istituzione rimuove o modifica il permesso di quell'indirizzo.

Questo non sostituisce KYC, screening delle sanzioni o monitoraggio delle transazioni. Fornisce all'istituzione un meccanismo a livello di rete per far rispettare l'esito di tali processi.

L'istituzione può controllare chi distribuisce smart contract?

Sì. La Deployer AllowList può limitare il deployment dei contratti agli indirizzi approvati. Ciò consente a un'istituzione regolamentata di impedire a terzi arbitrari di distribuire applicazioni nello stesso ambiente di rete del proprio token di deposito, asset di regolamento o altri flussi di lavoro regolamentati.

Un istituto finanziario può controllare le commissioni di rete?

Sì. Le Avalanche EVM L1 espongono parametri di commissione configurabili e un Fee Manager. Una L1 dedicata isola inoltre il blockspace dell'istituzione da applicazioni non correlate su una catena condivisa, il che può rendere costi e capacità più controllabili. La politica esatta delle commissioni e la progettazione del gas token restano scelte dell'operatore della L1.

I token emessi dall'istituzione possono rimanere riservati?

Possono, a seconda della progettazione. Encrypted ERC (eERC) di Avalanche è uno standard token riservato che cifra onchain i saldi dei token e gli importi dei trasferimenti, mantenendo le prove necessarie per transizioni di stato valide. Lo standard supporta inoltre una chiave di revisore opzionale che può decifrare saldi e importi per una supervisione autorizzata.

Una sfumatura importante: eERC non è una modalità di privacy automatica per ogni Avalanche L1. È uno standard token distribuibile utilizzabile su reti EVM compatibili, tra cui la Avalanche C-Chain e le Avalanche L1. Le istituzioni possono anche scegliere pattern di privacy a livello di rete, come limitare chi può connettersi a e leggere una L1 riservata ai soli validatori.

Perché l'interoperabilità è importante per il denaro digitale emesso dalle banche?

Un deposito digitale o una stablecoin è più preziosa quando può partecipare a regolamenti oltre il registro in cui è stata creata. I casi d'uso pertinenti includono il regolamento di titoli, il collaterale tokenizzato, i trasferimenti di tesoreria, flussi FX e i pagamenti cross-border.

Il Project Agorá del BIS illustra il punto: il suo prototipo del 2026 ha combinato depositi bancari commerciali tokenizzati e riserve di banche centrali tokenizzate su infrastrutture programmabili per testare il regolamento wholesale cross-border atomico e multivaluta. La sfida più ampia non è solo emettere denaro digitale, ma far sì che diverse forme di denaro e asset regolamentati collaborino in sicurezza.

All'interno di Avalanche, ICM fornisce messaggistica nativa tra le Avalanche L1. Un'istituzione può quindi progettare una L1 dedicata con proprie regole di partecipazione, mantenendo un percorso tecnico per comunicare con altre reti Avalanche. L'interoperabilità commerciale, legale e normativa deve comunque essere risolta separatamente.

Un istituto finanziario ha già testato questa architettura Avalanche?

Sì. ANZ ha testato una rete Avalanche controllata dall'istituzione nell'ambito di un progetto di regolamento di asset tokenizzati cross-chain con Chainlink. Nel flusso dimostrato, ANZ ha utilizzato una rete Avalanche Evergreen per la compatibilità EVM, il permissioning e un gas token personalizzato. Il progetto ha collegato Avalanche ed Ethereum tramite Chainlink CCIP e ha simulato un regolamento delivery-versus-payment coinvolgendo stablecoin e asset tokenizzati emessi da ANZ.

Il caso di studio dimostra che un grande istituto finanziario può utilizzare un ambiente Avalanche dedicato come parte di un'architettura di regolamento controllata e interoperabile. Non dovrebbe essere descritto come prova che ANZ abbia lanciato un prodotto stablecoin bancario generalmente disponibile su Avalanche, né come prova che Avalanche da sola fornisca ogni elemento del flusso end-to-end.

Blockchain privata vs. blockchain pubblica vs. Avalanche L1

Le Avalanche L1 vanno intese come una terza architettura, non come una sostituzione universale delle reti private o pubbliche: offrono un controllo dedicato della rete pur restando parte di un ecosistema blockchain multichain.

Una Avalanche L1 sostituisce i sistemi di core banking?

No. La blockchain è un livello dell'architettura. Le banche si affidano ancora a sistemi per i conti dei clienti, la contabilità generale, la tesoreria, la contabilità, i report normativi, sanzioni e AML, l'onboarding, la gestione delle riserve e i registri legalmente autorevoli. Il livello onchain deve essere integrato con quei sistemi affinché emissione, trasferimenti e rimborso restino coerenti con i libri contabili e gli obblighi legali dell'istituzione.

Cosa la tecnologia non risolve?

• Classificazione normativa. Sono le autorità a determinare se lo strumento è un deposito, una stablecoin, un prodotto di moneta elettronica, un titolo o un'altra posizione regolamentata.
• Trattamento di bilancio e delle riserve. Gli obblighi legali e contabili di una stablecoin o di un deposito tokenizzato esistono indipendentemente dalla blockchain selezionata.
• Rimborso. Gli utenti necessitano di un processo affidabile per convertire lo strumento digitale in denaro bancario convenzionale o in un altro asset di regolamento concordato.
• Finalità legale. La finalità tecnica delle transazioni e la finalità di regolamento legalmente riconosciuta sono correlate ma non identiche.
• Governance dell'interoperabilità. La messaggistica tecnica non crea da sola accordi commerciali, standard comuni o riconoscimento tra istituzioni e giurisdizioni.
• Politica di conformità. La tecnologia può far rispettare le regole, ma sono i regolatori e le istituzioni a definirle e a restare responsabili degli esiti di conformità.

Come dovrebbe una banca valutare l'infrastruttura blockchain per stablecoin o depositi tokenizzati?

Per le istituzioni che valutano un deployment in produzione, la decisione centrale non semplicemente quale catena supporta i trasferimenti di token. È come governanza di rete, integrazione dei registri, applicazione della conformità, privacy, finalità di regolamento e connettività esterna opereranno insieme. Questi requisiti dovrebbero essere valutati come un'unica architettura, poiché una capacità a livello blockchain non stabilisce automaticamente il corrispondente processo legale o operativo.

1. Chi controlla l'insieme dei validatori e gli aggiornamenti della rete?
2. Si può impedire a wallet non autorizzati di transare a livello di rete?
3. I permessi di deployment dei contratti, emissione e rimborso possono essere limitati a entità approvate?
4. Si possono supportare saldi e importi di transazione riservati dove richiesto?
5. Revisori o autorità di regolamentazione autorizzati possono ricevere la visibilità necessaria?
6. Commissioni e capacità sono prevedibili, o esposte a domanda non correlata su blockspace condiviso?
7. Qual è il modello di finalità tecnica della rete, e come si mappa sulla finalità di regolamento legale?
8. Lo strumento può interagire in sicurezza con altre reti, sistemi di pagamento e asset tokenizzati?
9. La piattaforma supporta standard e strumenti familiari, inclusa la compatibilità EVM dove utile?
10. L'architettura può aggiungere partecipanti, giurisdizioni e casi d'uso senza una riprogettazione completa?

In che cosa Avalanche è diversa per il denaro digitale emesso dalle istituzioni?

Avalanche non è l'unica tecnologia valida. Ethereum e le reti Layer 2 offrono un ampio accesso a chain pubbliche; le piattaforme DLT private offrono un forte controllo istituzionale; e le banche stanno già utilizzando entrambi gli approcci.

Il fattore distintivo di Avalanche è architetturale: un'istituzione può operare una L1 sovrana invece di limitarsi a distribuire un token sulla rete condivisa di altri. Quella L1 può combinare validatori permissionati, controlli su transazioni e deployment, commissioni configurabili, compatibilità EVM e messaggistica interchain nativa. Funzionalità di token riservati come eERC possono essere aggiunte dove l'applicazione lo richiede.

Per una banca che considera sia il controllo dell'infrastruttura sia la connettività all'ecosistema come requisiti di primaria importanza, questa combinazione è l'argomento più forte a favore di una Avalanche L1.

Domande frequenti

Quale tecnologia consente a una banca di emettere una propria stablecoin o un deposito tokenizzato?
Tecnologia blockchain o di registro distribuito combinata con smart contract, integrazione con i registri di core, controlli di identità e conformità, custodia, privacy e connettività di regolamento. Una banca può utilizzare una rete privata, una blockchain pubblica o una rete dedicata controllata dall'istituzione come una Avalanche L1.

Cos'è un deposito tokenizzato?
Un deposito tokenizzato è un deposito bancario commerciale rappresentato su infrastrutture programmabili o tokenizzate. Rimane una passività della banca emittente ed è concepito per preservare le caratteristiche economiche di un deposito bancario.

Un deposito tokenizzato è la stessa cosa di una stablecoin?
No. Un deposito tokenizzato è una passività di deposito bancario. Una stablecoin è un token digitale emesso separatamente, progettato per mantenere un valore stabile, e può avere un emittente, un modello di garanzia, una struttura di rimborso e un trattamento normativo diversi.

Le banche usano già la blockchain per i depositi tokenizzati?
Sì. HSBC gestisce un Tokenized Deposit Service su infrastruttura blockchain privata, mentre J.P. Morgan rende il proprio token di deposito in USD JPMD disponibile per i clienti istituzionali su Base, una Ethereum Layer 2 pubblica.

Cos'è una Avalanche L1?
Una Avalanche L1 è una rete sovrana nell'ecosistema Avalanche con un proprio insieme di validatori e regole configurabili. Può essere progettata come rete istituzionale permissionata e può utilizzare un ambiente di esecuzione compatibile EVM.

Una banca può limitare chi usa una Avalanche L1?
Sì. Una Avalanche EVM L1 può utilizzare una Transaction AllowList per limitare l'invio di transazioni agli indirizzi approvati, oltre alla gestione permissionata dei validatori.

I saldi dei token possono rimanere riservati su Avalanche?
Sì, a seconda della progettazione. Encrypted ERC può cifrare saldi dei token e importi dei trasferimenti e supporta una chiave di revisore opzionale. La privacy a livello di rete può anche essere implementata limitando l'accesso a una L1 riservata ai soli validatori.

Una banca ha usato la propria rete Avalanche?
ANZ ha utilizzato la propria rete Avalanche Evergreen in un test di regolamento di asset tokenizzati con Chainlink. Il progetto ha impiegato compatibilità EVM permissioning e un gas token personalizzato nell'ambito di un flusso DvP cross-chain.

Una banca ha bisogno di una propria blockchain per emettere un deposito tokenizzato?
No. Una banca può utilizzare infrastrutture private, distribuire su una catena pubblica o gestire una blockchain dedicata. Una Avalanche L1 dedicata è più rilevante quando l'istituzione desidera il controllo a livello di rete e un percorso verso una più ampia connettività blockchain.

In conclusione

Le banche non necessitano di un'architettura blockchain specifica per emettere denaro digitale. Reti private, blockchain pubbliche e catene istituzionali dedicate possono tutte supportare stablecoin o depositi tokenizzati. Le domande migliori sono quanta parte dell'infrastruttura l'istituzione debba controllare, quanta privacy e permissioning richieda e quanto connesso debba essere il denaro risultante.

Una blockchain privata massimizza il controllo ma può isolarsi. Una blockchain pubblica condivisa massimizza l'accesso diretto all'ecosistema ma lascia la rete di base fuori dal controllo della banca. Una Avalanche L1 offre un terzo modello: l'istituzione può gestire il proprio ambiente blockchain sovrano, configurare chi valida e chi transa, controllare deployment e commissioni e connettersi ad altre reti Avalanche tramite messaggistica interchain nativa.

Quell'architettura non elimina il lavoro legale, normativo, contabile o operativo necessario per emettere denaro digitale. Fornisce agli istituti finanziari un livello blockchain configurabile su cui tali requisiti possono essere implementati.

Fonte: Metaverse Post