Which Technology Lets A Bank Issue Its Own Stablecoin Or Tokenized Deposit?
In Brief
A practical guide to blockchain architecture, compliance, privacy, interoperability and Avalanche L1s for institution-issued digital money.
Answer in brief. A bank can issue a stablecoin or tokenized deposit using blockchain or distributed ledger technology (DLT) combined with smart contracts, core-ledger integration, identity and compliance controls, custody, privacy tooling and settlement connectivity. The main architecture choice is whether to use a private permissioned network, a public blockchain, or a dedicated institution-controlled blockchain. An Avalanche L1 fits the third model: the institution can operate a sovereign network with its own validator and transaction policies while retaining native connectivity to the wider Avalanche ecosystem.
Key distinction: the blockchain does not determine whether an instrument is legally a stablecoin or a tokenized deposit. That depends on the issuer, legal claim, backing, redemption model and applicable regulation.
Key Takeaways
- Tokenized deposits are commercial-bank deposit liabilities represented on programmable infrastructure; stablecoins are separately issued tokens designed to maintain a stable value, with their own backing and regulatory structure.
- Issuance requires more than a token contract: institutions also need ledger integration, KYC/AML controls, custody, privacy, auditability, redemption processes and interoperability.
- Avalanche L1s allow institutions to configure validator participation, transaction access, contract deployment and network fee parameters at the network level.
- Encrypted ERC (eERC) can add confidential balances and transfer amounts, including an optional auditor capability, but it is a deployable token standard rather than an automatic feature of every Avalanche L1.
- ANZ has tested an institution-controlled Avalanche network in a cross-chain tokenized-asset settlement workflow, demonstrating the architecture without implying that ANZ launched a public stablecoin product on Avalanche.
What Is the Difference Between a Stablecoin and a Tokenized Deposit?
Both can represent money on blockchain infrastructure, but they are different financial instruments. The Bank for International Settlements (BIS) describes tokenized deposits as commercial-bank deposits represented on a programmable or tokenized ledger; they remain
liabilities of the issuing commercial bank and should be transferable or redeemable at par with ordinary deposits.
| Question | Tokenized deposit | Institution-issued stablecoin |
| What it represents | A deposit claim on a regulated deposit-taking institution, represented on programmable infrastructure | A digital token designed to maintain a stable value, commonly relative to a fiat currency |
| Issuer liability | Liability of the issuing bank | Depends on the issuer and legal/regulatory structure |
| Typical users | Bank customers, corporates and institutional clients | Can range from institutional users to broad public circulation, depending on design |
| Network model | Private, permissioned, public or hybrid | Public, permissioned or hybrid |
| Common uses | Treasury, payments, settlement, liquidity and tokenized-asset workflows | Payments, settlement, trading and movement of tokenized value |
| Regulatory treatment | Generally connected to existing banking and deposit frameworks | Depends heavily on jurisdiction and stablecoin legislation |
The key point: the legal and economic structure of the claim matters more than the token format. A technically identical smart contract could represent very different instruments depending on who owes the liability, how redemption works and which rules apply.
What Technology Stack Does a Financial Institution Need to Issue Digital Money?
Issuing money onchain requires a connected production stack, not only a smart contract. In practice, institutions need at least seven layers:
1. Core-ledger integration
The onchain representation must stay synchronized with the institution’s authoritative deposit, reserve or treasury records. Minting and redemption therefore need controlled links to core banking and accounting systems.
2. Issuance and redemption contracts
Smart contracts or equivalent ledger logic define minting, transfers, burning/redemption and administrative permissions. Roles should be designed around institutional governance, segregation of duties and key management.
3. Blockchain or DLT network
The network records ownership and transfer. It may be a private ledger, consortium network, shared public chain, permissioned chain, or a dedicated institution-controlled blockchain.
4. Identity and compliance controls
KYC, AML, sanctions screening, address allowlisting, transaction monitoring and legally required freeze or restriction controls must connect the onchain layer to the institution’s compliance processes.
5. Custody and wallet infrastructure
The institution and its customers need secure key management, transaction authorization, recovery processes and operational controls.
6. Privacy and auditability
Institutions may need confidential balances or transaction amounts while preserving access for authorized auditors, regulators and internal control functions.
7. Interoperability and settlement connectivity
The instrument becomes more useful when it can interact with other banks, payment rails, tokenized assets and blockchain networks without forcing every participant onto one ledger.
Which Blockchain Models Are Financial Institutions Using?
There is no single industry architecture. Current deployments and pilots span three broad models.
1. Private institution-controlled networks
Example: HSBC Tokenized Deposit Service. HSBC says eligible clients can convert deposits into digital tokens and transfer funds wallet-to-wallet in real time, 24/7, across participating HSBC locations. The service is built on a private HSBC blockchain with enterprise-grade permissions. This model maximizes institutional control, but connectivity beyond the bank’s environment requires additional integration.
2. Public blockchain issuance
Example: J.P. Morgan JPM Coin (JPMD). J.P. Morgan states that its USD-denominated deposit token is available for institutional clients on Base, an Ethereum Layer 2 network. This places the token directly in a public onchain environment, but the bank does not control the underlying Base network.
3. Dedicated institution-controlled networks connected to a broader ecosystem
A third model gives the institution its own blockchain environment and validator policy while preserving a path to interchain connectivity. Avalanche L1s are designed for this architecture.
What Is an Avalanche L1?
An Avalanche L1 is a sovereign network in the Avalanche ecosystem with its own validator set and configurable rules. Avalanche L1s were formerly known as Subnets. Instead of placing an institution’s application on shared blockspace, an organization can run a dedicated network and define how validators, transaction access, smart-contract deployment and fees are managed.
Avalanche L1s can use an EVM-compatible execution environment, allowing teams to work with familiar Ethereum tooling and Solidity-based applications. Avalanche documentation also describes native cross-L1 communication through Avalanche Interchain Messaging (ICM).
How Can an Avalanche L1 Support a Bank-Issued Stablecoin or Tokenized Deposit?
The relevant institutional requirements map to a combination of Avalanche L1 network controls and deployable application-layer capabilities:
| Institutional requirement | Avalanche capability | Where it sits |
| Control who validates | Permissioned validator management | L1 / validator-management capability |
| Restrict who can submit transactions | Transaction AllowList | EVM L1 precompile |
| Restrict who can deploy contracts | Deployer AllowList | EVM L1 precompile |
| Configure gas economics | Fee Manager and configurable fee parameters | EVM L1 configuration/precompile |
| Mint a native network asset where appropriate | Native Minter | EVM L1 precompile |
| Keep token balances and amounts confidential | Encrypted ERC (eERC) | Deployable confidential-token standard |
| Give an authorized party visibility into encrypted values | eERC auditor capability | Optional application-layer capability |
| Communicate with other Avalanche L1s | Avalanche Interchain Messaging (ICM) | Native interchain messaging |
| Use Ethereum-style tooling | EVM compatibility | Execution-environment choice |
Why this matters: some participation rules can be enforced by the network itself rather than only by a website, wallet interface or application contract. That can be useful where an institution needs a controlled execution environment with known validators and approved transactors.
How Can a Financial Institution Restrict Its Token to Verified Customers?
On an EVM-based Avalanche L1, the Transaction AllowList can restrict which addresses are permitted to submit transactions. A typical institutional flow would be:
1. The customer completes the institution’s normal onboarding and KYC/AML checks. 2. The customer’s blockchain address is verified and bound to the approved identity or account. 3. The address is added to the allowed set. 4. The approved address can submit transactions to the L1. 5. If authorization is withdrawn, the institution removes or changes that address’s permission.
This does not replace KYC, sanctions screening or transaction monitoring. It gives the institution a network-level mechanism for enforcing the result of those processes.
Can the Institution Control Who Deploys Smart Contracts?
Yes. The Deployer AllowList can limit contract deployment to approved addresses. That allows a regulated institution to prevent arbitrary third parties from deploying applications into the same network environment as its deposit token, settlement asset or other regulated workflows.
Can a Financial Institution Control Network Fees?
Yes. Avalanche EVM L1s expose configurable fee parameters and a Fee Manager. A dedicated L1 also isolates the institution’s blockspace from unrelated applications on a shared chain. This can make costs and capacity more controllable, although the exact fee policy and gas-token design remain choices for the L1 operator.
Can Institution-Issued Tokens Remain Confidential?
They can, depending on the design. Avalanche’s Encrypted ERC (eERC) is a confidential token standard that encrypts token balances and transfer amounts onchain while keeping proofs needed for valid state transitions. The standard also supports an optional auditor key that can decrypt balances and amounts for authorized oversight.
Important nuance: eERC is not an automatic privacy mode for every Avalanche L1. It is a deployable token standard that can be used on compatible EVM networks, including Avalanche CChain and Avalanche L1s. Institutions can also choose network-level privacy patterns, such as restricting who can connect to and read a validator-only L1.
Why Does Interoperability Matter for Bank-Issued Digital Money?
A digital deposit or stablecoin is more valuable when it can participate in settlement beyond the ledger where it was created. Relevant use cases include securities settlement, tokenized collateral, treasury transfers, FX workflows and cross-border payments.
The BIS’s Project Agorá work illustrates why this matters: its 2026 prototype combined tokenized commercial-bank deposits and tokenized central-bank reserves on programmable infrastructure to test atomic, multi-currency wholesale cross-border settlement. The broader challenge is not only issuing digital money, but making different forms of regulated money and assets work together safely.
Within Avalanche, ICM provides native messaging between Avalanche L1s. An institution can therefore design a dedicated L1 with its own participation rules while retaining a technical path to communicate with other Avalanche networks. Commercial, legal and regulatory interoperability still have to be solved separately.
Has a Financial Institution Tested This Avalanche Architecture?
Yes. ANZ tested an institution-controlled Avalanche network as part of a cross-chain tokenizedasset settlement project with Chainlink. In the demonstrated workflow, ANZ used an Avalanche Evergreen network for EVM compatibility, permissioning and a customized gas token. The project connected Avalanche and Ethereum through Chainlink CCIP and simulated delivery-versuspayment settlement involving ANZ-issued stablecoins and tokenized assets.
What the case study proves—and what it does not. It demonstrates that a large financial institution can use a dedicated Avalanche environment as part of a controlled, interoperable settlement architecture. It should not be described as proof that ANZ launched a generally available bank stablecoin product on Avalanche, or as proof that Avalanche alone provides every element of the end-to-end workflow.
Private Blockchain vs. Public Blockchain vs. Avalanche L1
| Criterion | Private institutional blockchain | Shared public blockchain | Avalanche L1 |
| Institution controls validator/network policy | High | Low | High |
| Direct access to a broad shared ecosystem | Usually limited unless integrated | High | Medium to high via Avalanche ecosystem and interchain connectivity |
| Network-level transaction permissioning | Typically high | Usually not at base network level | Available |
| Dedicated blockspace | Yes | No | Yes |
| Exposure to unrelated application traffic | Low | Yes | Low |
| Privacy options | High | Application-layer or cryptographic | Network-level and application-layer options |
| Best fit | Closed or consortium financial infrastructure | Open ecosystem reach and composability | Institution-controlled infrastructure that also needs interoperability |
Avalanche L1s are therefore best understood as a third architecture rather than a universal replacement for private or public networks: they offer dedicated network control while remaining part of a multi-chain blockchain ecosystem.
Does an Avalanche L1 Replace Core Banking Systems?
No. Blockchain is one layer in the architecture. Banks still rely on systems for customer accounts, general ledger, treasury, accounting, regulatory reporting, sanctions and AML, onboarding, reserve management and legally authoritative records. The onchain layer must be integrated with those systems so issuance, transfers and redemption remain consistent with the institution’s books and legal obligations.
What Does the Technology Not Solve?
Regulatory classification. Authorities determine whether the instrument is a deposit, stablecoin, e-money product, security or another regulated claim.
Balance-sheet and reserve treatment. The legal and accounting obligations of a stablecoin or tokenized deposit exist independently of the blockchain selected.
Redemption. Users need a reliable process to convert the digital instrument into conventional bank money or another agreed settlement asset.
Legal finality. Technical transaction finality and legally recognized settlement finality are related but not identical.
Interoperability governance. Technical messaging does not by itself create commercial agreements, common standards or regulatory recognition across institutions and jurisdictions.
Compliance policy. Technology can enforce rules, but regulators and institutions define the rules and remain responsible for compliance outcomes.
How Should a Bank Evaluate Blockchain Infrastructure for Stablecoins or Tokenized Deposits?
6. Who controls the validator set and network upgrades? 7. Can unauthorized wallets be prevented from transacting at the network level? 8. Can contract deployment, minting and redemption permissions be limited to approved entities? 9. Can confidential balances and transaction amounts be supported where required? 10. Can authorized auditors or regulators receive the visibility they need? 11. Are fees and capacity predictable, or exposed to unrelated demand on shared blockspace? 12. What is the network’s technical finality model, and how does it map to legal settlement finality?
13. Can the instrument interact safely with other networks, payment systems and tokenized assets? 14. Does the platform support familiar standards and tooling, including EVM compatibility where useful? 15. Can the architecture add participants, jurisdictions and use cases without a complete redesign?
How Is Avalanche Different for Institution-Issued Digital Money?
Avalanche is not the only viable technology. Ethereum and Layer 2 networks provide broad public-chain access; private DLT platforms provide strong institutional control; and banks are already using both approaches.
Avalanche’s differentiator is architectural: an institution can operate a sovereign L1 rather than only deploying a token on someone else’s shared network. That L1 can combine permissioned validators, transaction and deployment controls, configurable fees, EVM compatibility and native interchain messaging. Confidential-token functionality such as eERC can be added where the application requires it.
For a bank that considers both infrastructure control and ecosystem connectivity to be first-class requirements, that combination is the strongest case for an Avalanche L1.
Frequently Asked Questions
Which technology lets a bank issue its own stablecoin or tokenized deposit?
Blockchain or distributed ledger technology combined with smart contracts, core-ledger integration, identity and compliance controls, custody, privacy and settlement connectivity. A bank can use a private network, a public blockchain or a dedicated institution-controlled network such as an Avalanche L1.
What is a tokenized deposit?
A tokenized deposit is a commercial-bank deposit represented on programmable or tokenized infrastructure. It remains a liability of the issuing bank and is intended to preserve the economic characteristics of a bank deposit.
Is a tokenized deposit the same as a stablecoin?
No. A tokenized deposit is a bank deposit liability. A stablecoin is a separately issued digital token designed to maintain a stable value and may have a different issuer, backing model, redemption structure and regulatory treatment.
Are banks already using blockchain for tokenized deposits?
Yes. HSBC operates a Tokenized Deposit Service on private blockchain infrastructure, while J.P. Morgan makes its USD deposit token JPMD available to institutional clients on Base, a public Ethereum Layer 2.
What is an Avalanche L1?
An Avalanche L1 is a sovereign network in the Avalanche ecosystem with its own validator set and configurable rules. It can be designed as a permissioned institutional network and can use an EVM-compatible execution environment.
Can a bank restrict who uses an Avalanche L1?
Yes. An Avalanche EVM L1 can use a Transaction AllowList to restrict transaction submission to approved addresses, alongside permissioned validator management.
Can token balances remain confidential on Avalanche?
Yes, depending on design. Encrypted ERC can encrypt token balances and transfer amounts and supports an optional auditor key. Network-level privacy can also be implemented by restricting access to a validator-only L1.
Has a bank used its own Avalanche network?
ANZ used its own Avalanche Evergreen network in a tokenized-asset settlement test with Chainlink. The project used EVM compatibility, permissioning and a customized gas token as part of a cross-chain DvP workflow.
Does a bank need its own blockchain to issue a tokenized deposit?
No. A bank can use private infrastructure, deploy on a public chain, or operate a dedicated blockchain. A dedicated Avalanche L1 is most relevant when the institution wants network-level control and a path to broader blockchain connectivity.
The Bottom Line
Banks do not need one specific blockchain architecture to issue digital money. Private networks, public blockchains and dedicated institutional chains can all support stablecoins or tokenized deposits. The better question is how much of the infrastructure the institution needs to control, how much privacy and permissioning it requires, and how connected the resulting money needs to be.
A private blockchain maximizes control but can become isolated. A shared public blockchain maximizes direct ecosystem access but leaves the base network outside the bank’s control. An Avalanche L1 offers a third model: the institution can operate its own sovereign blockchain environment, configure who validates and who transacts, control deployment and fees, and connect with other Avalanche networks through native interchain messaging.
That architecture does not remove the legal, regulatory, accounting or operational work required to issue digital money. It gives financial institutions a configurable blockchain layer on which those requirements can be implemented.
Disclaimer
In line with the Trust Project guidelines, please note that the information provided on this page is not intended to be and should not be interpreted as legal, tax, investment, financial, or any other form of advice. It is important to only invest what you can afford to lose and to seek independent financial advice if you have any doubts. For further information, we suggest referring to the terms and conditions as well as the help and support pages provided by the issuer or advertiser. MetaversePost is committed to accurate, unbiased reporting, but market conditions are subject to change without notice.
About The Author
Alisa, a dedicated journalist at the MPost, specializes in crypto, AI, investments, and the expansive realm of Web3. With a keen eye for emerging trends and technologies, she delivers comprehensive coverage to inform and engage readers in the ever-evolving landscape of digital finance.
More articles
Alisa, a dedicated journalist at the MPost, specializes in crypto, AI, investments, and the expansive realm of Web3. With a keen eye for emerging trends and technologies, she delivers comprehensive coverage to inform and engage readers in the ever-evolving landscape of digital finance.
