SV Governance CIPs
- Hi everyoneAnother great topic that has been coming up a lot lately - SV governance.Both of these are early drafts and all feedback welcome. I would suggest we focus on the voting one prior to the operating one but I present them together because it is ultimately related.ThanksEric--
W Eric Saraniecki +1 (773) 719-1983 Co-Founder, Head of Network Strategy eric@... Creators of Canton Network
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. - hi everyonereceived some very strong feedback to find an alternative to SV Weight for Voting Weight and here is my current best idea after testing out several approaches. Feedback welcomeOn Fri, May 8, 2026 at 1:29 PM W. Eric Saraniecki <eric@...> wrote:Hi everyoneAnother great topic that has been coming up a lot lately - SV governance.Both of these are early drafts and all feedback welcome. I would suggest we focus on the voting one prior to the operating one but I present them together because it is ultimately related.ThanksEric--
W Eric Saraniecki +1 (773) 719-1983 Co-Founder, Head of Network Strategy eric@... Creators of Canton Network
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.
Thanks to @Eric for the v0.2 revision .
I am Gustav Arentoft - Leading Ecosystem for Zenith. Before joining Zenith I ran StableLab which was the first professional delegate, and one of the largest governance service providers to DeFi, L2s and L1s. We worked with teams such as AAVE, Polygon, Arbitrum, Optimism, Sky/MakerDAO, Uniswap, Compound and many others.
I would like to suggest three refinements aimed at how the voting mechanic itself functions as participation broadens beyond the current SV set. Each is framed as an amendment to v0.2 rather than an alternative model.
1. Consolidate the four-option voting model
Under the v0.2 rules:
-
Abstain counts as participation but contributes neither to quorum nor outcome
-
Do Not Vote appears not to count as participation, and contributes neither to quorum nor outcome
-
Only Yes and No count toward outcome
Do Not Vote is therefore strictly dominated by Abstain which has the same impact on quorum (none), same impact on outcome (none), but Do Not Vote is additionally counted as a missed vote for the quarterly participation requirement. There is no scenario in which a rational SV chooses Do Not Vote over Abstain. One of the problems in Governance systems is to get people to vote in the first place, so there is no scenario where someone would go through the trouble of voting without actually choosing Abstain over Do Not Vote.
Suggested amendment:
For each proposal, SVs choose one of: Yes, No, or Abstain. Failing to record any vote within the voting window is treated as a missed vote for participation purposes. We could also be in situations where SVs accidentally chose Do Not Vote and then receive the penalty for not voting.
A small simplification that removes a confusing, potentially harmful to SV’s, redundancy from the proposal.
2. Let Abstain count toward quorum
Closely related to (1). Under v0.2, an SV that participates by selecting Abstain does not contribute to quorum. As the SV set grows and participation broadens, contested or specialized proposals risk gridlock: most SVs participate (to avoid the penalty), but not enough Yes/No weight gathers to clear the 50% quorum threshold. The net effect is that the dominant strategy for any indifferent SV becomes Abstain, and the effective passage bar climbs above the stated 33% of total network weight (50% × 66.7%).
Suggested amendment — separate participation quorum from outcome quorum:
Quorum: (Yes Weight + No Weight + Abstain Weight) ≥ 50% of Total SV Voting Weight
Pass: Yes Weight / (Yes Weight + No Weight) ≥ 66.7%
This preserves the spirit of the 2/3 supermajority on the binary decision while ensuring that engaged-but-undecided participation still allows governance to function. It also produces a healthier signal: an SV that shows up and Abstains contributes to the legitimacy of the result without skewing it. If Abstain does not count towards the Quorum then essentially it can become possible to block proposals with a “neutral” vote. If an SV shows up to vote it would make sense to let that vote count towards the threshold. Imo it's better if people vote No rather than Abstain. In case a proposal fails due to too many Abstain votes, it can be difficult to understand the exact reason for the failed proposal unless explicit reasoning is given by all the Abstain votes, and even then it would be more qualitative than quantitative.
3. Open delegation to Recognized Delegates
v0.2 restricts delegation to other SVs. We'd suggest revisiting this for three reasons:
It concentrates rather than decentralizes. A popular SV becomes a delegation magnet, accumulating voting influence beyond its own stake without proportionate accountability.
It excludes the natural professional delegate market. Mature governance ecosystems (Uniswap, Optimism, Arbitrum, Compound, MakerDAO) all support delegation to non-stakeholder professional delegates — governance specialist firms, professional services firms, independent institutional advisors. These delegates publish voting platforms, maintain voting records, and bring deliberative bandwidth that operator-SVs might not have time for. Canton's institutional positioning makes this constituency a particularly natural fit.
It pushes operators into a role they aren't optimized for. SVs are infrastructure operators with commercial books of business. Their incentive structure in governance is inherently weighted toward their own business interests rather than the broader health of the network. A complementary class of governance-focused participants strengthens the system.
Professional delegates heightens Governance Maturity and Participation Organizations that focus on governance dedicates a lot more time to scaling the governance operations of the protocols, most of the governance systems in Web3 relies heavily on delegates as the stewards of the governance ecosystem.
Suggested amendment:
An SV may delegate its Voting Weight to (i) another SV, or (ii) a Recognized Delegate.
Recognized Delegates are entities approved through a public application process administered by the Foundation, which may include (but is not limited to) professional services firms, governance specialist firms, and independent institutional advisors. Recognized Delegates must:
-
Publish a public delegate platform and a continuous voting record
-
Be subject to the same participation requirements as SVs
-
Be removable from the Recognized Delegate registry by SV-weighted vote
This is also a natural place to import the Foundation-delegation practice common in mature governance systems, whereby Foundation-held weight is delegated to a diverse slate of Recognized Delegates rather than exercised directly. We'd be interested in the community's view on whether that practice is in scope for this CIP or better treated separately.
It should also be noted that of course it is completely up to the SV’s if they want to delegate to professional delegates, and they would only achieve any voting power in case the SV’s trust them enough to delegate to them. On top of that delegations can be removed at any given moment so in case a professional delegate acts out of their scope then the SVs can just remove their voting power.
Happy to take any questions / conversations about the topics that I have brought forward here.
-
- Thank you, Eric, for putting together these two CIPs.
On the 200m cap: we propose loosening it, either by raising the ceiling to 350m or by replacing the single cap with a tiered schedule (after vesting discount): full weight on the first 200m of locked CC, then 25% credit from 200m to 600m, 15% from 600m to 1b, and 10% above 1b.
For example, a standalone SV with 750m CC locked lands at 322.5m of voting weight under the tiered schedule:
- First 200m at 100% → 200m
- Next 400m (200m to 600m) at 25% → 100m
- Final 150m (600m to 750m) at 15% → 22.5m
The 200m cap too strictly decouples an SV's actual lock-in and time commitment from its voting share. Raising the cap or moving to a tapered schedule still keeps the largest holders heavily compressed relative to their total stake, while retaining a governance incentive to deepen commitment beyond the current cap. It also keeps a clear path toward decentralization as the network matures.
A question on the Operator Governance CIP: since Operators are an elected set of self-operated SVs, does that necessarily leave a set of self-operated SVs that don't hold an Operator seat? If so, it may be worth considering whether we should distinguish between self-operated non-Operator SVs and Operator SVs with regards to SV Voting Weight.Best,
Billy Goodwin | Associate, Digital Assets
245 Park Avenue • New York, NY 10167
billy.goodwin@... - thanks Billydid my own modeling based on your suggestions - i don't think the tiering is worth the complexity - the results are nearly identical to raising the cap and the simplicity of having one variable we can tweak over time via CIP is more appealing from my perspectivewould be great to hear from others about the 200 vs 350 cap - it's immaterial to us at DA given the > 3b lock we have so i'm not sure our opinion is illuminating in the matterOn Mon, Jun 22, 2026 at 2:24 PM Billy Goodwin (Tradeweb) via lists.sync.global <billy.goodwin=tradeweb.com@...> wrote:Thank you, Eric, for putting together these two CIPs.
On the 200m cap: we propose loosening it, either by raising the ceiling to 350m or by replacing the single cap with a tiered schedule (after vesting discount): full weight on the first 200m of locked CC, then 25% credit from 200m to 600m, 15% from 600m to 1b, and 10% above 1b.
For example, a standalone SV with 750m CC locked lands at 322.5m of voting weight under the tiered schedule:
- First 200m at 100% → 200m
- Next 400m (200m to 600m) at 25% → 100m
- Final 150m (600m to 750m) at 15% → 22.5m
The 200m cap too strictly decouples an SV's actual lock-in and time commitment from its voting share. Raising the cap or moving to a tapered schedule still keeps the largest holders heavily compressed relative to their total stake, while retaining a governance incentive to deepen commitment beyond the current cap. It also keeps a clear path toward decentralization as the network matures.
A question on the Operator Governance CIP: since Operators are an elected set of self-operated SVs, does that necessarily leave a set of self-operated SVs that don't hold an Operator seat? If so, it may be worth considering whether we should distinguish between self-operated non-Operator SVs and Operator SVs with regards to SV Voting Weight.Best,
Billy Goodwin | Associate, Digital Assets
245 Park Avenue • New York, NY 10167
billy.goodwin@...
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. Generally, we are ok with the use of a 350M voting weight cap as Eric describes. We would, however, like raise a couple items that we believe should be added to the current proposal to prevent potentially damaging governance edge cases.
Quorum Adjustments:
In the current proposal, the minimum passing vote requirement is ~33% of the total voting weight (2/3 "Yes" votes under a 50% quorum). Under such a low threshold, the network may be faced with edge cases wherein a "No" vote could result in a low participation (and low approval) vote reaching quorum and passing. To combat this, we believe that low participation votes should be required to have overwhelming passing support which decreases to the 2/3 requirement as total voting weight increases.
More formally, we propose that a vote should pass only if:
- The vote has >1/2 of total voting weight voting yes; and
- The vote has >2/3 of the yes+no voting weight voting yes
Under the new structure a 50% total vote quorum is required, with the ratio of yes votes decreasing from 100% of the voting weight at the lowest quorum threshold to 66.67% at 75% of total voting weight engaging.
Fixed voting weight:
To prevent additional edge cases wherein entities may attempt to "game" the locking system and increase lock only after seeing contention within a vote we also propose that SV weights are "locked" at their values for a given vote as of the time of vote proposal on-chain.
Other items for consideration
We're also evaluating several other items that may benefit from slight adjustments. We will circle back on this thread with further feedback, but welcome community input in the interim.
- Mechanisms for SV weight slashing or removal due to non-conformance with governance responsibilities: max abstention thresholds, evaluation cycle, etc.
- Controls on delegation of SV weight to minimize risk of vote centralization
- Hi everyone,
From our position operating a "Tier-1" Super Validator with weight 10, which has been live since November 2025, I wanted to highlight a practical concern with the proposed fixed 350M token threshold (or any similar fixed-cap accumulation model) for governance weight or privileges.
Even with one of the highest weights in the network, it would take us approximately 5 years to accumulate 350M tokens under current reward rates. With the continued onboarding of new SVs, this timeline is likely to extend substantially. This structure inherently advantages SVs who joined before 2026 and creates an uneven playing field that does not scale fairly with network growth.Proposed alternative mechanismWe suggest that governance weight, voting privilege, and priority should primarily derive from the percentage of the 30% liquid portion of rewards that each SV voluntarily locks in perpetuity, rather than from accumulating a large fixed token amount. Under the framework established in CIP-0105, SVs already receive rewards structured such that a significant portion (typically 70%) is locked to maintain full weight, leaving a 30% liquid component available to the operator.
We propose to tie additional or core governance influence directly to what percentage of that 30% liquid share an SV chooses to lock long-term. Key benefits of this approach:
- Removes early-mover bias: Newer SVs are not structurally disadvantaged by needing years to catch up on a fixed nominal threshold. Weight scales with commitment rather than tenure alone.
- Stronger alignment with network growth: Locking more of the liquid portion demonstrates skin-in-the-game and long-term alignment. While selling liquid rewards is rational for operators, it can be misaligned with the broader ecosystem. This mechanism rewards those who choose to further commit.
- Natural scaling: As the network grows and more rewards are earned, the liquid portion grows proportionally. Governance influence remains tied to ongoing commitment rather than hitting an arbitrary fixed cap.
- Incentivizes ecosystem alignment for all participants: Every SV starts from the same CIP-0105 structure. Those who lock a higher percentage of their liquid rewards gain proportionally higher voting weight/priority. This is transparent, merit-based on commitment, and applies equally regardless of when an SV joined.
- Complements existing mechanics: This can sit alongside or refine the current CIP-0105 locking framework without requiring a complete overhaul. The percentage locked from the liquid share could act as a multiplier or direct component in the weight calculation within the new governance drafts.
“Base weight (per existing CIP-0105 mechanics) + additional governance multiplier based on the % of the 30% liquid reward portion that the SV voluntarily locks in perpetuity.”Parameters such as the exact weighting curve or minimum lock thresholds could be set as adjustable governance parameters (subject to future CIPs with appropriate SV voting thresholds). This model keeps the system dynamic, fair, and strongly aligned with long-term network success.
I’m happy to discuss specific implementation details or help model how this could integrate with the voting and operating frameworks in the current drafts. We could also explore hybrid approaches that combine elements of percentage-of-earned and commitment-based locking.
Looking forward to the community’s thoughts and continued discussion on these important governance topics.
Best regards,
Heslin Kim
Zenith Proof Group is directionally supportive of the proposed changes to the Super Validator governance framework. We agree that the network would benefit from broader and more consistent participation in decisions that affect its long-term development, and we support efforts to establish clearer expectations around governance.
That said, we believe the proposal should account for an important practical constraint: not every current or incoming Super Validator may be operationally, legally, or institutionally prepared to participate in governance immediately.
The current framework appears to assume that each Super Validator can either:
- Establish the internal processes required to review and vote on proposals; or
- Delegate its voting authority to another qualified participant.
Before introducing changes that could materially affect an SV’s governance rights, rewards, or standing, we believe it would be prudent to confirm that each Super Validator is prepared to pursue at least one of these paths.
In practice, establishing a governance process can take significantly longer than anticipated. This is especially true for large financial institutions, regulated entities, and publicly traded companies, where voting decisions may require legal review, compliance approval, internal committee oversight, or formal authorization from senior management.
Delegation may not fully resolve this issue. Some organizations may be restricted from delegating governance authority, particularly where that delegation could be interpreted as outsourcing a fiduciary, corporate, or regulatory responsibility. It should therefore not be assumed that every SV can readily delegate its vote if direct participation is not yet feasible.
To address these concerns, Proof Group proposes reframing governance participation as an affirmative, opt-in responsibility rather than an automatic requirement attached to all Super Validators.
Under this approach:
- Every Super Validator would retain the right to apply for voting status.
- An SV electing to participate would affirm that it has the necessary governance, compliance, and operational processes in place.
- Voting status would become effective upon approval by the existing two-thirds threshold of voting Super Validators.
- Participating SVs would then be subject to the applicable participation and delegation requirements.
- Non-voting SVs would remain active network participants and retain their hosted SV rights, but would not count toward the overall voting pool and would not be penalized for failing to vote on matters they have not affirmatively elected to govern.
We believe this model would produce a smaller but more capable and accountable voting body. An SV that is not prepared or interested in governance should be able to opt out transparently rather than remain nominally responsible for votes it cannot adequately evaluate.
This distinction is important. A deliberate decision not to assume governance responsibility is preferable to chronic non-participation, uninformed voting, or delegation arrangements that an organization is not equipped to oversee.
An opt-in structure would also make the maximum SV voting lock less central to maintaining governance quality. If voting authority is limited to SVs that have affirmatively demonstrated readiness and received approval from the existing voting set, we believe the maximum voting lock could reasonably be reduced to 100 million CC without undermining the integrity of the process.
We would also encourage the proposal’s authors to consider a transition period during which all existing and incoming Super Validators can formally indicate whether they intend to:
- Participate directly in governance;
- Participate through an approved delegation arrangement; or
- Remain non-voting.
This would provide the community with a clearer picture of actual governance capacity before any new participation requirements or penalties take effect.
Proof Group supports the broader objective of strengthening Super Validator governance. Our proposed amendment is intended to ensure that the resulting framework prioritizes informed, intentional, and accountable participation rather than treating voting as a universal obligation that every organization is presumed able to fulfill.
Thank you to everyone advancing this discussion. We welcome feedback from both existing and prospective Super Validators, particularly regarding internal governance readiness and the feasibility of delegation prior to this group taking affirmative action.
On Thu, Jul 2, 2026 at 7:29 AM Heslin Kim via lists.sync.global <heslin=gevulot.com@...> wrote:Thanks everyone for the feedback. We've attached an updated draft of the SV Governance CIP. We've added a number of items discussed in the Tokenomics Working Group over the last several weeks.
We'd also like to propose one additional item for consideration - in addition to the vote proposal rate limit included in the draft, we'd like feedback on having a potential interim step in the transition to wider SV governance wherein only SV Operators are able to propose votes. This would allow the network additional safeguards from potential errant, unintentional or otherwise bad faith vote proposals that may impact participation criteria during the period where new participants are building out their internal vote processes. If the community agrees, this would be added as an interim phase prior to opening vote proposals to all SVs.
- One other quick note, we debated what the right maximum number of votes proposed/initiated per day is to account for legitimate vote activity while preventing large numbers of errant/unintentional votes being initiated. We have it set to 5 in the current draft but are open to a different number or even potentially excluding the Foundation from that limit.Open to any thoughts on the topic. Thanks!Chris
- Attached is an updated version of the CIP featuring feedback from the wider community over the last week. This draft includes additional language to illustrate a potential emergency "threshold" vote framework, restrictions for vote proposals in Phase 1 to just SV operators and an additional note in Phase 1 indicating that a proposal rate limit mechanism must be ratified by SVs prior to Phase 2.We have not yet included any edits to incorporate a potential burn in period that was discussed last week. We're continuing to gather feedback on that item and welcome further thoughts on the burn in and other items here.-------
CIP-XXXX: Weighted CIP Voting v0.5
Title: Weighted CIP Voting
Author: W Eric Saraniecki
Status: Proposed
Created: 2026-XX-XX
Type: Governance
License: CC0-1.0
Abstract
This proposal evolves the Super Validator (SV) governance model to support improved participation among SVs in CIP voting.
The proposed changes expand direct participation in governance by extending voting power based on a formula that takes locked cc, time as SV, and operations into account.
The rollout is structured in two phases:
-
Phase 1: Expand participation in CIP voting to all SVs via #cip-vote
-
Phase 2: Transition to fully on-chain vote process
This approach allows for immediate adoption while a technical process is implemented.
Motivation
Extend the current voting process in a way that preserves its strengths while improving quality of outcomes and breadth of participation.
Specification
Weighting
Each SV’s Voting Weight is determined by the following formula. These weights are established on a per vote basis at the time the relevant vote is initiated on Canton Mainnet. No weight changes may take place for an SV between the initiation and conclusion of the vote on Mainnet:
-
If you are a Self-Operated SV :
# Tokens Locked (Capped)
-
If you are a Hosted SV :
# Tokens Locked (Capped) * # of Days Active SV / Vesting Duration
Cap : 350m CC
Vesting Duration : 1461 Days
Examples:
Name
Weight
Locked CC
Time an SV
Hosted?
SV Voting Weight
SV1
30
3b
710 days
Self-Operated
200m
SV2
25
3b
710 days
Hosted
97.2m
SV3
3
25m
250 days
Self-Operated
25m
SV4
1
25m
250 days
Hosted
4.27m
Any Active SV may choose to lock additional CC for additional SV Voting Weight (up to the cap).
An SV’s Voting Power is their SV Voting Weight / Total SV Voting Weight
Voting Model
Each SV may propose/initiate a vote on Canton Mainnet up to 5 time per day, measured from midnight UTC until 23:59:59 PM UTC. In the event the SVs vote to determine any votes we’re proposed/initiated in bad faith, errantly or unintentionally, they may be removed from voting requirement metrics established by this CIP.
Each SV is assigned voting power according to the calculated SV Voting Weight described above.
For each governance proposal, SVs may do one of the following:
-
Yes
-
No
-
Abstain
-
Do Not Vote
Abstention is treated as participation but does not contribute to the decision outcome.
Only Yes and No votes are included in determining the result of a proposal.
Vote Aggregation and Decision Rules
The outcome of a proposal is determined by aggregating SV votes on a weighted basis.
A proposal passes if both:
-
[Quorum] The vote has at least 50% of the total voting weight voting “yes”; and
-
[Passing Threshold] At least 66.67% of the votes submitted as “yes” or “no” were submitted as “yes”.
Under this structure, a 50% voting weight quorum is required and the percent of votes required to be “yes” for a passing vote decreases from 100% of the voted weight at the lowest quorum threshold to 66.67% when 75% or more of the total potential voting weight engages in the vote.
If Quorum is not met, the proposal is considered invalid and no action is taken. If the Passing Threshold condition is not met, the vote fails and no action is taken.
Abstentions satisfy participation requirements but do not count toward quorum.
Effective at Threshold Votes
Some situations may require time-sensitive effectivity of Super Validator vote decisions to avoid network instability that should not wait for a longer-dated effectivity timeline. For these votes, Effective at Threshold-style votes may be used wherein the vote becomes effective as soon as the appropriate passing threshold is crossed. Effective at Threshold votes will not receive full SV vote participation, and as such, they will be explicitly excluded from SV voting requirement calculations.
Effective at Threshold votes will pass as soon as:
-
[Passing Threshold] At least 66.67% of the votes submitted as “yes” or “no” were submitted as “yes”.
Not all votes may be proposed as Effective at Threshold votes. SV’s delegate the responsibility for recommending specific in-scope Effective at Threshold vote types to the Canton Foundation Tokenomics Committee.
Delegation
An SV may delegate its Voting Weight to another SV.
-
Delegation is explicit and revocable
-
The delegate’s vote applies to the full delegated weight
-
Delegation counts as participation for the delegating SV when the Delegate participates
This enables efficient participation while preserving representation across the SV set.
For the avoidance of doubt, any delegated voting weight counts towards the weight cap of the SV accepting the delegation. Accepting delegated voting weight does not permit an SV to exceed the voting weight cap. In the event such delegation would cause an SV to exceed the voting weight cap, their voting weight instead is set to the voting weight cap. As an example:
Assume:
-
SV 1 has 100M voting weight. SV 2 has 300M voting weight. The voting weight cap is 350M.
-
SV 1 enters into an agreement to delegate its voting weight to SV 2.
-
SV 2 now has an aggregate 400M voting weight (100M + 300M). This exceeds the voting weight cap of 350M, as a result SV 2 has a voting weight of 350M and the remaining 50M is ignored for voting purposes.
If a delegate fails to participate, the delegating SV is treated as not having participated.
Participation Requirements
SV participation is evaluated on a quarterly basis.
-
An SV may not miss more than 2 time-limited governance votes in a given calendar quarter. This count resets at the beginning of each calendar quarter.
-
Starting 90 days after this CIP takes effect, an SV may not abstain from more than 90% of time-limited governance votes on a rolling 90-day basis.
Key properties:
-
Abstain counts as participation
-
Delegation counts as participation
-
Only failure to vote counts as a missed vote
If an SV exceeds this limit:
-
Its SV Reward Weight is reduced by 10% of its total earned SV reward weight not including any weight subsequently lost to any weight slashing or reduction action taken as a result of Network governance.
Role of Operators
SV Operators are responsible for ratifying governance decisions.
-
In all phases, operators execute the final aggregated SV vote outcome
-
Operators do not exercise independent discretion in governance decisions
Phased Implementation
Phase 1: Off-Chain Aggregation
-
All SVs are included in governance voting through an off-chain process
-
Votes are collected, aggregated, and verified by the Tokenomics Working Group and/or designated governance coordinators
-
Operators execute the resulting aggregated vote on-chain
-
In Phase 1, Operators will be the only SVs able to propose new votes
This phase enables immediate expansion of participation without requiring changes to on-chain infrastructure.
Prior to graduating to Phase 2, SVs must ratify vote proposal rate limit frameworks for Phase 2. At time of drafting for this CIP, a global rate limit of 5 vote proposals per day has been proposed, but this may restrict periods with substantial time-sensitive votes. Potential solutions may include, but are not limited to:
-
Increasing the per-SV vote proposal rate limit,
-
Removing the rate limit from Operators, or
-
Allowing some SVs an exemption from the vote proposal rate limits.
Phase 2: On-Chain SV Voting
-
SV voting is represented directly on-chain
-
Delegation and vote aggregation are handled through protocol-level mechanisms
-
Operators continue to execute the aggregated outcome, now derived directly from on-chain inputs
This phase completes the transition to a fully on-chain governance model.
-
- As far as I am aware, there are currently no publicly drafted standards or definitive guidelines outlining the procedural path to becoming a Self-Hosted SV Operator. Given that this CIP references the role, it would be helpful for those of us holding SV titles to understand the criteria, timing, and process for transitioning from “ghost” SVs to Self-Hosted SVs.
A minor note on the example weightings: in the table entry “SV1 30 3b 710 days Self-Operated 200m,” I believe the voting weight should read 300m (as previously flagged by Chris M.).
Thank you,
Heslin Kim
Zenith - Here's the current operational procedure for becoming an SV node operator, after the SVs have voted to allow an entity to operate an SV node:
https://github.com/canton-foundation/configs/blob/main/Super%20Validator%20Operational%20Processes/onboarding-supervalidator-mainnet.md - I'd like to request clarification on the definition of threshold in the "Effective at Threshold" case. The July 28th version of the CIP says:
Effective at Threshold votes will pass as soon as:
-
[Passing Threshold] At least 66.67% of the votes submitted as “yes” or “no” were submitted as “yes”.
Does this mean that the vote will pass as soon as three votes have been cast, with two in favor? Or does the vote still require a quorum representing 50% of total SV voting weight? -