En résumé, une banque peut émettre un stablecoin ou un dépôt tokenisé en utilisant la blockchain ou la technologie de registre distribué (DLT), combinée à des smart contracts, une intégration au registre central, des contrôles d'identité et de conformité, la conservation d'actifs, des outils de confidentialité et une connectivité de règlement. Le principal choix d'architecture se situe entre un réseau privé à permission, une blockchain publique ou une blockchain dédiée contrôlée par l'institution.

Un Avalanche L1 correspond au troisième modèle : l'institution peut exploiter un réseau souverain avec ses propres politiques de validation et de transactions, tout en conservant une connectivité native à l'écosystème Avalanche élargi.

Une distinction essentielle structure tout le sujet : la blockchain elle-même ne détermine pas si un instrument est juridiquement un stablecoin ou un dépôt tokenisé. Cela dépend de l'émetteur, de la créance juridique, du backing, du modèle de rachat et de la réglementation applicable.

Points clés

• Les dépôts tokenisés sont des passifs de dépôts bancaires commerciaux représentés sur une infrastructure programmable, tandis que les stablecoins sont des jetons émis séparément, conçus pour maintenir une valeur stable, chacun avec son propre backing et sa propre structure réglementaire.
• L'émission exige plus qu'un contrat de jeton : les institutions ont également besoin d'une intégration au registre, de contrôles KYC/AML, de la conservation d'actifs, de la confidentialité, de l'auditabilité, de processus de rachat et d'interopérabilité.
• Les Avalanche L1 permettent aux institutions de configurer la participation des validateurs,'accès aux transactions, le déploiement de contrats et les paramètres de frais réseau au niveau du réseau.
• Encrypted ERC (eERC) peut ajouter des soldes et des montants de transfert confidentiels, y compris une fonction d'auditeur optionnelle, mais il s'agit d'un standard de jeton déployable et non d'une fonctionnalité automatique de chaque Avalanche L1.
• ANZ a testé un réseau Avalanche contrôlé par l'institution dans un flux de règlement trans-chaîne d'actifs tokenisés, démontrant l'architecture sans que cela implique qu'ANZ ait lancé un produit de stablecoin public sur Avalanche.

Quelle est la différence entre un stablecoin et un dépôt tokenisé ?

Les deux instruments peuvent représenter de la monnaie sur une infrastructure blockchain, mais ce sont des instruments financiers différents. La Banque des règlements internationaux (BRI) décrit les dépôts tokenisés comme des dépôts bancaires commerciaux représentés sur un registre programmable ou tokenisé. Ils demeurent des passifs de la banque commerciale émettrice et devraient être transférables ou rachetables au pair avec les dépôts ordinaires.

La structure juridique et économique de la créance importe plus que le format du jeton. Un smart contract techniquement identique pourrait représenter des instruments très différents selon qui doit la créance, comment fonctionne le rachat et quelles règles s'appliquent.

Quelle pile technologique une institution financière doit-elle avoir pour émettre de la monnaie numérique ?

Émettre de la monnaie on-chain nécessite une pile de production connectée, et pas seulement un smart contract. En pratique, les institutions ont besoin d'au moins sept couches.

1. Intégration au registre central. La représentation on-chain doit rester synchronisée avec les registres faisant autorité de l'institution en matière de dépôts, de réserves ou de trésorerie. L'émission et le rachat nécessitent donc des liens contrôlés vers les systèmes bancaires et comptables centraux.

2. Contrats d'émission et de rachat. Les smart contracts ou une logique de registre équivalente définissent l'émission, les transferts, la destruction/le rachat et les permissions administratives. Les rôles doivent être conçus autour de la gouvernance institutionnelle, de la séparation des tâches et de la gestion des clés.

3. Réseau blockchain ou DLT. Le réseau enregistre la propriété et les transferts. Il peut s'agir d'un registre privé, d'un réseau de consortium, d'une chaîne publique partagée, d'une chaîne à permission ou d'une blockchain dédiée contrôlée par l'institution.

4. Contrôles d'identité et de conformité. Le KYC, l'AML, le filtrage des sanctions, l'allowlisting des adresses, la surveillance des transactions et les contrôles de gel ou de restriction imposés par la loi doivent relier la couche on-chain aux processus de conformité de l'institution.

5. Infrastructure de conservation et de portefeuilles. L'institution et ses clients ont besoin d'une gestion sécurisée des clés, d'une autorisation des transactions, de processus de récupération et de contrôles opérationnels.

6. Confidentialité et auditabilité. Les institutions peuvent avoir besoin de soldes ou de montants de transaction confidentiels tout en préservant l'accès des auditeurs autorisés, des régulateurs et des fonctions de contrôle interne.

7. Interopérabilité et connectivité de règlement. L'instrument devient plus utile lorsqu'il peut interagir avec d'autres banques, rails de paiement, actifs tokenisés et réseaux blockchain sans forcer chaque participant sur un seul registre. Cela signifie également que les décisions d'interopérabilité affectent la gouvernance et la opérationnelle, et pas seulement la messagerie technique : les participants ont besoin de permissions, de processus de règlement et de responsabilités définis à travers les systèmes connectés.

Quels modèles blockchain les institutions financières utilisent-elles ?

Il n'existe pas d'architecture unique dans le secteur. Les déploiements et pilotes actuels couvrent trois grands modèles.

1. Réseaux privés contrôlés par l'institution. Le service de dépôts tokenisés de HSBC en est un exemple. HSBC indique que les clients éligibles peuvent convertir leurs dépôts en jetons numériques et transférer des fonds de portefeuille à portefeuille en temps réel, 24h/24 et 7j/7, entre les sites HSBC participants. Le service repose sur une blockchain HSBC privée avec des permissions de niveau entreprise. Ce modèle maximise le contrôle institutionnel, mais la connectivité au-delà de l'environnement propre de la banque nécessite des intégrations supplémentaires.

2. Émission sur blockchain publique. Le JPM Coin (JPMD) de J.P. Morgan en est un exemple. J.P. Morgan indique que son jeton de dépôt libellé en USD est disponible pour les clients institutionnels sur Base, un réseau Layer 2 d'Ethereum. Cela place le jeton directement dans un environnement on-chain public, mais la banque ne contrôle pas le réseau Base sous-jacent.

3. Réseaux dédiés contrôlés par l'institution et connectés à un écosystème plus large. Un troisième modèle donne à l'institution son propre environnement blockchain et sa propre politique de validation, tout en préservant un chemin vers la connectivité inter-chaînes. Les Avalanche L1 sont conçus pour cette architecture.

Qu'est-ce qu'un Avalanche L1 ?

Un Avalanche L1 est un réseau souverain de l'écosystème Avalanche avec son propre ensemble de validateurs et des règles configurables. Les Avalanche L1 étaient anciennement appelés Subnets. Plutôt que de placer son application sur un espace de blocs partagé, une organisation peut exploiter un réseau dédié et définir la gestion des validateurs, de l'accès aux transactions, du déploiement de smart contracts et des frais.

Les Avalanche L1 peuvent utiliser un environnement d'exécution compatible EVM, permettant aux équipes de travailler avec les outils Ethereum familiers et des applications basées sur Solidity. La documentation Avalanche décrit également une communication native entre L1 via Avalanche Interchain Messaging (ICM).

Comment un Avalanche L1 peut-il prendre en charge un stablecoin ou un dépôt tokenisé émis par une banque ?

Les exigences institutionnelles pertinentes correspondent à une combinaison de contrôles réseau des Avalanche L1 et de capacités déployables au niveau applicatif. Pourquoi c'est important : certaines règles de participation peuvent être appliquées par le réseau lui-même plutôt que uniquement par un site web, une interface de portefeuille ou un contrat applicatif. Cela peut s'avérer précieux lorsqu'une institution a besoin d'un environnement d'exécution contrôlé avec des validateurs connus et des émetteurs de transactions approuvés.

Comment une institution financière peut-elle restreindre son jeton aux clients vérifiés ?

Sur un Avalanche L1 basé sur EVM, la Transaction AllowList peut restreindre les adresses autorisées à soumettre des transactions. Un flux institutionnel typique serait le suivant :

1. Le client effectue les vérifications d'onboarding et de KYC/AML habituelles de l'institution.
2. L'adresse blockchain du client est vérifiée et liée à l'identité ou au compte approuvé.
3. L'adresse est ajoutée à l'ensemble autorisé.
4. L'adresse approuvée peut soumettre des transactions au L1.
5. Si l'autorisation est retirée, l'institution supprime modifie la permission de cette adresse.

Cela ne remplace pas le KYC, le filtrage des sanctions ou la surveillance des transactions. Cela donne à l'institution un mécanisme au niveau du réseau pour appliquer le résultat de ces processus.

L'institution peut-elle contrôler qui déploie des smart contracts ?

Oui. La Deployer AllowList peut limiter le déploiement de contrats aux adresses approuvées. Cela permet à une institution régulée d'empêcher des tiers arbitraires de déployer des applications dans le même environnement réseau que son jeton de dépôt, son actif de règlement ou ses autres flux régulés.

Une institution financière peut-elle contrôler les frais réseau ?

Oui. Les Avalanche EVM L1 exposent des paramètres de frais configurables et un Fee Manager. Un L1 dédié isole également l'espace de blocs de l'institution des applications sans rapport sur une chaîne partagée, ce qui peut rendre les coûts et la capacité plus contrôlables. La politique de frais exacte et la conception du jeton de gaz restent des choix de l'opérateur du L1.

Les jetons émis par une institution peuvent-ils rester confidentiels ?

Ils le peuvent, selon la conception. Encrypted ERC (eERC) d'Avalanche est un standard de jeton confidentiel qui chiffre les soldes de jetons et les montants de transfert on-chain tout en conservant les preuves nécessaires aux transitions d'état valides. Le standard prend également en charge une clé d'auditeur optionnelle capable de déchiffrer les soldes et les montants pour une supervision autorisée.

Une nuance importante : eERC n'est pas un mode de confidentialité automatique pour chaque Avalanche L1. Il s'agit d'un standard de jeton déployable utilisable sur les réseaux EVM compatibles, y compris la C-Chain d'Avalanche et les Avalanche L1. Les institutions peuvent également choisir des schémas de confidentialité au niveau du réseau, comme restreindre qui peut se connecter à et lire un L1 réservé aux validateurs.

Pourquoi l'interopérabilité est-elle importante pour la monnaie numérique émise par les banques ?

Un dépôt numérique ou un stablecoin a plus de valeur lorsqu'il peut participer à des règlements au-delà du registre où il a été créé. Les cas d'usage pertinents incluent le règlement de titres, les collatéraux tokenisés, les transferts de trésorerie, les flux FX et les paiements transfrontaliers.

Le projet Agorá de la BRI illustre le propos : son prototype de 2026 a combiné des dépôts bancaires commerciaux tokenisés et des réserves de banques centrales tokenisées sur une infrastructure programmable pour tester un règlement de gros atomique et multidevise transfrontalier. Le défi plus large n'est pas seulement d'émettre de la monnaie numérique, mais de faire interagir en toute sécurité différentes formes de monnaie et d'actifs régulés.

Au sein d'Avalanche, ICM fournit une messagerie native entre les Avalanche L1. Une institution peut donc concevoir un L1 dédié avec ses propres règles de participation tout en conservant un chemin technique pour communiquer avec d'autres réseaux Avalanche. L'interopérabilité commerciale, juridique et réglementaire reste à résoudre séparément.

Une institution financière a-t-elle testé cette architecture Avalanche ?

Oui. ANZ a testé un réseau Avalanche contrôlé par l'institution dans le cadre d'un projet de règlement trans-chaîne d'actifs tokenisés avec Chainlink. Dans le flux démontré, ANZ a utilisé un réseau Avalanche Evergreen pour la compatibilité EVM, les permissions et un jeton de gaz personnalisé. Le projet a relié Avalanche et Ethereum via Chainlink CCIP et a simulé un règlement livraison contre paiement impliquant des stablecoins émis par ANZ et des actifs tokenisés.

L'étude de cas démontre qu'une grande institution financière peut utiliser un environnement Avalanche dédié dans le cadre d'une architecture de règlement contrôlée et interopérable. Elle ne doit pas être présentée comme la preuve qu'ANZ a lancé un produit de stablecoin bancaire généralement disponible sur Avalanche, ni comme la preuve qu'Avalanche fournit à lui seul tous les éléments du flux de bout en bout.

Blockchain privée vs blockchain publique vs Avalanche L1

Les Avalanche L1 sont donc mieux compris comme une troisième architecture plutôt que comme un remplacement universel des réseaux privés ou publics : ils offrent un contrôle réseau dédié tout en restant partie intégrante d'un écosystème blockchain multi-chaînes.

Un Avalanche L1 remplace-t-il les systèmes bancaires centraux ?

Non. La blockchain est une couche de l'architecture. Les banques continuent de s'appuyer sur des systèmes pour les comptes clients, le grand livre, la trésorerie, la comptabilité, le reporting réglementaire, les sanctions et l'AML, l'onboarding, la gestion des réserves et les registres faisant autorité juridiquement. La couche on-chain doit être intégrée à ces systèmes afin que l'émission, les transferts et le rachat restent cohérents avec la comptabilité et les obligations juridiques de l'institution.

Ce que la technologie ne résout pas

• Classification réglementaire. Les autorités déterminent si l'instrument est un dépôt, un stablecoin, un produit de monnaie électronique, un titre ou une autre créance régulée.
• Traitement au bilan et des réserves. Les obligations juridiques et comptables d'un stablecoin ou d'un dépôt tokenisé existent indépendamment de la blockchain choisie.
• Rachat. Les utilisateurs ont besoin d'un processus fiable pour convertir l'instrument numérique en monnaie bancaire conventionnelle ou en un autre actif de règlement convenu.
• Finalité juridique. La finalité technique des transactions et la finalité juridiquement reconnue du règlement sont liées mais ne sont pas identiques.
• Gouvernance de l'interopérabilité. La messagerie technique ne crée pas à elle seule d'accords commerciaux, de standards communs ou de reconnaissance entre institutions et juridictions.
• Politique de conformité. La technologie peut appliquer des règles, mais les régulateurs et les institutions définissent les règles et restent responsables des résultats de conformité.

Comment une banque doit-elle évaluer l'infrastructure blockchain pour les stablecoins ou les dépôts tokenisés ?

Pour les institutions évaluant un déploiement en production, la décision centrale n'est pas simplement de savoir quelle chaîne prend en charge les transferts de jetons. Il s'agit de savoir comment la gouvernance du réseau, l'intégration au registre, l'application de la conformité, la confidentialité, la finalité du règlement et la connectivité externe fonctionneront ensemble. Ces exigences doivent être évaluées comme une seule architecture, car une capacité au niveau de la blockchain n'établit pas automatiquement le processus juridique ou opérationnel correspondant.

1. Qui contrôle l'ensemble des validateurs et les mises à niveau du réseau ?
2. Peut-on empêcher des portefeuilles non autorisés de transiger au niveau du réseau ?
3. Les permissions de déploiement de contrats, d'émission et de rachat peuvent-elles être limitées aux entités approuvées ?
4. Les soldes et montants de transaction confidentiels peuvent-ils être pris en charge lorsque nécessaire ?
5. Les auditeurs ou régulateurs autorisés peuvent-ils recevoir la visibilité dont ils ont besoin ?
6. Les frais et la capacité sont-ils prévisibles, ou exposés à une demande sans rapport sur un espace de blocs partagé ?
7. Quel est le modèle de finalité technique du réseau, et comment correspond-il à la finalité juridique du règlement ?
8. L'instrument peut-il interagir en toute sécurité avec d'autres réseaux, de paiement et actifs tokenisés ?
9. La plateforme prend-elle en charge les standards et outils familiers, y compris la compatibilité EVM lorsque utile ?
10. L'architecture peut-elle ajouter des participants, juridictions et cas d'usage sans refonte complète ?

En quoi Avalanche est-il différent pour la monnaie numérique émise par les institutions ?

Avalanche n'est pas la seule technologie viable. Ethereum et les réseaux Layer 2 offrent un large accès aux chaînes publiques ; les plateformes DLT privées offrent un fort contrôle institutionnel ; et les banques utilisent déjà les deux approches.

Le différenciateur d'Avalanche est architectural : une institution peut exploiter un L1 souverain plutôt que de simplement déployer un jeton sur le réseau partagé de quelqu'un d'autre. Ce L1 peut combiner des validateurs à permission, des contrôles de transaction et de déploiement, des frais configurables, la compatibilité EVM et une messagerie inter-chaînes native. Des fonctionnalités de jetons confidentiels telles qu'eERC peuvent être ajoutées lorsque l'application l'exige.

Pour une banque qui considère à la fois le contrôle de l'infrastructure et la connectivité à l'écosystème comme des exigences de premier ordre, cette combinaison constitue l'argument le plus solide en faveur d'un Avalanche L1.

Questions fréquentes

Quelle technologie permet à une banque d'émettre son propre stablecoin ou dépôt tokenisé ?
La blockchain ou la technologie de registre distribué combinée à des smart contracts, une intégration au registre central, des contrôles d'identité et de conformité, la conservation d'actifs, la confidentialité et une connectivité de règlement. Une banque peut utiliser un réseau privé, une blockchain publique ou un réseau dédié contrôlé par l'institution tel qu'un Avalanche L1.

Qu'est-ce qu'un dépôt tokenisé ?
Un dépôt tokenisé est un dépôt bancaire commercial représenté sur une infrastructure programmable ou tokenisée. Il demeure un passif de la banque émettrice et vise à préserver les caractéristiques économiques d'un dépôt bancaire.

Un dépôt tokenisé est-il la même chose qu'un stablecoin ?
Non. Un dépôt tokenisé est un passif de dépôt bancaire. Un stablecoin est un jeton numérique émis séparément, conçu pour maintenir une valeur stable, et peut avoir un émetteur, un modèle de backing, une structure de rachat et un traitement réglementaire différents.

Les banques utilisent-elles déjà la blockchain pour les dépôts tokenisés ?
Oui. HSBC exploite un service de dépôts tokenisés sur une infrastructure blockchain privée, tandis que J.P. Morgan rend son jeton de dépôt USD JPMD disponible pour les clients institutionnels sur Base, un Layer 2 public d'Ethereum.

Qu'est-ce qu'un Avalanche L1 ?
Un Avalanche L1 est un réseau souverain de l'écosystème Avalanche avec son propre ensemble de validateurs et des règles configurables. Il peut être conçu comme un réseau institutionnel à permission et utiliser un environnement d'exécution compatible EVM.

Une banque peut-elle restreindre qui utilise un Avalanche L1 ?
Oui. Un Avalanche EVM L1 peut utiliser une Transaction AllowList pour restreindre la soumission de transactions aux adresses approuvées, en complément d'une gestion des validateurs à permission.

Les soldes de jetons peuvent-ils rester confidentiels sur Avalanche ?
Oui, selon la conception. Encrypted ERC peut chiffrer les soldes de jetons et les montants de transfert et prend en charge une clé d'auditeur optionnelle. La confidentialité au niveau du réseau peut également être mise en œuvre en restreignant l'accès à un L1 réservé aux validateurs.

Une banque a-t-elle utilisé son propre réseau Avalanche ?
ANZ a utilisé son propre réseau Avalanche Evergreen dans un test de règlement d'actifs tokenisés avec Chainlink. Le projet a utilisé la compatibilité EVM, les permissions et un jeton de gaz personnalisé dans le cadre d'un flux DvP trans-chaîne.

Une banque a-t-elle besoin de sa propre blockchain pour émettre un dépôt tokenisé ?
Non. Une banque peut utiliser une infrastructure privée, déployer sur une chaîne publique ou exploiter une blockchain dédiée. Un Avalanche L1 dédié est surtout pertinent lorsque lstitution souhaite un contrôle au niveau du réseau et un chemin vers une connectivité blockchain plus large.

En conclusion

Les banques n'ont pas besoin d'une architecture blockchain spécifique pour émettre de la monnaie numérique. Les réseaux privés, les blockchains publiques et les chaînes institutionnelles dédiées peuvent tous prendre en charge des stablecoins ou des dépôts tokenisés. Les meilleures questions sont : quelle part de l'infrastructure l'institution doit-elle contrôler, quel niveau de confidentialité et de permissions lui faut-il, et à quel point la monnaie résultante doit-elle être connectée.

Une blockchain privée maximise le contrôle mais peut devenir isolée. Une blockchain publique partagée maximise l'accès direct à l'écosystème mais laisse le réseau de base hors du contrôle de la banque. Un Avalanche L1 offre un troisième modèle : l'institution peut exploiter son propre environnement blockchain souverain, configurer qui valide et qui transige, contrôler le déploiement et les frais, et se connecter à d'autres réseaux Avalanche via une messagerie inter-chaînes native.

Cette architecture ne supprime pas le travail juridique, réglementaire, comptable ou opérationnel requis pour émettre de la monnaie numérique. Elle donne aux institutions financières une couche blockchain configurable sur laquelle ces exigences peuvent être mises en œuvre.

Source : Metaverse Post