Mailing Lists/CIP - 0091 - Add Zenith as an SV of max weight 8.75Source on lists.sync.global ↗

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

cip-discuss5 messagesstarted 17-10-2025
Also mentions:CIP-0045
  1. #1Norbert Vadas17-10-2025source ↗
    Dear GSF Members,

    Please find below and attached our proposal "CIP-00XX: Add Zenith as an SV of weight 8.75", open for discussion. Please note that this proposal supersedes the previous one submitted on 2 September. The scope has been revised significantly based on the discussions we had with the Digital Assets team, hence, we are submitting a new proposal as advised.

    At Zenith, we propose to build a solution enabling:
    • 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.
    While we propose a max weight of 8.75, the majority of the weight is reachable through performance and adoption KPIs.

    We hereby request your feedback, as well as your support and endorsement for our draft CIP.
    Please do not hesitate to reach out to us with any questions you may have.

    Thank you very much,
    Norbert

    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.

    1. 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.

    1. 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.

    1. 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.

    1. 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.

    1. 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).

    1. 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.

    Deliverable

    Acceptance Criteria

    Deadline

    Weight Earned

    1. Demonstrate transaction processing between Canton and an EVM-based VB, with settlement on Canton, including the implementation of the external_call() function in Daml (in three phases)

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    Phase 1:  

    • Implement the external_call() function to Daml

     
    Phase 2: 

    • Demonstrate a transaction spanning Canton and the VB: including transaction queue, native EVM execution, atomic transaction confirmation, and settlement through the new VB state root being exposed to Canton. 

    • No proving and verification yet. 

     

    Phase 3: 

    • Demonstrate a transaction spanning Canton and the VB: including transaction queue, native EVM execution, atomic transaction confirmation, and settlement on Canton with off-chain proof verification. 

    • Proof verification is done by the Canton participant off-chain, with verification results being posted to Canton through the external_call() function.

     
     
     
     

    4 months from CIP Approval  


    4 months from CIP Approval

     

     

     

     

     

    4 months from CIP Approval

     

     

     

     

     

     

     

     

     

     

    0.25 

     
     
     

    0.25

     

     

     

     

     

     

     

    0.25

     

     

     

     

     

     

     

     

     

     

     

    2. Demonstrate transaction processing between Canton and an EVM-based VB, with settlement on Canton, including the implementation of the verify() function in Daml

    • Implement the verify() function to Daml to allow native ZK-proof verification in Daml contracts 

    • Demonstrate a transaction spanning Canton and the VB: including transaction queue, native EVM execution, atomic transaction confirmation, and ZKP-based settlement on Canton with proof verification performed directly in the Daml contract.

    4 months from CIP Approval

     

     

     

     

     

    0.5

     

     

     

     

     

     

    3. Launch a public beta testnet with transaction processing between Canton and an EVM-based VB, with settlement on Canton

    • The testnet includes a faucet on Canton and is open publicly for anyone to test the functions as described above (see milestones 1 and 2).

     
     

    3 months from the completion of milestone 2

     

     

     

    1

     

     

     

     

    4. Mainnet for EVM-based VBs:  with transaction processing between Canton and an EVM-based VB, with settlement on Canton.

    • Mainnet deployments for EVM-based VBs, as described in the Specification section, featuring atomic transaction confirmations between Canton and VBs (optimistic), and subsequent ZKP-based settlement and finality on Canton, with proof verification directly done by the Daml contract.

    5 months from completion of testnet (milestone 3)

     

     

     

    1.5

     

     

     

     

     

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

    Deliverable

    Acceptance Criteria

    Deadline

    Weight Earned

    Enterprise and institutional pilots

    • Onboarding at least 20 enterprise or institutional entities to deploy VBs through submission-based criteria, with approved eligibility determined by the Canton Foundation.

    Within 24 months of EVM-based mainnet delivery.

    0.25 weight per batch of 5 committee-approved Virtual Blockchain (VB) pilots (up to a weight of 1).

    Canton Coin Integration

    • Contribute to the burning of at least $10 million $CC annually.

    Within 18 months of EVM-based mainnet delivery.

    0.5

    Transactions per second (TPS)

    • 1 TPS of transactions originated in Canton and triggering an event on a VB.

    Within 12 months of EVM-based mainnet delivery.

    0.5

    Real-world assets (RWAs) issued

    • Over $1 billion in RWAs issued on Canton Virtual Blockchains.

    Within 12 months of  EVM-based mainnet delivery.

    1

    Total Value Locked (TVL)

    • Over $1 billion in TVL deposited to Canton and transferred to Canton Virtual Blockchains.

    Within 12 months of  EVM-based mainnet delivery.

    1

    Monthly Transaction Volume

    • Surpass $15 billion in monthly transaction volume across all transactions originating from Canton and triggering an action on a VB.

    Within 24 months of  EVM-based mainnet delivery.

    1


    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

     
     
  2. #2Yiannis Varelas20-10-2025source ↗
    This is significant improvement compared to what was proposed initially. 

    I also like the fact that the majority of the weight is shifted towards delivery. 

    This is a technically ambitious, high-leverage work that moves Canton forward.

    Although I'm very public on my "non-EVM" views, the reality is that 
    this proposal expands execution to multi-VM environments while maintaining
    Canton-grade privacy, settlement and overall principles, without affecting
    the actual network operations. So we can have the good without sacrificing 
    our values. 

    I'm waiting for thoughts from others here, but I think we can sponsor this.



  3. #3Norbert Vadas22-10-2025source ↗
    Dear GSF Members,

    Based on the questions received, we've added an appendix to our original proposal titled "CIP-00XX: Add Zenith as an SV of weight 8.75". 
    The "Appendix 1 - Economic Relationship between Canton and Virtual Blockchains" can be found at the end of the pdf attached to this message. There has been no change to any parts of our original proposal besides the addition of the appendix. 

    In essence, Virtual Blockchains extend Canton’s execution capacity without diverting value or utility away from $CC.

    Please do not hesitate to reach out to us with any questions you may have.

    Thank you very much,
    Norbert
  4. #4Alex Chen23-10-2025source ↗
    Thanks for this updated CIP and appendix - the changes have been positive to align the VBs and their technical workflow to Canton's tokenomics and governance. We'd like to get some clarity and suggest some changes to further refine the proposal and drive the incentives toward a successful outcome:
     
    • Change the CC Integration deliverable in growth/adoption weights to be denominated in CC to better align with CC-denominated burns on the network and avoid potential subjectivity in CC-to-USD conversion rates.
    • We'd like the Zenith team to present the solution and discuss technical roadblocks, most notably undertaking complex ETH contracts and maintaining speed in TPS / performance. This can during the weekly Tokenomics Working Group or separate call with available SVs who are also interested in the education prior to casting their vote. The latter may be more appropriate with the growing agenda in the short-term.
    Welcome any thoughts on the above. 
     
    Kind regards,
    Alex Chen
     
    Cumberland
  5. #5Norbert Vadas24-10-2025source ↗
    Thank you for your comment and suggestion, Alex.
    • CC burn amount: According to your suggestion, we've modified the burn amount in the "Canton Coin Integration" deliverable under the Growth/adoption KPIs to be 50million $CC annually (the original suggestion converted at $0.2 per $CC).
      • I am attaching the PDF including this slight modification. Everything else remains unchanged.
    • Regarding performance and scalability: The VB performance depends quite significantly on the type of EVM operations included in the VB block. We have been proving Ethereum mainnet since April 2025 (over 1.2M mainnet blocks), and the proving complexity varies based on the operations in the block, because there is an asymmetry between gas usage and proving complexity. Consequently, some operations come with significant proving overhead. However, in a permissioned VB operator setup we do not expect this to be a problem, as they would not purposefully build proving-heavy blocks creating a bottleneck for themselves.
      • Considering the average patterns of Ethereum's transaction/block composition, in the near term, we can expect to comfortably scale to 15,000-18,000 TPS across VBs with the current tech stack that we already use to prove the execution of Ethereum mainnet.
      • The performance improvements of zkVMs have been remarkable in the past 12-18 months (3-4x per quarter), and we expect this to continue in the coming 12 months at least, which could result in additional performance gains for Canton VBs on top of our broader projections.
    • We'd be glad to join the Tokenomics Working Group call to give more details. However, based on the feedback received from Eric S. (Digital Asset), we were suggested to join the working group's call once we have a sponsor for our CIP. We are currently in discussions with multiple parties about sponsorship, have endorsements from several already, and will be joining one of the upcoming calls after circling around with Eric.
    Please do not hesitate to reach out with any questions that may arise.
     
    Thank you very much,
    Norbert