Ownership Vote 217 proposes to add the GaugeManager extension to both the stableswap and crypto factory ownership proxies, enabling permission-less reward management for factory gauges.
Abstract:
The GaugeManager extension can be found here along with its minimal set of tests here.
Currently, the only way third-party rewards can be added to factory deployed gauges is via a governance vote or with the assistance of a core team member. Adding this contract will enable gauge creators to bypass both, and simply manage gauge rewards themselves.
Note: the gauge manager will only be able to add new rewards, and grant distribution rights. Gauge managers do not have control over the distribution period, or the ability to claw back rewards once given to the gauge.
Ok the title really gave me a scare because permissionless reward management would be bad.
When browsing through the contract it looks like we would give someone a gauge manager role (thus this is permissioned)
My question is, if someone wants to add a reward we would have to vote to give someone a manager position anyway so why not just vote for the reward in the first place?
Is this a high in demand feature? I don’t see what the trouble is for having someone submit a proposal to add their rewards.
Why do we want to give a role and trust some manager entity to do these infrequent tasks?
I think it’s better to just let it pass through the dao normally
Ah I do see now that the deploy gauge sets the gauge manager by default to the address which deployed it.
Still question the real need for this? Like I’ve deployed various pools’ gauges on their behalf which would make me their managers in this setup.
People could also add certain rewards that affect various systems that might not be obvious to these managers etc. Seems like the safe thing to do since this affects the Curve system in a general sense is to still have dao vote for it.
If someone wants to permissionlessly add rewards for whatever reason they can make their own staking contract etc too
Yes. Requests for assistance to add rewards to factory gauges has been very consistent. In fact, frequent enough that despite the lack of documentation surrounding reward management on gauges, someone wrote up a slide deck on the entire process. And since then a couple of projects have referenced those slides when asking clarifying questions to the core team.
For most projects I agree. The actual reason why the extension was written was because the Liquity team wanted a seamless/painless/trustless way to deploy their gauge and then instantly add rewards during their deployment. So basically a contract will manage the rewards for their gauge. Further details I do not know.
Generally speaking though, the issue is time. The delay between putting up a proposal, having a vote, etc. etc.
Not sure how to answer this one I can say that this system is already in place on sidechains and built-in to the sidechain gauge factories. The deployer of a gauge controls the reward management (adding rewards + granting distributor rights). I don’t think this is a red flag though.
Very true. I think however for a majority of projects the fact that curve gauges have this built-in, plus their history of success, makes it more desirable to use the gauges to create a staking contract. There’s also the fact that having a proliferation of staking contracts would open LPs and stakers to counter-party risk. They now have to trust a project created their staking contract correctly, as opposed to trusting that curve factory gauges (which have that history). Lastly, most projects aren’t competent enough to make staking contracts themselves, deploy them, or manage them. Having this feature on curve gauges, gives projects something they can’t shoot themselves in the foot with, or shoot stakers in the foot with.
p.s.
Also, this sounds good on paper, but really the DAO would just rubber stamp stuff. It would just be theater, and a delay. (theater in the sense that people just see rewards and click yes, or wait for someone else to tell them to vote yes). That and, I’ve yet to see a reward vote go up, it’s just a hindrance to most.
I can say that this system is already in place on sidechains and built-in to the sidechain gauge factories. The deployer of a gauge controls the reward management (adding rewards + granting distributor rights). I don’t think this is a red flag though.