In brief, a bank can issue a stablecoin or a 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 lies between 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.

A key distinction frames the entire topic: the blockchain itself does not determine whether an instrument is legally a stablecoin or a tokenized deposit. That depends on the issuer, the legal claim, the backing, the redemption model, and the applicable regulation.

Key Takeaways

• Tokenized deposits are commercial-bank deposit liabilities represented on programmable infrastructure, while stablecoins are separately issued tokens designed to maintain a stable value, each with its 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 instruments 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.

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 and 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, a consortium network, a shared public chain, a 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. This also means that interoperability decisions affect governance and operational design, not only technical messaging: participants need defined permissions, settlement processes, and responsibilities across the connected systems.

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. HSBC's Tokenized Deposit Service is one example. 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 own environment requires additional integration.

2. Public blockchain issuance. J.P. Morgan's JPM Coin (JPMD) is an example. 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. Rather than 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. 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 valuable 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 run as follows:

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, which can make costs and capacity more controllable. 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 the proofs needed for valid state transitions. The standard also supports an optional auditor key that can decrypt balances and amounts for authorized oversight.

An 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 the Avalanche C-Chain 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á illustrates the point: 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 tokenized-asset 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-versus-payment settlement involving ANZ-issued stablecoins and tokenized assets.

The case study 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

Avalanche L1s are 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, the 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 that 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 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?

For institutions evaluating a production deployment, the central decision is not simply which chain supports token transfers. It is how network governance, ledger integration, compliance enforcement, privacy, settlement finality, and external connectivity will operate together. Those requirements should be assessed as one architecture because a capability at the blockchain layer does not automatically establish the corresponding legal or operational process.

1. Who controls the validator set and network upgrades?
2. Can unauthorized wallets be prevented from transacting at the network level?
3. Can contract deployment, minting, and redemption permissions be limited to approved entities?
4. Can confidential balances and transaction amounts be supported where required?
5. Can authorized auditors or regulators receive the visibility they need?
6. Are fees and capacity predictable, or exposed to unrelated demand on shared blockspace?
7. What is the network's technical finality model, and how does it map to legal settlement finality?
8. Can the instrument interact safely with other networks, payment systems, and tokenized assets?
9. Does the platform support familiar standards and tooling, including EVM compatibility where useful?
10. 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 treats both infrastructure control and ecosystem connectivity as 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 questions are 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.

Source: Metaverse Post