CIP-1694 | SPO pre-defined voting options

[adamrusch]

Addition of language that allows for SPOs to delegate to pre-defined voting options. PR created by Adam Rusch and Johnny Kelly. Idea for achieving SPO pre-defined voting options came from Martin Lang of ATADA Stake Pool at the September 23, 2024 Ledger Working Group meeting.

[lehins]

Here is the ticket on the Ledger side that goes into some reasons and outlines more specifics of this change: IntersectMBO/cardano-ledger#4645

Cross referencing it for anyone interested in following progress on implementation of this feature.

[Hornan7]

I second that PR by saying, 'That's about time!' 😅🥰👍

[Hornan7]

The total active voting stake for SPOs usually doesn’t include 'Auto-Abstain' in the calculations for any governance actions, including hard fork governance. Since hard forks will not include 'Auto-Abstain' and 'No-Confidence' voting options, wouldn’t it be better to rephrase this with the assumption that we are effectively discussing active stake delegated to stake pools, rather than just the active stake that has voted?

[Hornan7]

Same here. To dispel confusion about what constitutes 'active voting stake' for SPOs, it's important to note that the 'Auto-Abstain' voting option is typically not included in the 'active voting stake' calculations, while 'Auto-No-Confidence' is. Should we add some additional clarifications regarding the hard fork exception?

[intertreeJK]

The SPOs' relationship to the Automated Voting Options being added as a Note after the Automated Voting Options section is placed to dovetail off of the existing explanations of how these options affect the Active Voting Stake.

[rphair]

I won't be at the next CIP meeting when this is introduced (https://hackmd.io/@cip-editors/98), but just in case it's undisputed & perhaps can be merged there, I'm endorsing this in advance due to the approval of the Ledger team & governance advocates.

[Ryun1]

hello!

Thanks for the pull request @adamrusch and team, I am a fan of this.

Changing active CIPs once marked as active has proven to cause compatibly issues.
Tooling claiming to be CIP-1694 compliant will no longer be.

May I suggest that we change this to be its own proposal (I know it will be brief) but I feel this will make tracking compatibility much easier.

[lehins]

@Ryun1 I'd like to argue against your suggestion. Technically CIP-1694 is not yet fully active. It will only be active after the bootstrap phase is over with Chang+1 HF, which is exactly when the full CIP-1694 goes into affect. This feature that is being described in the PR is something that is currently being implemented for the Chang+1 HF in Ledger.

So, if we do this change in a separate CIP, technically then ledger will not be CIP-1694 compatible 😉

We also discussed this on a call and @disassembler and @kevinhammond also made the same suggestion: just amend the existing CIP-1694.

[perturbing]

I see that a separate CIP is not necessary, but I want to guard against inconsistencies with this change to CIP 1694.

Are you sure that the suggested changes cover all things that should change?

For example, is line 722 still correctly formulated?

[Hornan7]

Are you sure that the suggested changes cover all things that should change?

For example, is line 722 still correctly formulated?

I believe line 722 is indeed correctly formulated.

That being said, I suggested more clarification in this comment (on line 521):
#916 (comment)

I believe line 494 and 521 should probably be revised. As it is currently written, it suggests that the thresholds for hard forks are exempt from being calculated based on 'active voting stake.' In reality, even for a hard fork, it's still necessary to meet a threshold of active voting stakes. The only exceptions are the exemption of 'auto-abstain' and 'auto No-confidence' voting options regarding 'Hard-fork initiation' governance action.

[perturbing]

Thank you, @Hornan7 :)

And for completeness, do you think we should add some line from this issue for context somewhere in the CIP?

[Hornan7]

And for completeness, do you think we should add some line from this issue for context somewhere in the CIP?

I think Johnny Kelly and Adam Rusch did a great job with this PR. It summarizes the changes to the ledger well in the CIP-1694, though I believe the part mentioned above could be slightly modified. 😇

[Ryun1]

@lehins

My main motivation for wanting this in its own proposal is for communication reasons
It is a lot simpler to communicate "heads up new Ledger CIP-????" rather than CIP-1694 is changing again
Having this change in its own proposal, gives the authors a chance to fully describe the motivation and rationale for this making communicating easier

Furthermore much tooling has considered itself CIP1694 compliant, having tested across different networks with and without bootstrapping
Changing CIP1694 will now mean these tools are not compliant, and it is a challenge to reach out to all these tools to let them know

Anyway, seems like the sentiment is against me on this one 😆
If this is to stay as a change to CIP1694, I must request a few changes

• Please update the ChangeLog section
• Please add the rationale for this change to the Rationale section
  • Capturing the motivation for this change I feel is really important
  • Currently the change is proposed but there is no description on WHY this is changing, and what problem this solves

cc @adamrusch

[Hornan7]

While I appreciate your perspective on the benefits of creating a separate CIP, I believe it is crucial to maintain and update CIP-1694 instead. This document serves as the official key reference for how Cardano's governance features operate at the protocol level and is integral to our governance framework.

The CIP-1694 is also referenced multiple times in the Interim Constitution:

1. Appendix 1 - Cardano Guardrails Introduction: This section states that implementing on-chain governance requires establishing guardrails based on CIP-1694 to ensure the Cardano Blockchain operates securely and sustainably.

2. Guardrail 2.5 - Governance Parameters: This section emphasizes that the goals of managing governance parameters include ensuring governance stability and maintaining a representative form of governance as outlined in CIP-1694.

3. Guardrail Script 9: CIP-1694 is cited multiple times within this section, reinforcing its role as a foundational document for governance practices during the Interim Period.

Given that the CIP-1694 is already established as the main reference point in the Interim Constitution, creating a new CIP for this change would imply significant modifications to the Constitution itself to incorporate this new reference. This could lead to confusion and misalignment within our governance framework if these changes are not done concurrently in both documents.

As Alexei mentioned, we are still in the bootstrap phase, which is why I also believe we should prioritize updates to CIP-1694 to ensure it accurately reflects our governance processes. 😃👍

[rphair]

I'm sorry for not contributing much so far beyond agreeing with the points everyone is making on both sides. I can see how a trail of distinct CIPs documenting any changes to the baseline would be important as @Ryun1 is saying. I also can see why it's necessary at this point to confine the sum of this behaviour to CIP-1694 alone, as a special case beyond this generally desirable process, because of CIP-1694's uniquely defined & comprehensive role.

I think what @Ryun1 offers in #916 (comment) would be an excellent compromise — to rationalise and record this update within CIP-1694 itself — and to follow this precedent for any similar updates until some evolutionary change might break that uniquely intimate relationship between CIP-1694 and the overall Governance process.

[rphair]

@adamrusch - consensus at CIP meeting today is that we only await updating as per #916 (comment) before double-checking the added rationale / changelog & then hitting the merge button for this.

[Crypto2099]

I believe it would be sufficient to add this pull request as an additional link in the "discussion" section of the header which can be accomplished via a separate housekeeping PR.