EDIT 2: As many members requested to reduce the collateral to debt reward, it will be set to 20% for collateral and 80% for debt.
EDIT 3: A clarification that the Genesis backstop consist of 3 members.
EDIT 5: the mining rate per block was updated to 0.47564688 BPRO per block to reflect 250k BRO minting per 3 months.
A week before the binding on-chain vote for the new governance, now is the time to discuss how the Genesis governance will evolve to include more users, developers and liquidators (via token minting).
Other than the token distribution, the community should also reach a consensus around the decision making process post the Genesis vote, e.g., off-chain voting with multisig execution, and how future Jars will be distributed.
We start by considering a plan for the token distribution, then discuss a mechanism for future decisions, and finally suggest a way to distribute future Jars.
The objective is to reach a consensus and make the needed adjustments before formalizing it with an off-chain voting, and then to put it into an on-chain vote on April 26th.
- 500,000 BPRO to Current (*) Maker integration users, proportional to their mScore. E.g, a user that has 0.1% of the total mScore will get 500 tokens. (*) snapshot will be taken on April 26th.
- 500,000 BPRO to Current (*) Compound integration users, proportional to their cScore. E.g, a user that has 0.1% of the total cScore will get 500 tokens. (*) snapshot will be taken on April 26th.
New BPRO tokens will be minted for a minimum period of at least four years. The minting will occur in every block, and for simplicity we discuss the expected minting according to time periods.
1,325,000 BPRO per year will be minted into a Reservoir contract, which will be under the control of the DAO, and will be used to on-board new participants into the governance, in any way the DAO will see fit.
825,000 BPRO per year will be distributed for devs. In the first year this will be sent to an address controlled by by the founding team, but the founding team will not vote.
- 250,000 BPRO for new (and existing) users, for a 3 month period. After that, the DAO may decide whether to use a portion of the Reservoir to allocate governance tokens to new users.
- 150,000 BPRO for the current Genesis backstop, which is composed from 3 entities, for a period of 1 year . After that, the DAO decide whether to use a portion of the Reservoir to distribute more BPRO to the backstop.
The governance smart contract will be the one currently used by Compound Finance (Bravo) for on-chain voting. For off-chain votes, snapshot.org will be used, and a selected multisig will execute the decisions voted by the token holders.
Initially, on-chain voting will only be used to replace the selected multisig, if it misbehaves.
A Quorum of 250,000 BPRO will be set, meaning that in order to approve a proposal, at least 250,000 tokens will have to vote in favor.
A Proposal Threshold of 2,500 BPRO will be required for a user to create a new proposal. Using Delegation will enable users to delegate their voting power to other users, enabling them to propose once the threshold is met.
Once a proposal is placed it will have a two days Voting Delay before voting can begin and a five days Voting Period to reach the needed quorum for it to pass.
A two days Timelock period will be set for successful proposals before they will be executed.
We welcome additional discussion/suggestions on the initial quorum and other parameters.
The off-chain voting would be used to give execution instructions to the multisig, in particular on-boarding new liquidators, and on user incentives.
In addition, the multisig will initially execute the DAO’s decisions regarding the Reservoir tokens.
In the absence of an execution mechanism to off-chain votes, it is imperative that proposed decisions will be precise, and to formally define the decision mechanism.
The proposal is that initially only yes/no decisions could be voted, and that a 250,000 BPRO quorum will be needed.
This mechanism could be changed only if a 250,000 PRO quorum will vote, on a yes/no decision, on a new decision making proposal.
Alternatively, a change could be made by voting, on-chain, on a new multisig that will adhere to different rules.
We welcome additional discussion/suggestions on the initial mechanism.
It is proposed that the initial multisig will be composed of the 3 genesis backstop members (and to reduce their workload, every time 2 out of the 3 liquidators will serve as key holders in the multisig), and one key will be held by one of our developers who will provide technical support. In order to execute a decision, 2 out of the 3 multisig key holders will have to sign.
The multisig will control the liquidation proceed parameters, which will be decided by the DAO. Despite an appearance of a conflict of interest, the security model is not being weakened. While a malicious backstop could nullify all proceed sharing, this is no different from a malicious backstop that simply stops liquidating (leaving the proceed sharing at 0).
Conflict of interest may arise if a malicious backstop refuses to on-board additional members, and in that event, the DAO would have the ability to revoke the multisig power by an on-chain voting.
It should be noted that in any period, the multisig will not have any control over the user deposited funds.
Further to the recent community discussion, users will accumulate both non- transferable score and transferable governance tokens. The non-transferable score will be used for the liquidation proceeds distribution (the Jar), and the token will only be used for voting.
If the initial liquidity mining program is approved, then in every block (for the first 3 months) roughly 0.47564688 BPRO and score will be minted in every block, and will be divided to users according to the proportional USD value of their collateral and debt.
For this purpose, in every block 4/5 of the block allocation will be given out according to the proportional debt value, and 1/5 will be given according to the proportional collateral value.
For example, if the protocol total debt is $50M, and a user has $1M debt, then in every block he will get (1/50 * 4/5 * 0.47564688) BPRO and score. Further, if we assume the total deposits are $100M and the user has $3M deposits, then he will additionally get (3/100 * 1/5 * 0.47564688) BPRO and score in every block.
EDIT: Discussion about Jar distribution post Genesis vote
Each protocol (namely, Maker and Compound) will have its own Jar, and a Jar will be distributed according to the non-transferable score whenever it holds more than $50k in value. Whenever a Jar is distributed, the user score is reset to zero.
The score and BPRO allocation, will be executed by the multisig on a weekly basis, and will use BadgerDAO implementation for that.
The allocation for the period between the beginning of the on-chain vote (April 26th) and the end of the vote will be retroactively distributed after the vote ends.