sCIP#21 - DAO Role Delegation

Proposals
#1

Summary:

Allow the DAO to delegate classes of protocol changes to specific trusted addresses, and allow it the power to revoke this privilege at any time.

Abstract:

Currently every change made to Curve must go through a DAO vote and achieve 15% or 30% quorum (depending on type of change). This works great for popular issues like the veCRV admin fee sharing, however some types of votes have difficulty achieving quorum, although they may be important to get passed. This includes parameter changes and additions of new pools.

Instead of requiring the DAO to vote on every change, we can create a role and assign it to a trusted member of the community, or to a multisig of a trusted team. An example of a role might be “Curve Pool Deployer”. The DAO might vote to give Llama this role. Discussions can take place on pools the community wishes to see. Llama might poll the community via signal vote for the popularity of prospective pools. He ultimately has the power to, and is responsible for actually deploying the pool, and in the happy case, the DAO is satisfied and takes no action.

In the case where Llama acts maliciously by deploying a pool against the wishes of the DAO, a time lock prevents Llama’s actions from taking immediate affect. If the DAO can garner a quorum before the lock expires, they can overrule Llama’s deployment. In this case, they revoke the “Curve Pool Deployer” privilege from Llama and assign it to Michael.

For:

This model of selectively delegating tasks to individuals or small teams helps Curve make changes quickly and lets the DAO focus on only bigger changes to the protocol.

Against:

The DAO should vote directly on every change to the protocol, including parameter changes.

Poll:

This is part “a” of a multistep signal vote process. This step is asking if you support introducing DAO role delegation in any capacity. If there is support, the next step will be to take ideas from the discussion here and propose a single class of protocol changes to trial as the first role delegation. The final step will be to determine who the trial run will delegate to.
https://signal.curve.fi/#/curve/proposal/QmbzDxpwmmYriKMcotezqBuFtjzhf7SW5zXQmGtqfrTBrs

1 Like
#2

This is one of the areas of research for grant applicants as described here: https://news.curve.fi/more-about-ecosystem-grants/

This is a lot of work and something the team would have to consider fairly low priority for the foreseeable future even with a yes vote.

1 Like
#3

There have been several other suggestions for how to improve voter turnout that may be more suitable near term solutions. This includes free voting that is subsidized by the Curve team. Also, Michael has suggested a type of vote delegation he calls “liquid democracy” where addresses that dont vote will automatically delegate their vote power down a chain of addresses until one of them makes use of the vote power.

The core of this proposal is to gauge whether the community finds it palatable to move away from direct democracy in all cases, in favor of a representative democracy for certain types of recurring votes. I tried to lay out how representative democracy can make things easier for voters without requiring them to cede control to the trusted representative.

What I think is really cool about this system is that 1. it allows Curve to stay nimble by creating management roles. 2. It should increase transparency because these managers must communicate their intentions and actions with the DAO in order to keep their privileged position. 3. The DAO becomes more resilient because it is central to delegating power, and can shift responsibilities at any time.

If there is support for the concept of DAO role delegation, I hope it might be an inspiration for a grant applicant to help make it happen.

1 Like
#4

While I understand the desire for “nimbleness”, I’d like to identify the issue(s) that this is trying to solve; because I believe those to be mostly technical in nature and this is not a philosophical argument for a representative democracy.

It sounds like there are fundamentally two issues:

  1. Folks don’t vote because it’s too costly.
  2. Folks don’t vote because they don’t have time or time to understand each vote.

I think you identified @WormholeOracle both “free” voting via some other mechanism than today and Liquid democracy which solve the issues above respectively.

So, the question becomes, can those two things be achieved in an amount of time that makes the effort to consider a different voting model too costly. I think yes personally and I’d like to see more discussions about how to get there…I’m not seeing them and feel like we’re all waiting for someone to take ownership…shall we?

#5

I think this is a philosophical question more than a technical one. Liquid democracy produces a different sort of power structure than a representative democracy. Depending on your perspective, liquid democracy offers more possibility for active involvement by not formalizing any kind of organizational/power heirarchy. Or, as I see it, it leaves a void open that can create confusion as to who is in charge of developing Curve. Right now, it’s pretty clear. We have the core Curve team working hard to develop and make the most informed strategies for how Curve progresses, and the DAO mostly confirms and gives feedback to the core team’s plans. What if suddenly there were no core Curve team and the DAO has to make its way on its own?

That’s why I prefer vote by representation. It seats the DAO in a central position to assign roles to qualified individuals and teams. If someone fails in their duty or more roles are required, the DAO can shift responsibilities and delegate a wider range of duties. This avoids the risk of a power void that could paralyze progress. You could make the argument that so long as Curve produces value to people, volunteers will come forward to fill that void. But I’d rather the DAO be in the driver’s seat instead of just kind of hoping that motivated people keep coming forward.

#6

The thing I don’t like is the perception that it inverts the voting system. Now instead of voting to pass changes, which by default will fail, it’s a system of veto power. If for whatever reason people were unable to cast a veto vote, the default would be to enact the change…

In RE to “who is in charge of developing Curve” per the liquid democracy. Do you not feel that if a graph visualization existed that showed all relationships that would be satisfied?

#7

There’s a tacit agreement, not immediately obvious to an outsider seeing how Curve is structured, that a small core team is responsible for carrying the development of Curve. The DAO makes itself vulnerable by not formally mandating that team their responsibilities. A mandate creates clarity about the relationship and the expectations, and it also makes it clear to everyone what types of roles are needed to keep Curve operating. That helps the DAO find replacements when it loses people.

Whether you have a voting system by enacting or by vetoing, right now the core team can technically push through anything they want. Occasionally they are unable to because of voter apathy (fail quorum) rather than opposition to their agenda. I’d rather mandate them to do what they think is good for Curve, and if for some strange reason they start betraying our interests, then at that point veto them out of power. It’s built on trust in the Curve team in either vote system, but by vetoing we only require the DAO when we are REALLY unhappy. In which case you won’t have a problem getting people out to vote.

#8

there is nothing right now that needs immediate attention or reaction by a group of trusted individuals.
one example of would be something like yearn vaults where it’s in everyone’s interest to have people available to stop/change strategies if problems arise.
Curve also has community grant dao members who now have the ability to move without full dao votes. (which means the current signal vote is kind of weird because we already have a delegated group)

Basically if we need an agile group for something then sure, voting on said group is fine. but curve doesn’t have/need anything right now that requires day-to-day watch/management. Changes to A param and new pools definitely do NOT fall in this category and are absolutely fine with full dao votes.

also the overrule mechanic could be useful to have if you went down this road buts its definitely not “good security” as mustering the block is harder than deploying the attack.

now if we’re just talking about increasing vote turnout, i think there’s other things that need to be explored first, specifically things like free L2 voting etc.

#9

The purpose of this proposal isn’t really just about increasing voter turnout. It poses a question about the role the DAO plays in governance. And, by the way, I’m not posing the question assuming Curve is destined to remain #5 on defipulse forever. I’m assuming Curve outgrows the DAO’s ability to reasonably govern it directly.

I see two ways it can scale.
One way is there is a company that asserts control over the development and operations, and Curve is sort of the product of that company. In that case, the DAO is at the mercy of what decisions that company makes. People can laud the virtues of direct decentralized governance all they want, end of the day DAO lives and dies by the decisions made by the company.
The other way is that the DAO takes the reins by asserting that it IS the company, and it has the right to hire and manage the people it needs to help it grow. In the second case, the DAO’s role is not to handle protocol changes/upgrades directly. It’s to manage the people who are responsible for handling those details.

The second way is more exciting to me, it’s the way I think is in the interests of the Curve team and community, who all want to see this thing succeed in the long run. I see the second way as the anti-fragile, resilient way.

#10

just sounds like a topic that will work itself out down the road when stuff is too big to manage, or need daily maintenance.

but “protocol changes/upgrades” is definitely what the dao should be doing. so i STRONGLY disagree here. things the dao can do beyond that is giving delegation for daily maintenance/quick reflex(ex. yearn vaults) or hiring/rewarding development of contracts or eco-system (grants etc)

point is when we need the flexibility this topic will come up again but right now it doesnt really make sense to me. we dont know what kind of roles and what permissions these future groups will have so discussion is kind of moot.

#11

Thanks to everyone who voted! There was strong support for the ideas laid out on this proposal, but not enough votes to meet quorum. I hope to see continued discussion around delegation and how we as a community conceptualize the role our DAO plays in decision making!

2 Likes
#12

Thanks for the continued challenge to the status quo @WormholeOracle! I look forward to your next proposal.

2 Likes