Contractor Swarm 🪴

[gabi]

Current Problems

1. Contributors have lower income rates than the market rates.
2. Contributors do not have a sense of stability as a consequence of variable monthly income.
3. There is a lack of long-term alignment with the project.
4. The loss of good people to better incentives should be addressed.

My Thesis

1. We should offer better rates to stay competitive with the market.
2. This issue is inherent when working on a DAO structure. Regardless there is a specific group of contributors that aligns well with a traditional payroll + equity scheme.
3. We need to create a mechanism that gives contributors a long-term perspective.
4. Motivation is essential, and I believe we still need to think harder about how we can adjust the incentives to the goals outlined in the Covenant.

Proposed Solution

Create a new way to compensate core contributors with a fixed monthly payroll and the option to receive a percentage in equity.

I believe this solution complements the existing ways to get compensated. In particular, I think it addresses the above points as follows:

1. We can raise the rate of contributors and attract new talent because core contributors will be on the payroll. Also, note that we can consider blacklisting incentives like pollen for people on payroll as a way to make it more appealing to all community members.
2. Core contributors get financial stability.
3. The solution gives the option to receive a configurable % of the payroll on equity, building a clear incentive for long-term alignment.
4. Higher rates and a payroll + equity scheme are more competitive incentives. With payroll, we have a better way to compensate multidisciplinary contributors that help across swarms.

Implementation

v1

An Aragon organization will have a list of members that vote on who to add/remove from payroll.

The payroll application is configured with two tokens: a denomination token (WXDAI) and an equity token (Nectar). Nectar will be a new token exchangeable 1:1 for HNY in the future (at the end of vesting).

There are some extra configuration parameters that we should discuss and decide on as a community:

• Equity multiplier: the multiplier that equity gets vs denomination token. For example, if we have a multiplier of 2 with a payroll of 1000 WXDAI, and we decide to receive 50% in equity, then we will get 500 WXDAI + 1000 WXDAI worth of HNY, minted as Nectar with the corresponding vesting.
• Vesting duration: the time duration of vesting
• Vesting cliff: the time at which vestings cannot be claimed.

We also have to decide as a community the payroll amounts and if we plan to have different payrolls for different roles.

v2

We will integrate with Celeste, allow anyone to add/remove members to the payroll, and make that action challengeable.

Technical Details

We have to modify the current version of the payroll app to include the HNY price oracle to the _transferTokensAmount method, so we can keep the Nectar <> HNY 1:1 relation when new payments are made.

[ceresbzns]

This makes a lot of sense.

I was hoping you could expand on a few points, if you have thoughts:

• What is the reason for using Nectar rather than just vesting HNY? Is to enable payroll-app to mint new tokens without having to draw directly from the Common Pool?
• How should we go about deciding who gets to be on Payroll Swarm?
• Why use an Aragon org? The interface is painfully slow and sometimes inaccessible. There are a few other multisig and DAO platforms available - could we choose a different one?
• What is the definition of core contributor for the purposes of eligibility for payroll?

[altcoins]

This is a well-reasoned, thoughtful, and compelling approach to the issue at hand. Well done, @gabi. You have the backing of my very modest HNY stack

[sem]

I’ve mixed feelings about this proposal.

On one hand, I think it would be valuable to provide stability to those core contributors who choose being paid via a payroll. Taking care of the hive is taking care of the bees, at the end.

On the other hand, I’ve these concerns with the current proposal:

1. People that is chosen by the community to perform a specific role can feel legitimate to decide over things they shouldn’t. It is very important not to build and fund a bureaucracy that then it is going to be very difficult, or even impossible, to remove.
2. It is going to be difficult to decide as a community who is in and who is out of the payroll. One of the cool things about 1hive is that we don’t need a support of 50% of the community to fund things. Conviction Voting can be used to fund small initiatives with small support if the supporters are patient enough. I think the payrolls should follow a similar philosophy, not to seek an agreement of the majority of the DAO, just enough support to be useful.
3. Celeste should not be the entity who decides who is in a payroll. Celeste is not specific of 1hive, as it is going to be used by multiple 1hive-independent DAOs. The purpose of Celeste is to help decide an outcome based on a previous agreement made by the members of a DAO, but (and that’s very important) not to govern the DAOs that use it. We need to establish a separation of powers between each specific DAO governance tokens and Celeste. Celeste could then be used to decide if a specific work has been completed with enough quality (using as evidence the initial proposal and the presented work) and stopping payments in case that they do not meet those requirements.

Having that in mind, I think that it is still valuable to advance on provide financial stability to core contributors of 1hive. I think that making some use of the payroll app would be interesting, but we have to make sure that any initiative that starts to be inefficient will fall for the good of the hive. It would be disastrous to institutionalize a political caste that parasitizes the community in any form.

Let’s discuss about it to find a good solution.

[willjgriff]

@gabi

An Aragon organization with a list of members that votes whom to add/remove from payroll.

The members will also have to agree what other members salaries will be. Do you expect there to be a payroll app for each Swarm or 1 for the whole of 1Hive? If a swarm wants to experiment with Payroll then I encourage them to do so within their swarm but I think a global 1Hive payroll will be difficult to coordinate. How will we decide who the multisig owners are? Who should get a salary? The process for removing someone who is no longer contributing? What constitutes contributing within different domains (since it’s across the board)? I think at least these questions need to be answered.

[Eth_Man]

Funny it took Maker over a year before they formalized Core Units and Core Unit positions.

I am still waiting for formal statements of what the Core Unit Authority and Responsibilities are. In anything like the above what will come up (I can 100% guarantee this) is how one manages performance, and who and how a judgement is made regarding performance. This leads to the biggest issue which will be how to deal with someone in a formal position that is not performing? Or the more usual why someone got a higher bonus than someone else.

Finally I have been pointing out work should be paid for in xDAI and this should be done by selling HNY communally vs. just doling it out and letting people choose whether to hold or not. HNY should be a bonus for recognition of work above and beyond - as a bonus - or potentially as a payment in conjunction for work done/ time put in whatever. This HNY should vest over time (Maker is using 3 years) so the worker has to stay in good standing or lose their bonus rewards or at least some portion.

Also these HNY that are paid should be in options with a strike price so the worker has an incentive to help the company perform vs. just getting free money.

I had brought up in Maker for quite some time to build a treasury to create a fund to provide employees (or people taking up Core Unit positions) some reasonable certainty they have future funding in escrow in a well managed secure treasury. The idea of just pulling from surplus whenever money is needed creates issues if surplus is 0, and MKR has to be sold. Which would be again a reason for 1Hive to think about building a treasury that has some stablecoins and methodically selling HNY (DCA) on the market and/or taking income and instead of burning HNY buying xDAI to build some stablecoins.

Maker is still struggling with the idea of a treasury, in fact almost every other DAO I know if is in one form or another. Paying for work also still an issue generally.

I already know this complicates conviction voting. Also there is an appeal of just setting a HNY price and HNY using CV to authorize a go-ahead of a project.

Honestly what I would like to see is not necessarily a payroll but some guarantees of amount of xDAI worth of work to key people the DAO wants to retain that basically get first shot at HNY for work available in proposals. This I think is more aligned with how 1Hive works generally and probably is easier to implement and manage than basically doing a formal Payroll.

I already know dev rates are low. And don’t even get me started on what my multiple degrees, 15+ years of consult experience in over 200 companies as team lead, as well as what my current employ pays me hourly is worth. Point here is that if someone can make more money elsewhere than here - frankly I think they should move on to that position or the DAO should step up. I mean some devs with right experience could easily be worth $100-200+/hr based on actual work accomplished, previous skills etc. Can this DAO afford those kinds of wages? Or even put up a commitment to $100K+/yr for even 1 full time permanent dev position? Also people need to realize even a 150-200K/yr job can mean 60-80hr weeks with some companies. There are people that pull down 6 figures working 3/4 time or 1/2 time.

I have also commented privately within Maker when a commitment is to be made by a DAO or organization to an individual in such regards perhaps the individual also has to step up with a slashable stake as earnest funds towards such a cross relationship. Every company has a provisional period before an employee can’t be terminated for no reason. The point here is that commitment must be a two way street otherwise people will just pass through with everything to gain and nothing to lose.

There are also other issues like non-compete agreements, NDA, and other kinds of restrictions an employer might want before they will even commit to accept an employee application. I don’t see this stuff as very enforceable in the current space but it highlights issues that will eventually need to be dealt with. If there is a problem that needs to be addressed I’d like to hear it. If there is a goal to achieve I would like to understand better what that is, and look for simpler ways to achieve it.

I am not saying 1Hive needs to do any of the above. I am saying the above are typical things one will be forced to consider when making such arrangements.

[paul]

I have extreme views on this. I don’t expect most people to agree with me but I’m passionate enough about this that I’d like to share my opinion…

Hourly and Salaried compensation is a modern form of slavery. By selling our time we’re indirectly saying that someone else owns that time. Our time is ours, and no one should be transacting their time for money, especially in a DAO. People should contribute because they care about a purpose and feel that they can create value, and people should be rewarded for value they create, but also have their financial needs reliably met.

In my dream world, compensation for a typical 1Hive swarm would have 2 components:

• Basic Income: A flat rate paid to contributors meant to cover reasonable life expenses, scaled for level of contribution and consecutive time periods of contribution. The swarms are small enough that it’s not hard to distinguish part time vs. full time contributors, and rewarding consistent contribution would incentivize people to contribute consistently.
• Add-on for Value Created: An amount agreed on by the 1Hive community to reward past work done by a Swarm, paid from the Common Pool through a Proposal. The swarm could then use Coordinape or similar to distribute to the team.

I mentioned on the Tulip call today that I don’t think we have a great sense of how much value a Swarm creates until after the fact. @ceresbzns had the idea to time-lock payments in xCOMB to align the swarm on building that value, which seems like it could work for Tulip, but for Swarms that must pay in Honey, it just isn’t possible to know how much value they’re creating at the moment they’re creating it. Measuring past value creation isn’t easy either, but we have a MUCH better idea of how much value Tulip created over the last 3 months than how much it’s currently creating for the next 3 months.

Above all else the financial incentive for us should be to create value. If a swarm with a moonshot idea crushes it and creates $100 million in value for the 1Hive community, they should be rewarded with a significant portion of that growth. If they fail completely, then at least their basic financial needs should’ve been met while they were working.

I think this structure would make people generally happier, and better incentivize people to focus their time on creating value. Happiness and value creation are good goals.

Thank you @gabi for bringing this idea forward - I’m glad we’re talking about this.

[ceresbzns]

@paul

A flat rate paid to contributors meant to cover reasonable life expenses, scaled for level of contribution and consecutive time periods of contribution.

Honest question - how is what you’ve described different from a salary?

[paul]

The freedom to come and go as you want.

Salaries come with the expectation of your time: Office Space - Working Tomorrow - YouTube

[sacha]

@paul

Hourly and Salaried compensation is a modern form of slavery. By selling our time we’re indirectly saying that someone else owns that time.

Strongly disagree with this take applied to crypto networks.

The subtle but important difference here is that magic internet money doubles up as capital, and capital gives you back time.

By blurring the line between currency and capital we are able to give everyone a real stake in the productivity of the economy they are participating in.

For example, imagine if your USD actually appreciated when US equites went up? How would that affect your sense of ownership?

The key here is that we are able to create economies in which everyone is an owner.

In other words, the exact opposite of slavery.

[sacha]

Why should one not be free to seek stability too? Say you already know this is what you want to devote the rest of your life to

[sacha]

The main goals, as I see it, are twofold:

1. To be able to reward and retain talented and intrinsically motivated individuals (@ceresbzns and @paul are two that immediately come to mind)

2. To provide a sense of stability to talented and proven contributors who wish to dedicate themselves to this project

@sem and @willjgriff raise some very just concerns – should we choose to go down this path, it does sound like the Swarm is the right level at which to do so.

Would anyone be interested in starting a working group with me? The goal would be to build off of @gabi’s original proposal to try to answer the questions raised.

[ceresbzns]

Tulip swarm has been struggling with the challenges of contributor stickiness for a few months now, so this question of compensation and rewards is felt very keenly by the swarm. We spent most of our team call this past week discussing the topic. I’ll share my notes from that discussion here:

• Great conversation about compensation, contributor stickiness, and incentives. Thanks to everyone for sharing your thoughts and insights. Here are my main takeaways from that discussion:

Consensus that:

• we need to be able to offer a predictable stream of comp
• we need to create stickiness through vesting, streaming, or protocol tokens that accrue value of the project
• without good comp we won’t have contributor stickiness

We need to solve problems of how to:

• structure compensation to align incentives (stickiness, consistency)
• decide what rates and comp would be
• validate work is being done in a decentralized way (turn streaming on/off, scaling comp)
• fund tulip from honey pot when big outlays would require big conviction votes

@sacha I took an action item from the swarm to keep driving the conversation, so I think it would be a natural extension of that to collaborate with you and others in a payroll working group.

[DogeKing]

In one or other way there is no way of avoiding changes we need right now in most important swarms in 1Hive.For success of 1hive devs are the crucial and most important members.
I don’t know if someone is following tulip swarm and work of that group or not but from my surveys which I created 4/5 months ago(answers from members of tulip) - raising rates for most positions in swarm is def needed.

Down is like ceres said is the points from our last tulip meeting and we need to find solutions for most of this problems.(most important for me is how to motivate devs to stay and work for 1hive - because without devs there is no success of this DAO.)

Consensus that
-we need to be able to offer a predictable stream of comp
-we need to create stickiness through vesting, streaming, or protocol tokens that accrue value of the project
-without good comp we won’t have contributor stickiness

We need to solve problems of how to
-structure compensation to align incentives (stickiness, consistency)
-decide what rates and comp would be
-validate work is being done in a decentralized way (turn streaming on/off, scaling comp)
-fund tulip from honey pot when big outlays would require big conviction votes

[gabi]

Thank you everyone for a great discussion on the topic. There was a lot of valuable feedback to consider before answering. And great questions were raised that I’ll do my best to address.

Now I recognize the proposed solution was optimistic and kept several open questions. Thought I am happy we started the conversation.

---

@ceresbzns to answer your questions, though some may change as we improve the proposed solution:

• What is the reason for using Nectar rather than just vesting HNY? Is it to enable payroll-app to mint new tokens without having to draw directly from the Common Pool?

The way the Payroll App works is by minting tokens (optionally with vesting) every time a salary is redeemed. So as you mention by having Nectar we prevent giving permissions to transfer funds directly from the Common Pool and having to modify a lot of the Payroll app smart contract logic.

• How should we go about deciding who gets to be on Payroll Swarm?

My intention with using Celeste on v2 was to create a Credible Neutral system where anyone had the permission to add/remove members to payroll, though the action can be challenged. One alternative we can consider to prevent concerns raised by @sem is creating a Garden with a Covenant designed to handle Payroll applications.
Regardless, I am sure this is the most important point we want to have right if we want to prevent the coercion of the system.

• Why use an Aragon org? The interface is painfully slow and sometimes inaccessible. There are a few other multisig and DAO platforms available - could we choose a different one?

I thought of an Aragon organization so we can leverage the existing Payroll application we have build. I agree that the current interface (aragon.1hive.org) is painfully slow and not super reliable. But we can use Aragon Connect and The Graph to create our own custom UI like we are doing on 1hive.org and Gardens. I imagine this feature is we get it right to be valuable for every Garden.

• What is the definition of core contributor for the purposes of eligibility for payroll?

This is a difficult question and most of us will have a different answer. I believe the key is to create a mechanism that gives everyone the same opportunities without distinctions.

---

I consider the warnings from @sem to be important in order to keep the system Credible Neutral. I also agree with the point that @willjgriff raised about the experiment at the swarm level instead of having a global 1Hive payroll.

@Eth_Man the experience you share about Maker dealing with a similar question is great, so we can learn from that and prevent similar mistakes. And I agree that having a treasury with stable funds is an important topic tight with the current discussion.

@paul I like your idea of having a basic income and a surplus reward tight to the value creation that the swarm creates.

---

@sacha @ceresbzns let’s coordinate the first meeting of the working group

[ceresbzns]

@gabi @sacha Here’s a LettuceMeet for meeting 1: LettuceMeet - Easy Group Scheduling

[griffgreen]

@gabi

I also agree with the point that @willjgriff raised about the experiment at the swarm level instead of having a global 1Hive payroll.

+1 for making this at a the Swarm level… I would argue we shouldn’t ever need to do it at a higher level.

[ceresbzns]

Gabi, Sacha and I met to discuss this today. Here is the HackMD with the discussion I put together ahead of the call, where I tried to synthesize what’s been expressed here on the forum as well as the swarm-level conversations I’ve been privy to: Payroll Hack

Here’s the notes from the call itself:

CALL NOTES Aug 20, 2021

• Goals of the call:
  • identify next steps, possible solutions to the problem statement
• Payroll decision-making should happen at a swarm level
  • should allow room for experimentation
• Let’s start simpler and iterate
• Pay rates are holdover from seed era, might be time to update / increase
• Biggest missing piece may be long-term incentive
  • (!) How do we decide who receives those long-term incentives?
    • Swarm decides amongst its own contributors as a group
      • Coordinape or Aragon dot voting
• Important to attract the ‘right people’, i.e., intrinsically motivated folks

Framework for long-term incentives:

• Swarm drafts framework for short-term + long-term rewards for contribution
• Swarm achieves consensus / agreement from swarm contributors
  • how do we define consensus in this case?
• Swarm stands up smart contract (DAO) to hold long-term funds
• Proposal submitted to Honeypot specifically for swarm budgeting, longterm (separate from short term wages funding)
• Swarm has autonomy to decide management (spreadsheet or more programmatic method), amounts + vesting schedule, token vs options etc. and administrates from the commonly held smart contract

Open question: can swarms pass big enough funding proposals from Honeypot?

• One possible solution: swarms accumulate 5-10 HNY a week or a month? towards building up a treasury reserve for long-term incentives
• If swarm has their own token, they should think about ways to use it towards creating a long-term incentive structure

Open question: should swarm treasuries think to request stable amounts or hold stablecoin for weekly payouts?

Open question: what’s a reasonable way to structure a recurring stipend, if desired? what’s a good way mechanism for cutting off a contributor from the stipend?

Open question: what’s the right way to structure governance inside a swarm? token-weighed? etc. What’s the right DAO smart contract to use? Gardens would be ideal, but need to be careful with setting parameters for voting tokens. Gnosis multisig and Moloch DAO provide simpler solutions available today.

Next steps / Action Items:
* Share notes on Forums
* Set up another call next week to push convo forward
* Encourage swarms to start internal discussions about how they’d like to structure governance / incentives

Some initial visualizations of payroll funding

[ceresbzns]

LettuceMeet for second meeting, week of Aug 23rd: LettuceMeet - Easy Group Scheduling

[metaverde]

It isn’t called salary?
Doesn’t have the baggage.
Tbh we should develop our own verbiage to preclude any presumption of actual employment.

Replying to @paul
This is why it took me so long to join Tulip swarm.
Not paying in the context of hourly or salary would certainly help.

Since the goal is not to make money but to provide community good any financially successful project should reward all of the people actively involved with 1hive.
Not necessarily equally, but people shouldn’t be disincentivised from working on free projects.

@ceresbzns … maybe three tiers?