Tulip Swarm Compensation Stack Upgrade

Draft: Tulip Swarm Compensation Stack Upgrade

For the reasoning and motivation behind this proposal, please see the broader payroll swarm discussion on the forums and hackmd

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.


  • 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


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 at Various Stipends Supported

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 with stipends alone, which 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 HNY issuance model, according to insight from @sacha. I’ve struck it from the proposal.
* uCOMB is a proposed, unified COMB token. For more, see my posts on the forums

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
Stipend Distribution Superfluid
Premium Allocation Coordinape
Premium Distribution Superfluid

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, check out this writeup outlining some of the key features.

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 incorrectly.

While i like this initiative i wonder if we checked with the current market conditions the rates,

if we take a junior developer that earns 60/hr that works 6 hrs for day will be kind of 8k per month, not sure in which part of the world that dev lives and i am totally against rates/part of the world that you live but going to my specific case of where i live south america a junior that wins that is a millionare, when we started was like 35, that i agree that was maybe a bit low for people living in USA or europe but 60 i think we are a bit high.

My question is, is there any part of the world that with 4,5,6 k you can not live and pay your expenses as a guy/girl that is just starting in their labor life?

Don’t take this as my hard think about this, just thinking in loud since we have members for all around the world

1 Like

This new compensation scheme is promising. It will great experience to run a pilot on the Tulip swarm.

My only suggestion is to consider giving the 1Hive community a way to keep checks and balances of the premium pool. This point is particularly important if we would like to create a system that works well for every other swarm that would like to start with a similar compensation stack.

Once we form a good understanding of the key features that work, we can consider if make sense to integrate them on Garden so others communities can also leverage them.


Other important point that was not mentioned is: how other existent incentives on 1Hive (aka Pollen) should be adjusted (if any).

A missing statement that was missing from my previous post is : how we can make it fair within the 1hive ecosystem? why a gardens dev want to work in the gardens swarm with a rate of $50/hr if they can work in the tullip swarm for 100/Hr?


I’m suggesting these rates based on compensation being offered through other DAOs, as well as through commercial sector employment. My logic is mostly framed using opportunity cost - why would someone work at 1Hive when they can go work for Balancer, or Harvest, etc.?

If a contributor lives where there’s a low cost of living and they can earn rates that make them very rich, while a contributor who lives in Europe and earns the same rate that is nonetheless attractive to them, then I think that’s fantastic.


We do need to figure this part out. There’s two natural limiting factors we can consider:

  • Swarms shouldn’t grow beyond a certain size (around 12 people, would be my argument), so the DAO should exercise discretion in offering new stipends.
  • The swarm premium pool is proposed to stay the same regardless of stipended contributors, which means that each additional contributor will receive a diminishing premium. As long as other swarms are able to offer meaningful comp in the same range, that will incentivize 1Hive contributors as a whole to seek positions in those other swarms with less saturated premium pools.

Given the amounts being proposed here, I think it would be appropriate to propose that accepting a stipend and premium from a swarm would also require opting out of Pollen. I’ll update.


yeah makes sense, my main concern is to not generate a dispute inside 1hive to be part of a swarm because a baseline hrly compensation

Like the complex thing for me is. Tulip is pretty much requesting a huge percentage of the whole 1hive monthly spending from Treasury to be allocated to it. While attempting to take away revenue from 1hive by reducing the honeymaker honey buyback program.

When does Tulip predict to generate revenue and be sustainable? The implication in this proposal is that it never will. It will always need 1hive to fund it’s developments.

If it’s not planning to be sustainable it’s a bad investment of our Honey and Contributors.

We should invest in other swarms that have an easy plan to achieve that. And devs can distribute themselves appropriately according to their preferences and motivations.

If we want to have a more generalized payout structure it should be something at the 1hive level. I don’t want to have as 1hive our best devs working all on the same stuff, even less if that is neither sustainable or key for the identity and values of the DAO.

If we figure out a way to have this payout methodology at the core of 1hive I am all about discussing it. I don’t feel interested in discussing about disbursing significant treasury resources into a single swarm that has yet to prove itself a good investment for the DAO.
I believe in the people contributing at 1hive but I think there’s a lot of other projects where we can be way more successful than trying to compete in Defi.


Maybe 1hive should look at dispursing more to contributors.

I don’t think sustainability is necessarily based on income from that project being generated. We print our own money.

The point of DAOs in this context is to be able to compensate generously.

We haven’t been.

Arguing against someone getting better compensation because someone else isn’t should really be an argument for the other to get better compensation as well.


I have to agree with @ceresbzns here. I live in the United States and of the hourly rates for Solidity development that I have been offered - $60 is still the lowest. $60 / hr to contribute to something that is truly greater than myself and truly benevolent is attractive despite it being a lower rate. The other rates that I have been offered range from $100-140 / hr.

The rates I have been offered as a blockchain strategy advisor however are $250+ / hr. For myself - with limited savings - I may still not be able to justify working more than part-time on Tulip.

Also this is all very new to me - as I executed my first successful role as a Blockchain Strategist - and also as a Smart Contract Developer in just the past 40 days.


So much of this proposal is fantastic. I especially like the vesting tokens for incentivizing long term participation and alignment; and the Superfluid distributions.

My concerns are with the stipends. There are accountability issues in DAOs. There are definitely people who are happy to get a stipend, fail to deliver and take their $3000 out the door with them. I understand there’s additional friction for time-tracking, proposals ETC. - but I am not sure reducing those frictions will work here. There has to be some kind of methodology that makes contributors accountable. Whether that’s daily progress reports, time-tracking software or something else.

I can’t really speak much to the issues presented by @luigy because I am not very well versed in the internal structure / politics / workings of 1Hive.

My only feedback there is that products which are built by each swarm must in fact support the value of HNY. It doesn’t really make sense to segregate the swarms and think of them as separate entities; but more like branches of the 1Hive tree. The creations of the different swarms are actually the desirable output of utilizing HNY as a resource.

There’s also the issue of brain-drain currently. You might not be able to achieve the stickiness desired for really high-value-add contributors without having higher compensation. There are a huge amount of companies and VC hiring in this space. I get offered a job in the space on average every two days. Arkhan from Alethea AI encouraged me to apply this morning; and they just raised $16 million for their iNFTs.

So there’s a few key questions here:

What is more sustainable; building new products that are designed to support the value of HNY, or hodling HNY in the treasury?

How does 1Hive compete for powerful human resources with companies that have large amounts of capital?


My expectation is the risk of folks reneging on their stipend agreements will be fairly low actually. Given the criteria outlined, only trusted members of the community will be eligible for a full stipend. I don’t specify in my proposal since it’s out of scope, but I would also expect that team conduct with full stipend members would include best practices like pair programming and daily standups which will help with regular accountability.

We’ve definitely had issues with freelancers engaging in this behavior, so I specify that payment is rendered on delivery for freelance work for that reason.

We can’t generate value just holding HNY in the treasury. Period. Without putting it to work, there’s no expectation that there will be a future return of value. There’d be no reason to have it at all, in fact.


You’ve cut to the heart of the matter. My attempt to answer that question in my proposal above was to say “provide for their basic needs in the short term and offer a credible opportunity to receive a generous share of community capital in the long term.”


I’ve struck the proposed HNY qty from the Premium Pool. Given current HNY prices and issuance policy, it would not be possible to support stipends and premiums for the swarm. Tulip Swarm premium only to be paid out in COMB, which the swarm itself manages.


I love the fact that tulip is experimenting with incentive structures. This will pay dividend for all other swarms. Also love trying out new tools (especially superfluid)

However, I’m very much against the moloch DAO. Gardens and Celeste are flagship products which we should be dogfooding unless there is a clear reason not to.

Gardens has regular and conviction voting. If there is a need to not use conviction voting for capital allocation (And I really don’t see why this should be a problem) we can just use the second agent and regular disputable voting.

Furthermore, I really don’t like the “membership club pseudo DAO” thing (basically moloch), especially for this use case. It’s too exclusive for a core swarm in my opinion.

Regardless tulip ever becomes or profitable or not, having another strong DAO helps boost the garden/Celeste network effect. If The tooling is suboptimal (which admittedly it currently is) tulip should work with gardens to make it better thus making gardens more compelling in the longterm


I am totally agree that the rates needs to be improved i was just really surprised that if those numbers is what is being pay now a junior is earning more than what we are paying a senior. So if that is the case we need to act fast to avoid more talents going away from the 1hive.

What i don’t want to start happening is all the devs wanting to work in a swarm because of this, that is why i insist that need to be something at a 1hive level, then each swarm apply whatever bonus or cool process for payments that they want

@Kyle_Stargarden Hello, apologies for the tag. Is there a way to reach out to you? I’m currently exploring getting into the blockchain industry as a Product Designer. I want to discuss to know if there are any tips or guidance you can give me.

Plus I’d love to know a Blockchain Strategist as well, a very cool position to be in. :grin: :grin:

1 Like

These incentive and vesting schedules are first-rate.

In terms of the DAI offered, there are developers living in California and Cambodia that are of an equal skill level, but have wildly different living expenses. I feel like in this newly remote economy we’re not necessarily penalizing Californians by going to $60 p/h because they operate in a world where opportunities in tech are plentiful relative to his fellow coding community members. If we’re not awarding geolocation differences based in IP addresses for contributions to the discussion board in SourceCred then I think trying to address living standards around the world is too big of an undertaking beyond the scope of this DAO. Many DAOs are going to with Western Europe or American standardized incomes and they’ve scaling nicely. The fact that a DAO offers a 0.01% salary for one coder and a modest one for another can’t be easily fixed without world governments coming to agreements on trade, currency manipulation, and minimum wage laws. This isn’t happening anytime soon. So, I think as long as users are delivering the goods and hitting the marks in their respective responsibility roles then we should keep delivering the HNY/DAI. Often the contributions of a swarm member is many times over what they are paid. I can think of a dozen or more regular members that are delivering enormous value and steadfast resolve to making this project a success residing in South America, Asia, and Eastern Europe. Delivering quality coding and content is the end goal. Projects that deliver this end up scaling because the community can sense it and respond by getting involved themselves.