Kortom, een bank kan een stablecoin of een getokeniseerde deposito uitgeven met behulp van blockchain of distributed ledger-technologie (DLT) in combinatie met smart contracts, kernadministratie-integratie, identiteits- en compliancecontroles, custody, privacytooling en settlementconnectiviteit. De belangrijkste architectuurkeuze ligt tussen een private permissioned netwerk, een publieke blockchain of een dedicated blockchain onder controle van de instelling.

Een Avalanche L1 past in het derde model: de instelling kan een souverein netwerk exploiteren met eigen validator- en transactiebeleid, met behoud van native connectiviteit met het bredere Avalanche-ecosysteem.

Een belangrijk onderscheid kenmerkt het hele onderwerp: de blockchain zelf bepaalt niet of een instrument juridisch een stablecoin of een getokeniseerde deposito is. Dat hangt af van de emittent, de juridische claim, de dekking, het aflossingsmodel en de toepasselijke regelgeving.

Kernpunten

• Getokeniseerde deposito's zijn vorderingen op commercieel-bancaire deposito's die worden weergegeven op programmeerbare infrastructuur, terwijl stablecoins afzonderlijk uitgegeven tokens zijn die ontworpen zijn om een stabiele waarde te behouden, elk met een eigen dekkings- en regelgevingsstructuur.
• Uitgifte vereist meer dan een tokencontract: instellingen hebben ook administratie-integratie, KYC/AML-controles, custody, privacy, auditbaarheid, aflossingsprocessen en interoperabiliteit nodig.
• Avalanche L1's stellen instellingen in staat validatordeelname, transactietoegang, contractimplementatie en netwerkfeeparameters op netwerkniveau te configureren.
• Encrypted ERC (ERC) kan vertrouwelijke saldi en transferbedragen toevoegen, inclusief een optionele auditorfunctionaliteit, maar het is een implementeerbare tokenstandaard en geen automatische feature van elke Avalanche L1.
• ANZ heeft een instellingsgecontroleerd Avalanche-netwerk getest in een cross-chain workflow voor getokeniseerde asset-settlement, waarmee de architectuur wordt gedemonstreerd zonder te impliceren dat ANZ een publiek stablecoinproduct op Avalanche heeft gelanceerd.

Wat is het verschil tussen een stablecoin en een getokeniseerde deposito?

Beide instrumenten kunnen geld vertegenwoordigen op blockchaininfrastructuur, maar het zijn verschillende financiële instrumenten. De Bank for International Settlements (BIS) omschrijft getokeniseerde deposito's als commercieel-bancaire deposito's die worden weergegeven op een programmeerbare of getokeniseerde ledger. Ze blijven schulden van de uitgevende commerciële bank en moeten tegen par overdraagbaar of inwisselbaar zijn met gewone deposito's.

De juridische en economische structuur van de claim is belangrijker dan het tokenformaat. Een technisch identieke smart contract zou zeer verschillende instrumenten kunnen vertegenwoordigen, afhankelijk van wie de schuld verschuldigd is, hoe aflossing werkt en welke regels van toepassing zijn.

Welke technologiestapel heeft een financiële instelling nodig om digitaal geld uit te geven?

Het uitgeven van geld onchain vereist een verbonden productiestapel, niet alleen een smart contract. In de praktijk hebben instellingen ten minste zeven lagen nodig.

1. Kernadministratie-integratie. De onchain-weergave moet gesynchroniseerd blijven met de gezaghebbende deposito-, reserve- of treasury-administratie van de instelling. Minting en aflossing vereisen daarom gecontroleerde verbindingen met kernbank- en boekhoudsystemen.

2. Uitgifte- en aflossingscontracten. Smart contracts of equivalente ledgerlogica definiëren minting, transfers, burning en aflossing, en administratieve machtigingen. Rollen moeten worden ontworpen rond institutioneel bestuur, scheiding van taken en key management.

3. Blockchain- of DLT-netwerk. Het netwerk registreert eigendom en overdracht. Het kan een private ledger, een consortiumnetwerk, een gedeelde publieke chain, een permissioned chain of een dedicated blockchain onder controle van de instelling zijn.

4. Identiteits- en compliancecontroles. KYC, AML, sanctinesscreening, address allowlisting, transactiemonitoring en wettelijk vereiste freeze- of restrictiecontroles moeten de onchain-laag verbinden met de complianceprocessen de instelling.

5. Custody- en walletinfrastructuur. De instelling en haar klanten hebben veilig key management, transactieautorisatie, herstelprocessen en operationele controles nodig.

6. Privacy en auditbaarheid. Instellingen kunnen vertrouwelijke saldi of transactiebedragen nodig hebben, met behoud van toegang voor geautoriseerde auditors, toezichthouders en interne controlefuncties.

7. Interoperabiliteit en settlementconnectiviteit. Het instrument wordt nuttiger wanneer het kan interageren met andere banken, betalingssystemen, getokeniseerde assets en blockchainnetwerken zonder elke deelnemer op één ledger te dwingen. Dit betekent ook dat beslissingen over interoperabiliteit bestuur en operationeel ontwerp beïnvloeden, en niet alleen technische berichtenuitwisseling: deelnemers hebben gedefinieerde machtigingen, settlementprocessen en verantwoordelijkheden nodig over de verbonden systemen.

Welke blockchainmodellen gebruiken financiële instellingen?

Er is geen enkele industriestandaardarchitectuur. Huidige implementaties en pilots omvatten drie brede modellen.

1. Private instellingsgecontroleerde netwerken. HSBC's Tokenized Deposit Service is een voorbeeld. HSBC zegt dat in aanmerking komende klanten deposito's kunnen omzetten in digitale tokens en fondsen wallet-naar-wallet in realtime kunnen overdragen, 24/7, tussen deelnemende HSBC-locaties. De dienst is gebouwd op een private HSBC-blockchain met enterprisegrademachtigingen. Dit model maximaliseert institutionele controle, maar connectiviteit buiten de eigen omgeving van de bank vereist aanvullende integratie.

2. Publieke blockchain-uitgifte. J.P. Morgan's JPM Coin (JPMD) is een voorbeeld. J.P. Morgan stelt dat zijn in USD gedenomineerde depositotoken beschikbaar is voor institutionele klanten op Base, een Ethereum Layer 2-netwerk. Dit plaatst het token direct in een publieke onchain-omgeving, maar de bank beheerst het onderliggende Base-netwerk niet.

3. Dedicated instellingsgecontroleerde netwerken verbonden met een breder ecosysteem. Een derde model geeft de instelling een eigen blockchainomgeving en validatorbeleid met behoud van een pad naar interchain-connectiviteit. Avalanche L1's zijn ontworpen voor deze architectuur.

Wat is een Avalanche L1?

Een Avalanche L1 is een souverein netwerk in het Avalanche-ecosysteem met een eigen validatorsset en configureerbare regels. Avalanche L1's stonden voorheen bekend als Subnets. In plaats van de applicatie van een instelling op gede blockspace te plaatsen, kan een organisatie een dedicated netwerk draaien en bepalen hoe validators, transactietoegang, smart contract-implementatie en fees worden beheerd.

Avalanche L1's kunnen een EVM-compatibele executieomgeving gebruiken, waardoor teams kunnen werken met bekende Ethereum-tooling en Solidity-gebaseerde applicaties. Avalanche-documentatie beschrijft ook native cross-L1-communicatie via Avalanche Interchain Messaging (ICM).

Hoe kan een Avalanche L1 een door een bank uitgegeven stablecoin of getokeniseerde deposito ondersteunen?

De relevante institutionele vereisten vertalen zich naar een combinatie van Avalanche L1-netwerkcontroles en implementeerbare applicatielaagcapaciteiten. Waarom dit belangrijk is: sommige deelnameregels kunnen door het netwerk zelf worden afgedwongen in plaats van alleen door een website, walletinterface of applicatiecontract. Dat kan waardevol zijn wanneer een instelling een gecontroleerde executieomgeving nodig heeft met bekende validators en goedgekeurde transactoren.

Hoe kan een financiële instelling zijn token beperken tot geverifieerde klanten?

Op een op EVM gebaseerde Avalanche L1 kan de Transaction AllowList beperken welke adressen transacties mogen indienen. Een typische institutionele flow verloopt als volgt:

1. De klant doorloopt de normale onboarding- en KYC/AML-controles van de instelling.
2. Het blockchainadres van de klant wordt geverifieerd en gebonden aan de goedgekeurde identiteit of account.
3. Het adres wordt toegevoegd aan de toegestane set.
4. Het goedgekeurde adres kan transacties indienen bij de L1.
5. Als de autorisatie wordt ingetrokken, verwijdert of wijzigt de instelling de machtiging van dat adres.

Dit vervangt geen KYC, sanctinesscreening of transactiemonitoring. Het geeft de instelling een mechanisme op netwerkniveau om het resultaat van die processen af te dwingen.

Kan de instelling bepalen wie smart contracts implementeert?

Ja. De Deployer AllowList kan contractimplementatie beperken tot goedgekeurde adressen. Zo kan een gereguleerde instelling voorkomen dat willekeurige derden applicaties implementeren in dezelfde netwerkomgeving als haar depositotoken, settlementasset of andere gereguleerde workflows.

Kan een financiële instelling netwerkfees beheren?

Ja. Avalanche EVM L1's bieden configureerbare feeparameters en een Fee Manager. Een dedicated L1 isoleert bovendien de blockspace van de instelling van ongerelateerde applicaties op een gedeelde chain, wat kosten en capaciteit beheersbaarder kan maken. Het exacte feebeleid en het ontwerp van het gas-token blijven keuzes voor de L1-operator.

Kunnen door instellingen uitgegeven tokens vertrouwelijk blijven?

Dat kan, afhankelijk van het ontwerp. Avalanche's Encrypted ERC (eERC) is vertrouwelijke tokenstandaard die tokensaldi en transferbedragen onchain versleutelt, met behoud van de bewijzen die nodig zijn voor geldige statustransities. De standaard ondersteunt ook een optionele auditorsleutel die saldi en bedragen kan ontsleutelen voor geautoriseerd toezicht.

Een belangrijke nuance: eERC is geen automatische privacymodus voor elke Avalanche L1. Het is een implementeerbare tokenstandaard die kan worden gebruikt op compatibele EVM-netwerken, waaronder de Avalanche C-Chain en Avalanche L1's. Instellingen kunnen ook netwerkniveau-privacypatronen kiezen, zoals beperken wie verbinding kan maken met en lezen van een validator-only L1.

Waarom is interoperabiliteit belangrijk voor door banken uitgegeven digitaal geld?

Een digitale deposito of stablecoin is waardevoller wanneer deze kan deelnemen aan settlement buiten de ledger waarop deze is gecreëerd. Relevante use cases zijn onder meer effectensettlement, getokeniseerd onderpand, treasury-overboekingen, FX-workflows en grensoverschrijdende betalingen.

Het BIS-project Agorá illustreert het punt: het prototype van 2026 combineerde getokeniseerde commercieel-bancaire deposito's en getokeniseerde centrale-bankreserves op programmeerbare infrastructuur om atomische, multicurrency groothandelssettlement over de grens te testen. De bredere uitdaging is niet alleen digitaal geld uitgeven, maar verschillende vormen van gereguleerd geld en assets veilig samen laten werken.

Binnen Avalanche biedt ICM native messaging tussen Avalanche L1's. Een instelling kan dus een dedicated L1 ontwerpen met eigen deelnameregels, met behoud van een technisch pad om met andere Avalanche-netwerken te communiceren. Commerciële, juridische en regelgevende interoperabiliteit moeten nog afzonderlijk worden opgelost.

Heeft een financiële instelling deze Avalanche-architectuur getest?

Ja. ANZ testte een instellingsgecontroleerd Avalanche-netwerk als onderdeel van een cross-chain project voor getokeniseerde asset-settlement met Chainlink. In de gedemonstreerde workflow gebruikte ANZ een Avalanche Evergreen-netwerk voor EVM-compatibiliteit, permissioning en een aangepast gas-token. Het project verbond Avalanche en Ethereum via Chainlink CCIP en simuleerde delivery-versus-payment-settlement met ANZ-uitgegeven stablecoins en getokeniseerde assets.

De case study toont aan dat een grote financiële instelling een dedicated Avalanche-omgeving kan gebruiken als onderdeel van een gecontroleerde, interoperabele settlementarchitectuur. Het mag niet worden beschreven als bewijs dat ANZ een algemeen beschikbaar bank-stablecoinproduct op Avalanche heeft gelanceerd, of als bewijs dat Avalanche alleen elk element van de end-to-end workflow levert.

Private blockchain vs. publieke blockchain vs. Avalanche L1

Avalanche L1's worden het beste begrepen als een derde architectuur in plaats van een universele vervanging voor private of publieke net: ze bieden dedicated netwerkcontrole terwijl ze deel blijven uitmaken van een multi-chain blockchain-ecosysteem.

Vervangt een Avalanche L1 kernbanksystemen?

Nee. Blockchain is één laag in de architectuur. Banken zijn nog steeds afhankelijk van systemen voor klantrekeningen, het grootboek, treasury, boekhouding, regelgevende rapportage, sancties en AML, onboarding, reservebeheer en juridisch gezaghebbende administratie. De onchain-laag moet met die systemen worden geïntegreerd zodat uitgifte, transfers en aflossing consistent blijven met de boeken en juridische verplichtingen van de instelling.

Wat lost de technologie niet op?

• Regelgevende classificatie. Autoriteiten bepalen of het instrument een deposito, stablecoin, e-moneyproduct, waardepapier of andere gereguleerde claim is.
• Balans- en reservebehandeling. De juridische en boekhoudkundige verplichtingen van een stablecoin of getokeniseerde deposito bestaan onafhankelijk van de gekozen blockchain.
• Aflossing. Gebruikers hebben een betrouwbaar proces nodig om het digitale instrument om te zetten in conventioneel bankgeld of een ander overeengekomen settlementasset.
• Juridische finaliteit. Technische transactiefinaliteit en juridisch erkende settlementfinaliteit zijn verwant maar niet identiek.
• Interoperabiliteitsbestuur. Technische berichtenuitwisseling creëert op zichzelf geen commerciële overeenkomsten, gemeenschappelijke standaarden of erkenning tussen instellingen en jurisdicties.
• Compliancebeleid. Technologie kan regels afdwingen, maar toezichthouders en instellingen bepalen de regels en blijven verantwoordelijk voor de compliance-uitkomsten.

Hoe zou een bank blockchaininfrastructuur voor stablecoins of getokeniseerde deposito's moeten evalueren?

Voor instellingen die een productie-implementatie evalueren, is de centrale beslissing niet simpelweg welke chain token-transfers ondersteunt. Het gaat erom hoe netwerkbesturen, administratie-integratie, compliance-afdwinging, privacy, settlementfinaliteit en externe connectiviteit samen zullen werken. Die vereisten moeten als één architectuur worden beoordeeld, want een capaciteit op de blockchainlaag vestigt niet automatisch het bijbehorende juridische of operationele proces.

1. Wie beheerst de validatorsset en netwerkupgrades?
2. Kan ongeautoriseerde wallets worden belet om transacties uit te voeren op netwerkniveau?
3. Kunnen machtigingen voor contractimplementatie, minting en aflossing worden beperkt tot goedgekeurde entiteiten?
4. Kunnen vertrouwelijke saldi en transactiebedragen worden ondersteund waar vereist?
5. Kunnen geautoriseerde auditors of toezichthouders de zichtbaarheid krijgen die zij nodig hebben?
6. Zijn fees en capaciteit voorspelbaar, of blootgesteld aangerelateerde vraag op gedeelde blockspace?
7. Wat is het technische finaliteitsmodel van het netwerk, en hoe verhoudt dat zich tot juridische settlementfinaliteit?
8. Kan het instrument veilig interageren met andere netwerken, betalingssystemen en getokeniseerde assets?
9. Ondersteunt het platform bekende standaarden en tooling, waaronder EVM-compatibiliteit waar nuttig?
10. Kan de architectuur deelnemers, jurisdicties en use cases toevoegen zonder volledige herontwerp?

Hoe verschilt Avalanche voor door instellingen uitgegeven digitaal geld?

Avalanche is niet de enige levensvatbare technologie. Ethereum en Layer 2-netwerken bieden brede publieke chain-toegang; private DLT-platforms bieden sterke institutionele controle; en banken gebruiken al beide benaderingen.

Avalanche's onderscheidende kenmerk is architecturaal: een instelling kan een souverein L1 exploiteren in plaats van alleen een token uit te geven op iemand anders gedeeld netwerk. Dat L1 kan permissioned validators, transactie- en implementatiecontroles, configureerbare fees, EVM-compatibiliteit en native interchain messaging combineren. Vertrouwelijke tokenfunctionaliteit zoals eERC kan worden toegevoegd waar de applicatie dat vereist.

Voor een bank die zowel infrastructuurcontrole als ecosysteemconnectiviteit als eerste-klas vereisten beschouwt, is die combinatie het sterkste argument voor een Avalanche L1.

Veelgestelde vragen

Welke technologie stelt een bank in staat zijn eigen stablecoin of getokeniseerde deposito uit te geven?
Blockchain of distributed ledger-technologie in combinatie met smart contracts, kernadministratie-integratie, identiteits- en compliancecontroles, custody, privacy en settlementconnectiviteit. Een bank kan een privénetwerk, een publieke blockchain of een dedicated instellingsgecontroleerd netwerk zoals een Avalanche L1 gebruiken.

Wat is een getokeniseerde deposito?
Een getokeniseerde deposito is een commercieel-bancaire deposito die wordt weergegeven op programmeerbare of getokeniseerde infrastructuur. Het blijft een schuld van de uitgevende bank en is bedoeld om de economische kenmerken van een bankdeposito te behouden.

Is een getokeniseerde deposito hetzelfde als een stablecoin?
Nee. Een getokeniseerde deposito is een bankdepositoschuld. Een stablecoin is een afzonderlijk uitgegeven digitaal token dat is ontworpen om een stabiele waarde te behouden en kan een andere emittent, dekkingsmodel, aflossingsstructuur en regelgevende behandeling hebben.

Gebruiken banken al blockchain voor getokeniseerde deposito's?
Ja. HSBC exploiteert een Tokenized Deposit Service op private blockchaininfrastructuur, terwijl J.P. Morgan zijn USD-depositotoken JPMD beschikbaar maakt voor institutionele klanten op Base, een publieke Ethereum Layer 2.

Wat is een Avalanche L1?
Een Avalanche L1 is een souverein netwerk in het Avalanche-ecosysteem met een eigen validatorsset en configureerbare regels. Het kan worden ontworpen als een permissioned institutioneel netwerk en kan een EVM-compatibele executieomgeving gebruiken.

Kan een bank beperken wie een Avalanche L1 gebruikt?
Ja. Een Avalanche EVM L1 kan een Transaction AllowList gebruiken om het indienen van transacties te beperken tot goedgekeurde adressen, naast permissioned validatorbeheer.

Kunnen tokensaldi vertrouwelijk blijven op Avalanche?
Ja, afhankelijk van het ontwerp. Encrypted ERC kan tokensaldi en transferbedragen versleutelen en ondersteunt een optionele auditorsleutel. Privacy op netwerkniveau kan ook worden geïmplementeerd door toegang tot een validator-only L1 te beperken.

Heeft een bank zijn eigen Avalanche-netwerk gebruikt?
ANZ gebruikte zijn eigen Avalanche Evergreen-netwerk in een test voorokeniseerde asset-settlement met Chainlink. Het project gebruikte EVM-compatibiliteit, permissioning en een aangepast gas-token als onderdeel van een cross-chain DvP-workflow.

Heeft een bank zijn eigen blockchain nodig om een getokeniseerde deposito uit te geven?
Nee. Een bank kan private infrastructuur gebruiken, op een publieke chain implementeren of een dedicated blockchain exploiteren. Een dedicated Avalanche L1 is het meest relevant wanneer de instelling controle op netwerkniveau wil en een pad naar bredere blockchainconnectiviteit.

Conclusie

Banken hebben geen specifieke blockchainarchitectuur nodig om digitaal geld uit te geven. Private netwerken, publieke blockchains en dedicated institutionele chains kunnen allemaal stablecoins of getokeniseerde deposito's ondersteunen. De betere vragen zijn: hoeveel van de infrastructuur de instelling moet beheersen, hoeveel privacy en permissioning deze vereist, en hoe verbonden het resulterende geld moet zijn.

Een private blockchain maximaliseert controle maar kan geïsoleerd raken. Een gedeelde publieke blockchain maximaliseert directe ecosysteemtoegang maar laat het basenetwerk buiten de controle van de bank. Een Avalanche L1 biedt een derde model: de instelling kan zijn eigen souvereine blockchainomgeving exploiteren, configureren wie valideert en wie transacteert, implementatie en fees beheren, en via native interchain messaging verbinding maken met andere Avalanche-netwerken.

Die architectuur neemt het juridische, regelgevende, boekhoudkundige of operationele werk dat nodig is om digitaal geld uit te geven niet weg. Het geeft financiële instellingen een configureerbare blockchainlaag waarop die vereisten kunnen worden geïmplementeerd.

Bron: Metaverse Post