CIP - 0091 - Add Zenith as an SV of max weight 8.75

• Canton participants to run EVM execution environments (and in the future other VMs, like SVM, etc.), deployed as Canton Virtual Blockchains (VBs) on Zenith, that can interoperate with Canton subnets, and be verifiably settled on Canton.
• developers to build DeFi and other applications on Canton VBs using standard EVM tooling (Solidity, Hardhat, etc.),
• users to submit EVM transactions and interact with EVM-based Virtual Blockchains directly from the Canton Network (through Canton transactions), and
• Canton subnets to connect to other ecosystems.

CIP-00XX: Add Zenith as an SV of Weight 8.75

CIP: CIP 00XX

Title:  Add Zenith as an SV of Weight 8.75

Author: Norbert Vadas norbert.vadas@...
Teemu Paivinen teemu@... 

Heslin Kim heslin.kim@...

Henri Kamarainen henri.kamarainen@...

Status: Draft

Type: Governance

Created: 2025-10-17

License: CC0-1.0

Abstract:

• Add Zenith as a Super Validator (SV) of weight 8.75, with the majority of the weight reachable through growth and adoption KPIs.

• Zenith commits to building a solution enabling participants in the Canton Network to run execution environments using arbitrary VMs (EVM, SVM, MoveVM etc.) deployed as Canton Virtual Blockchains (VBs) on Zenith, that can interoperate with Canton subnets, and be verifiably settled on Canton. VBs provide: 

• A multi-VM execution environment with atomic transaction confirmations and subsequent zero-knowledge proof (ZKP)-based settlement and finality on Canton.

• Trust-minimized execution by verifying ZK proofs of correct VB state transitions directly in Daml contracts, ensuring integrity and settlement on Canton Network.

• This provides a trust-minimized solution between Canton and smart contracts running inside VBs, allowing Canton participants to run composable EVM- or SVM-compatible environments as VBs.

Motivation:

Based on the Polyglot Canton Whitepaper, the following are key priorities of Canton Network:

• Increased developer accessibility (through other languages, including Solidity or Rust),

• EVM compatibility

• Privacy

• Regulatory compliance

To address these priorities, we propose Virtual Blockchains (VBs) as a natural extension of Canton’s Polyglot strategy. Each Canton participant can operate a permissioned, EVM-compatible VB in their own domain.

• Virtual blockchains extend Canton with EVM compatibility and provide atomic transaction confirmations and ZK-proof-based settlement and finality on Canton.

• Institutions and enterprises retain privacy, regulatory compliance, and control by operating their own permissioned VBs.

• Developers gain native Solidity support with familiar Ethereum tooling.

In the future, VBs can also be launched with other VMs, such as SVM, allowing compatibility with various prominent ecosystems.

By integrating Zenith, Canton gains:

1. Composability

Zenith extends Canton with an EVM execution environment (with other VMs in the future), enabling participants to run different runtimes (EVM, SVM, MoveVM, etc.) inside Virtual Blockchains (VBs) that are directly interoperable with Canton subnets. Transactions initiated on Canton can span both Canton and VBs, triggering actions in the VB runtime with atomic transaction confirmations and subsequent ZKP-based settlement and finality.

Daml remains the canonical privacy and authorization layer. VBs are adapters that expand developer reach while settling into Canton through ZK-verified state roots. This approach allows Canton to attract builders from different blockchain communities without compromising Canton's consistency and confidentiality.

• This expands developer accessibility by supporting Solidity, Rust, and other languages, reducing the Daml learning curve, and attracting builders from different blockchain communities (Ethereum, Solana, Cosmos).

• Enterprises and developers can select the runtime best suited to their use case (e.g., EVM for general-purpose apps, SVM for high-throughput DeFi).

• Zenith’s permissioning model allows VBs to be operated as:

• Private isolated environments for enterprise use cases,

• Private multi-network deployments,

• Public permissionless VBs, or

• Whitelisted permissioned networks.

• Canton VBs can also serve as mirror environments for existing Web2 systems or Web3 dApps, enabling seamless multi-network interoperability.

2. Interoperability:

Zenith’s solution is built to allow Canton to house native environments. It enables two-way transaction flows between Canton subnets and VBs, with VB state roots verifiably committed back into Canton.

• Transactions spanning Canton and VBs remain atomically confirmed and gain finality with ZKPs being verified directly in Daml contracts.

• This minimizes reliance on fragile bridges and reduces systemic risk, while also meeting enterprise-grade security and compliance requirements.

3. Performance:

Zenith is purpose-built to allow for off-chain parallelization and horizontal sharding for VB execution, verified through zero-knowledge proofs:

• Horizontal sharding allows Canton to scale linearly by adding Canton Virtual Blockchain shards, supporting unbounded TPS volumes. It also enables shard-specific execution channels for segregating data streams.

4. Accessibility:

Both Haskell and Scala are non-native development languages for crypto developers. Canton can ease onboarding and scale its Web3 dApp ecosystem by opening up accessibility with Zenith’s RISC-V execution layer, liberating Canton’s Web3 potential and providing direct access to execution environments built on different VMs.

Summary:

Zenith’s solution—encompassing an EVM runtime (with other VMs in the future), composability, trust-minimized execution and settlement, ecosystem expansion, off-chain parallelization, and horizontal sharding—aims to further strengthen Canton Network’s position as a powerful "network of networks.”

Value and utility alignment with $CC

Virtual Blockchains (VBs) interacting with Canton can directly increase the utility and value of the Canton Network’s native token, $CC, by integrating it into their operational and settlement flows.

The mechanisms below could further strengthen the alignment of VBs with Canton:

• Burning of transaction fees: Daml contract calls that initiate interaction with a VB, and the interaction with a Daml contract to settle the VB’s state roots on Canton require the payment of transaction fees in $CC. These transaction fees could be burned to align with Canton’s burn-mint model and contribute to maintaining the burn-mint equilibrium.

• Native token for VBs: VBs could be launched with $CC as their native asset, allowing users to pay fees and sequencers to collect rewards in $CC. By using $CC as a native token, VB operators could reduce regulatory friction, using a standard asset already integrated across the network. A portion of the network fees on the VB can also be burned as part of the VB block finalization.

• Economic security for settlement:

• If multiple Canton participants act as VB operators, they could be required to stake $CC as economic security to ensure honest behavior and transaction inclusion.

These mechanisms could ensure that the growth of VBs extending Canton also drives demand and value for $CC. We are happy to explore other avenues to further align with Canton and the $CC token.

About the Applicant:

Zenith Network:

Zenith is a MiCA-compliant, RISC-V-based protocol for deploying Canton Virtual Blockchains (VBs). Virtual Blockchains are fully programmable blockchain environments deployed on Zenith as RISC-V programs, executed in RISC Zero’s zkVM, R0VM, and settled to Canton.

Virtual Blockchains enable different runtime environments to run off-chain, with cryptographic proofs ensuring the correctness of state transitions and execution. In the case of an EVM-based VB, by compiling Reth to run within the R0VM, we achieve full compatibility with standard Ethereum tooling (e.g., Solidity, Hardhat, Remix, Metamask), while moving execution off-chain and still maintaining trustless security guarantees through ZK proofs.

The team building Zenith:

Zenith, built by ZkCloud, has its headquarters in Helsinki, Finland. It spun out of Equilibrium Labs, an R&D studio founded in 2017 and focused on the hardest engineering problems around security, privacy, and scaling of the decentralized web, with a team of over 100 talented individuals. The Labs has worked with some of the Web3 industry's top companies, such as Ethereum Foundation, Fireblocks, Solana Foundation, Zcash, and more.

Equilibrium Labs, creator of Zenith and Membrane Finance, has proven itself as a trusted R&D studio through Paxos' acquisition of Membrane Finance on February 4, 2025. By operating and launching the MiCA-compliant EUROe stablecoin, regulated by Finland's Financial Supervisory Authority, Equilibrium Labs enabled Paxos to gain Electronic Money Institution status in the EU, showcasing its expertise in regulatory-compliant financial infrastructure.

Specification:

Zenith empowers Canton with an EVM execution environment (other VMs in the future), featuring atomic transaction confirmations, subsequent ZK-proof-based transaction settlement and finality on Canton, and interoperability with other ecosystems, such as Ethereum, Base, or Solana.

Canton participants can run their own virtual blockchains, with different runtime environments, such as EVM or SVM. Every VB block produces a zero-knowledge proof (ZKP) that certifies the correct execution of all state transitions. These proofs are verified by a Daml contract on Canton, which records the new VB state root.

• As an example, by operating an EVM-based VB, Canton participants can deploy applications written in Solidity, use familiar tooling, e.g. Hardhat or Metamask, and execute the app inside the VB’s EVM runtime, just as they would do on Ethereum. All VBs are going to be natively interoperable on Zenith, and they can interoperate with other ecosystems through IBC.

By verifying proofs of VB execution directly in the Daml contract, VBs provide a trust-minimized solution for transaction execution and settlement across both environments.

The concept of Virtual Blockchains fits well with Canton’s “network of networks” design and aligns with the privacy model of Canton subnets: the Canton participant running the Canton subnet also operates the VB in a permissioned way and acts as the sequencer of the VB.

Trusted execution model

The Canton participant serves dual roles:

• Operates a node in the Canton subnet, listening to transactions submitted by users on Canton,

• Operates the VB, acting as the VB’s sequencer, ordering and executing EVM transactions. (In the case of private VBs, the VB operator also generates the proof for the VB block.)

The model provides the following execution guarantees:

• Native EVM transaction execution for optimistic confirmation, followed by all state transitions of the VB being proven and verified through ZK proofs.

• Sequential, single-threaded EVM semantics (consistent with Ethereum).

• As long as the trusted entity (Canton participant/VB operator) acts honestly, the native EVM execution and execution within the zkVM to generate the proof will result in the same new state root.

• No state contention due to rejection of conflicting transactions by the VB operator.

VB block building dynamics:

• When there are no incoming transactions, no new VB blocks are built.

• When transactions are submitted to the VB, block building can be triggered at configurable time intervals or upon reaching a certain gas utilization/limit.

Extensions needed in Daml

The following new primitives will be implemented in Daml:

1. An external_call() function in Daml

• Allows Canton contracts to call a deterministic external, locally running service and receive results from it.

• Required for confirming the result of native execution back to Canton, and also to convey the result of ZK-proof verification until the verify() function is available.

• Follows Canton’s native two-step validation process.

1. The submitter executes the function during interpretation and includes the result (and optionally its hash + metadata) as part of the transaction view.

2. Each validator re-executes the same external_call() locally.

3. If any validator obtains a different output, validation fails, mirroring the same determinism rule as for any existing Daml primitive.

2. A verify() function for ZK-proofs in Daml

• Adds native verification capability for zero-knowledge proofs generated for the VB’s state transitions, by implementing a verify() function.

• Ensures Canton contracts can verify the integrity of VB state roots settled to Canton.

Process flow for transactions spanning Canton and a VB

1. Transaction submission

• • Users submit transactions via Canton.

  • When interaction with an EVM-based Virtual Blockchain (VB) is required, each tx includes a signed EVM transaction payload.

2. Native execution and transaction confirmation

• • The Canton participant, who also operates the VB sequencer, collects these transactions and executes them sequentially in the VB’s native EVM runtime.

  • For each transaction:

    • If it touches a piece of state already modified by a previous tx in the same batch, it is rejected (to avoid contention).

    • Otherwise, it passes an optimistic transaction confirmation to Canton. This confirmation is atomic and part of the initial transaction flow triggered by the user via Canton.

  • At this stage, it is a soft confirmation (not yet backed by a ZK proof).

3. VB block production and settlement

• • Every ~30 seconds (configurable as mentioned above), the VB operator bundles a batch of transactions into a block and triggers block creation for the VB on Zenith.

  • The block is executed, and a new VB state root is produced, along with a ZK-proof proving the state transition from old-root to new-root. The VB block also includes a list of Canton-related events (e.g., “A sends CC to B”) and Merkle proofs that tie those events into the new-root.

  • The proof is submitted back to Canton, where it is verified natively in the Daml contract.

  • The VB block is settled on Canton, and the earlier optimistic transaction confirmation is substituted with the results of the ZK proof verification, providing hard confirmation and finality.

Until the verify() function is in place, the ZKPs can be verified by the Daml contract using the external call functionality. Alternatively, ZKPs could be simply stored on-chain and verified by a whitelisted quorum of participants.

Deliverables for full SV Reward:

The proposed framework allocates a results-driven total potential weight of 8.75 across two key areas: Integration (3.75), and 0-to-1 Growth and adoption weights (5).

1. Integration deliverables (max. weight of 3.75): develop and integrate a robust infrastructure that allows Canton subnets to have access to and interoperate with VBs with atomic transaction confirmations, and subsequent ZKP-based settlement on Canton.

2. 0 to 1 Growth and adoption weights (max weight of 5): Zenith will drive adoption and real-world impact through measurable growth metrics.

Zenith is also committed to fostering collaboration and driving ecosystem growth by actively participating in the Global Synchronizer Foundation and joining committees related to technology, tokenomics, and marketing.

Rationale:

Zenith’s proposal is a performance-based plan that ties rewards to tangible outcomes. By focusing on ambitious yet achievable KPIs, we aim to:

• Solve critical technical challenges (composability, interoperability, performance).

• Drive enterprise and institutional adoption not only on Canton subnets but also on Canton Virtual Blockchains, positioning Canton as a leader in both Web2 and Web3 circles.

• Minimize risks for the Canton Foundation by ensuring our Super Validator reward model and product integration are directly tied to long-term alignment and ecosystem growth.

Zenith is committed to earning its place as a Super Validator by delivering transformative results for the Canton ecosystem. Our weighted value framework ensures accountability, aligns incentives, and drives adoption for both Canton Network and Canton Virtual Blockchains. We look forward to your feedback and collaboration regarding this proposal.

SV Reward Mechanics:

Zenith will implement the following mechanics both for itself, and for all other Super Validators whose SV weights are contingent on completion of specified contributions, following similar mechanics:

• An extraBeneficiary PartyID associated with the ‘escrowed’ Super Validator will be set up by the GSF with an SV Weight at the maximum earnable weight in the CIP that granted rights to that Super Validator.
  

• • The Applicant is responsible for all costs associated with the operation of the escrow SV

  • The escrow SV will NOT mint rewards on a block by block basis

  • All escrow SV rewards will go to the Unclaimed Rewards pool
    

• ⅔ of the Super Validator Operators will update their configurations to allow GSF to host the full weight to be earned by the given Super Validator
  

• Applicant is required to present proof of successfully completed milestones to the Tokenomics Working Group
  

• • Applicant is required to present a calculation for number of Canton Coin it should earn for meeting the requirements of the milestone
    

• If the Tokenomics Working Group agrees the milestone has been met and agrees with the calculation, an announcement will be sent via the Tokenomics-Announce mailing List

• • The GSF will update the extraBeneficiary to an active PartyID controlled by that Super Validator.

  • ⅔ of Super Validator Operators will then assign a portion of the Unclaimed Rewards to be minted by the Applicant’s Validator, based on the calculation approved by the Tokenomics working group.
    

• If any milestones and associated rewards are not achieved by the deadline

• • Applicant will be notified that they have not met a deliverable by the GSF

  • Remaining SV Weight assigned to the extraBeneficiary SV will be removed from the GSF node configuration, and the total SV weight of the GSF SV node will be reduced by the same amount by a vote of the Super Validators.

  • The Tokenomics Working Group will make a recommendation to the SVs on what to do with the Unclaimed Rewards.
    

• Applicant is subject to CIP-0045 : SV Operating Requirements

• • If, at any time, the Applicant has been rewarded SV Weight > 2.5, they are required to operate their SV within 6 months of crossing that Weight. This SV node will join the network with an SV weight of zero (0) and may add weights as the SV completes the milestones listed in this CIP.

Copyright

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

Changelog

• 2025-10-17: Proposal draft