Incentive Structure

Here is a long-form draft of the incentive structure I’ve been playing around with in my head over time. This is just a draft and it is meant to get the ball rolling on how we could set up $MOONEY incentives over time:

  1. We set aside some % of our MoonDAO treasury for incentives (distributing voting power in the DAO based on contributions). This portion of the $MOONEY treasury is dispersed in a geometric series over time:
    50% in year 1
    25% in year 2
    12.5% in year 3

    and so on, infinitely.

  2. Each pay year is split into 12 payments linked to the moon cycle (we are MoonDAO afterall…)
    For example:
    Year 1 → 50% of treasury deployed, 50%/12 = 4.166% per month.
    Year 2 → 25% of the treasury deployed, 25%/12 = 2.083% per month.
    etc.

  3. We use a point system to allocate $MOONEY to people we think are doing good work. This looks something like coordinape and we allocate points to each other (but cannot allocate points to ourselves). For example, each pay cycle is distributed into 12,000 points.

We can do something like:

  • Astronauts get 4,000 points to allocate to others
  • Rocketeers get 4,000 points to allocate to others
  • MoonSettlers get 4,000 points to allocate to others

If there are two Astronauts then each person would get 2,000 points to allocate to there points. If there are 8 Rocketeers each would get 500 points to allocate to others, and if there are 20 MoonSettlers each would get 200 points to allocate to others.

  1. We define roles in MoonDAO in a bottom-up way by the contributors. The contibutors are “rolled over” from the previous pay period as long as they did some work in the previous pay period. If they stop doing work in the previous pay period they are no longer eligible to give out points, for example:
  • A MoonSettler is defined as: Someone who has contributed positively to MoonDAO in the previous pay-period (as decided – by 3 in “support” – by the Rocketeers and Astronauts)

  • A Rocketeer is defined as: Someone who has led (or co-led) a workstream during the previous pay period. Workstreams are defined by the Astronauts. Rocketeers are voted in/out by the MoonSettlers, Rocketeers, and Astronauts by a 50% majority.

  • An Astronaut is defined as: Someone who is creating new workstreams, judiciously managing parts of the DAO that don’t have procedures in place (yet – over time Astronaut roles over time will have less power as procedures are put in place), and doing high-level direction and external representation of the DAO. Astronauts can be voted in/out by the Astronauts, Rocketeers, and MoonSettlers – and a XX% majority is needed for these. (I was going to make it 70% but maybe that’s too high, I do think it’s important to make it a little difficult to add Astronauts, maybe less difficult to remove them? Like 70% to add, 50% to remove?)

At the end of the pay period we add new members and do a round of promotions, or remove contributors that are no longer working on the DAO.

  1. As the pay period goes, each contributor can start adding their points to others that they think are doing great work. The people who get points don’t necessarily even need to be in the DAO, it can be anyone that has helped push the mission forward. These points allocations are totally at the discretion of each individual and can be changed over time. All point allocation are visible and transparent (think something like a spreadsheet where only each person can modify their points but you can see everyone else’s point allocations).

  2. At the end of the pay period the point allocations are tallied up, and the $MOONEY is distributed based on the proportion of points that an individual has received. If someone doesn’t go through and allocate their points, that’s fine, their points just don’t enter into the fraction and it’s as if they simply “agree with the status quo of how others distributed their points.”

==

Hopefully all of that makes sense, all of this is up for discussion and we can tweak the definitions, numbers, until we reach something that is agreeable to people in a Snapshot proposal.

It might be worth explaining all of this on a focused call as well since there is a lot to process in this discussion and it’s important for everyone’s voice to be heard!

3 Likes

I like this idea. Do you imagine us building this or is this something that is configurable within the Coordinape system? I’ve only looked at Coordinape very briefly so I don’t know what the configuration options are.

Obviously in a geometric series we would need the market price of MOONEY to follow a similar geometric trend for compensation to be sustainable, but theoretically that would happen if we are creating value in the world and front-loading compensation. Executing on our mission accrues value to the governance token and that value will be expressed in the market.

1 Like

I think we can execute on this without a lot of dev overhead (I’m sure we’ll tweak things over time as we see what is working and what isn’t) – so for a first pass I think we could just use a Google sheet (pretty basic, I know) where you can only change your “column” for contributions.

Would be pretty simple to put together!

And wrt to the value of $MOONEY, of course, no promises can be made here, but if we devote more time and energy into the project I think that we’ll see the value of the project go up in time :wink:

New Business:

Roles

I really like how they are defined.

I’m having discomfort regarding the way roles are established for a contributor. It seems very busy - if we’ll be voting often. Let’s say someone co-leads one month, but goes to Antarctica for 6 weeks (like you do) comes back, we have to vote them back in? Same for Moon-settlers which I’m going to guess will have a lot more churn. Maybe, part of having a role implies an agreement to vote and allocate points every epoch/month.

What happens if someone doesn’t allocate their points?

And how does this work for bounties? Can someone just satisfy bounties without necessarily getting a role?

For the pro/demotion of an Astronaut - I hope we always have a mechanism for the instantiation of astronauts. I have experience with a 50 year old 100%-consensus based, “leaderless” organization, and even they have times when they mobilize astronauts - super rare, but they had to when the pandemic hit. In their case, it has to be a unanimous vote, for us 70% actually feels about right.

Now, this is an easily gameable system especially since the barrier to MoonSettler entry is so low. In a matter of months, you could vote in enough people to vote in any astronaut you want. (This is where a college of electorates comes in). We need another layer. Like the multi-sig or the judiciary. This doesn’t stop a hostile takeover but … I just remembered an article on anti-capture. Anyway, I’ll go find it and be back tomorrow.

OLD Business:

Reflecting on something @Kori said about structuring the geometric series around Phases is really interesting. This will create quicker cycles for us to gauge how well our compensation mechanisms are serving our community.

And I was wondering - why can’t someone redistribute their points to someone else? So, let’s say, I get what I think is way too much credit for something, instead of points going back to treasury or my having no way to resolve that, what if I could give my points to someone else?

I rather liked @zeroindex 's idea of people sitting around a table and deciding together how to distribute points, but the points going back to the treasury, if they exceed a person’s expectation, felt weird. This is another way folx could game the system - dump all their points in one person.

I’m wondering, what would be the absolute simplest thing we could do?

What if we ranked each other, every epoch we rank each other based on our perception of their contribution? Then we just created allocations based on those placements? Pros and cons, as Pablo would say.

One big concern I have, lightly touched on this evening, is trying to rank whose work is the most valuable by verticals - legal is more valuable than design is more valuable than web-dev … oh no no no; I recommend against that. It reminds me of a joke where all the parts of the body were trying to explain why they were the most important part - guess who ultimately won. Or in Hitchhiker’s Guide to the Galaxy where everyone dies of disease because they shipped the telephone janitors off planet.

This proposal adjacent thoughts:
We may need to have a “Community Success” person - or some mechanic for helping understand churn. It would be interesting to plot churn against $MOONEY activity/value.

Also as part of Community, for the people managing contributors and tasks - we’ll need a proper HR role - eventually. Not today.

1 Like

I’m having discomfort regarding the way roles are established for a contributor. It seems very busy - if we’ll be voting often.

Maybe we can batch these promotions at the end of the month? Group them together so we’re not voting all the time. We don’t want to do it too often, but we do want to keep things fresh.

Let’s say someone co-leads one month, but goes to Antarctica for 6 weeks (like you do) comes back, we have to vote them back in?

Hmm. Vacations are definitely fine, they just wouldn’t be included for those pay periods (say they go on a big trip for 3 months). But for things more than 3 months, I feel like the organization can change a lot quickly, so they would need to go through the regular channels to be added back in (but in this case it would be easy if they are an awesome contributor and people remember them).

What happens if someone doesn’t allocate their points?

This is fine, their points are removed from the numerator and denominator of the final summation so the proportion of $MOONEY allocated to each person does not change. No allocation means you support the status quo.

And how does this work for bounties? Can someone just satisfy bounties without necessarily getting a role?

This is cool because now people with roles can allocate capital, which means they can set up bounties for others to do their work (kinda cool). If other people start doing those bounties and get good at them then they can eventually get a role. You don’t need a role to do a bounty though.

For the pro/demotion of an Astronaut - I hope we always have a mechanism for the instantiation of astronauts. I have experience with a 50 year old 100%-consensus based, “leaderless” organization, and even they have times when they mobilize astronauts - super rare, but they had to when the pandemic hit. In their case, it has to be a unanimous vote, for us 70% actually feels about right.

Agreed. 70% in and 50% out feels right to me. Hard to put new leaders in, but easier to remove them.

We need another layer. Like the multi-sig or the judiciary. This doesn’t stop a hostile takeover but … I just remembered an article on anti-capture. Anyway, I’ll go find it and be back tomorrow.

From the adversarial side – people with roles are just capital allocators at the end of the day. They don’t necessarily have power to govern anything (necessarily), but I agree if enough bad actors get in they can start taking over the congress. Senate will be difficult unless if you just pack it with bodies. Open borders is a double edged sword. Hopefully the culture of MoonDAO will weed out bad apples from the bunch, and for this we need a judiciary for removal of people that are actively doing things to hurt the DAO. Judiciary could be a committee that is apart from the multi-sig that handles cases of misbehavior. Like a supreme court – ideally this can be done in some sort of distributed way though.

And I was wondering - why can’t someone redistribute their points to someone else? So, let’s say, I get what I think is way too much credit for something, instead of points going back to treasury or my having no way to resolve that, what if I could give my points to someone else?

That’s interesting. I guess once you get your $MOONEY you can give it away to others outside of the system. So if someone really wants to do that they can give it away that way. We can also make it so you have to “accept” the payment you’re getting (there might be some weird cases where you can’t actually accept payment for your work). So that could be done too. Maybe just a you can “claim” this much, and the person needs to go in and grab their pay. Otherwise it just sits in the treasury.

What if we ranked each other, every epoch we rank each other based on our perception of their contribution?

I mean this is basically what we’re doing, but the allocations based on payments are flexible, which I think is a plus.

One big concern I have, lightly touched on this evening, is trying to rank whose work is the most valuable by verticals - legal is more valuable than design is more valuable than web-dev … oh no no no; I recommend against that.

Well, each individual gets to have their say in this. There’s no top down, it’s just collectively determined what workstreams have been most valuable for that pay period. I think it’ll fluctuate each pay period

We may need to have a “Community Success” person - or some mechanic for helping understand churn. It would be interesting to plot churn against $MOONEY activity/value.

Yeah I can see this being a really valuable role, we need more data on health metrics of the community in general for sure.

Also as part of Community, for the people managing contributors and tasks - we’ll need a proper HR role - eventually. Not today.

Hmm. HR needs to be done right. It’s a dangerous thing to install. I fled my old company because of all-powerful HR bureaucracy. Hated it. Maybe there’s a better way, so far I think we’re doing pretty well without it though :slight_smile:

2 Likes

Pablo have shown a draft of the incentive structure.

He proposed to release $MOONEY to reward members.

Year 1 → 50% of treasury deployed, 50%/12 = 4.166% per month.

Year 2 → 25% of the treasury deployed, 25%/12 = 2.083% per month.

etc.

Here are some problem I’m worrying about:

  1. Price collapse

The number 4.166% of in treasury releasing every month is about:

2,616,124,5800.50.04166=54,493,875

But there are only 39,692,062 $MOONEY in the UniswapV3 pool at block number 14275723. That is 54,493,875/39,692,062=1.37 times. The pool is not able to undertake for even once. The price of $MOONEY will go collapsed even if a small part of them swaps. This will hurt both holders and worker paid by $MOONEY. It could bring catastrophic consequences for community.

  1. Mismatch of the rewards and the progress in overall perspective

Reward at a same speed in 12 months doesn’t meet the reality that different amount of work are done in different month, Even the number of workers and participants varies hugely in different month. We also have to consider the hardness of projects which have to pay more reward to attract skilled members to attend in.

Considering the situation of $MOONEY V3 pool and the long-term developments, I have a different plan:

  1. Reward founders and early workers with considerable amount of $MOONEY, but only one time.

  2. Spend will according to a predetermined time-line and project. Firstly, we have to work out our long-term plan in according with our mission. Reserve some fund every season for unexpected project which may find wonderful to carry out.

  3. Committee supervises the routine and project spending:

a) set and pay wages for long-term work members including themselves. Wages should be little higher than local mkt level.

b) Examine the incentive structure of project and propose to community. The incentive structure for different projects may have very different form. Reward for nonprofit projects may set beforehand. Bonus for agency members of profitable project is necessary to attract and retain them.

1 Like

How much $Mooney we have in our treasury? 4.16% is that too much or too littler consider to the actual efforts people contributed?

Agree with @Bay0.eth we should not have a fixed amount of budget every month given that the actual works may vary over time.

This is very novel & interesting idea. However, I can see some potential problems with this approach.

  • People may be overpaid or underpaid for what they are doing.

  • People tend to delay their work, and want to keep the role as long as possible.

  • People tend to promote their friends so that they can create a circle of benefits. You give me your points, I give you mine.

  • Underbudgeting the important & difficult tasks that most people don’t understand. Say Member A is doing task X, it is important and required a very rare skill set. But as it is complex, and in backend so very few people aware of that. As a result, he/she received very little point.

My suggestion is as below

  • Apply your approach for perhaps the first few cycles (months) to reward early contributors. When not enough bad actors come in & take over.

  • Have a fixed amount of budget for operating expenses. This should be based on actual effort. Say currently we have XX people actively involved on MoonDAO’s operation. Sum up amount of hours they spend per month then multiply to a wage (higher than market, enough attractive for people to participate).

  • Budget for new workstreams. The workstream leaders shall prepare a budget plan & implementation plan for his workstream and propose to community. If it is approved. Then the workstream budget is secured. Workstream leaders can promote the payment mechanism, wage that most suitable to their workstream. All payment, works are monitored by community.

  • Quarterly bonus for high performance members who significantly contribute to MoonDAO’s community. We can reserve a fixed budget for this bonus. The mechanism to allocate it can follow your approach. It is just perfectly suitable in this case.

Just my 2c

1 Like