Skip to content

cip-0091.md

Latest commit

 

History

History
93 lines (65 loc) · 7.25 KB

cip-0091.md

File metadata and controls

93 lines (65 loc) · 7.25 KB

CIP 0091

  CIP: CIP 0091
  Title: Add Zenith as an SV of Weight 10
  Author: Norbert Vadas,Teemu Paivinen, Heslin Kim, Henri Kamarainen
  Status: Approved
  Type: Governance
  Created: 2025-10-17
  Approved: 2025-11-04
  License: CC0-1.0

Abstract:

Add Zenith as a Super Validator (SV) of weight 10, 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 Virtual Blockchains (VBs) on Zenith, that can interoperate with Canton subnets, and be verifiably settled on Canton Mainnet.

Motivation:

Based on the Polyglot Canton Whitepaper, key priorities of Canton Network include global composability, privacy, and regulatory compliance. To address these priorities, Zenith proposes Virtual Blockchains (VBs) as a natural extension of Canton’s Polyglot strategy, enabling EVM-compatible environments with atomic transaction confirmations across Daml and EVM-compatible applications.

About the Applicant:

Zenith is a MiCA-compliant, RISC-V-based protocol for deploying Virtual Blockchains (VBs). It is developed by ZkCloud, a spinout of Equilibrium Labs in Helsinki, Finland. Equilibrium Labs has delivered products such as the EUROe stablecoin and worked with the Ethereum Foundation, Fireblocks, Solana Foundation, and Zcash.

Specification:

Zenith empowers Canton with an EVM execution environment (and other VMs in the future), providing atomic transaction confirmations across Daml and other VB-based applications, ZK-proof-based settlement and finality on Canton, and connectivity with ecosystems like Ethereum, Base, and Solana.

VBs run in a trusted execution model where the Canton participant serves dual roles:

  1. operating a node on the Canton subnet, and
  2. also acting as the sequencer or operator of the VB.

VBs use the following new primitives that will be implemented in Daml:

  • external_call() function: Allows Canton contracts to call a deterministic external, locally running service and receive results from it. It confirms the result of native execution back to Canton for atomic transaction confirmation and can also convey ZK-proof verification results.
  • verify() function: Ensures Canton contracts can verify the integrity of VB state roots settled to Canton. It can be implemented in two ways:
    1. Adding native verification capability to Daml contracts for zero-knowledge proofs.
    2. Utilizing the external_call() function to pass verification results to the Daml contract.

Deliverables for Full SV Reward:

The proposed framework allocates a total potential weight of 10 across two key areas: Integration (4) and Growth and Adoption (6).

Deliverable Acceptance Criteria Deadline Weight Earned
MVP • Demonstrate transaction processing between Canton and Zenith EVM (prev. called VB)
• Implement verify() function in Daml
• Deploy Zenith EVM testnet on a Canton Test Network (local multi-node environment)
• Submit feature-complete pull requests to the relevant upstream repositories, and receive preliminary approval from maintainers		 +4 months from CIP Approval +1
Demonstrated composability based on Canton main branch • Deploy Zenith EVM (prev. VB) on a local multi-node Canton test network built from the Canton and Splice main branches demonstrating that all needed changes have been accepted by the core developers and will be released with the next MainNet upgrade
• Deploy an asset on Zenith EVM and compose with a Daml-native asset through a Daml-native DEX deployed on the Canton test network into an atomic swap		 +4 Months from MVP +3

Growth and Adoption Weight — Predicated upon demonstration of Daml to VB composability:

Deliverable Acceptance Criteria Deadline Weight Earned
Enterprise Production Deployments Any enterprise or institution approved by the Canton Foundation that deploys > $10M of TVL on Canton via VBs. Within 12 months of the MainNet upgrade including external_call() +0.5 per approved party up to a max of +1.5
Canton Coin Burn Contribution All CC Burn attributed to VBs. Within 12 months of the MainNet upgrade including external_call() +0.5 per 10M of $CC burn up to a max of +3
Real-world assets (RWAs) issued Over $1 billion in RWAs issued on Canton Virtual Blockchains. Within 12 months of the MainNet upgrade including external_call() +1.5

Rationale:

Zenith’s proposal ties rewards to measurable outcomes, balancing technical contributions with ecosystem growth. This approach ensures accountability, alignment, and tangible value creation for the Canton ecosystem.

SV Reward Mechanics:

  • An extraBeneficiary PartyID associated with the ‘escrowed’ Super Validator will be setup by the Foundation, or another SV node operator approved to provide SV rewards escrow services, with an SV Weight at the maximum earnable weight.
    • The Applicant is responsible for coordinating the process of setting up the escrowed weights with the GSF and the operator of the SV node.
    • 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 the escrowing SV node to host the full weight to be earned by the given Super Validator.
  • Applicant is required to present proof of successful completed milestones to the Tokenomics Working Group.
    • Applicant must present a calculation for the number of Canton Coin it should earn for meeting milestone requirements.
  • If the Tokenomics Working Group agrees the milestone has been met and approves 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 approved calculation.
  • If any milestones and associated rewards are not achieved by the deadline:
    • Applicant will be notified 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.

Copyright

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

Changelog

  • 2025-10-17: Initial draft of the proposal.
  • 2025-10-28: Re-write of the proposal.
  • 2025-11-04: Approved CIP.
  • 2026-03-11: Text updated after request