💫Fiscal Policy and Treasury Management
Fiscal Policy and Treasury Management
The Treasury Pool receives platform fees and redistributes them through the Reward Protocol. Pledging and minimal in-ecosystem fees stimulate growth. Strategic fiscal policy aims for stable token appreciation.
Token Governance:
Recognizing the importance of decentralization, a foundational principle in blockchain networks, Rebels Revolt will initially function as a centralized entity. However, our vision is to evolve into a fully decentralized platform governed by DAO members through a dedicated governance token derived from the $RBLS token. This transition aligns with our commitment to embracing decentralization and democratizing governance.
The governance process involves proposal, discussion, voting, auditing, and implementation stages, with participation open to token holders.
Democratic governance.
The governance model of Rebels Revolt is based on democratic principles. Each user has a voice in the functioning of the ecosystem and can help shape its future direction.
Initial stage: Rebels Revolt is complete control until the protocol is stabilized. No voting is done; issues and events requiring hotfixes can be attended to immediately.
Partial decentralization: Rebels Revolt is still in control of critical aspects of the platform. However, non-critical issues can be put to the vote democratically. Voting can be on-chain or off-chain, depending on the implementation.
Decentralization: The platform is now fully decentralized. The DAO makes all decisions through on-chain voting.
Governance Process:
Roles & Responsibilities
For effective functioning, many roles come together to make up the DAO. At a minimum, the following positions will exist:
Role
Responsibilities
Core developers
Provide bug fixes, protocol development & implementation, technical support, and help maintain high coding standards.
Community managers
Community managers help with the smooth functioning of digital communities. They are the stewards of the community—Responsibilities include inducing new members, responding to questions, and managing social platforms like Discord & Snapshot.
Voting members
While anyone can create a proposal for change, voting is restricted to token holders.
Council members
The council members audit proposals for change and code implementation to ensure no security lapses on the platform. They may be part of a core community (e.g., multi-sig), which may take emergency actions, like shutting down, on a majority vote.
The chart below shows a high-level view of the governance process:
Stage 1: Discuss
$RBLS allows anyone with an idea to improve the protocol or change parameters. The first stage involves testing the waters to minimize spam and load on users. Post your opinion on the $RBLS community channel, and the user who initiated the idea will promote the proposal.
Wait for at least 72 hours to gauge the audience’s reaction. If the initial reactions are positive and encouraging, the user can then take the next step of putting the idea to a formal vote.
Stage 2: Vote
The voting process can be on-chain or off-chain via a platform like Snapshot. The project team will decide on the modality when the project moves into the partial decentralization stage.
While anyone can create a proposal and put it up for a vote, only token holders will have the right to vote. To avoid spam, the proposal creator must deposit $RBLS tokens (the equivalent of US$50) before creating the proposal. At their discretion, the project team may waive the fee in the initial stages of the project. Subsequently, the DAO decides on the cost required to create a proposal.
The voting will last for five days. The proposal must reach a minimum threshold for it to be considered valid. There are two thresholds to be factored in:
Quorum: At any time, 100% of the voting power is represented by the circulating supply of $RBLS tokens. The quorum means a minimum of the total voting power available to vote for the vote to be valid. For instance, if the quorum was 25% and the circulating supply was 100 million tokens, then at least 25 million tokens represented by the token holders must participate in the vote. If the quorum is not met, then the proposal is discarded.
Support: Support represents the minimum % of the quorum in favor of the proposal. As in the example above, if the support threshold is 50%, then the submission must garner the support of at least 51% of the voters. Else, the proposal is rejected.
Considering that not everyone will actively participate in votes in the early stages, the quorum and support thresholds will be small. Eventually, the DAO can define and change the threshold.
Note: Voting will be prohibited in the initial stages. During partial decentralization, non-critical aspects are put to the vote, while the core project team decides necessary items without any voice. The decision of what’s critical and non-critical finally rests with the core project team during the initial and partial decentralization stages.
Stage 3: Audit
Even though a proposal has garnered enough support, it doesn’t necessarily mean it will be implemented. After a valid vote is passed, the recommendation enters an audit phase, where the core developers, along with other people necessary, conduct a security audit of the proposal. Any concerns (technical, business, security, or general) may be raised during this stage, and relevant stakeholders will be asked for their views and opinions. The team carefully examines any adverse effect of the change – for instance, vulnerabilities, malicious intent to drain funds, etc.
If any adverse effect is detected, the core developers (and council members) may veto the change, even though the proposal has passed successfully. The veto will be explained with clear reasons for rejecting the proposal.
If no concerns are raised, the team estimates the time and resources required for execution and seeks the budget for implementation. The budget approval process may go through a vote, too. The DAO can decide limits on which budget approvals will be auto-approved or put for a vote.
Stage 4: Implement
Lastly, once all stages are crossed, the proposal is implemented.
Last updated