cDFI Governance Voting
Governance extension allowing cDFI holders to vote on DeFiChain governance proposals
Last updated
Governance extension allowing cDFI holders to vote on DeFiChain governance proposals
Last updated
Auch auf Deutsch verfügbar:
Voting Power Definition: Voting power in cDFI governance is determined based on a user’s wallet address and a specific blockchain block height.
It is the cumulative total of cDFI held:
→ IN Wallet
→ IN cDFI Staking
→ IN cDFI LM Positions
→ NOT inclusive of cDFI in external protocols (in the current version)
Calculation Process:
Voting power is computed for each governance cycle separately.
Once calculated for a given cycle (cycle Z), the voting power remains fixed until the cycle concludes and votes are executed.
For subsequent cycles, voting power is recalculated based on updated cDFI positions.
Registration Requirement:
Voting power calculations occur simultaneously for all registered wallets at the start of the voting phase.
Registration is mandatory for participation in the on-chain snapshots of voting power.
Wallets that fail to register before the voting phase begins are ineligible for that cycle and will have zero voting power.
Security Measures: The registration and snapshot mechanism serves as a protection against token-related attacks, ensuring fair calculation of voting shares.
This system ensures that voting power is accurately and securely represented for each registered participant in the cDFI governance process, with recalculations at each new cycle to reflect updated wallet positions.
The cDFI governance process follows a lifecycle similar to the on-chain governance of DVM, with key differences tailored to the cDFI system:
1. Proposal Discovery:
• Proposals are periodically scanned and indexed from the chain when they appear in an “Open” state.
• Indexed proposals are then made available for processing within the cDFI infrastructure.
• Unlike DVM, there is a slight delay in cDFI for proposals to appear due to this indexing step.
2. Proposal Submission Phase:
• In DVM, proposals can be submitted and voted on during the first half of the governance cycle (d0->d45).
• In cDFI, voting is only allowed in the second half of the cycle after the proposal submission phase ends (d45->d90).
• Proposals are visible during the submission phase but show a message: “Voting is not enabled yet for this proposal.”
• A snapshot of voting power is taken when the governance cycle is published, and this snapshot remains unchanged until the cycle concludes, preventing same-token attacks.
3. Voting Phase:
• In DVM, the second half of the cycle allows for voting but not for new submissions.
• In cDFI, this phase begins by publishing proposals on EVM for voting and creating a voting power snapshot.
• Voting is permitted for most of the second half, but the cycle ends a set number of blocks before DVM’s voting phase concludes to allow time for vote execution.
• If all registered voting power is used up before the phase ends, voting concludes early, and execution starts to expedite the process.
4. Votes Calculation Phase:
• This additional phase in cDFI governance involves calculating the total voting power of registered cDFI holders.
• The process involves determining the number and selection of masternodes that will participate in the orchestration of the voting.
• This phase must occur before the end of the DVM voting period.
5. Votes Execution Phase:
• In this final step unique to cDFI, votes are executed on-chain, with ongoing monitoring to ensure correct vote execution from the selected masternodes.
• This lifecycle structure accommodates the unique requirements of cDFI governance, ensuring secure and efficient execution of voting processes while aligning closely with the DVM governance model.
Following a successful voting phase, the cDFI governance system proceeds with the votes calculation phase, where it determines the number of masternodes required for each decision type and assigns them to available masternodes for vote execution.
Masternode Calculation Formula:
• The number of masternodes for each decision type is calculated using the formulas:
• Yes Votes = (Yes Voted Shares) / 20,000
• No Votes = (No Voted Shares) / 20,000
• Neutral Votes = (Neutral Voted Shares) / 20,000
Assignment Process:
• Once the required number of masternodes is calculated, they are assigned starting from the newest masternodes to the oldest.
• Assignments follow the order: Yes votes first, followed by No votes, and then Neutral votes until the calculated numbers are fulfilled.
• Prioritizing newer masternodes helps mitigate the impact of any resignations that may occur during the calculation and execution phases.
Additional Measures:
• Extra precautions are in place to handle any resignations that occur during the calculations or the execution of votes, ensuring continuity and accuracy in the voting process.
• This process ensures that the act of voting is orchestrated effectively, with appropriate distribution and assignment of masternodes to execute the votes based on calculated needs.
