Zenith: connecting the Ethereum ecosystem with Canton
EthCC[9] · 30 Mar 2026 · 18:29
Norbert Vadas presents Zenith, an EVM execution environment designed for Canton. The presentation discusses deploying unmodified Ethereum applications and making them atomically composable with Canton’s institutional ecosystem.
Speakers
Topics
From EthCC[9], hosted by Ethereum France.
Transcript
Hi everyone. This is Norbert from Zenith and I'm going to be presenting today about how we connect Ethereum's ecosystem with Canton. So, let's dive in. Before we go into the the details of what Zenith is, I want to quickly talk about two things. So, on the one hand we've got Ethereum with its rich DeFi ecosystem, battle-tested DeFi applications, and also one of the largest developer bases out there. On the other hand, we have Canton, which has institutional adoption at scale, processing $350 billion of daily volume, over 600 or sorry, $6 trillion of
on-chain assets have been processed on applications on Canton. You see that for example, JP Morgan is launching JPM Coin on Canton network, DTCC is tokenizing US Treasuries, Nasdaq is connecting their Calypso platform to Canton network, and banks like BNY and Lloyds, they are issuing tokenized deposits. So, there are quite a few things going on, and the latest news I think has been Visa, just a couple of days ago coming online as a super validator on Canton.
So, we do see that actually financial institutions do trust digital asset and its 10-year track record. There is a reason why they have chosen Canton. On the other hand, um of course, they also want higher yield opportunities for passive assets or or previously passive or low-yield assets. They want mobilization for those assets in a multi-chain world, basically. And they also want global distribution and 24/7 um markets for those assets.
Um and actually that's where uh Ethereum comes in. Because to build an application on Canton currently natively, you need to learn Daml and you need to basically uh rewrite your existing applications and many of them already exist on on Ethereum in a new language um going through auditing, etc., etc. again. Now, this is a lot of risk and uh that's where actually I think Zenith becomes super important and unlocks a whole lot of new opportunities is because we connect Ethereum's developer base to Canton.
And without rushing ahead too much, um we basically allow you to deploy Solidity applications on Zenith EVM that then become atomically composable on Canton and act just like as if they were deployed natively on Canton. But let's take a quick look at that. So, what is Zenith? Um we are basically extending Canton's execution capabilities with EVM compatibility first and then soon after comes SVM as well. As I mentioned, current focus is uh on EVM and that means for Ethereum developers that they can natively deploy Ethereum applications on Zenith using familiar
tooling, etc. We're going to be talking about that more. And these applications become atomically composable with Canton unlocking a whole new range of use cases that have not been really possible in the Ethereum and the L2 uh landscape because of the of the bottlenecks that uh the lack of atomic composability um uh provides. And then for enterprises, it it actually means that they can operate their own EVM environments which are composable with any Canton subnets.
So, atomic composability, we've mentioned that quite a few times, but more importantly, it unlocks multi-leg transactions. We are We're going to be talking a little bit more about this as well, and it unlocks true unified liquidity, which I think is is going to be super interesting how that evolves. But, let's take a quick look at how you can build on Zenith. So, basically, Zenith EVM is the reference implementation run by our own team. And you can directly deploy EVM applications on Zenith EVM.
When we are live on on our mainnet, we're going to be talking about our roadmap as well. This is a high-performance network, 100k plus TPS. We don't promise millions. 100k plus as of now is is pretty much enough for most use cases. And you can go as low as like you can have as low as 50 500 milliseconds of latency. You will have ready-to-use tooling such as Oracles, interop, indexing, and such. And basically with this, you can have fast go-to-market because you can lift and shift existing Solidity applications. And then on the other hand, you have you have the Zenith stack which
allows teams, enterprises, institutions to build customizable EVM environments. For Canton, these are configurable on the economics level, on the fee model level. You can have your own native token. You can implement sequencing logic etc. These are compliant and compliant environments where you can set up custom permissioning. And also, these have been designed with enterprises and institutional use cases in mind particularly.
Um let's take a quick look at the technicalities on a high level. Zenith EVM is Reth based, so it's a it's a bytecode compatible EVM environment. We support all libraries, we support all standards, be it 3643 for for RWAs or or 4626 for tokenized vaults, etc. And we expose vanilla Ethereum RPC interface. So it's it's super easy to connect with. Regarding the atomic composability, there are two important things to mention here, I think. One of which is the external call primitive.
That's something that we have implemented as like the Zenith team have implemented in Daml directly, and this facilitates Daml contracts to deterministically call out to Solidity contracts, send send EVM payloads as inputs, trigger native EVM execution, receive transaction outputs, and also receive the EVM state root to settle that on Canton. And with this actually, I already started talking about the the final two points on this slide, which are also pretty important.
All EVM transactions are routed through Canton, and I I don't know how how heavy that lands now, but this is significantly different than the current architecture of whenever people build an additional layer on top of something that already exists. So, in case of an L2, we often get the question whether we are an L2. In case of an L2, basically transaction volume and gas fees and all the gas token utility it moves from the base layer to the layer two.
Now, since we are routing all EVM transactions through Canton and we have the external core primitive to allow Dharma contracts to atomically interact with EVM contracts. Basically, you have an environment where we are literally an enshrined EVM extension which where coordination is done on Canton and settlement after the transactions after the EVM transactions have been processed, state route settlement is also done on Canton. I think we're going to touch upon this a little more, but I uh yeah, I don't want to
go to many details as of now. Now, how can you build on Zenith? As I mentioned, we are an Ethereum equivalent environment using breath etc. So, this means your dev x if you want to deploy on Zenith will be lifting and shifting your existing solidity application just replacing the RPC URL to Zenith's endpoint and basically using all the standard Ethereum tooling like hard hat and metamask, you are good to go to deploy your application. It should be a very similar and will be a very similar look and feel of how you would actually deploy on Ethereum.
Now, with regards to interoperability um Zenith EVM, we are not a bridge as well. Just mentioning it because we often get mixed up in in that sense as well. So, Zenith even though we are in the middle from a certain perspective, we are connected to the broader Solana base Ethereum ecosystem through interop solutions like layer zero or CCIP and others. So, that's one angle. But, then on the other angle, we have atomic interrupt, which we are implementing ourselves between Canton and Zenith EVM. And this is important because we don't want to break the atomic composability. That's That's a given through by routing
all transactions through Canton and having the external call primitive to allow multi-leg operations executed in a single transaction. So, you have this interrupt, and from this perspective, basically, you can move any existing assets from current large ecosystems like Ethereum or Solana or Base to Zenith EVM and start composing them atomically with any and every Canton application and subnet. Now, how does that composability look like?
So, as I mentioned, all EVM transactions are routed through Canton. This essentially means that basically, we allow Canton users to submit EVM transactions directly from Canton. The EVM payload is wrapped into a native Canton transaction that lands with Canton's synchronizer. This native Canton transaction is composed of a set of operations, like a tree of operations, which include a Canton leg, let's say, taking some asset native on Canton, and we want to swap it to some asset on the on the EVM side. So, let's assume we have two legs there.
This set of operations includes all the Canton side the operation start, and then comes another one, which is the external call. It takes the wrapped EVM payload, shoots it to to the EVM side. It triggers native execution, and then um it receives all the transaction outputs and also the new state root after the execution took place. So, basically um the external call is step two, the invocation from the Daml contract to the EVM. Yeah, that's maybe something worth mentioning. Our EVM has a a contract on Canton um a Daml contract living on Canton, which registers incoming transactions,
communicates with the EVM, and also takes the the EVM state roots and settles them. So, that's basically coordinating uh the composability element here. So, after native execution, um all the transaction results are um received by the Daml contract. Um all the There is a deterministic validation because all validators involved in the transaction are re-executing uh basically the transaction. And that's how they validate that either all post-transaction results are the same or the transaction fails.
And then there is subsequent atomic settlement and finality, uh which is uh which is done on Canton. Um this allows like to put it in a more practical perspective, this allows something like you can bridge an asset from uh or move an asset from Canton to Zenith EVM. You can borrow against that asset. You can swap what you borrowed to another asset to to get into a certain position. Um and then you could even hedge against that position and settle all these legs in a single transaction atomically. So, you can execute complex strategies um cross Canton and Zenith EVM.
Also, another aspect could be that real-world assets could become instantly usable in DeFi because you can purchase some tokenized asset, and within the same transaction, as a second leg, you could put that up as a collateral in a D5 protocol and start earning yield on top. And this basically eliminates the execution risk between legs and also enables institutional grade transaction logic and transaction flows, which is uh pretty much unheard of uh in the EVM space as of now.
So, and another aspect I think uh absolutely worth mentioning is unified liquidity. And I I mean true unified liquidity. Due to the architecture of Zenith and the atomic composability that we unlock, you can have atomic swaps across any Zenith chain and any Canton subnet. Uh for example, you can have cross-domain liquidity, you can have complex D5 operations spanning both networks and spanning applications living on those two networks, and you can have multi-chain settlement of these complex workflows in a single transaction where Canton acts as the coordination layer and also the settlement layer as I as I
mentioned earlier. Now, we are coming up on time, so uh a quick um overview on where we are. We have a testnet implementation, end-to-end transaction processing across Canton across a Canton test network and Zenith EVM deployed on top of that. Um this has been uh completed early March. We are looking to have mainnet readiness on Canton uh by the end of Q2, and the production go live of Zenith EVM mainnet uh on Canton mainnet is expected to come in Q3.
And uh even though our testnet is actually um uh an internal testnet as of now, we do have a public explorer which I quickly want to show you if I can bring this up here. Yep, very good. So, we processed almost 200k transactions here. Um, I quickly want to show this element to you. So, you see that we have approximately 195 K transactions, and you see that we've got the same number of external calls here. This means that every single transaction that hit Zenith EVM was routed through Canton and had to utilize the external core primitive to trigger the EVM execution.
And you also see that all transactions have a Canton reference update and also an EVM hash. So, you can see that uh you can actually have an overview on both transactions, uh both sides of the transactions basically. If you Yeah, let's take a quick look at uh at the network, um and maybe this is something good to close with. So, we have we shoot a a transaction to our network every every couple of seconds.
We have an EVM node here. Oh, by the way, this transaction that you see on the screen, um it's about someone directly shooting a transaction to Zenith EVM, which then uh gets routed to Canton, also can process a leg on Canton, and then settles back to Canton. So, the way it happens is the transaction lands in the EVM node, it gets prepared, the relayer wraps it into a native Canton transaction, it's submitted to Canton synchronizer, and then there is validator one running actually the EVM node, the relayer, and the external core server. So, relay validator one processes the transaction executing both legs locally and posting
the signatures and the the transaction results back to the synchronizer. Validator two re-executes everything, including the external core and the native EVM execution, locally. Also sends back the results to the synchronizer. And there is a an entity called observer, which is not common or not usually in in the Ethereum space. They validate transactions taking um without running the external core. So, taking the external core results from these two participants, they also shoot back the the validation results and their signatures to the synchronizer.
Once the synchronizer has checked that all signatures match and everybody agrees on the post state, then everybody the the transaction reaches finality and everybody updates their own um local states on their own nodes. So, um that's where that's where we are now. Um in case there are any questions, I'm happy to uh to discuss further. Other than that, thank you very much for listening to us. Uh please take a look at our website. We've got some docs out. Um also happy to chat on uh on our socials. And uh yep, thanks a lot for being here.
Thank you very much.