Summary
With the end of the period approaching, it is time we established how to distribute retroactive rewards.
With the DAO expressing badges not being a priority, suggest simply voting after the final mint of the period on different categories where members can distribute their voting weight. The team would then tabulate the distribution according to the weights and allow the DAO to make a final approval.
Steps
Weighted vote on categories:
- Days voted
- number of fragments voted on
- number of Boosts
- number of Winners voted on before leaderboard (if possible)
- VP spent in each round (doubles up on active rewards)
- number of gov proposal voted on
- buy back & burn $BOTTO
- send to treasury
Divide up retroactive rewards pool among categories and weight by rounds participated in
- E.g. If “days voted” got 10% of the vote, 10% of the retroactive rewards pool would be distributed to voters based on the proportion of days voted relative to everyone else.
Background
In BIP-14 that established the parameters of the second period, we introduced direct distributions of revenue. There was significant debate about how to go about it, and so two systems were established: active rewards and retroactive rewards.
Active rewards are 25% of revenue distributed each round to voters weighted by the amount of voting points they spent. This was coupled with a change to voting point generation such that everyone generated voting points linearly where 1 $botto = 1 vp generated per week, and removing a cap on voting points such that it could be easy to vote as much as you desired on one fragment.
Some members disagreed with this because of how it favored whale voting behavior to pick favorites rather than provide a diverse amount of feedback across many fragments. The counter to this was that there was still strong incentive alignment by whales to give Botto good feedback, and so active rewards for voting points spent won a good deal of support.
Retroactive rewards were established to give the DAO an opportunity to decide on the other 25% of revenue at the end of the 12 week round and the available hindsight of what was seen as valuable contributions and potentially reward more diverse behavior.
BIP-14 and other discussions proposed a badge system to help facilitate this such that it would be easy to see different types of contributions to inform what to reward.
That system was not set up or agreed on in BIP-14, and when a sketch of that system was put forward, the response of the community was that it was not a priority over other systems like setting up vBOTTO. (Side note: the feedback was not that it wasn’t wanted, only that other improvements were a higher priority. Further, an establishment of vBOTTO could allow for a badging system, soulbound or not, to be implemented permissionlessly.)
The DAO must now decide how to distribute retroactive rewards. It may also want to consider if this is the revenue distribution process it wants to keep going forward.
Specifications
A. Defining categories to reward
Distributing rewards will be most straightforward if we pick behaviors that can be proportionately rewarded. We can also only reward behaviors that have been tracked throughout the period, and so the onboarding bounties are a good reference to start with.
- Days voted
- number of fragments voted on
- number of Boosts
- number of Winners voted on before leaderboard (if possible)
- VP spent in each round (doubles up on active rewards)
- number of gov proposal voted on
- buy back & burn $BOTTO
- send to treasury
Divide up retroactive rewards pool among categories and weight by rounds participated in relative to others.
B. How to vote
We can choose to spread votes across multiple categories such, and portion out the revenue distributions accordingly. Snapshot allows for this mechanism.
The team can then provide an accounting based on the distribution of voting before executing.
This vote should happen after the Period ends so as to not allow easy gaming.
Timeline (tentative, may be pushed back to review scenarios)
Now-Jan 31 - Discuss and finalize prop, add/remove categories as needed
Jan 31-Feb 2 - Weighted vote
Feb 3 - Final Tabulation
Distribution prior to new Period