I’d like to kick off a discussion on building some community norms on how to award people who contribute to the protocol. My opinion is that we should err towards being overly generous to contributors to help create and sustain interest in developing the protocol.
Baseline community standard:
I’d propose a baseline of 10 COMP to any address that submits a proposal that goes to vote
An additional 10 COMP to any address that submits a proposal that is approved
I think this should be the floor of what someone receives even if the proposal is just for a simple parameter change.
Proposal specific bonuses
On top of this baseline there should be proposal specific bonuses for proposals that required unique work. This could be requested by the proposer or recommended by independent members of the community
Bonuses for work not in proposals
Much work on the protocol does not result proposals and should be recognized and rewarded through periodic true ups. Examples of this would be things like Comp.vote, Blck’s transaction bot, Warios help with the DAI compensation proposal, etc.
Backdated rewards
To kick things off I’d like to submit a proposal to disburse rewards for work up until now. Doing that for the proposals is easy but to reward work that did not result in a proposal we will need to come up with a list. Here is my start, what else?
I like this idea a lot, separate from the incentives, having a clear mechanism to determine what the community agrees are worthwhile contributions seems like a definite efficiency gain, which alone I think should speed up iteration cycles for possible contributors.
On the backdated rewards, all I can say that comp.vote is awesome, blck is always helpful on the discord and forums, and I feel very honored and surprised to be included along with them.
Why? Things like parameter changes aren’t hard at all, take 5 clicks at most and take 10-20 usd. Yes they are needed but do they really need 10 comp?
This I think is very good, but 10comp is a bit excessive. something like 5 comp is better IMO.
YES!
Yes, I think it should get >=50 comp for it.
Y E S ! I think this deserves about the same thing as comp.vote if not more. @wario put in lots of work for these charts without expecting a reward.
Old and useful, also deserves some comp.
As I have stated before, I don’t think rewarding sai is a good idea. First, sai is basically useless; you would need to use it as plain money rather than voting. Two, sai reserves are needed! Sai is still a money market, just has no supplying interest rate. Yes these reserves are growing since people are repaying their debt, but I don’t think that this should be used over comp, especially as one of the big “brandings” for lowering comp speeds in guantlet’s proposal was so it could be used for grants.
Also just for the record I wish that the community multisig not be used for granting comp.
Much work on the protocol does not result proposals and should be recognized and rewarded through periodic true ups.
I agree with this, and have experienced first hand why this may be valuable.
Back in March last year, when governance had just been launched and didn’t yet have an interface, I quickly scrambled together a (very) basic implementation in a couple days. I figured this might serve as a good starting block in implementing a more legitimate interface, but quickly lost interest as there didn’t seem to be any incentive to continue working on it. Had it been standardized back then that community work may be rewarded, I could have seen myself continuing to iterate over it, eventually creating something with much more significant value.
To be clear, I’m not asking to be compensated for this project, but simply wanted to share why standardizing community work outside of proposals may be valuable in incentivizing community contributions.
The most expensive aspect of making a complex proposal as a dev is probably paying for audits. Even if the dev is fully reimbursed for the cost of the audit if their proposal passes, they are taking on an uncompensated risk in the case their proposal doesn’t pass. It might be help if there was a way for the protocol to pay a trusted auditor for changes which, e.g. reach the 100,000 COMP proposal threshold, without being contingent on it passing and being accepted by the protocol.
Re: “community improvements” such as comp.vote, I don’t think the proposal system necessarily fits developments that are not direct changes to the protocol. It is expensive and slow-moving, which is fine for changes to code securing user assets, but raises the barrier for other developments. I think a system that drips COMP from a separate stream (separate from the yield farming one) based on community preference (possibly some kind of separate COMP delegation system) would be good at rewarding community developments.
While I believe that the SAI should be used to burn/buy comp or at least be changed in some respect.
Lets say that another community multisig with a grants committee shall receive at LEAST 0.05 COMP a block to be distributed to contributors. I have looked around and seen many impressive projects that never made into reality because of the inadequate economic incentives.
Firstly, I think that the sole compensation for protocol efforts should now be COMP. SAI was used prior to the grantComp function, but should no longer be used. I’ll just share my point of view here as I have received multiple “bounties” from the protocol.
We should definitely have some sort of multisig that can distribute grants to non-protocol development efforts. This multisig should also have a part in spurring protocol development, maybe providing help with audits, gas deployment, and minimal compensation along the development process. I think that the major development bounty for protocol changes should still be part of the on chain proposals for the time being.
If anyone has experience running grants committees, maybe we could set one up (think like Uni grant committee). If not, maybe we can go more towards a democratic snapshot voting method? Didn’t put too much thought into this yet, but it is definitely important.