Conceptualizing the Future of Financial Infrastructure with ZKsync
Alex Gluchowski is the co-inventor of ZKsync and co-founder and CEO of Matter Labs. ZKsync is an advanced Ethereum Layer 2 blockchain network offering privacy and scalability using ZK proofs.
In this conversation, Alex and Will Beeson discuss the benefits of ZK technology for financial use cases, architectural considerations in building blockchain networks for complex industries like finance, optimal infrastructure for tokenized financial assets and workflows, ZKsync’s trustless network and shared liquidity vision and more.
Transcript
Will:
Alex Gluchowski, welcome to Rebank. It’s wonderful to connect with you. I’m a huge fan of everything you're working on at Matter Labs. To kick things off, how do you describe what you're building at Matter Labs? What’s the high-level view, in your own words?
Alex:
Absolutely. At Matter Labs, we’re the creators of ZKsync, which is a scaling solution for Ethereum and other public blockchains. It uses zero-knowledge proofs to provide scalability while ensuring the integrity of computations and transactions.
ZKsync began as a research project. It was one of the earliest ZK rollups built on Ethereum. As zero-knowledge cryptography advanced and the software reached production quality, we were able to build the first ZK rollup that supported Ethereum’s Solidity smart contracts without requiring any modifications. That was a major milestone. For the first time, developers could deploy to a ZK rollup using standard Ethereum tooling.
Since then, the protocol has evolved further. What I would describe as the third generation of ZKsync is known as the Elastic Chain. It has shifted from a single rollup into a network of interconnected blockchains, all secured by zero-knowledge proofs.
This new architecture is something I’m incredibly excited about. It brings us closer to the long-term vision of blockchain technology that we’ve been working toward since the days of Bitcoin and Ethereum. The mission is to move the entire world of value onto Web3—anything that touches value should be on-chain. We want to build an internet of value, where users, institutions, and applications are all connected much like how the internet connects people today.
In this system, anyone can transact, exchange value, and run applications without relying on centralized intermediaries or trusted third parties. The ultimate goal is a peer-to-peer network that anyone can verify, even on a mobile phone. Imagine a world where a billion or even 10 billion people can verify and interact with this system directly from their personal devices.
That’s the direction ZKsync is moving in.
Will:
Amazing. Alright, there are a few really interesting directions we can dig into.
One topic, which I’m sure feels like household subject matter to you at this point—and probably a question you’ve answered a hundred times—is zero-knowledge technology. Specifically, how it differs from many of the other public and private blockchain solutions that are out there.
I’d love to understand how you think about its unique relevance in the context of finance. What makes it so powerful?
And then separately, I’d love to get into the architecture you just described, the Elastic Network, and how that maps to your broader vision of where these networks are ultimately heading.
But maybe let’s start with the basics. Would you mind defining zero-knowledge and explaining why it’s central to the work you're doing?
Alex:
Sure. Zero-knowledge proofs, or ZK proofs, are a family of cryptographic protocols that can attest to the integrity of a computation. In short, they allow us to mathematically prove that a given computation was executed correctly, without revealing all of the underlying data.
They’re often associated with privacy, and rightly so, but privacy is just one application. You can use ZK proofs purely for scalability, without any privacy component at all. That’s why I prefer the broader term “ZK proofs,” since it covers both dimensions.
Now, why are ZK proofs so valuable in the context of blockchains?
The core strength of blockchains is computational integrity. These are networks designed to ensure that every participant in the system plays by the same rules. It’s a shift from relying on trusted institutions that promise not to act maliciously, to systems that simply cannot act maliciously because the rules are hard-coded and universally enforced.
This is a profound idea. Trust is a multi-trillion-dollar global industry. In the U.S., for example, about 15 percent of the workforce is engaged in some form of trust-building: legal, compliance, sales, relationship management, and so on. When you can replace trust with verifiable computation, you eliminate friction, reduce costs, and minimize the risk of human error or manipulation.
Let’s look at how traditional blockchains achieve this today.
Bitcoin and Ethereum, the first-generation blockchains, follow the principle of “don’t trust, verify.” Satoshi’s white paper assumes that everyone runs a full node and re-verifies every transaction. Ethereum extended this by introducing smart contracts and much richer programmability, but kept the same model. Everyone is still expected to run a full node and re-execute every computation themselves.
That’s a powerful model, but it comes with hard scalability limits. You’re asking consumer-grade hardware, even something like a Raspberry Pi, to process and store all the world’s financial activity. It’s not feasible. There isn’t enough memory, bandwidth, or compute power to support that.
So the industry began exploring scaling solutions. Most of them make compromises, either on decentralization, security, or trust assumptions. If you can’t re-execute every transaction, you either stop verifying altogether, or rely on someone else to verify on your behalf. At that point, you’re reintroducing trusted intermediaries and essentially recreating the traditional financial system.
That was the state of things until ZK proofs became production-ready.
Now, with zero-knowledge proofs, we can scale without compromising trust. Here's how it works.
All transactions in a block are executed off-chain. A proof of that execution is then generated using ZK technology. That proof is a compact, cryptographic artifact that anyone can verify in under a second, even on a mobile phone. It proves not just that the computation happened, but that it happened correctly. It's mathematically impossible to forge.
And it's all open source, from the math to the code that generates the proofs to the audits. Anyone can verify it.
But it gets even more powerful.
We can take multiple proofs from different chains and generate a single proof that verifies all of them together. This process is recursive. You keep combining proofs until you end up with one final proof that validates all computations across all chains. That final proof can be submitted to a settlement layer like Ethereum.
In the end, you’ve built a structure where every user, every application, and every chain behaves honestly, not because they trust each other, but because they cannot cheat.
That’s the breakthrough.
Machines can trust each other too. Once you have that, you can start building advanced systems with native interoperability, embedded privacy, and capabilities that just weren’t possible in a world where everyone needed to re-execute every transaction and see every data point.
Will:
Got it, that makes a lot of sense. There are a few points I’d love to dig into from what you just described.
First, it’s probably worth starting with a quick comparison. Could you walk us through, at a high level, the benefits of the ZK approach versus something like an optimistic rollup, which is still more common in the market today? I’m thinking of solutions like Arbitrum, Optimism, and others.
Alex:
I’d say the only reason optimistic rollups are more prevalent right now is because they were earlier to market. And honestly, the reason they were earlier is that they took some shortcuts. Most of them only enabled fraud proofs relatively recently, so for years they effectively operated more like proof-of-authority systems.
That said, they had first-mover advantage and built an early user base. But the users of optimistic rollups haven’t had access to the full functionality or cost benefits that ZK rollups offer. That’s starting to change.
The key difference is that ZK rollups provide much stronger security guarantees. They inherit the full security of Ethereum, while optimistic rollups introduce additional trust assumptions.
If we’re building what some people call the internet of value, it’s helpful to think of it like the internet we know today. The internet doesn’t run on a single server. Likewise, the internet of value won’t run on a single blockchain.
That’s become a widely accepted idea. There will be many chains for a variety of reasons. Some of that is technical, because no single chain can handle all the world’s transactions. But it’s also political and economic. People want control, customization, and alignment with specific business needs. No one-size-fits-all solution will work.
Given that, interoperability becomes the most important problem to solve.
With optimistic rollups and other systems that rely on crypto-economic incentives, it’s very difficult to create trustless interoperability. You end up relying on external bridge operators or validators. Or you’re forced to impose strict coordination rules that reduce each chain’s sovereignty.
ZK rollups don’t have that limitation. You can connect ZK chains using native protocols that are fully trustless. There’s no reliance on honest behavior from individuals or validators. Even if operators are compromised, the system remains secure. And every chain retains full autonomy. Each one can be fully sovereign, fully customizable, and still interoperable with others.
Here’s how I think about it.
Imagine you're building office space for multiple companies. Optimistic rollups give you a big open floor plan. Everyone works at desks in the same room. There’s no privacy, and everyone has to coordinate when to turn off the lights, how loud to talk, what temperature to set.
ZK rollups let you build private offices. You can close the door, control the lighting and environment, and manage everything independently. But you still have hallways and shared infrastructure. You can visit any other office instantly and securely. That’s the big difference, in architecture, in security, and in user experience.
Will:
Got it. So, on the subject of privacy.
We hear that word often in relation to ZK systems, and it seems to be one of their leading value propositions. Could you talk about what you actually mean by privacy in this context? Even at a basic level, how does it work in a ZK environment, and what kinds of privacy are possible that wouldn’t be feasible in other systems?
Alex:
Sure. Blockchains have struggled with privacy since the beginning, and the reasons tie back to what we discussed earlier. If every transaction must be re-verified by every participant, then every transaction has to be fully visible. All of that data has to remain public.
But if you hide any part of the data, how do you know the hidden part is being processed correctly? How do you ensure that there’s no manipulation happening? Without visibility, you either have to trust someone else, in which case it’s no longer a trustless blockchain system—it becomes a custodial platform, like a bank or some other centralized institution. Or, you need a way to verify computations without seeing all the inputs.
There are really only two technologies that can do this.
One is ZK proofs. The other is TEEs, or trusted execution environments. But TEEs are hard to use as a primary layer of protection. It’s difficult to guarantee that there are no flaws or bugs in them, and historically, there have been many vulnerabilities in trusted execution environments. You also have to fully trust the hardware vendors—companies like Intel or AMD—to secure everything properly, and many people suspect there are backdoors.
Because of that, TEEs might be useful as a second layer of protection, but they can’t serve as the foundation for secure systems at scale.
That’s where ZK proofs come in. Zero-knowledge proofs uniquely enable this type of system. They allow you to mathematically guarantee that a computation was executed correctly, according to the rules, without having to expose the full data involved.
You can selectively disclose only what’s necessary. For example, you could show proof of reserves without revealing individual balances. You could reveal the state of one user’s account to that user, without making it public to everyone. You can tailor the level of transparency based on what's appropriate for the use case.
There are generally two models for how privacy can be implemented with ZK systems.
The first is privacy at the account level. This is the model used by blockchains like Zcash, or privacy tools like Tornado Cash. These systems are focused on one very specific use case: enabling private transfers. And they work.
Will:
Just to be clear, in that model, the rest of the blockchain participants wouldn’t be able to see who was involved in a transaction or what was exchanged. Is that right?
Alex:
Even the basic act of transferring value privately between accounts has been difficult for blockchains to handle. That’s largely due to the same issue we discussed earlier. If every transaction needs to be re-verified, then it needs to be fully visible. If you hide any part of the data, it becomes hard to ensure the system is still executing correctly and hasn’t been tampered with.
Without visibility, you either have to trust a third party, in which case it's no longer a trustless blockchain, or you need some form of cryptographic assurance that the computation was performed correctly. And today, there are really only two technologies that can offer that assurance.
One is trusted execution environments, or TEEs. The other is zero-knowledge proofs.
TEEs are difficult to use as a foundational security layer. They’re vulnerable to bugs, and historically, there have been many successful attacks against them. You also have to trust the hardware vendors, like Intel or AMD, to build these systems securely. There’s widespread concern about potential backdoors, so most people don’t see TEEs as viable for high-stakes environments. They can be used as a secondary safeguard, but not as a primary layer of trust.
ZK proofs, on the other hand, give you mathematical guarantees. They let you prove that a computation was executed properly, without revealing the underlying data. You can choose what to disclose. For example, you might reveal proof of reserves or show individual users their account balances, without making that information public to the entire network.
There are two main ways to implement privacy using ZK systems.
The first is at the account level. This is what we see in projects like Zcash, or tools like Tornado Cash. These systems focus on private transfers. They do that job well. In this model, only the participants involved in a transaction can see the details. Everyone else sees nothing.
The challenge is expanding that privacy to support smart contracts.
Traditional smart contracts, like the ones on Ethereum written in Solidity, operate on a public shared state and are fully transparent. That model doesn’t translate easily into ZK-based privacy systems. There are some early-stage projects working on privacy-preserving smart contracts, but they require writing code in new languages and frameworks. The development process is conceptually difficult and quite different from how things work in Ethereum. You can't reuse the same security best practices or existing tooling. These are emerging systems, and they’re still a few years away from being ready.
That brings us to the second model, which is privacy at the chain level.
Think of a bank launching its own private chain. It might run as a Layer 2 on Ethereum, connected to Ethereum and to other private chains. Within that private chain, the bank has full visibility and control. But from the outside, no one can see the internal activity.
The system still uses Ethereum and ZK proofs to verify integrity. So every transaction and every state transition inside that private chain is provably correct. Developers and users can still use all the familiar Ethereum tooling—wallets, explorers, contracts—but the bank controls what data is visible and to whom.
You, as a user, might be able to see your balances and interact with public parts of the chain. But you can’t see the balances of other users. And no outside observer can see into the system at all.
We call this model a “private validium.” And right now, this is a massive area of demand from financial institutions.
The reason blockchain hasn’t been broadly adopted in institutional finance is that these organizations need privacy, compliance, and control. They need to meet strict regulatory requirements. That’s not possible on fully public blockchains.
Historically, their answer was to build consortium chains—shared ledgers run by multiple institutions, each operating their own validator. But that created other problems. Governance was hard. Agreement was hard. And most importantly, there was still no privacy within the consortium. Every participant could see everything that happened on the chain.
Private validiums solve that.
We’re seeing a huge wave of interest from major financial institutions. At Matter Labs, we’ve been working with UBS, Deutsche Bank, and a number of American banks. In each case, the institution operates its own private chain. They manage access, compliance, and visibility. They stay fully in control.
At the same time, these chains can still host public assets like Ether or USDC, and they can interoperate with other private chains. Two banks, for example, could conduct a transaction that’s only visible to them, without exposing it to the broader network.
This kind of infrastructure is extremely compelling, and it’s where we at Matter Labs are focused right now. We believe it will be the foundation for institutional adoption of blockchain technology, and we’re already seeing that momentum build.
Will:
Got it. Quick terminology check. Validium,tell me about that. That’s the customizable, dedicated implementation of a ZK chain, right?
Alex:
That’s correct. Broadly speaking, we refer to all of these systems as ZK chains. A ZK chain is any blockchain that is secured by zero-knowledge proofs.
The distinction between a validium and a rollup comes down to how data availability is handled. In a rollup, all transaction data is posted to Ethereum or another public Layer 1. That ensures full data availability on-chain. In a validium, the data is either kept off-chain, managed internally, or stored with a third-party provider.
So if you're using a public Layer 1 like Ethereum for data availability, it's considered a rollup. If you're managing data availability separately—whether through your own systems or a third party—then it's a validium.
Rollups are generally better suited to crypto-native use cases, because they inherit one hundred percent of their security from the underlying Layer 1. Everything is verifiable by anyone.
Validiums, on the other hand, introduce some trust assumptions around data availability. Whoever holds the data must be trusted not to withhold or manipulate it. But critically, the Layer 1 still verifies the correctness of all transactions using ZK proofs. So even if the operator is malicious or compromised, they can never execute an invalid transaction.
That guarantee is a massive upgrade compared to traditional private chains. It preserves integrity, even when full transparency isn't possible.
Will:
Okay. Let’s shift gears slightly and talk about the broader architecture that you envision.
You made some comments earlier about how the original vision of a blockchain-based internet, or a blockchain-native world, could be realized through a ZK-based environment. I’d love to dig into that a bit further. And then maybe we can explore some of the specific use cases you’re working on with partners.
To start, could you walk us through the overall architecture?
If I understand correctly, ZKsync Era was your first publicly available mainnet. And now it sounds like that has evolved into what you’ve referred to as the Elastic Network, which includes a series of customizable, dedicated chains that can interoperate.
Can you talk a bit about that broader vision?
Alex:
ZKsync Era is the first chain in what we call the Elastic Network. Since its launch, it’s been followed by a growing number of other chains, each focused on a different use case or niche. What we’re seeing is a diverse and expanding ecosystem, with dedicated chains serving everything from consumer apps to financial institutions.
For example, on the consumer side, we have Abstract and Cell Phone. Lance is launching a social network chain soon. In gaming, we have chains like Treasure DAO, ECK, and Ola. Ola, by the way, is one of the largest gaming payment providers in the world, and they’re launching a chain to support billions of active users.
Then there are financial chains like Gravity.
We also see a new category of chains emerging around exchanges, similar to the model Coinbase followed with Base. For instance, we have zkKronos, developed in collaboration with Crypto.com. WonderFi, the largest Canadian exchange, is launching a chain. Repo, the biggest exchange in Latin America, has one too. There’s also Union Chain, which is working with major Southeast Asian exchanges in the Philippines, Indonesia, and Thailand—reaching close to 200 million KYC’d users.
There are others as well. It’s a very broad and heterogeneous network. Each of these chains has some level of customization—whether in how they handle tokenomics, MEV, or other architectural details. These are things that couldn't easily be implemented on Era alone. That’s why the Elastic Network exists.
What brings it all together is interoperability, which is coming later this year. It will allow users to move between applications on any of the connected chains. Assets will be able to move seamlessly, with no need for external capital, liquidity providers, or cross-chain bridges. The transfers will be native, instant, and secured by zero-knowledge proofs and Ethereum itself.
In this constellation, ZKsync Era still plays a central role. It acts as the liquidity hub of the ecosystem. In fact, it's currently one of the most liquid chains in the entire Ethereum Layer 2 space. It’s also a major center for real-world assets. Over $2 billion worth of tokenized real-world assets now live on Era, second only to Ethereum’s $5 billion. All other chains are well below that.
So Era serves as a launchpad for applications, a home for DeFi liquidity, and the connective tissue for the broader Elastic Network.
Will:
I see. Tell me more about the interoperability between the various chains you mentioned.
I think I read in some of your materials that these different chains can still benefit from aggregated liquidity. I’d love to understand what that actually means.
And you also talked about the ability to seamlessly transact between different chains. Is that handled through a bridge? If so, how is that designed?
Alex:
The connection between chains is built into the architecture from the start. At the center of the Elastic Network is the concept of a shared bridge.
Zero-knowledge proofs ensure that participating chains cannot behave maliciously. Because of that, they can trust one another enough to share a bridge for both message passing and asset transfer.
This shared bridge allows chains to do more than just transfer assets. You can send arbitrary messages and even make method calls from one chain to another. The receiving chain will recognize the origin contract, verify its code, and trust its behavior because it relies on the same zero-knowledge proof system that secures its own environment.
Every asset in the Elastic Network—whether it’s natively minted on a chain or bridged from Ethereum into the shared bridge—can move freely across the entire network. This feature isn’t live yet, but the implementation is complete and will be deployed in the next few months.
Once it’s live, you’ll be able to make a method call on another chain, attach value to it in the form of any token, and know it will be executed correctly. That’s why having interoperability as a native protocol is so important.
Using external bridges introduces significant limitations. There are typically two types of bridges.
The first is the mint-and-burn model, which works only for assets designed for that bridge—USDC, USDT, or OFT tokens from LayerZero, for example. But it doesn’t work for native Ether, because no one other than Ethereum itself has the authority to mint or burn ETH.
To support asset movement in those cases, you need liquidity providers who maintain token reserves on every participating chain. So if a user wants to move ETH from Chain A to Chain B, a liquidity provider must have a sufficient ETH balance on Chain B to send to the user. Then the provider has to rebalance across chains later, or hope someone moves ETH in the opposite direction to restore equilibrium.
This model is extremely hard to manage at scale. It only works for a handful of high-liquidity tokens. It doesn't work for the long tail of assets. It doesn’t work for NFTs at all.
Maintaining liquidity pools comes with a capital cost. That capital is idle, and those costs are ultimately passed on to users in the form of fees—usually several basis points per transaction. And because liquidity is limited, especially on smaller or app-specific chains, the experience quickly breaks down.
There’s simply no scalable way to move liquidity freely through a network unless the interoperability is native to the protocol. And that only works if you can trust the integrity of each chain involved.
With zero-knowledge proofs, we can ensure that integrity while still preserving the autonomy of each chain. Optimistic rollups don’t have that option. To achieve similar interoperability, they have to ask chains to give up part of their sovereignty. That means limiting participation to a smaller number of chains within a tightly controlled cluster.
ZK systems don’t have that limitation. We can support dozens, hundreds, even thousands of chains, all interoperating through the shared protocol, without overloading the underlying infrastructure or introducing new trust assumptions.
Once this native interoperability is fully live, the next step is improving the user experience. Ideally, users shouldn’t even think about bridging.
You should be able to connect to an application, even if it’s on a different chain than where your assets are. The system will detect that, and with a single confirmation, it will bridge the necessary assets in the background, execute the transaction, and return the results—all automatically.
The end goal is a one-click experience that feels like Web2. From the user's perspective, it’s like clicking a hyperlink. Everything happens behind the scenes, and the complexity is abstracted away.
Will:
I see. So when you talk about shared liquidity, I imagine that’s what you’re referring to—the fact that you don’t have fragmentation like you do with the second approach to bridging. All balances, in a sense, remain available to transfer and interact with across chains in the network. Is that right?
Alex:
Correct. Yes. We can speak about shared liquidity and shared users across the entire Elastic Network.
Will:
Okay, just a quick clarifying question for me.
If I think about how most multi-chain or cross-chain tokens work today, there’s usually an implementation on multiple chains. The token contracts have to be deployed separately on each chain.
But it sounds like what you’re describing is different. You're saying there can be a native instance of a token on one Elastic Network chain, and that token can still be transacted with on a different chain and bridged back—without needing a new, canonical contract deployment on every other chain?
Is that right?
Alex:
Exactly. Technically, there are some nuances. There are still deployments on different chains, but you can have a standard contract that handles the bridging, regardless of where the token originates.
This is something managed at the protocol level. It’s essentially pre-installed. We already have this setup for tokens that are bridged through the native bridge, and it’s going to be extended to support all other tokens as well.
Will:
Okay, great. Let’s focus on some tangible use cases.
You mentioned earlier the range of partners in the Elastic Network who are running their own chains, but I also recall you referencing projects with Deutsche Bank and UBS. That might be interesting to unpack, especially in the context of finance and financial innovation.
Could you walk me through some of the finance-related use cases you're working on? And specifically, how the ZK approach or your zero-knowledge offering is uniquely relevant in those settings?
Alex:
This ties back to what I mentioned earlier about financial institutions.
With both Deutsche Bank and UBS, what we’re seeing is interest in building private chains that can extend their services to a much broader range of customers. These chains allow them to do things that wouldn’t be possible in the traditional financial system.
Take UBS as an example. They offer tokenized gold—a product they already provide internally to their clients. It allows for fractional ownership of physical gold with the option for physical delivery. The challenge is, if they wanted to offer that same product to customers of other banks, they’d need to onboard those customers directly. That would trigger a whole set of additional compliance requirements and introduce operational overhead.
Settlement would also be an issue. In traditional systems, settlement often takes days. You can’t instantly confirm ownership because you have to wait for the payment to clear. That process creates friction and delays.
With a private chain, they can tokenize the gold and pair it with stablecoin-based payments. Transactions can be settled instantly, at lower cost, with higher throughput. It also simplifies onboarding, because you don’t need to bring every user fully into your banking system just to allow them to transact.
We’re seeing similar models with other banks and institutions. There are usually a few core components.
First, they’re tokenizing some of their own assets or services. Second, they’re using these chains to custody client funds in a way that ensures compliance, privacy, and security. And third, they’re building infrastructure that lets them interoperate with other financial institutions in a secure and compliant way—something that’s extremely difficult to do across traditional systems.
Will:
Interesting. So when you talk about banks being able to spin up their own customizable chains—essentially private chains that are still connected to the broader network—it sounds like they would have full visibility into the activity within their chain, while other participants might have no access or only limited visibility into certain data points.
If you replicate that model across many different banks, it almost starts to resemble a blockchain-based version of core banking, doesn’t it? The entire transaction and balance ledger of a bank, reimagined on-chain.
Can you talk about how those systems then interact? For example, if two banks or financial institutions want to transact with each other, how does that work?
Does that happen in a public environment, or is there privacy-preserving connectivity between their private chains?
Alex:
There are multiple ways to structure it, but let me walk you through one example.
Imagine two banks, each operating its own private chain. They want to transfer or swap assets between each other. This could be initiated by customers moving funds from one institution to another, or it could be interbank settlement. Right now, those kinds of operations rely on legacy infrastructure—sometimes using correspondent banking systems, which are expensive, slow, and complex.
Using private chains connected to the Elastic Network, they can do it directly.
The assets involved could be extrinsic stablecoins like USDC or USDT, or they could be stablecoins issued by the banks themselves. If two banks have a strong relationship, they can mutually accept each other’s stablecoins because the counterparty risk is already well understood.
Here’s how a direct swap would work.
Bank A initiates a transaction on its own chain. This transaction contains a message to be delivered to a smart contract on Bank B’s chain. The contract and its terms—how much of Asset A is exchanged for Asset B, price slippage conditions, and so on—would have been reviewed and agreed on ahead of time.
The message is sent off-chain, then relayed and executed on Bank B’s chain. After execution, the result is returned to Bank A. Each step is verifiable, and Ethereum serves as the enforcement layer. If Bank B tries to ignore a message, Bank A can force it through Ethereum using its resistance guarantees. So even though there are three distinct steps—initiation on Chain A, execution on Chain B, and resolution back on Chain A—the whole operation is atomic. It either completes under the defined conditions or it fails and fully reverses.
The sequence looks like this:
- Chain A: Burn or lock the outgoing asset and generate a message to Chain B.
- Chain B: Mint the asset, perform the swap, and burn the swapped asset for return.
- Chain A: Redeem the incoming asset from Chain B.
Even though the process spans two chains and three transactions, the system guarantees that it either completes exactly as defined or fails completely. There’s no partial execution.
Now, another approach could be to create a third chain—a neutral intermediary—but I think the direct interoperability model is much more powerful. Historically, this wasn’t possible without trust. You had to rely on the validators or operators of the other chain to behave correctly. Even if you trusted them as individuals, institutions need formal guarantees.
In this setup, both chains are deployed within the Elastic Network. They use the same ZK proof system, the same integrity guarantees, and the same resistance enforcement via Ethereum. That creates mutual trust. Each chain can rely on the other’s behavior with the same level of confidence it has in its own system. They know the operators can’t behave maliciously, and that creates a whole new model for institutional interoperability.
Will:
As a final thought, I want to come back to something I referenced earlier about traditional core banking systems.
Looking across the market right now, we’re seeing more banks exploring tokenized deposits. Stablecoins are increasingly being used for payments and settlement, and we’re starting to see them show up in real economy use cases like cross-border payments and B2B transfers.
It seems like there’s a real opportunity to integrate some of these private chains—like the ones you’re helping banks deploy—directly into core banking systems. That kind of integration could allow for seamless transacting across both traditional fiat rails and on-chain flows, all within the same financial infrastructure.
As finance continues to upgrade its backend systems, this kind of hybrid model could be really powerful.
Do you have any thoughts or insights, based on the work you’ve done, around how these ZK-based chains could integrate directly with existing core banking infrastructure?
Alex:
What we’re seeing from our partners today is a heavy focus on internal tokenization.
For example, some banks have multiple subsidiaries within a country and need to manage liquidity between them. What they’re doing is tokenizing their own reserves, then using smart contracts to control access and rebalance liquidity across their internal banking infrastructure.
That was more or less the upper limit of what was possible until very recently. Regulatory constraints—especially in the U.S.—were very strict around what banks could and couldn’t do in crypto.
But that’s changing.
Just two or three weeks ago, there was guidance from U.S. regulators, including the White House, signaling that banks can start using crypto for custody of native digital assets. There’s also movement toward stablecoin legislation and interbank rules that would make it possible to do this safely and in a fully regulated way.
It’s expected that this legislation will be passed sometime this year, maybe even by summer. Everyone in the banking and financial industry sees that shift coming, and they’re preparing to do more than just internal liquidity systems.
The natural next step is to tokenize bank-owned assets, provide custody of crypto-native assets, and then use that within the architecture we’ve been discussing. That means private chains for compliance and control, but also interoperability with other institutions and access to public infrastructure.
Banks could interact directly with DeFi protocols or digital assets issued on public blockchains, while still maintaining internal protocols to enforce rules and compliance on-chain.
There’s a broad range of use cases that open up with this model, and the architecture we’ve outlined is what makes it possible.
Will:
Excellent. Alex, thank you so much for your time. This was an incredibly insightful conversation. I’m really excited about what you and the team are building, and the impact you’re already starting to have.
Alex:
Thank you, Will. I really enjoyed the conversation and was happy to share this.
Will:
Alex Gluchowski, thank you very much for joining us today.