tfgrid/circle_promotion
26
1
Fork 0
Code Issues 57 Pull Requests Packages Projects 4 Releases Wiki Activity

What to do about latest GEP (updating the GEP process) #294

New Issue
Closed
opened 2024-10-07 10:12:00 +00:00 by gosam · 7 comments
gosam commented 2024-10-07 10:12:00 +00:00
Owner
Copy Link

The latest GEP

https://forum.threefold.io/t/tfchain-dao-gep-voting-process-update/4409

did not pass.

What do we do now?

The latest GEP https://forum.threefold.io/t/tfchain-dao-gep-voting-process-update/4409 did not pass. What do we do now?
gosam added this to the Sep 30 – Oct 13 project 2024-10-07 10:12:00 +00:00
mik-tf commented 2024-10-07 12:11:02 +00:00
Owner
Copy Link

I can check today with the engineering meeting.

I'd think:

  • engage the community in the process: take note of all the feedback (e.g. hardware wallet voting, voting locked period, etc.)
  • do another GEP once we have incorporated the will of the community until the GEP
  • we might need to discuss a bicameral model: e.g. 50% vote power to tft holders, 50% to farmers
I can check today with the engineering meeting. I'd think: - engage the community in the process: take note of all the feedback (e.g. hardware wallet voting, voting locked period, etc.) - do another GEP once we have incorporated the will of the community until the GEP - we might need to discuss a bicameral model: e.g. 50% vote power to tft holders, 50% to farmers
👍 1
gosam modified the project from Sep 30 – Oct 13 to Oct 14 – Oct 27 2024-10-14 10:08:58 +00:00
gosam commented 2024-10-15 08:47:55 +00:00
Author
Owner
Copy Link

This is waiting for discussion with the full dev stakeholder group on Thursday.

This is waiting for discussion with the full dev stakeholder group on Thursday.
mik-tf commented 2024-10-17 14:42:53 +00:00
Owner
Copy Link

See this: tfgrid/circle_engineering#102 (comment)

See this: https://git.ourworld.tf/tfgrid/circle_engineering/issues/102#issuecomment-8760
mik-tf commented 2024-10-17 22:36:05 +00:00
Owner
Copy Link

Update

Some ideas to move forward and discuss with the community:

Voting Process Propositions Based on Community Feedback

Here are some options based on the feedback we had, not saying we implement all of it, nor that it's feasible. Lots of technically complex stuff have been proposed, e.g. voting with hardware wallet.

  1. Implement a hybrid voting system:

    • Maintain some voting power for node operators (e.g., 1 node = 1 vote)
    • Introduce token-based voting (e.g., 1 TFT = 1 vote)
    • Set a ratio between node votes and token votes (e.g., 40% node-based, 60% token-based)

  2. Introduce a token locking mechanism:

    • Require users to lock their TFT for a minimum period (e.g., 30 days) before being eligible to vote
    • Implement a sliding scale where longer lock periods grant more voting power

  3. Set voting power caps:

    • Implement a maximum voting power per wallet (e.g., 5% of total votes)
    • This helps prevent centralization while still allowing larger stakeholders to have a meaningful say

  4. Enable hardware wallet and Stellar-based voting:

    • Develop integrations to allow voting from hardware wallets
    • Create a mechanism for Stellar TFT holders to participate in voting

  5. Implement a formal proposal and discussion process:

    • Require a minimum discussion period (e.g., 2 weeks) before any vote
    • Allow community members to submit counter-proposals or amendments

  6. Communicate clearly the council operations:

    • Remind the community where the council documentation is
    • Explain the council organisation to the community in forum posts

  7. Introduce special voting categories:

    • For farming-specific rules, give extra weight to farmer votes
    • For technical decisions, consider giving extra weight to verified technical contributors

  8. Implement a gradual transition:

    • Phase in the new voting system over time (e.g., 6-12 months) to allow for adjustments and feedback

  9. Regular governance reviews:

    • Schedule periodic reviews of the governance system (e.g., annually)
    • Allow the community to propose and vote on governance improvements

Pros of Token-Based DAO Voting Process

Here is a list of arguments in favor of token-based DAO voting process:

Broader participation: Allows all token holders to participate in governance, not just farmers

Aligned incentives: Encourages token holding and potentially increases token value as people buy to participate in governance

Proportional representation: Voting power is proportional to stake in the network, which can be seen as fair

Increased liquidity: May increase token trading volume as people acquire tokens for voting rights

Easier entry: Lower barrier to entry for governance participation compared to farming

Flexibility: Allows for more nuanced voting mechanisms like quadratic voting or time-locked voting

Scalability: Can accommodate a larger number of participants more easily than farmer-only systems

Market signal: Voting outcomes may better reflect market sentiment and token holder interests

Encourages long-term thinking: With mechanisms like token locking, can incentivize long-term holding and thinking

Diversity of perspectives: Brings in viewpoints from investors, users, and other stakeholders beyond just farmers

Potential for delegation: Allows for the development of delegation systems, enabling more sophisticated governance

Adaptability: Easier to adjust voting power distribution over time if needed

Familiar model: Similar to governance in traditional finance, which may attract more mainstream participants

Farmer empowerment: As all TFT is minted by farmers, they have first access to voting power, maintaining their influence

Natural balance: Farmers' role in minting TFT creates a natural balance between farmers and other token holders

Incentivizes farming: May encourage more people to become farmers to gain voting rights through minting TFT

Reward for contribution: Farmers' voting power directly reflects their contribution to the network through minting

Organic growth: As farmers mint and distribute TFT, it naturally expands the voting base in line with network growth

Alignment with network growth: Voting power distribution organically follows the expansion of the network's infrastructure

Encourages ecosystem participation: Motivates farmers to engage with the wider ecosystem to maintain influence

TFDAO GEP Voting System: TFChain + Stellar Hybrid (Node-based + Token-based) with Passive Token Locking and Discussion+Voting Periods

This system proposes a hybrid/bicameral voting mechanism that combines node-based and token-based voting (50-50 voting power). This system allows participants to vote using TFT on either TFChain or Stellar, accommodating both hardware wallet users and farmers. The process involves a passive token locking mechanism. This encourages consistent token holding. The process also involves a two-phase voting period. The two-phase voting period ensures that the community members can discuss and improve on the GEP proposition. We also make sure the community understands the goals of each GEP.

  1. System Overview:

    • Main blockchain: TFChain
    • Secondary token location: Stellar network
    • Voting mechanism: DAO implemented on TFChain or as a separate smart contract

  2. Hybrid Voting System:

    • Node-based voting: Based on ThreeFold DAO weight
    • Token-based voting: 1 TFT = 1 vote
    • Ratio: 50% node-based, 50% token-based

  3. Node-based Voting Weight Calculation:

    • For each account:
      a) Identify all linked farms
      b) Get all eligible nodes per farm (see Node Eligibility Criterion)
      c) Calculate Compute Units (CU) and Storage Units (SU) per eligible node
    • Farm weight = 2 * (sum of CU of all eligible nodes) + (sum of SU of all eligible nodes)
    • Account's node-based voting weight = Sum of weights of all linked farms

  4. Node Eligibility Criterion:

    • Nodes must have completed at least 1 full minting cycle with 95% or more uptime in the cycle
    • Uptime is calculated based on node status reports over each minting cycle
    • Only nodes meeting this criterion are eligible for node-based voting

  5. Governance Event Proposal (GEP) Timeline:

    • Announcement: 30 days before the end of the voting period
    • Discussion Phase: First 15 days for community feedback and proposal updates
    • Voting Phase: Last 15 days for casting votes

  6. Snapshot-based Voting Process:

    • At the end of the voting period, simultaneous snapshots are taken on both TFChain and Stellar
    • Voting power is determined based on the snapshot data, passive token locking mechanism, and eligible node-based weights

  7. Passive Token Locking Mechanism:

    • For each wallet, determine the minimum balance held over the past 30 days
    • Token-based voting power is calculated using the lesser of:
      a) The current snapshot balance
      b) The minimum balance over the last 30 days

  8. Implementation Considerations:

    • Develop mechanisms for synchronizing snapshots
    • Ensure capability to efficiently query historical balances on both chains

  9. Advantages:

    • Balances influence of token holders and consistently reliable node operators
    • Encourages long-term high node uptime and reliability
    • Eliminates double-spending concerns
    • Simplifies cross-chain coordination
    • Increases fairness in voting
    • Encourages consistent token holding and node operation
    • Prevents last-minute manipulations of voting power
    • Allows hardware wallet usage and farmers to keep tokens in farming wallets

  10. Potential Challenges:

    • Ensuring accurate synchronization across chains
    • Handling potential network issues at snapshot time
    • Managing computational resources for historical balance

  11. Key Considerations:

    • Clearly communicate voting mechanism, snapshot timing, passive locking, and node eligibility criteria to participants
    • Ensure transparency and verifiability of the snapshot, node weight calculation, and uptime tracking processes
    • New wallets or those with incomplete 30-day histories cannot participate in token-based voting
    • New nodes must complete at least 3 minting cycles before being eligible for voting

This approach aims to provide a fair, secure, and inclusive method for incorporating both consistently reliable node operators and token holders into a single DAO voting system. It encourages long-term commitment to the network, sustained high node reliability, and prevents voting power manipulation while ensuring that participating nodes have a proven track record of contribution to the network.

## Update Some ideas to move forward and discuss with the community: ## Voting Process Propositions Based on Community Feedback Here are some options based on the feedback we had, not saying we implement all of it, nor that it's feasible. Lots of technically complex stuff have been proposed, e.g. voting with hardware wallet. 1. Implement a hybrid voting system: - Maintain some voting power for node operators (e.g., 1 node = 1 vote) - Introduce token-based voting (e.g., 1 TFT = 1 vote) - Set a ratio between node votes and token votes (e.g., 40% node-based, 60% token-based) 2. Introduce a token locking mechanism: - Require users to lock their TFT for a minimum period (e.g., 30 days) before being eligible to vote - Implement a sliding scale where longer lock periods grant more voting power 3. Set voting power caps: - Implement a maximum voting power per wallet (e.g., 5% of total votes) - This helps prevent centralization while still allowing larger stakeholders to have a meaningful say 4. Enable hardware wallet and Stellar-based voting: - Develop integrations to allow voting from hardware wallets - Create a mechanism for Stellar TFT holders to participate in voting 5. Implement a formal proposal and discussion process: - Require a minimum discussion period (e.g., 2 weeks) before any vote - Allow community members to submit counter-proposals or amendments 6. Communicate clearly the council operations: - Remind the community where the council documentation is - Explain the council organisation to the community in forum posts 7. Introduce special voting categories: - For farming-specific rules, give extra weight to farmer votes - For technical decisions, consider giving extra weight to verified technical contributors 8. Implement a gradual transition: - Phase in the new voting system over time (e.g., 6-12 months) to allow for adjustments and feedback 9. Regular governance reviews: - Schedule periodic reviews of the governance system (e.g., annually) - Allow the community to propose and vote on governance improvements ## Pros of Token-Based DAO Voting Process Here is a list of arguments in favor of token-based DAO voting process: **Broader participation**: Allows all token holders to participate in governance, not just farmers **Aligned incentives**: Encourages token holding and potentially increases token value as people buy to participate in governance **Proportional representation**: Voting power is proportional to stake in the network, which can be seen as fair **Increased liquidity**: May increase token trading volume as people acquire tokens for voting rights **Easier entry**: Lower barrier to entry for governance participation compared to farming **Flexibility**: Allows for more nuanced voting mechanisms like quadratic voting or time-locked voting **Scalability**: Can accommodate a larger number of participants more easily than farmer-only systems **Market signal**: Voting outcomes may better reflect market sentiment and token holder interests **Encourages long-term thinking**: With mechanisms like token locking, can incentivize long-term holding and thinking **Diversity of perspectives**: Brings in viewpoints from investors, users, and other stakeholders beyond just farmers **Potential for delegation**: Allows for the development of delegation systems, enabling more sophisticated governance **Adaptability**: Easier to adjust voting power distribution over time if needed **Familiar model**: Similar to governance in traditional finance, which may attract more mainstream participants **Farmer empowerment**: As all TFT is minted by farmers, they have first access to voting power, maintaining their influence **Natural balance**: Farmers' role in minting TFT creates a natural balance between farmers and other token holders **Incentivizes farming**: May encourage more people to become farmers to gain voting rights through minting TFT **Reward for contribution**: Farmers' voting power directly reflects their contribution to the network through minting **Organic growth**: As farmers mint and distribute TFT, it naturally expands the voting base in line with network growth **Alignment with network growth**: Voting power distribution organically follows the expansion of the network's infrastructure **Encourages ecosystem participation**: Motivates farmers to engage with the wider ecosystem to maintain influence ## TFDAO GEP Voting System: TFChain + Stellar Hybrid (Node-based + Token-based) with Passive Token Locking and Discussion+Voting Periods This system proposes a hybrid/bicameral voting mechanism that combines node-based and token-based voting (50-50 voting power). This system allows participants to vote using TFT on either TFChain or Stellar, accommodating both hardware wallet users and farmers. The process involves a passive token locking mechanism. This encourages consistent token holding. The process also involves a two-phase voting period. The two-phase voting period ensures that the community members can discuss and improve on the GEP proposition. We also make sure the community understands the goals of each GEP. 1. System Overview: - Main blockchain: TFChain - Secondary token location: Stellar network - Voting mechanism: DAO implemented on TFChain or as a separate smart contract 2. Hybrid Voting System: - Node-based voting: Based on ThreeFold DAO weight - Token-based voting: 1 TFT = 1 vote - Ratio: 50% node-based, 50% token-based 3. Node-based Voting Weight Calculation: - For each account: a) Identify all linked farms b) Get all eligible nodes per farm (see Node Eligibility Criterion) c) Calculate Compute Units (CU) and Storage Units (SU) per eligible node - Farm weight = 2 * (sum of CU of all eligible nodes) + (sum of SU of all eligible nodes) - Account's node-based voting weight = Sum of weights of all linked farms 4. Node Eligibility Criterion: - Nodes must have completed at least 1 full minting cycle with 95% or more uptime in the cycle - Uptime is calculated based on node status reports over each minting cycle - Only nodes meeting this criterion are eligible for node-based voting 5. Governance Event Proposal (GEP) Timeline: - Announcement: 30 days before the end of the voting period - Discussion Phase: First 15 days for community feedback and proposal updates - Voting Phase: Last 15 days for casting votes 6. Snapshot-based Voting Process: - At the end of the voting period, simultaneous snapshots are taken on both TFChain and Stellar - Voting power is determined based on the snapshot data, passive token locking mechanism, and eligible node-based weights 7. Passive Token Locking Mechanism: - For each wallet, determine the minimum balance held over the past 30 days - Token-based voting power is calculated using the lesser of: a) The current snapshot balance b) The minimum balance over the last 30 days 8. Implementation Considerations: - Develop mechanisms for synchronizing snapshots - Ensure capability to efficiently query historical balances on both chains 9. Advantages: - Balances influence of token holders and consistently reliable node operators - Encourages long-term high node uptime and reliability - Eliminates double-spending concerns - Simplifies cross-chain coordination - Increases fairness in voting - Encourages consistent token holding and node operation - Prevents last-minute manipulations of voting power - Allows hardware wallet usage and farmers to keep tokens in farming wallets 10. Potential Challenges: - Ensuring accurate synchronization across chains - Handling potential network issues at snapshot time - Managing computational resources for historical balance 11. Key Considerations: - Clearly communicate voting mechanism, snapshot timing, passive locking, and node eligibility criteria to participants - Ensure transparency and verifiability of the snapshot, node weight calculation, and uptime tracking processes - New wallets or those with incomplete 30-day histories cannot participate in token-based voting - New nodes must complete at least 3 minting cycles before being eligible for voting This approach aims to provide a fair, secure, and inclusive method for incorporating both consistently reliable node operators and token holders into a single DAO voting system. It encourages long-term commitment to the network, sustained high node reliability, and prevents voting power manipulation while ensuring that participating nodes have a proven track record of contribution to the network.
❤️ 1
gosam commented 2024-10-18 12:30:09 +00:00
Author
Owner
Copy Link

Wow @mik-tf – this is ... thorough! Well done. Let's discuss on Monday.

Wow @mik-tf – this is ... thorough! Well done. Let's discuss on Monday.
❤️ 1
thabeta commented 2024-10-21 13:59:18 +00:00
Member
Copy Link
  • two chains? just no.
  • Says who 50% 50% node owners and users? I'd say convert the capacity of the node to tft and use that in the voting
  • the 5% voting cap is naive, they can have multiple accounts and maintaing that threshold
  • 30 days lock = new users are less likely to be part of the process
  • 3 minting cycles = this proposal is rejected. given the amount of issues ppl have already with our minting process and their issues during power saving
- two chains? just no. - Says who 50% 50% node owners and users? I'd say convert the capacity of the node to tft and use that in the voting - the 5% voting cap is naive, they can have multiple accounts and maintaing that threshold - 30 days lock = new users are less likely to be part of the process - 3 minting cycles = this proposal is rejected. given the amount of issues ppl have already with our minting process and their issues during power saving
mik-tf commented 2024-10-21 14:57:08 +00:00
Owner
Copy Link

Update

  • As discussed with the engineering circle, it seems no "feedback proposal" can be easily implemented.
  • Decision:
    • For V3, we keep the current voting system
    • For V4, we can implement a token-based system. This will be done later when we are implementing V4.
# Update - As discussed with the engineering circle, it seems no "feedback proposal" can be easily implemented. - Decision: - For V3, we keep the current voting system - For V4, we can implement a token-based system. This will be done later when we are implementing V4.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
  
Issue

   
Question

   
Roadmap

   
Story

   
Task

   
Urgent
No Label
Issue
Question
Roadmap
Story
Task
Urgent
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Oct 14 – Oct 27
Assignees
Clear assignees
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: tfgrid/circle_promotion#294
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?