Demonstrating atomic swaps between Canton and Zenith EVM

Earlier this year, Zenith demonstrated the first atomic transaction flows between EVM applications and Canton Network, proving that Solidity applications deployed to Zenith can interact natively with Canton's institutional infrastructure.

Earlier this month, we completed the next milestone of our CIP-0091 demonstrating application-level composability with an end-to-end atomic swap between a Canton-native, CIP-0056-compliant asset and an ERC-20 asset on Zenith EVM, coordinated through a Canton-native settlement venue, an OTC trading app.

Completing a delivery-versus-payment workflow across the two environments proves that unified liquidity and the processing of multi-leg financial operations settled atomically across Canton and Zenith EVM is a reality.

The result is not two settlements connected by a bridge, a timelock or a best-effort relay. It is one Canton settlement that executes the Canton asset transfers and finalizes the Zenith EVM block carrying the corresponding EVM payout. Either the complete workflow commits, or none of it does.

Requirements

CIP-0091 defined the practical requirements precisely: deploy an asset on Zenith EVM and compose it with a Daml-native asset through a Daml-native DEX on a Canton test network in an atomic swap.

To make that requirement meaningful, the demo had to preserve the boundaries that real applications and users would expect:

• Alice is a Canton-native user. She interacts only with the Canton venue and a CIP-0056-compliant token interface.

• Bob is an EVM-only user. He uses an ordinary EVM account and never signs a Canton transaction.

• The venue is a Canton-native OTC settlement application. It creates the deal, emits the CIP-0056 allocation requests and triggers settlement.

• The assets span both environments: a Canton-native asset and a Zenith EVM ERC-20, with representations on the other side where required by the settlement flow.

• The venue and its core Daml workflow remain Zenith-agnostic. They depend on token-standard interfaces and ordinary Canton APIs rather than Zenith-specific application logic.

In the demo, Alice swaps 2.5 CC for 2.5 ZTH with Bob. Alice locks CC on Canton and receives wZTH on Canton. Bob burns ZTH on Zenith EVM and receives wCC to his EVM account. The amounts are illustrative; the important property is how authorization, allocation and finality are composed.

What we mean by atomicity

“Atomic swap” is often used for workflows implemented with hashed timelock contracts or coordinated transactions across independent chains. Those mechanisms can provide economic assurance that both sides eventually complete or unwind, but each leg is still finalized by a separate consensus mechanism at a separate time.

Zenith’s architecture provides consensus-level atomicity. Zenith EVM does not operate an independent Ethereum-style consensus layer. Its block production, canonical chain state and finality are mediated through Canton. More precisely, there aren't two separate validator sets, Canton and EVM nodes. A set of Canton validators hosting Zenith's contracts on Canton do the native EVM execution on their respective nodes locally. 

EVM transactions are collected into Canton-side block proposals, validators rebuild the proposed block from the ordered inputs, and Canton finality determines which EVM block becomes canonical. The finalized payload is then propagated back to the public EVM node. This architecture is described in the Zenith technical documentation.

For a transaction spanning Canton and Zenith EVM, the practical guarantee is therefore straightforward:

• If every Canton and EVM operation succeeds, the combined transaction commits;

• If either side fails validation or execution, the complete transaction fails; and

• There is no intermediate state in which one settlement leg is final while the other is still pending.

This is the property Milestone 2 set out to demonstrate.

Design overview

The demo design has four relevant elements:

Canton-native application and asset workflows

Alice, the venue and the Gateway (the atomic interop solution built by Zenith in-house) are represented as Canton parties. The venue records the deal terms, creates the buyer and seller allocation specifications, and invokes the standard CIP-0056 settlement flow. Alice’s asset is allocated through the token-standard interface.

The venue does not need direct rights over the EVM contracts. The Canton events needed during settlement are supplied through explicit disclosure.

Zenith EVM execution

Zenith EVM exposes the standard Ethereum JSON-RPC surface. EVM users can submit ordinary transactions with familiar wallets and tooling, the model is compatible with MetaMask and other standard EVM wallets.

Behind that interface, the EVM sequencer collects transactions for Canton-mediated block proposals. A builder executes the ordered payload, Canton participants confirm the result, and the Canton synchronizer/mediator determines finality. The finalized block payload is then imported into the public EVM node, where standard receipt and balance queries show the canonical result.

The Zenith Gateway

Bob has no Canton identity, so the Gateway represents him for the seller-side Canton choices. It observes Bob’s canonical EVM burn receipt, creates deal-bound burn evidence on Canton, and uses that evidence when accepting and allocating on Bob’s behalf.

The Gateway is a coordinator, not an alternative settlement layer. It cannot make a partially completed trade final. Its evidence and authorization are consumed by the Canton workflow, and settlement remains subject to Canton validation and consensus.

• Note: The Gateway design included below might be subject to some changes as we implement optimizations and improvements on our path to production launch.

The external_call() primitive

The external_call() primitive allows a Daml workflow to invoke a configured local service during transaction interpretation. Other validating participants independently re-execute or validate the same operation. A disagreement rejects the request rather than producing a divergent state.

The end-to-end external-call support was merged upstream into Canton in July 2026. It is planned for MainNet release with Canton 3.6 upgrade.

The end-to-end transaction flow

The complete workflow can be described in six stages.

1. Alice proposes the deal on Canton

Alice creates the initial DealTermProposal: 2.5 CC to be swapped against 2.5 ZTH. Her interaction is entirely Canton-native. She does not connect to Zenith EVM or construct an EVM transaction.

2. Bob authorizes the seller side on Zenith EVM

Bob burns 2.5 ZTH in an ordinary EVM transaction containing a reference bound to this specific deal. This is Bob’s seller-side authorization. He does not sign on Canton.

The Gateway observes the canonical burn receipt, attests it on Canton and accepts the deal on Bob’s behalf. Because the burn is tied to the trade reference, it cannot be repurposed for another order.

3. The venue emits allocation requests

Once the terms are accepted, the Canton-native venue creates the buyer and seller AllocationSpecifications. The Gateway party appears as the Canton-side stand-in for Bob, while Bob’s EVM address is carried as metadata.

This resembles the way an exchange can associate an external account using a memo or reference: the venue understands the standard business data, not the implementation details of the other environment.

4. Alice and the Gateway allocate the two legs

Alice allocates 2.5 CC through the CIP-0056 allocation interface.

It is the Gateway that creates the allocation on Bob's behalf, for the 2.5 wZTH. The Gateway can allocate only if the choice context contains the on-ledger evidence of Bob’s canonical burn. That evidence is consumed once. A replay cannot create a second valid seller allocation from the same burn.

5. The venue settles once

The venue, the OTC trade app, submits a single Canton transaction which executes both token transfers and, driven by the Gateway, verifies a mint voucher, calls out via external_call, and finalizes the EVM block that delivers Bob’s payout. Settlement and payout commit or abort together.

If any step fails, including voucher verification, EVM execution or validator agreement, the Canton settlement does not commit. If the settlement commits, Alice receives wZTH on Canton and the block paying wCC to Bob on Zenith is finalized simultaneously.

6. Bob verifies the canonical result through standard EVM APIs

The finalized payload is imported into the public EVM node. Bob can then query an ordinary Ethereum receipt and verify that his wCC balance increased by exactly the deal amount.

From Bob’s perspective, the workflow begins with a standard EVM transaction and ends with a standard EVM receipt. Canton provides the coordination and finality underneath without changing the wallet-facing EVM model.

The voucher: Bob approves an authorization, not a signed transaction

One design detail deserves its own explanation, because it is where atomicity and safety meet. When the payout to Bob is authorized, that authorization is a deal-specific voucher, not a pre-signed EVM transaction. 

It is a bound authorization: an N-of-M gateway-quorum signature that practically says, “deliver this amount to Bob, but only for this deal, only for these allocations, and only before time T.” 

Turning a voucher into an actual EVM mint requires the Gateway’s authorized-submitter key, and the on-chain contract independently enforces that the caller is the authorized submitter, checks the quorum signatures, honors the expiry, and marks each voucher single-use. A leaked voucher, replayed directly against the EVM, therefore mints nothing. The Gateway can consume the voucher only when there is a genuine order match, inside the settlement.

Why Zenith-agnostic application boundaries matter

The deepest architectural result is not that a bespoke Daml application can be wired to a bespoke EVM contract. It is that the Canton venue can remain unaware of Zenith-specific execution details.

During the workflow, the venue uses ordinary Ledger API calls, CIP-0056 interfaces, choice context, metadata and explicit disclosure. Interoperability is isolated in the Gateway and registry layer, where the EVM evidence and block-finalization extension belong.

That separation matters for several reasons:

• Existing Canton applications do not need to import Zenith logic: A venue can preserve its business logic and authorization model while supporting an EVM-side counterparty.

• The integration is reusable: Other Canton-native venues and asset workflows can compose through the same standards rather than rebuilding a Zenith-specific path.

• Execution details can evolve independently: Changes to the Zenith block pipeline or Gateway service do not require redesigning the venue’s trade lifecycle.

• The trust boundary stays explicit: The venue does not receive privileged EVM contract rights, and the Gateway does not acquire the power to finalize a partial settlement.

• Users stay native to their environment: Alice approves only on Canton; Bob authorizes only through an EVM transaction.

From milestone proof to public testnet

The complete stack was delivered in a containerized form so that evaluators could run it independently, inspect the Daml and Solidity contracts, and examine the Canton and EVM transactions. Their assessment confirmed the central result: a CIP-0056-compliant settlement can execute both token allocations while finalizing the EVM block that pays the EVM-only counterparty.

The next step is the public release of the Zenith EVM Testnet in the next few weeks. Watch out for our upcoming announcement.

Further reading

• Milestone 1 deep dive: Zenith demonstrates atomic transaction flows across Canton and Zenith EVM 

• Milestone 2 announcement: Zenith advances roadmap toward full EVM-composability on Canton MainNet 

• Documentation: docs.zenith.network