Zenith EVM on Canton: Understanding the Security Model

First, Correct the Mental Model

Zenith is the EVM execution layer for Canton Network. Its reference environment, Zenith EVM, is built on Reth and exposes standard Ethereum JSON-RPC, so developers can deploy Solidity bytecode and use familiar tools such as Foundry, Hardhat, ethers, and MetaMask. The important difference appears below that interface: Zenith EVM does not use Ethereum proof of stake or an independent Ethereum-style consensus layer. Its block production, canonical state, and finality are coordinated through Canton.

That makes the common phrase 'Canton EVM bridge' potentially misleading. Zenith's primary Canton integration is not described as a lock-and-mint bridge between Ethereum mainnet and Canton. Zenith routes EVM activity through Canton, represents canonical EVM state with Daml contracts, and uses Canton validation to settle EVM blocks and state roots. Canton-native workflows can coordinate EVM execution atomically through Zenith Gateway and the external_call primitive.

Zenith also describes future connectivity to external ecosystems such as Ethereum, Base, and Solana. Those external paths are a separate interoperability model and should not be conflated with the Canton-native atomic path. As of August 2026, official documentation presents a public Zenith EVM testnet. Zenith's August roadmap update says external_call has been merged into the Canton repository and a cross-environment asset swap has been demonstrated on a feature-complete test network. Production MainNet behavior should be reverified against release documentation before any security assessment or deployment decision.

What Zenith Is and Who Builds It

Zenith maintains the reference Zenith EVM environment and is a registered Canton Super Validator. The approved Canton Foundation proposal, CIP-0091, identifies Zenith as developed by ZkCloud, a spinout of Equilibrium Labs. The proposal describes a broader plan for virtual execution environments on Canton, beginning with EVM and with SVM support planned later. Current public developer documentation is focused on the EVM testnet.

From an application developer's perspective, Zenith EVM behaves like an Ethereum-compatible network at the execution and RPC layers. Standard transactions are signed and submitted through JSON-RPC; standard EVM opcodes, gas accounting, and ERC contracts are supported on the testnet. From a protocol-security perspective, however, Ethereum mainnet assumptions cannot be imported blindly. Canton mediates block ordering and finality, authorized Canton participants validate the environment, and EVM-specific context such as PREVRANDAO does not originate from Ethereum's Beacon Chain.

Zenith also distinguishes the reference EVM from the Zenith Stack, which is intended to let institutions operate customizable EVM environments. Configuration of access, economics, ordering, native assets, operators, and Canton connectivity can change the threat model. A review must name the exact environment rather than treat 'Zenith' as one fixed deployment with one fixed set of trusted actors.

How Canton-Mediated EVM Execution Works

The public architecture documentation describes Zenith EVM as an EVM-based subnet on Canton. EVM users submit ordinary transactions to an EVM node. Transactions are collected into Canton-side block proposals, validators rebuild the EVM block from the same ordered inputs, and Canton finality determines which proposal becomes canonical. The finalized block is then published to the EVM-facing side. On Canton, a set of Daml contracts records and governs the canonical EVM chain state rather than relying on one monolithic state contract.

For cross-environment operations, external_call allows a Daml workflow to invoke a locally running external execution service deterministically. In Zenith's published test architecture, an EVM-capable Canton participant runs an EVM node, relayer, and external call server. The submitter interprets the Daml transaction, executes the EVM payload, and includes the result in the relevant transaction view. Other validating participants independently re-execute the call. If their outputs differ, Canton validation fails.

Zenith Gateway uses this Canton-routed processing path so a Canton workflow and a Zenith EVM state transition can be part of one operation tree. In the demonstrated flow, both legs are committed through Canton or the combined transaction fails. This is protocol-level atomic composition between Canton and Zenith EVM, not two independently finalized chains exchanging proofs after the fact.

EVM or Canton submission → Canton-routed transaction and ordered payload → deterministic EVM execution by validating participants → Canton validation and finality → canonical EVM block and state root

The Two Submission Directions Have Different Edges

In Zenith's published March 2026 test flow, a transaction beginning at the EVM interface reached the EVM node before a relayer submitted the wrapped payload into Canton's sequencing flow. EVM-capable participants executed the payload through their external call servers, compared deterministic results, and finalized the new state through Canton. Current testnet documentation describes a Zenith EVM Sequencer collecting RPC submissions into Canton-mediated block proposals. In either description, the familiar JSON-RPC entry point reaches a larger validation pipeline than a standalone Reth node would.

When a Canton user initiates a workflow that triggers EVM execution, the submitting participant may not itself operate an EVM node. Zenith's published test flow has that participant call a prepare endpoint on an EVM-capable participant. The capable participant executes enough of the EVM path to prepare the transaction and returns it for inspection and signature; the original participant then submits the combined transaction to the synchronizer. This preserves the ability of Canton-only participants to initiate a composed workflow, but it makes preparation, inspection, signing, and endpoint trust explicit security boundaries.

The exact APIs, authentication, validator set, batching policy, and failure handling in a production environment must be confirmed from the deployed version. The test architecture is useful for reasoning, but it is not evidence that every future Zenith Stack instance will use identical operators or policies.

The Security Boundary Is Bigger Than a Bridge Contract

A conventional bridge review may focus on custody contracts, message verification, relayers, and wrapped-token supply. Zenith's Canton-native path demands a different system boundary. Reviewers must inspect the Solidity application, the Daml contracts that coordinate EVM state and composed workflows, the external_call implementation and server, EVM block construction, relayer behavior, validator configuration, and the APIs through which users submit or prepare transactions.

Determinism is a central requirement. Every validating participant must derive the same EVM result from the same ordered input. Contracts or infrastructure that depend on environment-specific randomness, local time, mutable external data, inconsistent fork configuration, or nondeterministic services can cause disagreement and rejection. The testnet documentation specifically warns that PREVRANDAO is supplied by Zenith's Canton-mediated block-building environment rather than Ethereum validator randomness, so applications must not assume Ethereum mainnet semantics for it.

Authorization crosses domains as well. An EVM signature proves control of an address under EVM rules; a Canton party and submission right represent authority under Canton rules. A composed workflow needs a defensible mapping between those identities and actions. Preparation services must not be able to substitute payloads, users must understand what they sign, and Daml controllers must not confer broader EVM effects than their workflow language communicates.

• EVM contracts, deployment parameters, upgrade paths, privileged roles, gas assumptions, and environment-dependent opcodes.
• Canton-side Daml contracts, party authorization, visibility, lifecycle, and state-root governance.
• Transaction batching, ordering, relaying, preparation, payload inspection, signing, and deduplication.
• External call server integrity, deterministic execution, Reth configuration, fork alignment, and validator consistency.
• Participant authorization, validator admission, synchronizer assumptions, monitoring, recovery, and emergency controls.

Cross-Domain Security Depends on Invariants Across Both Sides

Atomic settlement is a strong foundation, but it does not prove the business transition is correct. If a Daml workflow passes the wrong amount, asset identifier, recipient, or calldata to a perfectly deterministic Solidity contract, both legs can atomically commit the wrong outcome. Reviewers therefore need invariants that cover semantic equivalence, not only all-or-nothing execution.

For an asset exchange, conservation may require that the Canton asset consumed by a workflow exactly corresponds to the EVM asset delivered, with consistent decimals, identifiers, ownership, fees, and rounding. Uniqueness may require that a prepared payload cannot be signed or submitted twice in a different context. Authorization may require both the correct Canton party and the correct EVM account, rather than allowing control on one side to impersonate authority on the other.

Emergency behavior also needs a cross-domain specification. If an EVM contract is paused while a Canton offer remains exercisable, what should happen? If a validator or external call server is unavailable, can pending workflows be retried safely? If an upgrade changes EVM bytecode or Daml coordination logic, which version combinations are valid? Coherent failure states are part of the protocol, not secondary operations work.

• Atomicity: the Canton and EVM transitions both commit or both fail.
• Conservation: value is neither created nor lost through mapping, fees, decimals, or rounding.
• Uniqueness: a payload, intent, or authorization cannot be replayed in another batch or workflow.
• Identity binding: the intended Canton party and EVM account authorize the exact same economic action.
• Canonical state: validators agree on the ordered inputs, EVM block, result, and state root.
• Failure coherence: pause, retry, timeout, upgrade, and recovery behavior is safe across both environments.

Privacy Does Not Appear Automatically at the EVM Boundary

Canton provides selective disclosure for transaction views, but an EVM application normally assumes broadly observable state, calldata, logs, and RPC access. A team deploying on Zenith must document which EVM data is visible, who can query it, what the environment operator exposes, and how Canton-side privacy is preserved or intentionally relaxed when data crosses into Solidity execution.

The safest design does not rely on a vague claim that Canton makes every connected EVM application private. Privacy is an application and deployment property. Sensitive fields may need to remain on the Daml side, be represented by commitments or narrow references, or be disclosed only to a controlled EVM environment. Logs, explorers, indexers, RPC nodes, tracing systems, and support tooling all belong in the information-flow review.

This is also where institutional requirements meet EVM developer expectations. A public explorer is valuable for testnet debugging, while a regulated production workflow may require restricted observability, auditable access, and data-retention controls. The chosen Zenith environment must make that boundary explicit.

Current Status Changes the Review Questions

Zenith's public materials show meaningful progress. Its public EVM testnet currently identifies chain ID 936485 and ZTH as the test gas token. Zenith also reports more than 100,000 transactions processed in an earlier internal test environment, merged external_call work, and an August 2026 demonstration of a CIP-56 asset exchanged with an ERC-20 asset on a feature-complete test network. The Zenith site currently advertises a MainNet waitlist for Q4. These are development milestones and roadmap signals, not substitutes for production security evidence.

Before a mainnet deployment, teams should confirm the released Canton version, external_call semantics, production validator and operator model, Zenith EVM chain parameters, upgrade process, privacy configuration, fee mechanics, emergency controls, supported asset standards, and available monitoring. Any connection from Zenith EVM to external chains such as Ethereum or Base should be reviewed separately from the Canton-native Gateway path because it may introduce a different consensus, messaging, custody, and finality model.

A useful assessment should pin exact repositories, commits, contracts, node versions, network configuration, and operating responsibilities. Public architecture claims establish a model to test; deployed artifacts establish the actual scope.

Why Canton and EVM Composability Matters

EVM compatibility can bring Solidity applications, mature tooling, established libraries, and a large developer base closer to Canton's institutional assets and workflows. Canton can contribute privacy-aware coordination, independent application control, and atomic multi-party settlement. The combination is strategically interesting because it connects different application models without requiring every team to rewrite its logic in one language.

The same combination creates a new class of review problem. Solidity correctness, Daml authorization, Canton transaction visibility, EVM determinism, validator operations, and cross-domain accounting have to agree. Expertise limited to only one side can miss the failure mode that emerges at the boundary.

Teams evaluating Zenith should treat its architecture as a composed system, not a familiar EVM with a new RPC URL and not a conventional bridge with a different brand. Kann Audits can scope expert review across Solidity, Daml, off-chain infrastructure, and the invariants joining them. The objective is to test the exact deployed trust model as Zenith moves from testnet milestones toward production use.