CIP-XXXX: UTXO-based Voting Power Regeneration System for Cardano [draft]

[des1re10]

Dear Cardano community,

this is my second proposal concept to improve Cardano governance next to CIP-XXXX: Three-Factor Governance Voting System for Cardano

`# CIP-XXXX: UTXO-based Voting Power Regeneration System

Abstract

This CIP proposes a voting power regeneration system based on Cardano's UTXO model. The system introduces variable regeneration periods based on proposal urgency, allowing faster recovery for critical decisions while maintaining longer cooldowns for standard governance.

Motivation

Current blockchain governance systems face several challenges:

1. Large stakeholders can repeatedly influence multiple proposals in short timeframes
2. No mechanisms to encourage careful consideration of proposals
3. Limited incentives for consistent, thoughtful participation
4. One-size-fits-all voting periods don't account for proposal urgency

This proposal addresses these challenges through a simple regeneration mechanism that adapts to proposal importance while affecting all participants equally.

Specification

Proposal Categories

Proposals are classified into three urgency levels:

1. Standard Proposals

   • Regular governance decisions
   • Protocol improvements
   • Long-term planning
   • Default category for most proposals

2. Priority Proposals

   • Time-sensitive updates
   • Important parameter adjustments
   • Significant protocol enhancements

3. Emergency Proposals

   • Critical security fixes
   • Severe bug patches
   • Network stability issues
   • Must be verified by multiple SPOs

Core Mechanism

The system introduces a voting power regeneration mechanism with these key components:

1. Base Voting Power

   • Derived directly from UTXO's ADA value
   • Forms the foundation for all calculations

2. Regeneration Factor

   • Scales from 0 to 1 based on time since last vote
   • Calculated as: min(1.0, (CurrentSlot - LastVoteSlot) / RegenerationPeriod)
   • Regeneration period varies by proposal category

3. Implementation Formula

VotingPower = BaseVotingPower * RegenerationFactor

where:
BaseVotingPower = UTXO value in lovelace
RegenerationFactor ∈ [0, 1]  -- Time-based recovery

System Constants:
StandardRegenerationPeriod = EpochLength            -- 5 days
PriorityRegenerationPeriod = EpochLength / 2.5     -- 2 days
EmergencyRegenerationPeriod = EpochLength / 5      -- 1 day

Example Scenarios

1. Standard Proposal Vote

Scenario:
- UTXO Value: 1000 ADA
- 2 days since last vote (40% of standard period)

Calculation:
BaseVotingPower = 1000 ADA
RegenerationFactor = 0.4  -- 40% regenerated
Final VotingPower = 1000 * 0.4 = 400 ADA

2. Emergency Proposal Vote

Scenario:
- Same UTXO: 1000 ADA
- 2 days since last vote (200% of emergency period)

Calculation:
BaseVotingPower = 1000 ADA
RegenerationFactor = 1.0  -- Fully regenerated due to emergency timing
Final VotingPower = 1000 * 1.0 = 1000 ADA

Basic Anti-Gaming Controls

1. UTXO Requirements

   • Minimum UTXO size: 100 ADA
   • Basic tracking of voting history per UTXO

2. Regeneration Rules

   • Fixed rates per category
   • No acceleration mechanisms
   • Proposal categorization requires multi-signature verification

3. Emergency Controls

   • Emergency status requires verification from minimum 3 SPOs
   • Limited number of concurrent emergency proposals (max 2)
   • Automatic review period after emergency proposals

Risk Analysis

Key Risks

1. UTXO Manipulation

   • Risk Level: Low
   • Impact: Moderate
   • Mitigation: Basic UTXO tracking and minimum size requirements
   • Note: All manipulations leave permanent evidence on-chain

2. System Gaming

   • Risk Level: Low
   • Impact: Moderate
   • Mitigation: Fixed regeneration rates and category verification
   • Note: Emergency proposal abuse prevented by SPO verification

3. Category Misuse

   • Risk Level: Medium
   • Impact: Moderate
   • Mitigation: Multi-signature verification for category assignment
   • Note: Regular audits of proposal categorization

Parameter Specifications

Parameter	Default Value	Description
Standard Regeneration Period	5 days	Time for full recovery on standard proposals
Priority Regeneration Period	2 days	Time for full recovery on priority proposals
Emergency Regeneration Period	1 day	Time for full recovery on emergency proposals
Minimum UTXO Size	100 ADA	Minimum size for voting UTXOs
Emergency Verifiers Required	3	Minimum SPOs needed to verify emergency status

Parameter Justification

1. Time Periods

   • Standard period (5 days) aligns with epoch length for simplicity
   • Priority period (2 days) balances urgency with consideration time
   • Emergency period (1 day) allows quick response while preventing rushed decisions

2. UTXO Requirements

   • 100 ADA minimum prevents dust attack vectors
   • Large enough to discourage gaming through splitting
   • Small enough to maintain accessibility

3. Verification Requirements

   • Three SPO verification requirement provides a minimum threshold for consensus
   • Multiple verifications help prevent individual SPO compromise or collusion
   • Requirements can be adjusted through governance if needed

Copyright

This CIP is licensed under CC-BY-4.0.`

My github: https://github.com/des1re10/CIP-XXXX-Voting-Power-Regeneration-System-for-Cardano

Best regards,
M.Eng. Robert Ledwig

[des1re10]

Changes:

[12/18/2024]

• initial draft

[12/19/2024]

• descriptions updated
• further sections added
• parameter specifications added
• Core Mechanism section updated
• Vote Validation and Processing section updated

[12/20/2024]

• implementation timeline and deployment strategy removed
• proposal draft simplified
• Parameter Justification added

[rphair]

@des1re10 - This is to acknowledge that this discussion and #948 are visible to the CIP Editors, and to thank you for posting "discussions" for these ideas rather than simply beginning with CIP pull requests. 🙏

This will be my last posting duplicated between the 2 threads. There may be future concerns common to both these proposals; if this happens please consider either:

1. combining these 2 discussions into one, or:
2. raising a third discussion with elements common to these two ideas.

This is not a review but I do think your proposals read more like "statements of work" or Catalyst bids than CIPs. A CIP would never include a time schedule, and it's become much more important that implementors be left non-specific and progress be made decentralised wherever possible.

If this is work that you believe only you or your associates can do, it is definitely not a CIP and would do better in a forum designed for collaborative activity where you can find collaborators, contributors, and investors. The money-based details like the "donation" addresses definitely make it seem like this material was intended for a different medium.

Please let me ask you to read through the CIPs that have currently been merged into the CIP repository and ask yourself how the intent and presentation of your recent material may be different than the hundred-or-so CIPs that have been peer-reviewed and merged so far.

Given the huge amount of work you have put into these ideas, I would also recommend spending just another hour to read the CIP Wiki because there are many points that would help you strip your proposal into a set of technical specifications & justifications that might pass peer review as unbiased and impersonal standards: https://github.com/cardano-foundation/CIPs/wiki

... especially focusing on these questions: https://github.com/cardano-foundation/CIPs/wiki/2.-CIPs-for-Reviewers-&-Authors#when-is-a-design-document-not-a-cip

In the New Year I look forward to revisiting this discussion to see if some of these suggestions are being accommodated. Please trust me that what you might want to immediately ask me in response has already been answered in the Wiki... which I wrote to answer similar questions and save time & duplication of effort for both authors & editors. The Wiki material should help you "think like an editor" (or reviewer) about the vital differences between CIPs and other technical bids.