Contractor Swarm 🪴

[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?

[metaverde]

Tag me for these on the outro please?
Since I’m actively recruiting this is very relevant for me.

[Eth_Man]

@gabi thanks for starting up the conversation. Since you are getting a working group together. Something that comes from Maker to add to the add to the heap here.

There is a fair bit of discussion that happened regarding MKR compensation in salaries. Looks like Maker has made a choice on how they want to distribute this. The model is a RSU type model and it has a 6 month trailing average vesting price. MKR is also considered to be an addition on top of salary vs. a bonus.

Now 1Hive is in a very different position that Maker in that revenues are NOT sufficient to cover payrolls. I am pretty sure the best and fairest model here would be to offer sufficient salaries in DAI to cover what people need to live and that HNY (or MKR in the case of Maker) only be offered in a vesting contract as a bonus due to performance of revenues. The point here is two fold.

1. Make sure competitive salaries are available already in cash. contractors should not have to sell tokens to make ends meet. The organization should do that selling in a consistent way. This allows the whole of community owners to take the brunt equally and contractors to get compensated

Which brings me to a key point to insert here regarding terminology. This should not be called payroll and should be called ‘contractor swarm’. 1Hive needs to stay as far away from having employees as possible from legal and tax implications. 1Hive workers are contractors, must in the US pay their own SSI, Health, fund retirement, etc. Which means salaries will need to account for all of these extra expenses and contractors will have to learn to deal with them.

2. I personally think that once salaries are sufficient and competitive that bonuses based on total community performance (i.e. via a revenue metric) in options vs. RSU type would be the best way to align contractor interests in 1Hive performing with those of holders. 1Hive is so small this may not be a good option and Maker felt RSU was simpler. The point here is that the community can set HNY bonus compensation to vest (it darn well better btw) and that how much HNY is given out should be based on improvements in revenue streams. Have real targets 10K/month, 100k/month for say the bonus allotment period before HNY bonuses are unlocked.

3. Final point is that if contractors will get salaries I think it is prudent for 1Hive to begin rasing DAI. Instead of taking revenues to buy and burn HNY it should be converting these to DAI. So 1Hive better start thinking about how CV is going to work while also managing both conversion of HNY to DAI and HNY voting as well as proposal funding. Altering funding for contractors from HNY to DAI will be a critical step for 1Hive.

I think these are probably the key things to keep in mind and I would start right now by changing the title of this from Payroll to Contractor Swarm so everyone thinking and managing this wraps their heads around what this means in terms of the increase in funding required, and where the full responsibilities for things are (most falls on the contractor) so sustainable funding can be put into place and contractor negotiations can happen. I do like the idea of Core Unit budgets which I think 1Hive already has mechanics to manage. I just think 1Hive needs to formally decouple prices/costs/funding from HNY to DAI and then put together an asset management group to deal with how to convert revenues and assets into DAI so it is least disruptive to markets. (i.e. HNY DCA into DAI)

[Eth_Man]

@ceresbzns

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

Yes.

@ceresbzns

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?

That should be handled within the swarms. Maker uses a CU model where the CU lead basically allocates to their contractor FTEs. Basically CU contractors negotiate with the CU lead, the CU lead also proposes budgets to governance generally.

@ceresbzns

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.

Unclear and open. Maker has gone for a more centralized CU model where basically 1 person the CU lead, issues budget requests, negotiates CU FTE contractor terms etc. What 1Hive adopts could be up to each swarm but realize the more democratic this is - the more time will be required to complete key steps. For sake of efficiency I’d have swarms elect/appoint a swarm lead, and at least 1 assistant who are the interfaces between governance and swarm FTEs and budget management.

@ceresbzns

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

Probably not. Which is why 1Hive governance will need to step in here to construct a HNY to DAI DCA structure and fund it. Like pass a proposal to take 200HNY and sell it at some rate/day to raise DAI. swarms can still request funds in HNY but they should get them as DAI. HNY in the loosest sense should be a bonus related to performance of some kind. i.e. a swarm that gets say 20K/month in DAI might also get some amount of HNY based on some swarm performance metric also related to a revenue growth or target metric. One thing about converting revenues to DAI is that 1Hive will see what these are directly and then governance can more effectively manage them. Right now I have no clue what 1Hives revenue streams have been doing based on all the changes being made - are we up or down over past month - what do these look like over the year.

Revenue is one of the most important organization metrics - we need a dashboard and graph just for this. We also need a dashboard and graph for expenses. People have numbers - show me a graph please. We need historical tracking on these especially if we are going to start tying HNY bonuses to revenue/expense or other performance metrics.

Also realize that the way 1Hive inflation is structured 1Hive will have some real funding limits. So far I think there is enough HNY in the kitty to pay reasonable contractor budgets and to have some HNY as rewards.

HNY is more than MONEY so it is also time to start to change the mantra on that. DAI is money, HNY is MORE than MONEY because it votes, DAI just gets paid.

[sacha]

Thank you for taking the time to write this up. Several great points to think over

[Felix]

I want to second this idea by adding an bee referral program :
We should seeks for qualified people and appreciates recommandations made by current bees.

The logic would be the following:
If you recommend someone who is working actively in the community on a regular basis and are both still working actively in 1hive after six months of the new bee’s “first day” you are eligible to be paid a referral bonus.

$1500 for pm position
$1000 for regular position

[Blazingthirdeye]

I think maybe half those amounts. And just for developers or someone who can prove they’ve added significant value to community or maybe people who get nominated by a few bees. I would also reduce the length to 3-4 months.

[ComandoBurrito]

Nice post Gabi, you really are addressing some potential problems and also proposed solutions