# cDFI Governance Voting

<figure><img src="https://1186599547-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FvXh4igq8WcPa3ojldilw%2Fuploads%2F6I3Poz7UGcr9FSZ3oL1e%2FScreenshot%202024-09-13%20at%2018.01.27.png?alt=media&#x26;token=92c655d3-437e-478f-a114-0162639d137e" alt=""><figcaption></figcaption></figure>

{% embed url="<https://youtu.be/TxQAAeHBeIM?feature=shared>" %}

Auch auf Deutsch verfügbar:

{% embed url="<https://youtu.be/B2E-GCA88v0?feature=shared>" %}

## <mark style="color:blue;">Voting Power Summary</mark>

* <mark style="color:blue;">**Voting Power Definition:**</mark> Voting power in cDFI governance is determined based on a user’s wallet address and a specific blockchain block height.&#x20;
* It is the cumulative total of cDFI held:

<mark style="color:blue;">→</mark> IN Wallet

<mark style="color:blue;">→</mark> IN cDFI Staking

<mark style="color:blue;">→</mark> IN cDFI LM Positions

<mark style="color:blue;">→</mark> NOT inclusive of cDFI in external protocols (in the current version)

* <mark style="color:blue;">**Calculation Process:**</mark>
  * 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.
* <mark style="color:blue;">**Registration Requirement:**</mark>
  * 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.
* <mark style="color:blue;">**Security Measures**</mark><mark style="color:blue;">:</mark> 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.

## <mark style="color:blue;">cDFI Governance Lifecycle</mark>

The cDFI governance process follows a lifecycle similar to the on-chain governance of DVM, with key differences tailored to the cDFI system:

<mark style="color:blue;">**1. Proposal Discovery:**</mark>

• 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.

<mark style="color:blue;">**2. Proposal Submission Phase:**</mark>

<figure><img src="https://1186599547-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FvXh4igq8WcPa3ojldilw%2Fuploads%2FVlbZFjmDwnUoKGTWPFXC%2FScreenshot%202024-09-12%20at%2023.39.37.png?alt=media&#x26;token=f73cf82a-afb1-47c7-a5ec-e9dda49a1f02" alt=""><figcaption></figcaption></figure>

• In DVM, proposals can be submitted and voted on during the first half of the governance cycle (typically d0->d45).

• In cDFI, voting is only allowed in the second half of the cycle after the proposal submission phase ends (typically d45->d90). Calculated as:

<mark style="color:green;">cDFI Voting Start Block</mark> = <mark style="color:green;">VotingStartBlock</mark> + (<mark style="color:red;">VotingEndBlock</mark> - <mark style="color:green;">VotingStartBlock</mark>) \* *<mark style="color:blue;">**0.51**</mark>*

<mark style="color:red;">cDFI Voting End Block</mark>  = <mark style="color:green;">VotingStartBlock</mark> + (<mark style="color:red;">VotingEndBlock</mark> - <mark style="color:green;">VotingStartBlock</mark>) \* *<mark style="color:blue;">**0.95**</mark>*

*<mark style="color:blue;">**Working Example:**</mark>*

<mark style="color:orange;">VotingStartBlock = 4,550,000 -> VotingEndBlock = 4,680,000</mark>

<mark style="color:orange;">cDFI Voting Start Block \~</mark> <mark style="color:orange;"></mark><mark style="color:orange;">**4,616,300**</mark><mark style="color:orange;">, cDFI Voting End Block</mark> <mark style="color:orange;"></mark><mark style="color:orange;">**\~4,673,500**</mark>

• 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.

<mark style="color:blue;">**3. Voting Phase:**</mark>

• 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.

<mark style="color:blue;">**4. Votes Calculation Phase:**</mark>

• 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.

<mark style="color:blue;">**5. Votes Execution Phase:**</mark>

• 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.

## <mark style="color:blue;">Masternode Selection Process</mark>

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.

<mark style="color:blue;">**Masternode Calculation Formula:**</mark>

• The number of masternodes for each decision type is calculated using the formulas:

• Yes Votes = (Yes Voted Shares) / 20,000&#x20;

• No Votes = (No Voted Shares) / 20,000&#x20;

• Neutral Votes = (Neutral Voted Shares) / 20,000

<mark style="color:blue;">**Assignment Process:**</mark>

• 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.

<mark style="color:blue;">**Additional Measures:**</mark>

• 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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.crypto-factor.io/crypto-factor/cdfi-ecosystem/cdfi-governance-voting.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.