CIP-0051 Streamline onchain governance votes

1. #1Itai Segall07-03-2025source ↗
   Hi,

   
   

   We have collected input from Super Validators operators based on their experience with the on-ledger voting process over the past few months, and have put together a CIP draft for improvements to this process, to make it less error prone, more useful, and more intuitive. 

   
   

   Your input is welcome.

   
   

   ## CIP XXXX

   
   

   <pre>

   CIP: ?

   Title: Changes to on-ledger vote logic

   Author: Itai Segall

   Comments-Summary: No comments yet

   Status: Draft

   Type: Governance

   Created: 2025-03-04

   License: CC0-1.0

   </pre>

   
   

   ## Abstract

   
   

   This CIP proposes the following changes to on-chain voting:

   
   

   a) votes on config changes will change individual (or a few) config values, and not the whole set of configurations;

   
   

   b) vote proposals will have an expiration date, after which if not enough votes have been submitted,

   they will be auto-rejected;

   
   

   c) votes will remain open for editing until they become effective;

   
   

   d) votes will be early-rejected upon 2/3 majority of reject votes;

   
   

   e) vote requests can be labeled as "immediate effectivity",

   meaning they will automatically get accepted and take effect immediately as soon as 2/3 of the

   Super Validator nodes vote in favor.

   
   

   ## Specification

   
   

   ### Vote on Individual Configuration Values

   
   

   In the new implementation, a vote request will only apply changes to those fields that the

   proposer has chosen to change, leaving the others unmodified, regardless of their value at the

   time of applying the change.

   
   

   ### Expiration as a Due Date for Enough Votes

   
   

   Every vote request will have an expiration date. If at the time of expiration, not enough

   votes are in (i.e. less than 2/3 of the Super Validators have put in any vote), then the

   vote request is immediately considered stale and auto-rejected.

   
   

   ### Votes Remain Open

   
   

   The new implementation will allow votes to be modified until the point where the action being

   vote is scheduled to go into effect.

   
   

   ### Early Rejection

   
   

   In the new implementation, vote requests that collected 2/3 "Reject" votes will immediately

   close as rejected.

   
   

   ### Immediate Effectivity

   
   

   The new implementation will introduce an "immediate effectivity" option for vote requests,

   which does not specify an explicit effectivity date, but instead becomes effective immediately

   upon collecting 2/3 "Accept" votes, but not earlier than the expiration date.

   
   

   ## Motivation

   
   

   As the Super Validators developed experience with on-ledger voting, we realized that the current

   implementation is too complex, error-prone, and hard to reason about. We've encountered multiple

   cases where vote proposals with mistakes have been submitted. These mistakes

   could have been avoided with more

   intuitive processes, or at least cleared out from the pipeline once a mistake has been identified,

   thus making it easier to create a new one with no such mistakes.

   
   

   ## Rationale

   
   

   ### Vote on Individual Configuration Values

   
   

   In the current implementation, every vote on config changes (e.g. the AmuletConfig, which governs

   mining, fees, etc) replaces the entire set of configuration values from the current set to those

   specified in the vote request. This has often caused confusion when multiple vote requests were

   created roughly at the same time, but their interaction with each other was hard to reason about,

   ending up with conflicts, and with votes that accidentally overwrote each other's values.

   Limiting the changes that every vote makes to only a select subset of fields will significantly

   reduce these kinds of issues.

   
   

   ### Expiration as a Due Date for Enough Votes

   
   

   We have seen cases of vote requests that fail to attract the attention of operators and linger

   in the pipeline for longer than they should. Making the expiration date the deadline for

   operators to act upon the vote will help operators keep track of their required actions and

   when they are required, as well as clean up stale votes that failed to get attention.

   
   

   ### Votes Remain Open

   
   

   In the current implementation, once the expiration date on a vote request has passed,

   votes on it can no longer be modified. In practice, this has proven to be a burdening

   limitation, and Super Validator operators often expressed a need to modify their vote

   until the very last minute, i.e. until the corresponding action has become effective.

   The new implementation will satisfy that requirement by allowing any vote to be modified

   until the point where the vote has become effective.

   
   

   ### Early Rejection

   
   

   Mistakes happen. We have had several cases on ledger already where vote proposals contained

   errors, and the Super Validator operators quickly realized that the vote proposals should be rejected. In the current implementation,

   there is no way to quickly get rid of those votes despite wide agreement that they should

   be rejected.

   
   

   ### Immediate Effectivity

   
   

   If a vote passes its expiration date with 2/3 of the SVs in favor, it's highly likely that it will go into effect on chain. For vote proposals that impact application providers and Validator operators, it's helpful to know for certain that a vote will take effect, and then have some time to prepare for this impact. Providing separate expiration and effectivity dates meets this need.

   
   

   On the other hand, some votes only involve the Super Validators, and have little to no operational impact. And there is also the possibility that the Super Validators could want to introduce a bug fix quickly. In these cases, it would be valuable to apply a vote proposal as soon as possible rather than at a pre-determined future date.

   
   

   ## Backwards compatibility

   
   

   Vote requests are short-lived. The changes proposed here will apply only to vote requests created

   after these changes are applied, and leave past votes intact. The UI of the SV application will

   be adapted to match the new logic, but will come into use in sync with the changes in the Daml

   models described here.

   
   

   ## Reference implementation

   
   

   We have started implementing the required changes for this CIP, which include changes in the

   governance Daml models, as well as the backend and frontend of the SV application . Access to a test

   environment will be provided to all Super Validator Operators to experiment with and comment on

   before we finalize the code and finalize the changes.

   An early version of the code is available in the [`isegall/tmp-gov-votes`](https://github.com/hyperledger-labs/splice/tree/isegall/tmp-gov-votes) branch

   on the [Splice repo](https://github.com/hyperledger-labs/splice), including

   the required Daml changes, backend changes as well as frontend.

   To review the Daml changes, one can clone the repo locally and run

   `git diff isegall/tmp-gov-votes main -- daml`.

   
   
   

   ## Copyright

   
   

   This CIP is licensed under CC0-1.0: [Creative Commons CC0 1.0 Universal](https://creativecommons.org/publicdomain/zero/1.0/)

   
   

   
   

   --
   

   Itai Segall
   

   Director of Engineering, Canton Network / +1 551 208 8835
   

   Digital Asset, creators of Daml
   

   
   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.
2. #2Wayne Collier14-03-2025source ↗
   Adding a link to the PR:
   
   https://github.com/global-synchronizer-foundation/cips/pull/35
3. #3Chris Zuehlke20-03-2025source ↗

   Cumberland has reviewed and supports CIP-0051.  We’ll co-sponsor it.

    

   Thanks

   Chris

    

   toggle quoted message Show quoted text

   From: cip-discuss@... <cip-discuss@...> On Behalf Of Wayne Collier via lists.sync.global
   Sent: Friday, March 14, 2025 12:24 PM
   To: cip-discuss@...
   Subject: [ext] Re: [cip-discuss] CIP-0051 Streamline onchain governance votes

    

   Adding a link to the PR: https: //github. com/global-synchronizer-foundation/cips/pull/35 _. _,_. _,_ Links: You receive all messages sent to this group. View/Reply Online (#100) | Reply to Group | Reply to Sender | Mute This Topic | New Topic Your

   Adding a link to the PR:
   
   https://github.com/global-synchronizer-foundation/cips/pull/35

   This e-mail and any attachments may contain information that is confidential and proprietary and otherwise protected from disclosure. If you are not the intended recipient of this e-mail, do not read, duplicate or redistribute it by any means. Please immediately delete it and any attachments and notify the sender that you have received it by mistake. Unintended recipients are prohibited from taking action on the basis of information in this e-mail or any attachments. The DRW Companies make no representations that this e-mail or any attachments are free of computer viruses or other defects.