Incentivize governance participation

Should we incentivize governance participation? if so how?

Discuss.

3 Likes

If you mean monetary incentives for governance participation, I want to understand where is that thought coming from. Can you elaborate?

Instead of incentivizing management, today, everyone in this community should buy ens coin and hold it like btc or eth. If everyone in the community keeps it and does not sell, then 1 ens becomes 5000$. That’s when we support the management and ourselves. Hold the ens in your hand. Let’s make it together. Let the community draw attention. May both roses win :+1:

So one thing I’ve thought about quite a bit is how web3 is missing out on traditional organizational infrastructure. I know web3 is here to change and improve on how things have worked, but at the same time maybe we should not try reinventing the wheel, but reinvent whats built upon the wheel.

What I mean is that the reason every successful organization is built upon the traditional hierarchical configuration - CEO, Executive Board Members, SVPs - is because it works. Often times there are decisions which must be made and executed quickly, without the time to deliberate. These decisions can be better made by tighter groups.

Now, before I lose everyone to screaming about “The Man” and web3 breaking out of typical infrastructure, just hear me out.

We have a chance to both utilize the wheel already invented, while improving upon whats built on that wheel. With vote delegation we can arrive at a very similar hierarchical role types, but with web3 at its core resulting in a fluid and bottom-driven solution. Incentives are critical to this.

At the core of the idea is to incentivize delegation and voting. Lets say we have a pool for incentivizing participation in ENS DAO. That pool gets distributed upon each proposal to every ENS which voted. If you vote directly, you get to keep 50% of your distribution, with 50% going back into the pool. If you delegated your votes, and the entity you delegated to voted, you get to keep 99% of distribution and and 1% of your distribution goes to the entity you delegated. If you do not vote, or your delegate does not vote, you keep 0% and 100% goes back into the pool for the next proposal.

These numbers are made up and for example use only. The real solution will need a lot of discussion, game theory, testing, and likely constant tuning in real world use.

My thinking behind this, is that we want to reward delegating votes as much, if not more, than voting directly. I believe it is important to put the votes in the hands of users who spend more time researching and discussing proposals, as opposed to users who glance at a proposal and simply vote to receive incentive - which ultimately would harm the protocol.

By collecting a tiny portion of the incentives distributed to ENS delegated to you, you in turn are incentivized to participate. Further, if you do not participate, your delegates will quickly leave you as they would not receive incentives for being delegated to a non-participant.

With a scenario as I have laid out, we should quickly see ENS begin to accumulate to strong users who dedicate the time to discuss, propose, and vote. This is a good thing, because these are the type of users you WANT to be proposing and voting, those with the most knowledge. You will begin to see an organizational structure come up where an isolated few users receive lots of delegations. This is not necessarily a bad thing, as it would allow a stricter, more systematic group of users to respond quickly, when necessary, to any threats or important time-sensitive decisions. For example, if DAO proposals could be set to execute as soon as a winning majority of votes had been made as opposed to waiting for a strike time, then a “Board” of Delegates possessing enough votes to do this could coordinate together and quickly respond to any attacks or other pressing needs of the DAO.

Further, unlike traditional organizations, the ENS holders can quickly change organizational roles simply by changing their delegation.

To protect against malicious delegate-driven actors, we could:

  1. Use delegate caps. Any single delegate can only receive <=10% of total delegate votes, for example, at which point additional delegations would be disincentivized by… yep, not receiving incentives for delegating to that delegate. (again, 10% is just thrown out as an example w/o much thought given to that number)
  2. Vote-signaling. A delegate must signal their vote with a time lock. During this time lock, users are free to change their delegate status. Thus if their delegate votes against their wishes, they are free to redelegate to a delegate who signaled as they wish.
  3. I’m sure there are more ideas here!

This is really a blueprint of an idea, and not a mature solution. I welcome the discussion this brings, as well as the critiques and additions to the idea.

4 Likes