Tokenized deposits make money move like a digital asset. The deposit token becomes a digital representation of the deposit claim. But the deposit itself stays a regulated bank liability, with deposit insurance and prudential treatment unchanged.
The big question now is where that token should live. Banks have spent a decade testing permissioned ledgers, consortium networks, and even public chains. A newer answer could be building a bespoke rollup, meaning a dedicated Layer 2 chain that the bank or a bank consortium controls, running the Ethereum Virtual Machine (EVM) and anchored to an external settlement layer.
This article explains why the EVM standard matters even for banks that avoid public chains, where bespoke rollups could win against the alternatives, how a tokenized deposit rollup works, what the architecture looks like, and much more.
Why Does the EVM Standard Matter Even if a Bank Is Not Using a Public Chain?
The EVM is the execution environment that runs Ethereum smart contracts. A chain is EVM-compatible when contracts written for Ethereum run on it without modification. That definition sounds technical. The commercial consequence is simple. EVM compatibility determines which developers, audit firms, token standards, and integration tools a bank can use safely.
There are enough precedents now that indicate financial institutions are converging towards EVM standards. For example, J.P. Morgan’s tokenized deposit platform runs on a private Enterprise Ethereum stack. Deka Bank’s SWIAT ledger, used for live DLT repo transactions in the ECB trials, runs on Hyperledger Besu, a permissioned EVM chain. These are private systems. They still chose the EVM because it gave them mature contract standards and a deep talent pool.
According to the IMF’s 2026 fintech note on tokenized finance, the major new payment infrastructures, including Circle’s Arc, Stripe’s Tempo, and Coinbase’s Base, are all EVM-compatible, and even Swift’s planned blockchain infrastructure is being designed as EVM-compatible.
Source: IMF Notes 2026/006
So we can safely say the standard is also where the wider market is converging. For a bank, this convergence changes the risk calculation. A tokenized deposit contract written for an EVM environment today can later connect to, or migrate toward, whatever infrastructure the market settles on. It does not create interoperability by itself, but it gives contracts and messages common technical assumptions.
For a contract written for a proprietary environment, it’s hard.
There is a second reason. Regulators and auditors are building familiarity with EVM-based systems faster than with any other smart contract model, because that is where most institutional activity sits today. Hence choosing the EVM also shortens the review conversation.
EVM is therefore a standard for execution, not a decision to expose bank money to an unrestricted public network. The bank can keep the familiar application layer while choosing a more controlled infrastructure underneath it.
Why Choose a Bespoke Rollup Instead of Another Bank Blockchain Model?
A rollup is a chain that executes transactions in its own environment, batches them, and posts the results to a settlement layer such as Ethereum.
The IMF observes that banks have traditionally emphasized privacy, scalability, accountability, and predictable costs when evaluating ledger infrastructure.
“…banks have traditionally favored and explored permissioned ledgers operated by themselves or by a consortium of known entities for their own purposes and clients. They have emphasized privacy, scalability, accountability, and predictable costs.”
IMF Notes 2026/006
Rollups bring all of that to banks. A bespoke chain means the bank or the consortium defines that environment and its rules. Banks buys control by choosing a custom layer2 rollup chain.
Five things come with it.
- Blockspace and cost. The chain carries only the bank’s traffic, so throughput and fees do not move because of unrelated activity elsewhere.
- Throughput. It has to match payment-network volume. This requires higher transactions per second with fast finality.
- Validator selection. The bank decides who runs the nodes and under what contractual and supervisory arrangements.
- Rule placement. Compliance logic can sit at the protocol level, not only inside individual token contracts, so restrictions cannot be routed around.
- Upgrade authority. Protocol changes follow the bank’s change-management process rather than an external governance vote.
Anchoring to a public settlement layer provides external verifiability of the chain’s state, a path to public liquidity when a use case requires it, and a security assumption that does not rest entirely on the bank’s own operations.
Where could it be the best alternatives to existing blockchain solutions?
Banks should choose a bespoke rollup when they’re joining a shared, multi-bank network run by an operator that isn’t already a global systemically important bank or a large pre-formed consortium.
A single global bank running its own deposit token doesn’t need this. Its name is already the security. Take JPMC or Citi for example. A large coalition of major institutions co-governing a shared network doesn’t need it either, since trust comes from shared ownership among already-trusted parties. For example, SWIFT.
What a bespoke rollup solves is the middle case: a neutral operator, or a smaller or regional bank without the scale to build or validate its own chain, that needs a way to get verifiable settlement without either building years of reputation or joining someone else’s consortium on someone else’s terms.
In this setup, transaction data and execution stay inside the operator’s private environment, visible only to the parties involved. But every batch of transactions produces a cryptographic proof, and that proof settles on a public chain that’s already been running securely for years. A bank doesn’t have to trust the operator’s internal controls. It can check the proof itself, or have its own risk and audit teams check it, independent of anything the operator says.
| Model | Privacy | Public verifiability | Throughput | Who controls network admission |
| Permissioned rollup anchored to a public settlement chain (e.g Cari) | Execution and data stay inside the operator’s own environment; nothing broadcasts publicly | A cryptographic proof of correctness posts to the public chain and is checkable by anyone | Runs off the public base layer, so it’s not capped by base-layer limits, though still bounded by the operator’s own execution and proof-generation capacity | Operator alone approves participants; the anchor chain only checks proofs, it doesn’t admit anyone |
| Shared public institutional network (e.g Canton/ Provenance) | Transactions are decomposed so each party sees only its own portion; coordination nodes see metadata, not content | Confirmed by the network’s own validator set; no external chain involved | Scales across the whole network’s shared infrastructure | Public deployments: shared across the network’s foundation and members. Private deployments of the same technology: single operator, closer to row one, minus the external anchor |
| Enterprise permissioned DLT framework(e.g Besu/ Fabric) | Data isolated to named organizations via channels or private collections | Finality rests on the deployment’s own ordering service; no external public proof by default | Can be high inside a closed consortium, since there’s no public settlement step | Full control by whichever consortium deploys it |
| Dedicated appchain (Cosmos L1s/ Avalanche L1s) | Depends on custom modules; not private by default unless purpose-built | Verified by the chain’s own validator set, which it has to bootstrap and secure itself | Set by the chain’s own consensus design | Full control by whoever launches the chain, including who becomes a validator |
How Would a Tokenized Deposit Rollup Work?
Consider a corporate customer at Bank A paying a supplier at Bank B.
- The deposit is prepared for tokenization. Bank A authenticates the customer, runs its controls, and moves or earmarks funds in a designated deposit account. The integration layer instructs the token contract to mint the corresponding amount.
- The customer sends a payment instruction. The instruction comes through the bank’s portal, API, ERP, or treasury system. The wallet is linked to a verified customer record; the user does not need a public, self-custodied crypto wallet.
- Policy is checked before execution. Identity, sanctions, limits, available balance, and recipient eligibility are validated. The ordering service accepts approved transactions and places them in a deterministic sequence.
- The EVM contracts execute the token transfer. The deposit-token contract updates balances. Additional contracts can support escrow, conditional release, or delivery versus payment.
- The batch is proven and anchored. The rollup generates a proof or state commitment. A privacy-preserving design can publish verification material without publishing customer names, balances, or transaction details.
- Bank records and interbank obligations are completed. The integration bridge updates core systems, performs continuous reconciliation, and calculates the fiat obligation between Bank A and Bank B. That obligation is settled through the agreed settlement bank, RTGS connection, wholesale CBDC, or another legally recognized mechanism.
There are therefore two finality questions. The token transfer may be final on the rollup within seconds. The underlying interbank obligation becomes final only at the point defined by the scheme’s legal and settlement rules.
Architecture of a Rollup-Based Tokenized Deposit Network
A bank rollup shares roughly half its stack with any other rollup. The other half does not exist in consumer designs. A production bank rollup is best understood as a stack of five layers.
Application layer. The deposit token contracts themselves, with controlled mint and burn functions, transfer restrictions, pause and freeze capabilities for compliance events, hooks for programmable payment logic, and the APIs through which clients and partner institutions actually use the network.
Rollup operator layer. The execution environment itself, plus the sequencer that orders transactions, the prover that generates validity proofs, and the data availability arrangement that determines where transaction data is stored.
The integration and orchestration layer. It translates on-chain events into message formats the bank’s systems already process, such as ISO 20022, so that deposit ledger balances update in step with token movements. It routes events between the chain, core banking, and custody infrastructure. It runs continuous reconciliation between on-chain balances and deposit records. Banks must be able to coordinate real-time on-chain updates with the settlement finality of existing systems and with conventional payment messaging standards, or clients lose reach into today’s payment networks.
Settlement layer. A public chain, usually Ethereum, that receives proofs or batched data and provides external verifiability of the rollup’s state.
The access and reporting layer provides segregated views by role. The operator sees network-wide flows, each bank sees its own customers’ activity and its settlement obligations, and supervisors receive a read-only audit view. This layer has no equivalent in a public rollup.
For transfers within the same bank, the fiat rail only requires internal ledger adjustments. For transfers between banks, the token can settle immediately on the digital rail while an interbank fiat obligation is created. These obligations are accumulated and settled periodically—usually on a net basis.
Which Banks Are Already Building Deposit Rollups?
The clearest current example is the Cari Network, a consortium formed by five US regional banks including KeyBank, Huntington, First Horizon, M&T Bank, and Old National.
It runs a permissioned Layer 2 ZK rollup anchored to Ethereum. Its architecture matches the pattern described above. Deposit tokens are issued under ERC-20. Every token is backed one-to-one by a balance in a designated deposit account at a participating bank.
Source: Cari Network
Wallets are whitelisted and bound to KYC-verified customers. Transaction execution and data storage stay inside the network, with only validity proofs posted to Ethereum. Supervisors receive a dedicated read-only view. Net fiat obligations settle through a hub-and-spoke model administered by a settlement bank.
Deposits represented by Cari tokens remain regulated liabilities on the banks’ balance sheets and stay covered by FDIC insurance. The network is backed by the Mid-Size Bank Coalition of America and has joined the American Bankers Association’s Premier Partner Network. The API layer covers issuance, transfer between verified parties, and redemption back into dollars. As of July 2026, the network had expanded past 30 participating banks, with around 40 more in active discussions, representing combined assets above $10 trillion. Production launch is targeted for later in 2026.
Another Bank Projects as Useful Evidence
Deutsche Bank’s Project DAMA 2 uses a comparable architecture for a different purpose. Its architecture uses a privacy-enabled institutional ZK rollup on Ethereum with a permissioned sequencer for tokenized funds, stablecoins and other assets. It validates the same institutional logic: standard public infrastructure at the base, controlled execution above it, and a bank-friendly application layer.
Zeeve for Unbiased Consultation and Privacy-Enabled Rollup Infrastructure
Zeeve provides institutional-grade blockchain infrastructure for launching and operating bespoke rollups, including privacy-enabled tokenized deposit infrastructure designed for regulated environments. Zeeve Tegaris, the modular privacy layer, provides system-wide privacy, including the transaction layer and entire workflow.
The platform is ISO 27001 and SOC 2 Type II compliant, and supports Bring Your Own Cloud deployment so institutions can run rollup infrastructure within their own security and data-residency perimeter. For banks already running earlier-generation DLT platforms, Zeeve also supports migration from legacy blockchain infrastructure.
Zeeve has helped a big US bank with their tokenization initiative. Talk to Zeeve’s team for an unbiased architecture review of your tokenized deposit program.
