> For the complete documentation index, see [llms.txt](https://docs.renzofinance.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.renzofinance.com/governance/discussion-and-voting.md).

# Discussion & Voting

Renzo is a decentralized protocol that is governed by holders and delegates of REZ. Governance allows the community to propose, vote, and implement changes to the protocol. Members propose, discuss, vote on, and implement changes, decreasing the reliance on any centralized individual or team.

A proposal must follow the guidelines outlined in the sections below to pass. These guidelines may be updated over time as governance may choose to adjust them. Renzo Proposals can be created and submitted for on-chain voting by whitelisted wallets. Though not mandatory, it is highly recommended that a discussion post is created prior to the proposal being submitted on chain.

### Discussion&#x20;

The first step in the governance process is the discussion phase. The discussion phase is open to anyone and can be found at <https://gov.renzoprotocol.com/>.

This phase serves as the foundation for informed decision-making, allowing community members to propose ideas, debate their merits, and refine proposals before they move to a formal voting stage. The discussion phase typically unfolds in the following way:

1. Idea generation: Community members brainstorm and develop ideas that could improve the Renzo protocol.
2. Initial submission: An initial proposal is drafted and shared on the Renzo discourse group. This draft includes detailed information about the proposed change, its rationale, potential benefits, and any associated risks.
3. Community engagement: Once a proposal is submitted, it is open for discussion. All token holders and stakeholders are encouraged to participate.
4. Feedback and debate: Community members provide feedback, ask questions, and debate the merits of the proposal. This open dialogue helps identify strengths and weaknesses, allowing for a thorough evaluation.
5. Revisions: Based on the feedback received, the proposal’s author can make revisions to address concerns and clarify certain points.
6. Final draft: After revisions, the proposal is updated to a final draft. This version reflects the collective input of the previous stages and is typically more polished.
7. Readiness check: The final draft undergoes a readiness check to ensure it meets all necessary criteria and guidelines for moving to the voting phase.

The discussion phase will last five days upon the initial release of governance, but may be updated in the future.

### Voting&#x20;

The second step in the governance process is the voting phase. Voting is open to any eligible REZ holder and is currently held on [Snapshot](https://snapshot.box/#/s:renzogovernance.eth).

This phase follows the discussion phase and ensures that decisions reflect the collective will of the community. The following is a general overview of the voting process:

1. **Final proposal submission**: After a proposal has been refined and finalized during the discussion phase, it is officially submitted for voting. The final draft is made available for review by all voting members on Renzo’s voting page.
2. **Voting period announcement**: The protocol announces the start and end dates of the voting period. Upon the initial release of governance, the voting period will last five days and be subject to future upgrades.
3. **Voting eligibility**: To vote, REZ token holders must have voting power to participate in the vote. Current REZ Voting Power instances include: (a) REZ holders who have delegated: either to themselves or to another delegate. A list of official delegates are available on the governance page. (b) Legacy REZ staking contract, i.e. REZ holders who previously staked their tokens in this [contract](https://etherscan.io/token/0x3B50805453023a91a8bf641e279401a0b23FA6F9?a=0x1736011d3e075351b319dbc1da28dac68ea830a6). (c) ezREZ token holders. Note: Staked REZ and ezREZ are automatically self-delegated. If you’re just holding REZ in your wallet, you’ll need to manually delegate it to yourself or someone else to be eligible to vote.
4. **Casting votes**: Token holders with voting power can cast their votes. Depending on the REZ instance, votes are weighted on a linear basis.
5. **Delegated voting**: Some token holders may choose to delegate their voting power to trusted delegates who vote on their behalf. This allows for more efficient decision-making while still reflecting the preferences of the broader community. While there is a list of official delegates available on the governance page, users can also simply delegate to any address of their choice.
6. **Vote tallying**: As votes are cast, they are securely recorded and tallied. Votes may be cast in favor or against a proposal. Voters may also choose to abstain from voting, providing more votes to reach the quorum requirement.
7. **Quorum requirements**: Renzo has a quorum requirement, which is the minimum amount of votes required to successfully pass a vote proposal. **Current quorum threshold is 100,000,000 REZ**, subject to increase with future proposals as the circulating supply increases.
8. **Majority threshold**: Upon the initial release of governance, proposals require a majority of at least 50% + 1 vote to pass, subject to change with future governance proposals.

Result announcement: Once the voting period ends, the results are announced.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://docs.renzofinance.com/governance/discussion-and-voting.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.