Mailing Lists/CIP-TBD: Canton EVM Compatibility - Andrew SkurlatovSource on lists.sync.global ↗

CIP-TBD: Canton EVM Compatibility - Andrew Skurlatov

cip-discuss3 messagesstarted 06-12-2025
Also mentions:CIP-0056CIP-0084CIP-0091
  1. #1Andrew Skurlatov06-12-2025source ↗
    Hello,

    Please find the below CIP for discussion:

    —

    CIP: CIP-0084  
    Title: Canton EVM Compatibility
    Layer: Core
    Author: Gateway.fm
    Status: Draft  
    Type: Standards Track  
    Created: 2025-12-06  
    License: CC0-1.0

    Abstract

    This CIP introduces EVM compatibility to the Canton Network by enabling deterministic external execution of Ethereum transactions through the via the upcoming Canton external_call() interface, as introduced in the Zenith proposal.

    It allows execution of unmodified Solidity smart contracts inside Canton by delegating transaction processing to a modified, deterministic Erigon engine running locally on each participant node.

    Every validator invokes the same EVM execution via external_call(), ensuring consensus while preserving Canton’s privacy and atomic transaction guarantees.

    Each execution updates an on-ledger EVMContext that tracks Ethereum-style state roots and metadata.

    A JSON-RPC interface provides compatibility with existing Ethereum developer tools, and optional bridge primitivesenable asset and event flows between Canton and external EVM networks.


    Specification

    Summary

    This specification defines how the Canton Network will support EVM execution through integration with a deterministic, Canton-controlled Erigon engine accessed via the external_call() primitive.

    The goal is to enable Canton to run unmodified Solidity smart contracts deterministically while preserving Canton’s privacy model, consensus rules, and atomic transaction guarantees.

    Each execution updates an on-ledger EVMContext representing Ethereum-style state and metadata, allowing seamless interoperability between Solidity contracts, Daml workflows, and Canton-native applications.

    This design transforms Canton into a multi-VM, polyglot execution environment, connecting the Ethereum developer ecosystem with Canton’s secure and regulated infrastructure.

    Approach

    The proposed integration enables EVM execution within Canton by connecting its transaction engine to a deterministic, Canton-controlled Erigon service through the forthcoming external_call() primitive.

    Each Canton participant hosts a local Erigon instance configured as a non-networked, deterministic execution environment, with Canton itself acting as the consensus and coordination layer for all EVM operations.

    When a Daml contract or system module triggers external_call("evm", payload), the participant executes the Ethereum transaction locally on its Erigon instance, producing identical outputs—updated state roots, logs, and receipts.

    All informee nodes re-run the same computation to ensure full consensus and deterministic replay under Canton’s governance.

    The resulting EVMContext (state root, accounts, and logs) is stored on-ledger as a Canton contract, inheriting Canton’s native privacy, authorization, and atomic transaction guarantees.

    This design turns Canton into a Layer-0 consensus layer for EVM-based applications, providing private, verifiable execution of Solidity contracts within the existing network.

    This approach provides:

    • Deterministic integration: All participants run identical EVM computations locally, coordinated through Canton’s consensus layer.
    • Seamless compatibility: Unmodified Solidity contracts and standard Ethereum tooling (e.g., Hardhat, MetaMask) can interact via Canton’s JSON-RPC gateway.
    • Atomic composability: EVM and Daml contracts can execute within the same transaction tree while preserving Canton’s privacy boundaries.
    • Extensibility: The same external_call() interface can support additional deterministic runtimes (e.g., MoveVM, SVM) or zero-knowledge proof verifiers in the future.

    Solution

    The proposed solution enables EVM execution within the Canton Network by connecting its deterministic transaction engine to a modified Erigon execution service through the forthcoming external_call() primitive.

    Each participant node hosts a local Erigon instance configured as a deterministic, non-networked microservice, while Canton functions as the consensus and settlement layer—coordinating transaction ordering, validation, and privacy enforcement.

    Three key components define the architecture:

    1. Execution Layer — a modified Erigon runtime acts as the deterministic EVM engine, invoked via external_call("evm", payload).
      • Each invocation includes the current EVM state and signed transaction payload.
      • Execution yields a canonical result bundle (new state root, logs, receipts, and return data).
      • Erigon’s upcoming privacy subsystem will be leveraged and extended to align with Canton’s informee model, ensuring that EVM state and events inherit Canton’s fine-grained privacy semantics.
    2. Ledger Binding Layer — an on-ledger EVMContext contract represents EVM state within Canton’s eUTXO ledger model.
      • Each EVM transaction consumes the previous EVMContext and produces a new one, mapping Ethereum’s account-based updates into Canton’s contract lifecycle.
      • Resulting state roots and logs are finalized under Canton’s consensus, inheriting its authorization, privacy, and audit guarantees.
    3. Interoperability Layer — a JSON-RPC proxy provides standard Ethereum interfaces (e.g., eth_call, eth_sendRawTransaction, eth_getLogs) and routes them through the Canton participant API to the appropriate EVMContext.
      • Key infrastructure is unified by modifying Erigon’s key management to adopt Canton’s identity and namespace scheme, allowing consistent signing, verification, and address mapping across both systems.
      • Bridge primitives handle event attestations, asset transfers, and proof-based interoperability with external EVM networks, ensuring atomic cross-domain operations.

    Together, these components establish Canton as the consensus layer for deterministic EVM execution, providing atomic settlement, selective privacy, and regulatory-grade integrity for Ethereum-compatible smart contracts—without modifying Canton’s core runtime or consensus protocol.

    Architecture

    Components

    • EVM Execution Service (Deterministic Erigon)
      • Local, non-networked Erigon instance deployed per Canton participant.
      • Executes EVM bytecode deterministically when invoked through external_call("evm", payload).
      • Processes full EVM semantics, gas accounting, and log emission, producing canonical results (state root, logs, receipts, return data).
      • Integrates Erigon’s upcoming privacy subsystem to align data access with Canton’s informee model.
    • External Call Interface (external_call)
      • Deterministic host interface that connects Canton’s ledger engine to the Erigon execution service.
      • Validates payloads, executes the external call locally on each participant, and ensures identical results across all validating nodes.
      • Enforces Canton’s replay and determinism rules.
    • Ledger Binding Layer
      • On-ledger EVMContext contract maps Erigon’s account-based world state to Canton’s eUTXO ledger.
      • Each EVM transaction consumes the current EVMContext and creates a new one containing the updated state and Merkle root.
      • Applies Canton’s privacy and authorization policies through signatories and observers.
    • Sidecar RPC Proxy
      • Runs adjacent to each participant node, exposing a minimal Ethereum JSON-RPC interface (eth_call, eth_sendRawTransaction, eth_getLogs, eth_getCode, eth_getStorageAt).
      • Translates standard Ethereum RPC requests into Canton Ledger API calls targeting the correct EVMContext.
      • Returns Ethereum-compatible receipts, transaction hashes, and state queries.
      • Operates statelessly, caching only metadata necessary for routing and performance.
    • Privacy & Key Integration Layer
      • Unifies identity and key formats between Canton and Erigon by adopting Canton party keys and namespace-based address derivation.
      • Ensures all transactions, events, and logs follow Canton’s fine-grained informee-based visibility rules.
      • Supports interoperability with Ethereum-style wallets (e.g., MetaMask) through compatible signing schemes.
    • Bridge Primitives
      • Event Bridge: Generates deterministic Merkle commitments of emitted EVM events and validator/threshold attestations for external verification.
      • Asset Bridge: Provides lock/mint and burn/release mechanics for ERC-20 and CIP-0056–compatible assets; designed for eventual proof-based cross-network settlement.
    • Monitoring & Indexing
      • Provides metrics (latency, throughput, error rate, state size, bridge latency/success) and structured logs for transaction receipts and EVM events.
      • Maintains an internal index backing eth_getLogs queries and external observability dashboards.

    Data Model

    • EVMContext (logical instance)
      • Identity: contextId (required) and optional chainId (for RPC/tooling).
      • World State: serialized EVM state snapshot (accounts, contract code, storage trie, balances, nonces).
      • Policy: signatories (writers), observers (readers), authorized callers (whitelist/roles), optional gas/quota policy.
      • Metadata: EVM spec tag (e.g., London/Shanghai), sequence number (monotonic “blockNumber”), state root, code hash(es), created/updated timestamps.
    • On-Ledger Representation
      • Contract Type: EVMContext Daml/Canton contract anchors the latest state artifact (inline or chunked; large blobs via content-addressed storage).
      • Transition Model: each EVM tx consumes EVMContext(n) and creates EVMContext(n+1) with updated state root + metadata (preserves eUTXO semantics).
      • Determinism Hints: post-state hash, gas used, receipts hash recorded to aid replay verification across participants.
    • State Artifacts
      • Snapshot: canonical serialized world state; optional delta/journal for debug/audit.
      • Indexes (optional): per-context code index (address → code hash), storage hint index (address + slot → last touched).
    • Event/Log Model
      • Capture: EVM LOG* opcodes normalized to Canton events (topics, data, emitter address, tx hash, seq#).
      • Indexing: per-context, privacy-scoped log index supporting eth_getLogs filters (address/topics/seq range).
      • Bridging Commitments: Merkle commitments to emitted logs (by seq range) stored alongside the context for external attestations.
    • Key & Identity Mapping
      • Addresses: Ethereum addresses derived from (or mapped to) Canton party namespaces; mapping table recorded in context metadata.
      • Auth Links: optional delegation records tying EOA signatures to Canton party authorization for RPC-submitted transactions.
    • Privacy Annotations
      • Visibility Sets: observer lists on EVMContext govern who can read state/logs; enforced in Erigon’s privacy view.
      • Provenance: informee lists and submitting parties embedded in the context transition for audit.
    • Read Semantics
      • eth_call: executes against the current EVMContext snapshot (no consume/create); returns returnData only.
      • Queries: eth_getCode, eth_getStorageAt, balances read from the snapshot; subject to visibility rules.
    • Receipt & Metrics Records
      • Receipts: Ethereum-compatible receipt fields (status, logsBloom/hash, gasUsed, cumulativeGasUsed) attached to the transition.
      • Metrics: execution latency, gas used, state size deltas stored as per-context telemetry (optional) for ops dashboards.

    Execution Flow

    The EVM–Canton integration is designed as a hybrid model where Canton acts as the consensus and privacy layer, while a deterministic Erigon service handles execution of Ethereum bytecode. This setup separates execution, ordering, and data visibility, ensuring both compatibility with Ethereum tooling and alignment with Canton’s eUTXO and informee model.

    1. Ingress (RPC or Canton call)
      1. External Ethereum-compatible clients such as MetaMask, Hardhat, or Foundry interact with Canton through a Sidecar RPC Proxy that exposes the standard Ethereum JSON-RPC interface (eth_sendRawTransaction, eth_call, etc.).
      2. Each request is scoped to a particular EVMContext — a Canton contract representing the latest EVM world state.
      3. Transactions are then routed into the Canton Participant Node using the Ledger API or Daml command submission.
    2. Validation & Routing
      1. When the participant receives a request:
        1. It authenticates the sender based on the mapped Ethereum address ↔ Canton party.
        2. Fetches the most recent EVMContext snapshot, which contains the serialized world state and associated metadata.
        3. Uses the external_call("evm", …) primitive to invoke the deterministic EVM execution service.
      2. This ensures that every participant hosting the involved parties can replay the call under identical input conditions.
    3. Deterministic Execution (Consensus Layer Integration)
      1. The Erigon service (modified and stripped of P2P and consensus layers) executes the transaction in a sandboxed environment.
      2. Execution happens identically on all validating Canton nodes:
        1. The Canton ledger provides inputs (EVM state, transaction, environment parameters like timestamp and block number).
        2. The Erigon engine processes the transaction deterministically, without any external randomness or networking.
        3. The result bundle (new state root, logs, gas usage, status, and return data) is returned to the ledger engine.
      3. This design leverages Canton as the consensus layer — ensuring transaction ordering, finality, and visibility enforcement — while Erigon provides full EVM bytecode compatibility.
    4. Result Construction
      1. Once the Erigon service returns the canonical result:
        1. The ledger consumes the current EVMContext(n) and creates a new EVMContext(n+1) representing the updated world state.
        2. Canton emits events corresponding to the EVM LOG* opcodes, recorded as Canton events and indexed by topic.
        3. Receipts and logs are normalized for compatibility with Ethereum’s RPC expectations.
    5. Commit & Privacy Enforcement
      1. The transaction is finalized through Canton’s consensus:
        1. Each participant validates the deterministic execution outcome and cryptographically agrees on the same post-state root.
        2. Only authorized informees (signatories, observers) receive the updated state and event data.
        3. Erigon’s built-in privacy component enforces matching data visibility within its local store, maintaining parity with Canton’s privacy rules.
    6. Egress (RPC Response and Indexing)
      1. After successful commit:
        1. The Sidecar RPC Proxy returns standard Ethereum-compatible responses — txHash, receipt, or call result — to the client.
        2. Indexers and dashboards update from event feeds, maintaining topic-based filters for eth_getLogs and other queries.
        3. Bridge primitives (when enabled) can produce attestations or proofs for cross-chain settlement through the Global Synchronizer.
    7. Read Path Optimization
      1. For read-only RPC calls (eth_call, eth_getLogs, eth_getCode, eth_getStorageAt):
        1. The RPC Proxy directly queries the local Erigon instance instead of invoking a full Canton transaction.
        2. Crucially, all reads are performed against the latest committed EVMContext state root pinned in the ledger.
        3. This guarantees that even fast local reads remain consistent, deterministic, and privacy-aligned with the global Canton state.

    Privacy & Permissioning

    • Context-scoped privacy: Each EVMContext defines its own visibility boundaries. Signatories control write access; observers define who can see execution results and emitted events. Only parties within this context receive the updated state and logs after transaction finalization.
    • Cross-app atomicity: Canton allows EVM transactions to be composed atomically with Daml or other contracts in the same transaction tree. All sub-transactions obey Canton’s privacy layering, meaning informees see only the data relevant to them.
    • Role patterns: Administrative and operational controls (e.g., admin, operator, auditor) can be expressed as party sets and enforced during execution by the participant node or within the EVMContext contract.
    • Privacy synchronization: Erigon’s upcoming privacy subsystem will mirror Canton’s informee and visibility sets to guarantee consistent local data storage and query access.

    Environment & Semantics

    • Consensus mapping: Canton functions as the consensus and ordering layer for the EVM. Block metadata—block.number, timestamp, and basefee—is deterministically derived from the Canton ledger context rather than network clocks.
    • Gas model: The integration uses a compatibility gas mode that meters execution for parity with Ethereum tooling but omits economic gas fees. A quota mode can optionally cap compute and memory consumption per transaction.
    • Time and block constants:
      • block.timestamp → mapped to Canton effective time.
      • block.number → increments with each new EVMContext state.
      • coinbase, difficulty, basefee → fixed deterministic constants documented in the engine spec.
    • Addresses and keys: Ethereum’s secp256k1 addresses and keys are supported natively. Canton participants map Ethereum EOAs to Canton Parties using unified key registration. This ensures that Ethereum-signed transactions can authorize Canton actions without re-signing.

    Error & Revert Semantics

    • All revert conditions (REVERT, INVALID, OUT-OF-GAS) propagate as canonical Ethereum receipts with status = 0.
    • Determinism enforcement: Each participant recomputes the same post-state root. If any node diverges, the entire Canton transaction aborts before finalization.
    • Revert payloads are ABI-encoded and attached to the transaction result for debugging and RPC compatibility.

    RPC Compatibility

    • Minimum RPC Set: eth_chainId, eth_call, eth_sendRawTransaction, eth_getTransactionReceipt, eth_getLogs, eth_blockNumber, eth_getCode, eth_getStorageAt.
    • Namespacing: All endpoints are scoped per contextId and, optionally, chainId, ensuring clear isolation between EVM instances.
    • Sidecar proxy: RPC endpoints are hosted by a dedicated sidecar proxy running adjacent to the participant node. This proxy forwards write operations into Canton and handles read requests directly from the Erigon service, pinned to the latest committed ledger state root.

    Bridging

    • Event Bridge: Produces deterministic event commitments (Merkle or Keccak-based) along with validator attestations (threshold signatures or multisig). These attestations can be consumed by external EVM chains for verification.
    • Asset Bridge (Phase 1): Enables ERC-20 or ERC-721 token transfers between Canton and other EVM networks via a custodial relayer. Later versions may introduce proof-based validation or light-client verification.
    • Settlement: All bridge operations finalize through the Global Synchronizer, where attested activity markers record inter-network transfers and reward eligibility.

    Determinism, Resource & Security

    • External-call sandboxing: Every EVM invocation is performed via a deterministic external_call("evm", …) with no shared mutable state or non-deterministic inputs.
    • Resource isolation: Memory, CPU, and execution time are capped per call.
    • State snapshotting: Periodic compaction or pruning for large EVMContext states. Multi-context sharding is supported for parallel applications.
    • Validation & testing:
      • Opcode conformance tests across ≥ 3 participants.
      • Replay and determinism validation under load.
      • Privacy/informee enforcement tests.
      • Bridge integrity checks (supply and replay invariants).

    Parallelism & Contention Model

    EVM execution on Canton follows a consume–produce model: every state-changing operation targeting a given EVMContext must consume the latest state and produce the next one. While this ensures strong determinism, it naturally serializes updates within a single context. To support higher throughput without compromising consensus guarantees, the design introduces two complementary parallelism mechanisms:

    • Independent Parallelism (faster, compromises composability):

      Each EVMContext maintains its own state root and lifecycle. Transactions targeting different contexts are fully parallelizable, allowing applications to shard workloads by product line, asset type, tenant, or business domain.

      • No state contention.
      • No coordination needed between contexts.
      • Maximizes horizontal scalability.

    • Composable Parallelism (slower, 100% composable):

      For applications that require higher throughput inside one EVMContext, a deterministic sequencer collects incoming EVM transactions, orders them, and groups non-conflicting operations into batches.

      • Each batch becomes a single external_call("evm", batchPayload) invocation.

      • Conflicting transactions are deferred to subsequent batches.

      • The highest-priority transactions receive guaranteed inclusion.

        This reduces contention by avoiding a state-root update for every individual transaction, enabling multiple inflight submissions without invalidation.

    • Performance vs. Composability trade-off:

      • Independent Parallelism → highest throughput, but state is isolated per context.
      • Composable Parallelism → shared state and cross-contract composition, but with structured batching to mitigate contention.

    • Deterministic conflict handling:

      Because batching is performed deterministically, all participants replay the same batch boundaries and produce identical post-state roots. If any batch diverges, the entire Canton transaction aborts before commit.

    • Scalable path for future enhancements:

      The batching model is compatible with optional refinements such as pre-execution write-set detection (“witness generation”), storage-slot prioritization, and advanced scheduling heuristics. These can further minimize conflicts while preserving Canton’s deterministic semantics.

    • High-fidelity testing via public-chain resequencing:

      To validate correctness and parallelism safety, we will re-sequence real Ethereum mainnet blocks (or another public EVM chain) through the Canton EVM pipeline. This ensures that batching, conflict resolution, and commit rules remain compatible with real-world EVM transaction flows and do not break under adversarial or high-contention workloads.

    This hybrid model enables Canton to support high-throughput EVM workloads: scaling horizontally via multi-context sharding and vertically via deterministic sequencing and batching within a single context.

    Observability

    • Metrics export: latency (p50/p95), throughput, deterministic error rates, state size, gas usage, and bridge latency/success counters.
    • Structured logging: Each transaction emits structured JSON logs compatible with both Ethereum and Canton analytics.
    • Indexing: The Sidecar maintains a minimal event index suitable for eth_getLogs filtering and internal reward tracking.
    • Dashboards: Validators and application developers can monitor execution via standard Prometheus endpoints or Grafana dashboards connected to participant metrics.

    Timeline

    Technical Enablement Milestones

    1. Technical Discovery & System DesignConduct deep-dive research and architectural planning to align with Canton’s roadmap and Zenith primitives. Define complete integration model between Canton participants and the Erigon EVM service via external_call(). Deliverables: • System design document (Canton ↔ Erigon integration) • Specification of EVMContext contract model and privacy handling • Key mapping design (Ethereum ↔ Canton Party identities) • RPC and bridge interface definitions • Dependency analysis on external_call() and verify() Acceptance Criteria: • Architecture reviewed and approved by ≥2 Canton validator teams • Integration boundaries and determinism requirements validated by prototype outline • Risk and performance report finalized2 months from CIP approval
    2. external_call() Integration and EVM Execution Proof-of-ConceptImplement a prototype linking Canton’s participant node to a local Erigon service via external_call("evm", …). Demonstrate deterministic execution of EVM transactions under Canton consensus. Deliverables: • Working PoC of Canton–Erigon call pipeline • Deterministic execution verified across ≥3 participants • Privacy propagation confirmed within Canton scopes Acceptance Criteria: • Deterministic state root agreement across all participants • Transaction replay consistency validated • Latency under 1s for single transaction4 months from CIP approval
    3. Ledger Binding and RPC Proxy ImplementationIntroduce the on-ledger EVMContext contract type and the Sidecar RPC Proxy for Ethereum tool compatibility. Enable contract deployment and invocation through standard Ethereum JSON-RPC methods. Deliverables: • Deployed EVMContext contract • Sidecar RPC proxy with eth_call, eth_sendRawTransaction, eth_getTransactionReceipt, eth_getLogs • Integration tests with MetaMask, Hardhat, and Foundry Acceptance Criteria: • Full ERC-20 and ERC-721 lifecycle supported • Deterministic transaction replay under Canton consensus • RPC latency < 500ms (p95)6 months from CIP approval
    4. Public Testnet LaunchDeploy public testnet demonstrating end-to-end Canton–EVM execution. Provide faucet, RPC gateway, and monitoring dashboard. Deliverables: • Public testnet with ≥3 validator nodes • Faucet service for EVM transactions • Metrics and event indexer dashboard Acceptance Criteria: • ≥1,000 successful deterministic transactions • No state divergence among participants • Open developer access via standard Ethereum tooling7 months from CIP approval
    5. Mainnet Enablement and Governance ReviewPrepare for mainnet rollout following testnet validation and Zenith dependency availability. Conduct governance review and readiness audit. Deliverables: • Finalized deployment guide and validator configuration • Governance proposal for mainnet activation • Reward marker and audit integration with Global Synchronizer Acceptance Criteria: • Successful dry run on staging network • Validator acceptance for production • Governance approval of CIP activation8 months from CIP approval

    Ecosystem & Adoption Milestones

    MilestoneDeliverablesDeadline
    6. Enterprise Deployment WaveLaunch at least 2 enterprise-grade Canton–EVM applications in production (e.g., RWA issuance, settlement, payments). These deployments must generate meaningful economic activity, such as $5M+ in assets issued/settled, ongoing transaction flows, and initial Canton Coin burn resulting from execution and settlement activity.Within 3 months after mainnet
    7. Economic Activity Ramp-UpDemonstrate growing on-chain usage: achieve 2+ sustained TPS, accumulate $20M+ TVL or settlement volume, reach 20,000+ monthly transactions, and generate a measurable daily CC burn rate driven by EVM execution and bridge operations.Within 6 months after mainnet
    8. Developer & Ecosystem ScalingExpand developer adoption with at least 10 external teams launching Canton–EVM apps and 5+ open-source tooling contributions (indexers, SDKs, bridges, analytics). Directly increase network activity and ecosystem velocity. This should including $10M+ new TVL onboarded, additional monthly active users, and a sustained increase in Canton Coin burn driven by elevated execution and settlement activity.Within 9 months after mainnet
    9. Cross-Chain Integration LaunchDeliver one production-grade Canton ↔ external EVM chain integration, enabling $50M+ cross-network value flow (asset transfers, settlement, or messaging), contributing to sustained CC burn and cross-chain economic activity.Within 12 months after mainnet

    Motivation

    The Canton Network was designed to provide privacy-preserving, interoperable smart contract execution for regulated and institutional use cases. Its current execution model, centered on Daml, delivers strong guarantees of correctness and atomicity but remains largely isolated from the broader Web3 developer community.

    Meanwhile, the Ethereum Virtual Machine (EVM) ecosystem represents the dominant runtime for decentralized applications, with the largest global developer base, mature tooling, and extensive network effects.

    Introducing EVM compatibility through the external_call() mechanism and Erigon integration bridges this divide. It allows Canton to serve as the consensus and settlement layer for EVM transactions, executing standard Solidity contracts deterministically under Canton’s privacy and governance guarantees.

    This eliminates the need for protocol modifications or code rewrites—developers can deploy existing Ethereum-based applications such as DeFi protocols, tokenization platforms, and data oracles directly onto Canton with minimal friction.

    From a network perspective, this capability creates a new source of transactional and reward-generating activity. Each EVM execution validated through the Global Synchronizer contributes measurable transaction volume, supporting network rewards and incentivizing validator participation.

    It also opens the door to private and compliant DeFi, confidential enterprise settlement, and cross-chain asset flows—use cases not possible on public EVM networks.

    Finally, integrating EVM execution through Erigon’s privacy-aligned runtime solidifies Canton’s role as a polyglot execution and coordination layer, where diverse contract environments share a single identity, consensus, and compliance framework.

    This proposal therefore positions Canton as the institutional coordination hub for the EVM ecosystem, combining Ethereum’s open innovation layer with Canton’s regulated settlement infrastructure.

    Rationale

    This proposal adopts the Erigon + external_call() integration model because it provides the most modular, deterministic, and future-proof path to introduce EVM compatibility within Canton without altering its consensus or privacy architecture.

    The objective is to enable Solidity contract execution under Canton’s deterministic transaction model while maintaining alignment with its authorization, privacy, and settlement semantics.

    Alternative Approaches Considered

    • EVM-in-WASM (Rust-EVM compiled to WebAssembly):

      Running an embedded EVM interpreter as a WebAssembly module was considered for conceptual simplicity and potential cross-language uniformity. However, this method would depend on Canton’s not yet implemented WASM host environment and provide limited control over execution semantics. It was therefore deprioritized in favor of an immediately viable integration path.

    • Solidity Recompilation (via Solang):

      Translating Solidity contracts into another runtime format, such as WebAssembly, was explored but dismissed due to incompatibilities with core Solidity features and a lack of full parity with Ethereum’s EVM behavior. This would have prevented seamless onboarding of existing contracts and tools.

    Chosen Architecture: Erigon + external_call()

    The selected approach leverages Erigon as a local EVM execution service invoked through Canton’s upcoming external_call() primitive.

    Each Canton participant can deterministically call its Erigon instance within a transaction, ensuring every validator executes the same EVM computation and produces identical outputs.

    Canton remains the single source of ordering and finality, while Erigon provides fully compliant EVM execution semantics.

    Backwards compatibility

    This proposal introduces no breaking changes to existing Canton protocol behavior, transaction semantics, or consensus logic.

    The EVM integration is implemented entirely as an additive extension, leveraging the forthcoming external_call() primitive to interact with a local Erigon node.

    No modifications are required within Canton’s core runtime, ledger model, or Daml language semantics.

    Participation in EVM execution is fully optional: domains and participants that do not enable the EVM integration will continue operating unaffected.

    All EVM-related components—such as the sidecar RPC proxy and Erigon node—are modular services deployable alongside existing Canton nodes without altering network interoperability or consensus pathways.

    Reference implementation

    The reference implementation will be developed and maintained by Gateway FM, in collaboration with participating Canton node operators and the Global Synchronizer Foundation.

    It will be delivered as a modular extension to the Canton participant node, designed to integrate with the Canton runtime via the upcoming external_call() interface once it becomes available.

    Until then, a local stub implementation will be used for testing deterministic EVM execution.

    The reference codebase will include the integration logic required to orchestrate transaction ordering, state persistence, and validation using Canton as the consensus and settlement layer, while relying on a modified Erigon client for execution.

    Copyright

    This CIP is licensed under CC0-1.0: Creative Commons CC0 1.0 Universal

  2. #2Alex Chen12-01-2026source ↗
    Hi Andrew and Gateway team, thanks for your submission. We're currently reviewing this carefully given the technical nature of the CIP.

    It may be helpful to separate this CIP into 2 parts - with the timeline of Technical Enablement Milestones as a submission to the Dev Fund (which is in the process of being assessed) and the rest of the technical Specification as an implementation CIP.
     
    To the TWG, would be it helpful to loop in the Tech Ops Committee to assess the (i) technical feasibility and (ii) how reasonable the standards are?
     
    Kind regards,
    Alex
     
    --
    Cumberland
  3. #3Norbert Vadas25-01-2026source ↗

    Hi GSF members,

     

    At Zenith, we have been working on building an EVM compatibility solution under CIP-0091 for Canton, and find it important to give our perspective on Gateway's above CIP hoping that it contributes to its better understanding and evaluation.

     

    First of all, a quick update on the external_call primitive we are adding to Daml: The PR has been submitted in December, following which we had in depth discussions with the DA team, and received very valuable feedback on it. We've implemented the necessary changes and additions and have been testing them in the past weeks. The PR revision along with a detailed design document will be submitted very soon. With this, we hope that the PR could be merged and external_call rolled out to the Canton TestNet in the coming weeks to allow Zenith's testnet to go live, spanning Canton and Zenith's EVM environment.

     

    In the past 8-10 months we've been dedicating our entire company’s time and resources to design and build the EVM-compatibility solution with atomic composability across native Canton applications and EVM apps, along with the external_call  primitive that enables this.

     

    Gateway's CIP basically proposes an identical solution to what is already being built by Zenith, with the two key differences being:

    • Zenith uses the Reth client while Gateway uses the Erigon client for EVM execution, and 
    • Zenith also introduces zero-knowledge proofs to make all EVM state transitions verifiable directly on Canton in a trustless way. This is something that Gateway does not have.

    Erigon is a long-existing technology, and this CIP is proposing to use the external_call primitive built by Zenith to facilitate interaction between Canton and the EVM.

     

    Considering this, Gateway’s CIP brings very little actual technical innovation to Canton, therefore we propose that all weight-carrying deliverables of this CIP be purely business-based milestones. No technical milestones seem to be justified based on the reasons mentioned above.

     

    Furthemore, if an Erigon-based EVM solution is something that Canton would like to pursue, Zenith and Gateway should collaborate on the implementation to avoid redundant/replicated work and ensure high-level compatibility.

     

    While there are some benefits in multiple implementations, we feel they are outweighed by negative effects of duplicating work in a time where Canton is working to reduce emissions, as well as the general compatibility issues that are likely to emerge. Instead, Gateway could be working with us, build on Zenith's EVM stack for Canton, and integrate the Erigon stack directly into Zenith to ensure compatibility. We’d be happy to collaborate with them on this.

     

    We are grateful to all governing SVs for considering our perspective.
    Best regards,

    Norbert