Category: Process
Author: Campbell Law
ABSTRACT
This document proposes the voting protocol for the RARI DAO outlined in “RRC-0: Introducing the RARI Foundation and Fully On-Chain Governance for RARI DAO - Process” based on a holder’s locked $RARI (“veRARI”). This document should be reviewed and considered in conjunction with RRC-0, which has been simultaneously posted at Snapshot
MOTIVATION
The main motivation behind this proposal is to create the voting infrastructure for the community to participate in the decision-making of the RARI DAO, the governing body of the RARI Foundation. The core objectives for the proposed voting system, in alignment with the RARI Foundation’s guiding values, are:
- Greater voting power for long-term lockers (Long Term Sustainability)
- Direct on-chain voting and proposal execution (Autonomy + Efficiency & Accountability)
The proposed veRARI (vote-escrowed $RARI) model is based on the notion that long-term aligned participants are willing to exchange short-term liquidity for enhanced privileges within the RARI DAO, which primarily include, but are not limited to, voting rights. This model encourages long-term oriented decision-making rather than the pursuit of individual short-term interests.
RATIONALE
As the RARI ecosystem evolves and expands, a well-defined proposal and voting system is required to gather new community ideas and provide a clear path for these ideas to be approved and implemented.
The RRC Process as detailed in RRC-0 needs an accompanying consensus mechanism. It must be fair, transparent and automated. Balancing each of these requirements is challenging: on-chain solutions make it costly to vote; off-chain solutions are less expensive, but require actions to happen outside of the platform.
This proposal outlines a voting protocol and system based on veRARI that seeks to balance the pros and cons of various voting approaches, and to hold up the RARI Foundation’s core guiding values of autonomy, efficiency and accountability, and long-term sustainability. The voting protocol based on veRARI can be found below in the following SPECIFICATIONS section.
KEY TERMS
veRARI – a non-standard ERC-20 implementation representing non-transferable voting power a holder receives upon locking their $RARI in a voting-escrow contract for a chosen period of time. Technically, veRARI is a non-standard ERC20 token implementation
Lock – an instance of locked $RARI with a specific Release Schedule. One address can have multiple Locks with different Release Schedules. E.g. one may have a Lock of 100 $RARI with a one-month Release Schedule, and another Lock of 1000 $RARI with a two-year Release Schedule.
Lock Amount – number of $RARI subject to a Lock.
Release Schedule – a schedule according to which locked $RARI are released over time.
Release Cadence – time-based intervals whereupon locked $RARI are released. The default Release Cadence shall be weekly (i.e., locked $RARI releases will occur on a weekly basis).
Cliff Period – a period in a Release Schedule during which no locked $RARI are released (i.e., the Cliff Period must pass before any locked $RARI are released).
Slope Period – a period in a Release Schedule during which locked $RARI are linearly released in accordance to the Release Cadence.
Slope – rate at which locked $RARI is released during the Slope Period in accordance to the Release Cadence.
Governor – veRARI-governed smart contract enabling the submission, voting, and execution of RRCs
Timelock – smart contract where, for the duration of the Cooldown Period, Accepted RRCs are queued for implementation and execution. The RARI Foundation’s Board will have the power to veto Accepted RRCs in the Timelock only for the specifically enumerated reasons in RRC-0.
SPECIFICATIONS
Assuming the approval of RRC-0:
Introducing veRARI
Vote-Escrowed $RARI (“veRARI”) is an extension and modification of a similar concept originally introduced by Curve DAO. The main distinction in the case of veRARI is the introduction of a Cliff Period, which serves as a period of “hard-locking” during which no locked $RARI is released.
In short, veRARI is received proportionally to the Lock Amount and the duration of such Lock, and is reduced as locked $RARI are released.
Any $RARI holder can create a Lock specifying following parameters:
- Lock Amount
- Cliff Period
- Slope
Upon creation of a Lock, a Release Schedule will be initiated.
- No locked $RARI will be released during the Cliff Period and instead, to-be-released locked $RARI will accrue and be released in a single batch upon the end of the Cliff Period.
- The Slope Period is determined as: Slope Period = Lock Amount / Slope.
See the illustrative examples below depicting three different types of Locks that are possible to create based on the parameters submitted.
- Green: Only the Cliff Period is present in the Lock, Slope is set to be equal to Lock Amount.
- Amber: Both the Cliff Period and Slope Period are present in the Lock.
- Yellow: The Cliff Period is equal to 0, only the Slope Period is present in the Lock.
Parameters
The following initial parameters of the system are proposed to be set:
- Cliff Min = 3 weeks
- Cliff Max = 104 weeks (2 years)
- Slope Min = Lock Amount/104
- Slope Max = Lock Amount
- Note: This gives us Slope Period to be:
- Slope Period Min = 1 week
- Slope Period Max = 104 weeks
The voting power of an individual Lock is dynamic and directly corresponds to the Release Schedule.
- The initial veRARI balance is determined by the Cliff Period and Slope Period
- During the Cliff Period, the veRARI balance remains constant
- During the Slope Period, the veRARI balance decreases as locked $RARI is released
Total voting power of a user is the sum of voting power of all their Locks
The illustration below depicts a hypothetical chart of how the Lock Amount corresponds to the veRARI balance
- Blue = Lock Amount during the Cliff Period and Slope Period
- Red = Balance of
Below is the initial veRARI balance formula:
- where Cliff Min <= Cliff Period <= Cliff Max and Slope Period Min <= Slope Period <= Slope Period Max
This formula consists of three main components:
-
Fixed Component – the veRARI balance a user receives regardless of the duration of the Lock
- This means, at a minimum, the initial veRARI balance will equal 20% of the Lock Amount.
-
Variable Cliff Period Component – changes to the veRARI balance depending on the length of the Cliff Period
- Increases to the veRARI balance range from 0% to 80% of the Lock Amount depending on the Cliff * Period relative to the Cliff Min and Cliff Max.
-
Variable Slope Period Component – changes to the veRARI balance depending on the length of the Slope Period
- Increases to the veRARI balance range from 0% to 40% of the Lock Amount depending on the Slope Period relative to the Slope Period Min and Slope Period Max
Note: The Variable Cliff Period Component is weighed twice as heavily vs. the Variable Slope Period Component in the calculation of the veRARI balance given that no locked $RARI is released during the Cliff Period, while locked $RARI are linearly released during the Slope Period.
A user’s overall initial veRARI balance will be 20% to 140% of the Lock Amount:
- 20% multiplier is achieved by setting the Cliff Period equal to the Cliff Min and the Slope equal to the Slope Min.
- 140% multiplier is achieved by setting the Cliff Period equal to the Cliff Max and the Slope equal to the Slope Max.
Full Implementation is below:
On-chain Governor Set up
This document also proposes a system of direct governance based on the OpenZeppelin Governor contract with a TimeLock extension contract and veRARI as the voting-enabled token. The governance user interface will be accessible via Tally, while the veRARI locking user interface will be accessible at rari.foundation.
Main components of the governance system:
RARI Token Contract - Plain ERC-20 Token used as a main foundation for governance
veRARI Locking Contract - Escrow contract holding locked $RARI and maintaining veRARI balance
- Supports migration
- Upgradable
- Voting-enabled: supports snapshotting mechanism to be able to connect with Governor
Governor Contract - Main governance contract managing Proposals, Voting, Quorum and Threshold
- Uses veRARI as the voting token
- Voting capability opens immediately upon launch
- The voting options for a Live RRC are “In favor” and “Against.” Voting “In favor” means the voter is in favor of implementing the RRC exactly as-is. Voting “Against” means the vote is against implementing the RCC exactly as-is — one may vote “Against” to encourage the author to resubmit the RRC after making changes.
- Quorum and threshold are denominated in veRARI
- Quorum is 10% of veRARI total supply
- Threshold for proposal submission is 5000 veRARI
- Upgradable
- The voting for each proposal will be open for 5 days.
- Docs: Governance - OpenZeppelin Docs
TimeLock Contract - Extension of the Governor Contract enabling the Cooldown Period.
- !! Acts as an executor so it should hold Treasury funds as well as all Admin Roles in other contracts. Tech details:
- After a proposal is passed in the Governor it can be queued for time-lock for 2 days period
- After this period is proposal is executed and the technical executor is TimeLock contract
- That means that Treasury Funds, Approvals, Admin functions should use TimeLock contract as “owner” of everything, not governor.
- Proposals that are approved by the holders of the requisite number of veRARI will enter into the Cooldown Period, during which the Board of the Foundation may reject such proposals for reasons detailed in RRC-0 and the Foundation bylaws. If the Board does not affirmatively reject proposals approved by holders of the requisite number of veRARI during the Cooldown Period, such proposals will be implemented.
- Veto right can be transferred to another wallet by governance decision
- Docs: Governance - OpenZeppelin Docs
Tally - Front-end service for submitting, voting, queueing, executing proposals
Rari.foundation - Locking Interface
- Interface for Lock creation
- veRARI calculator
- Delegation interface: to be implemented here
The illustration below depicts how different parts of the governance model interact with each other:
Contingent upon approval of RRC-0 and RRC-1, this Governance Model will be used for all proposals starting from RRC-2.
STEPS TO IMPLEMENT
Solution is implemented:
- Launch veRARI locking user-interface
- Launch Governor and snapshotting contract for veRARI
- Created specific space on Tally
- Set administrator addresses
- Set voting rules
- Opened ratification of RRC-0 and RRC-1
TIMELINE
Solution prepared and ready to be ratified
OVERALL COST
No cost to implement