CIP-0091: Add Zenith as an SV of max weight 10 | CIP Discussion

DrAmandaLMartinOriginal post

Oct 28, 2025

Hello all,

This CIP has undergone a re-write. Please see below open for discussion.

----

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

CIP: CIP 00XX

Title: Add Zenith as an SV of Weight 10

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 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:

The external_call() function: It allows Canton contracts to call a deterministic external, locally running service and receive results from it. It is used to confirm the result of native execution back to Canton for the atomic transaction confirmation, and it can also be used to convey the result of ZK-proof verification.
A verify() function: It 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, or 2. by 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 an EVM-based VB

* Implement verify() function in Daml

* Deploy VB on Canton TestNet, interacting with Zenith Testnet

+ 4 months from CIP Approval

Demonstrated composability on Mainnet

* Deploy VB on Canton Mainnet, interacting with Zenith Mainnet

* Deploy an asset on a VB and compose with a Daml-native stablecoin through an existing Daml-native DEX (assuming such a DEX exists and as agreed upon with the Accountability Committee) into an atomic swap.

+4 Months from MVP

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 Mainnet delivery	+ 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 Mainnet delivery	+ 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 Mainnet delivery	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 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 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.

Eric Saraniecki

Oct 28, 2025

hi everyone - I think many of you have a seen a few previous version of this

I helped modify the draft to this version for the following reasons:

1. If Zenith can pull off the Demonstrated Composability milestone, it would be an incredible achievement and a big unlock for the ecosystem. That would mean that EVM apps can co-exist with Daml apps and both slot into the existing Daml ecosystem.

2. It will be unpredictable as to how that would get adopted (I'm assuming quite well but not sure which dimensions) so I suggested simplifying the adoption milestones to number of high profile deployments, burn, and TVL

3. The adoption milestones are predicated on demonstrating the composability - without that composability, random EVM apps could fragment the app ecosystem so I wouldn't want to reward adoption of something that could be harmful to overall experience of the network

big thank you the Zenith team for going through so many versions of this and staying committed and willing to take on the challenge

Show quoted message

On Tue, Oct 28, 2025 at 2:56 PM DrAmandaLMartin via lists.sync.global <amartin=linuxfoundation.org@...> wrote:

Hello all,

This CIP has undergone a re-write. Please see below open for discussion.

----

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

CIP: CIP 00XX

Title: Add Zenith as an SV of Weight 10

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 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:

The external_call() function: It allows Canton contracts to call a deterministic external, locally running service and receive results from it. It is used to confirm the result of native execution back to Canton for the atomic transaction confirmation, and it can also be used to convey the result of ZK-proof verification.

A verify() function: It 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, or 2. by 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 an EVM-based VB

* Implement verify() function in Daml

* Deploy VB on Canton TestNet, interacting with Zenith Testnet

+ 4 months from CIP Approval

+1

Demonstrated composability on Mainnet

* Deploy VB on Canton Mainnet, interacting with Zenith Mainnet

* Deploy an asset on a VB and compose with a Daml-native stablecoin through an existing Daml-native DEX (assuming such a DEX exists and as agreed upon with the Accountability Committee) 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 Mainnet delivery

+ 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 Mainnet delivery

+ 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 Mainnet delivery

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

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

Justin Peterson

Oct 28, 2025

I agree. It would be an incredible and well-received contribution.

toggle quoted message Show quoted text

From: cip-discuss@... <cip-discuss@...> On Behalf Of Eric Saraniecki via lists.sync.global
Sent: Tuesday, October 28, 2025 3:02 PM
To: cip-discuss@...
Subject: Re: [cip-discuss] CIP-TBD: Add Zenith as an SV of max weight 10

CAUTION:This email originated from outside of Tradeweb. Do not open attachments or click on links if you do not recognize the sender or if the content appears unsafe/you cannot verify the content is safe.

hi everyone - I think many of you have a seen a few previous version of this

I helped modify the draft to this version for the following reasons:

big thank you the Zenith team for going through so many versions of this and staying committed and willing to take on the challenge

On Tue, Oct 28, 2025 at 2:56 PM DrAmandaLMartin via lists.sync.global <amartin=linuxfoundation.org@...> wrote:

Hello all,

This CIP has undergone a re-write. Please see below open for discussion.

----

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

CIP: CIP 00XX

Title: Add Zenith as an SV of Weight 10

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 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:

The external_call() function: It allows Canton contracts to call a deterministic external, locally running service and receive results from it. It is used to confirm the result of native execution back to Canton for the atomic transaction confirmation, and it can also be used to convey the result of ZK-proof verification.
A verify() function: It 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, or 2. by 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 an EVM-based VB

* Implement verify() function in Daml

* Deploy VB on Canton TestNet, interacting with Zenith Testnet

+ 4 months from CIP Approval

+1

Demonstrated composability on Mainnet

* Deploy VB on Canton Mainnet, interacting with Zenith Mainnet

* Deploy an asset on a VB and compose with a Daml-native stablecoin through an existing Daml-native DEX (assuming such a DEX exists and as agreed upon with the Accountability Committee) 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 Mainnet delivery

+ 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 Mainnet delivery

+ 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 Mainnet delivery

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

________________________________________________________________________

The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.

Tradeweb reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Tradeweb e-mail system.

SV Reward Mechanics:

Copyright

Changelog

SV Reward Mechanics:

Copyright

Changelog

SV Reward Mechanics:

Copyright

Changelog

Leave a reply