# **Proposal: Tulip Swarm Compensation Stack**

**Context:**
For the reasoning and motivation behind this proposal, please see the broader payroll swarm discussion on the [forums](https://forum.1hive.org/t/payroll-swarm/4236) and [hackmd](https://hackmd.io/vL4UIWjtQE-G1iGSqWNllQ)

I am not certain about any specific element of this proposal. I am, however, certain that we must upgrade our compensation stack. Any and all feedback is welcome.

> Changes made based on feedback are captured as comments, like this.

**Goals:**

* Promote contributor retention and stickiness by
* improving consistency and predictability of rewards
* improving quality of rewards
* aligning long-term incentives through reward structure
* Reward structures should be simple to understand and simple to administer
> This is important in order to minimize the cost of setup and administration, as well as sidestep the costs associated with negotiating (and renegotiating) compensation for each individual separately.

In **Section 1**, I propose a **framework** for deciding who will receive swarm compensation, how much, at what intervals.

In **Section 2**, I propose an initial set of **tooling** that can be used to implement the reward structure outlined in Section 1.

In **Section 3**, I propose the formation of a **Moloch DAO** to administer & govern the aforementioned framework and tooling.
___
## **Section 1:** **Framework**

I propose that swarm compensation have two basic components:
1) a **weekly stipend** to provide short-term alignment
2) a **vesting premium** to provide long-term alignment

### **Stipend:**

The intent of the weekly stipend is to provide committed swarm contributors with a steady and predictable compensation for their time and effort. I propose that the weekly stipend be offered in two tiers: **full** for contributors who are working in Tulip as their primary occupation, and **baseline** for everyone else.

|Stipend|Amount (weekly)|
|---|---|
|Baseline|500 DAI|
|Full|1,500 DAI
> There's some discussion to be had about whether stipends should be paid directly in HNY or converted to DAI. There's tradeoffs in either approach. At this moment in time, I'm inclined to argue that this should be paid directly in HNY because converting HNY to DAI (responsibly) would require an entire extra layer to manage at the swarm and/or DAO level.

Ideally, stipends will:
- remove the need for time-tracking
- for baseline contributors, create an incentive for continued participation, week to week
- for full contributors, comfortably provide for living expenses

**Criteria for eligibility:**
- 1Hive contributor in good standing
- Formal member of Tulip DAO
- Consistently attends team calls OR asynchronously updates
- Regularly contributes to the agreed priorities of the swarm (as recorded in swarm artifacts, e.g., roadmap, kanban, call notes)
- expected threshold on the order of 8 hours a week
- *Full stipend only:* works on Tulip swarm projects as their primary occupation

**How stipends are granted:**
- Member submits a proposal to receive a stipend at baseline or full rate
- All members assess proposal based on eligibility criteria
- Ideally, a consensus is achieved (as defined by no objections). Exact governance mechanism will be a function of DAO configuration used.

**Criteria for revocation:**
- Member commits a significant breach of trust, by intent or error
- Member violates the terms of the Community Covenant
- Member ceases to contribute to swarm priorities for 2 weeks or longer
- Member drops out of contact for 2 weeks or longer
- Member exits the DAO, e.g., by ragequit or ragekick

**How stipends are revoked:**
- Member submits a proposal to revoke the stipend of another member
- All members assess proposal based on revocation criteria
- Ideally, a consensus is achieved (as defined by no objections). Exact governance mechanism will be a function of DAO configuration used.

**Projected Burn Rates, Stipend**
|Full |Baseline |Monthly (DAI)| Annual (DAI)|Annual (HNY*)|
|---|---|---|---|---|
|1|3|12,000|156,000 |462
|3| 3| 24,000|312,000 | 923
|**4** |**2**| **28,000**|**364,000** |**1,077**
|5|5| 40,000|520,000| 1,538
|7|5|52,000|676,000| 2,000
> `*`Calculated at rate of 340 DAI : 1 HNY
> * The obvious standout issue here is that, *given current HNY price*, funding a single full-time product team (4-5 devs + 1 PM + 1 designer) with support team (marketing, data analysts, biz dev, etc.) would consume the entirety of the common pool budget. This is obviously not desirable.
> * I have bolded the middle column because I believe a 6 person team (4 full time devs, 1 part-time designer, 1 part-time PM) would be a *minimum viable* swarm composition to make fast, sustainable progress as a product team.

### **Vesting Premium**

The intent of the vesting premium is to provide committed swarm contributors with an opportunity to earn significant payoffs, contingent on the swarm achieving great success.

Ideally, the premium structure will:
- create an incentive for contributors to keep moving swarm projects towards completion
- create an incentive for contributors to maintain and improve projects after they've launched

**Criteria for eligibility:**
- Contributor continues meets all criteria for **baseline stipend** (above)

**How premiums are granted:**
- Once per month, DAO members allocate up to 100 premium points, divided amongst stipended contributors as they see fit
- NB: DAO members may include individuals who are not stipended swarm contributors, but will presumably have insight into the work being done
- Contributors receives a proportion of the premium pool, weighted according to their allocation of premium points.
- Initially, the premium pool will be composed of two tokens: HNY and uCOMB

**Premium Pool for distribution, proposed**
|Token|Monthly|Annual|
|---|---|---|
|HNY|100|1,200|
|uCOMB*|15,000|180,000
> 100 HNY / mo amount would not be supportable given current HNY issuance model, according to insight from @sacha
> `*` uCOMB is a proposed, unified COMB token. For more, see my [posts on the forums](https://forum.1hive.org/t/we-must-reform-the-honeycomb-part-2/4257)

**Vesting schedule**
* Once allocated, a premium has a vesting period of **twelve months** after which it is disbursed to the contributor.
* For current swarm contributors, vesting period will be backdated to date of first contributions.
* Premium will be disbursed in a linear rate at 1% of total premium vested per day, so each monthly premium amount would fully vest over ~3 months after unlock date
* Therefore, a contributor who has been working consistently towards swarm goals for twelve months will begin to receive a rolling monthly disbursement of premium in addition to their weekly stipend.
> Vesting period lengthened from 3 to 12 months and backdate provision added, based on feedback from @Sacha. Linear streaming added, based on feedback from @philogy

**How premiums are revoked**:
- If a contributor has their stipend revoked, their premium is automatically revoked as well and any unvested premium will be reclaimed by the DAO.

**Interaction between multiple compensation systems at 1Hive**
* A contributor may only receive a stipend and premium from one 1Hive swarm at a given time.
* A contributor may continue to receive compensation through freelance rates from other swarms.
* Contributors receiving a full stipend are ineligible to receive freelance rates from other swarms.
* On accepting a stipend (baseline or full) and premium, the member must exempt themselves from **Pollen** distributions.

> Added based on feedback from @Gabi

### **Freelance Rates**

Any contributor who is not yet eligible for stipend and premium should bill for their time, *payable on work delivered*, for a rate negotiated on an individual basis. Suggested rates below.

Any contributor who does not wish to join the DAO can choose to opt-out of the stipend and premium structure in exchange for *payment on work delivered*, for a rate negotiated on an individual basis. Suggested rates below.

|Role| Per hour|
|---|---|
Communications & Marketing | 50 DAI
Junior Developer | 60 DAI
Business Development |70 DAI
Project & Product Management | 80 DAI
UX Design | 80 DAI
Senior Developer | 100 DAI
> Rates increased based on feedback from @sandpiper

_____
## **Section 2: Tooling**

We can administrate the compensation plan outlined in Section 1 using tools that are available today, with no additional custom development work. The goal is to minimize the need for manual oversight, idiosyncratic implementations, or centralization through permissioned controls.

My criteria for tool selection:
1) publicly available for use today
2) supported on xDai

|Function|Toolset|
|---|---|
|DAO| [DAOhaus Moloch v2](https://daohaus.club/)
|Stipend Distribution |[Superfluid](https://www.superfluid.finance/)
|Premium Allocation| [Coordinape](https://coordinape.com/)
|Premium Distribution|[Superfluid](https://www.superfluid.finance/)
> Technically Coordinape isn't on xDai, but it's just used for signalling / accounting
____
## **Section 3: DAO Structure**

To act as the central smart contract for the Tulip DAO, I am proposing to use a **Moloch v2** summoned through **DAOhaus**. If you're not familiar with the Moloch framework, please read this [writeup outlining some of the key features](https://medium.com/raid-guild/moloch-evolved-v2-primer-25c9cdeab455).

A Moloch DAO has a fairly **robust set of capabilities** for on-chain governance, including the ability to:
* Record binding votes, which can execute on-chain transactions
* Send and receive tokens
* Interact with smart contracts via owned contracts called `minions`. Notably, these are capable of running Superfluid distributions.

In addition, there are a few **nice features** that I think are worth pointing out:
* High availability and responsive UX
> Unlike Aragon, lol
* Members can be asked to `tribute` tokens as part of their membership proposals, which are then at the disposal of the DAO. Members can then receive a combination of `shares` which have voting rights and economic rights, or `loot` which have only economic rights.
* Membership parameters can be outlined at the social layer and enforced by vote, allowing the DAO to decide:
* what tokens and amount to require as tribute (more on this below)
* a set maximum of how many shares (voting + economics rights) to allow any given member to accrue, enabling a full range from plutocratic maximalism to 1-vote-per-soul democracy, as desired by the DAO
* Members of the DAO have freedom to exit any time and recoup their tribute, plus any additional wealth that's accrued to the treasury. By exercising the `ragequit` function, an exiting member can burn some or all of their shares and loot in exchange for a proportional cut of the tokens held in the DAO treasury. This enables credible threat of exit for dissenting members.
* Funds can be held outside of ragequit, but within DAO control, by placing them in a minion. This is important for when funds are reserved for a specific purpose, such as stipend or bonus distributions.

Here's my proposal for the **parameters** of a Moloch DAO to act as the on-chain governance for Tulip Swarm:
* To be accepted, a prospective Tulip DAO members must either:
* be a known 1Hive contributor, or
* have BrightID verification
> sybil-resistance measure
* Members must tribute between 1 and 1,000 xCOMB
* On acceptance, members will receive 1 `share` per 1 xCOMB, up to a maximum of 1,000
* Members can buy additional shares by submitting a future proposal, but any single member can only ever have 1,000 `shares`
* Members can buy additional `loot` at a rate of 1 loot per xCOMB, with no upper limit
* Members are eligible to be `ragekicked` from the DAO if:
* they violate the Community Covenant
* do not participate in an on-chain vote for 6 consecutive months

If and when uCOMB is launched, the DAO will need to transition to using uCOMB and/or mCOMB as the governance token.

Tulip DAO will receive the **governance powers** currently owned by the Aragon DAO on xDai, including the ability to:
* modify xCOMB allocation streaming in Honeycomb
* unlocking staked farms in Honeycomb

Tulip DAO will also receive governance powers for **future implementations** of Tulip DAO projects, such as Honeyswap and Honeycomb on Arbitrum, and wherever else 1Hive goes, including:
* setting fee parameters on Honeyswap
* setting fee receiver behavior on Honeyswap
* modify uCOMB allocation streaming in Honeycomb
* unlocking staked farms in Honeycomb

But wait, what about **Gardens**?

I love Gardens and spoke with a few members of the Gardens swarm briefly to discuss the possibility of growing a Tulip Garden. However, based on our discussion, I believe that a Moloch DAO is better suited for Tulip swarm's needs for a few reasons:
1) Moloch DAOs have the smart contract powers outlined above that would be exceedingly useful for minimizing administrative overhead, especially the existing integrations with Superfluid.
2) Conviction voting is compelling but also complicated, with its many parameters that can be altered. This makes it challenging to understand and poses a significant risk should the initial parameters be set sub-optimally.