Vesting earnings proposal

[willjgriff]

This is a relatively simple approach to establishing a vesting process for 1Hive. If it’s successful it could be made available to other Gardens as well.

The basic idea would be to allow anyone who has claimed funds from the 1Hive common pool, including swarms, to choose to vest them once earned by sending the earned amount to a vesting contract instead of their own accounts. They would pick a timeframe/multiplier for vesting at the same time. The longer the timeframe the higher the multiplier. Then a Superfluid stream will be created distributing the total multiplied amount equally over the period specified, this will be visible on the Superfluid UI. The amount paid will be made up of the base amount sent to the vesting contract from the original receivers account plus the extra amount for vesting taken from the common pool.

For a WIP technical specification see here. Incase of any technical questions please read this first and feel free to comment.

Curious if anyone has any other suggestions as to how we might approach vesting funds earned from the common pool and if not if there is agreement that the above approach is acceptable.

[metaverde]

I love the idea of vesting and streaming.
This is the direction payments are going.
I’m thinking the additional Honey paid over time is made up for by the lack of sell pressure helping maintain value?

[willjgriff]

@metaverde

I’m thinking the additional Honey paid over time is made up for by the lack of sell pressure helping maintain value?

Partly that, and partly to give people the option to earn closer to what they would outside of 1Hive encouraging consistent contributions.

[s_ben]

Want to dig into specs more before forming a strong opinion, but this seems like such a good idea… When thinking about using gardens, vesting was actually the one big missing piece in my head. Was wondering where else to get that, possible implementation headaches involved. I think DAOs are all coming around to the need for this lego (or something like it). Gardens + vesting + streaming money would be all many projects need to spin up a DAO with legit governance and comp.

[paul]

I think this process would work OK, but I think it needs some changes to work as a first step towards a longer term system of how we pay ourselves.

I feel very strongly about a high level strategy for contributor compensation that has 3 components (kind of similar to Vitalik’s Retroactive Public Good Funding and DAOhaus’s new contributor compensation plan):

1. Basic Income

• Core contributors of a swarm earn a small amount of fixed money ($1-3k a month) to cover life expenses as they work, paid only in stablecoins.
• Amount is based on time commitment and consistency - i.e. part time vs. full time and new contributors vs. long time reliable contributors.
• Until 1Hive can grow enough stables for the whole DAO, swarms need to build their own stablecoin budgets (Gitcoin, Giveth, Grants, Hedgey, and Gnosis Auctions are some ways of doing this).

2. Retroactive Funding

• The majority of contributor compensation should be retroactive, paid in HNY.
• All retroactive funding should vest… there shouldn’t be an option to get this upfront.
• 1Hive as a community should decide how much retroactive funding goes to each swarm, and swarms should then distribute among themselves, probably with Coordinape.

3. Bounties

• 1-off tasks open for anyone to take on, which is where new contributors can earn money and reputation before joining a swarm as a core contributor.
• Funded by individual swarms, preferably in stables, but small amounts of HNY seem OK for this.
• Buzz DAO has a good working model using Notion, but we can probably expand to all of 1Hive using DeWork.

This vesting proposal as its written bundles the functions of both 1 and 2 at the same time, but if we build these vesting tokens to work for Retroactive Funding only, then we don’t need to worry about people being able to get their payment upfront, picking vesting periods, or even integrating into Conviction Voting/Common Pool.

A vesting tokens V1 model could work instead like this:

1. A Retroactive Funding Proposal is created in 1Hive where community agrees on a total amount of HNY, its vesting period, and a distribution % for each swarm.
2. Set up Superfluid streams with these parameters for each swarm’s multisig. I don’t see an issue with the HNY going direct to a Gnosis Safe with a team responsible for setting those streams up, at first at least, since it’ll be clear how those funds need to be dispersed. We can work towards integrating streams with Conviction Voting that other Gardens can use, but it doesn’t seem like we need that for an MVP?
3. Swarms then have a vesting HNY stream going to their multisig, which they can then handle distributing to their core contributors.

I think this achieves everything we’re looking to get out of vesting HNY:

• Raising effective pay for 1Hive core contributors, while aligning them with long term 1Hive goals
• Decreasing sell pressure of the HNY token
• Distributing governance influence more heavily to those currently creating value at 1Hive

[altcoins]

Paul has a way of writing that is very readable and impactful. I second what’s he’s penned here.

[willjgriff]

I believe Paul is suggesting we pay basic pay in stables without vesting at the minimum rates possible, and a “retroactive” bonus in Honey for completing milestones which is created and voted on quarterly and distributed to the swarms that are perceived to be creating the most value. The retroactive bonus will be vested to swarms, and swarms will be able to distribute it as they see fit. I see a couple of issues with this approach.

Firstly we don’t have a pool of stablecoins. This is a necessary pre-requisite to the above proposal. We should start encouraging swarms to start building pools of stablecoins but to do this there needs to be an easy approach that can be replicated quickly. @paul perhaps you can do a writeup on the possible approaches to generating stables and their likely effectiveness.

Secondly it suggests using coordinape/dot voting for distributing the retroactive funding between users in the swarms, once they have finished vesting. I’m not convinced this is a fair way of distributing rewards considering previous experience using this method. Perhaps a better way would be using the hours spent on the project by individuals during the previous period, or the total they earned. This can be decided by swarms but should be highlighted because my original proposal gives more choice to the workers than this one does.

[Lindsey]

These are great ideas. I love the idea of incorporating vesting into token distributions, as well as Pauls add on around incorporating a mix of stables for contributor rewards.

Patterns I’m seeing are:

1. Reducing the amount of market-liquid HNY put into circulation
2. Using stables as an alternative to HNY for some contributor rewards

Not sure what the outcome will be - but I feel like using HNY as a rewards for contributors that allign them with the long term vision of 1Hive, while using stables as a “runway” that gives a highly involved group of 1hive contributors something they can rely on is a great approach.

I think consideration on the impact of HNY on markets once vesting is over is important (does vesting just punt the problem down the road? Not sure really) Regardless I think its a good approach.

I also think the other consideration on incorperating stables is in how those stable reserves will be built up. (disclosure - I’m at Hedge of course, but think may need 3-5 different tools here to build up a stable coin reserve)

I think something that would help me visualize this is seeing what the forecasted monthly/yearly HNY distribution numbers looks like. Once you have those big numbers we could perhaps back into what different combos of HNY/Stables and vesting would help 1hive accomplish its goals.

[paul]

Yes that’s what I’m proposing

I’ll work with @Lindsey this week on a forum post talking through options for growing stablecoin budgets.

Even though it should happen as soon as possible I don’t think swarm stablecoin budgets are a prerequisite for a Basic Income + Retroactive Funding model. Retroactive Funding should be solved first if that’s going to be how contributors earn the majority of their pay. If good contributors can count on it being substantial for them, they’ll be more OK accepting Basic Income for ongoing work that’s below the market value of their work (correct me if this is wrong, contributors! This is true for me at least).

As far as distributing Retroactive Funding within a swarm - that’d be up to the swarm, so if Coordinape isn’t preferred they can choose another way. Personally I don’t think hourly tracking is a good long term solution in a DAO simply because I don’t trust all other contributors will be honest. It seems it’s worked well for the Gardens swarm so far, but I think that’s because we have a very intrinsically motivated team that’s passionate about the project working.

All this said, I think my only request for this vesting earnings proposal is that it be implemented within a Retroactive Funding event. I can propose a simple model for Retroactive Funding as a starting point:

• Target a Retroactive Funding proposal for 5% of the Common Pool, once a quarter, compensating the previous quarter’s work.
• Create a Gnosis Safe with a diverse group of 1Hive contributors to receive funding and sign transactions for Retroactive Funding.
• Swarms apply for Retroactive Funding through a Suggestion Proposal, pitching their case to the 1Hive community in their forum post.
• Set a due date/time for the Suggestion Proposals at which point the relative conviction is measured and is the portion of Retroactive Funding that goes to each Swarm.
• Retroactive funding is sent to swarm wallets through a 1-year vesting stream, i.e. with Superfluid

[Lindsey]

Sounds great @paul - will absolutely pull Alex in on this as well.

On the retro active funding - what are your thoughts on vesting periods? Should the HNY be be broken into tranches based on the size? Some thoughts to go through on that to make sure vesting doesn’t create a flood of HNY hitting the markets all at once when unlocked - but i’m sure there’s a solution.

Looking forward to chatting through this!

[paul]

Vesting periods are key to retroactive funding working imo! With Superfluid the vesting period works as a continuous stream so there’s no HNY flooding issue: https://app.superfluid.finance/

Updating my last comment so this is clear…

[Lindsey]

got it got it - that makes a ton of sense. Seems like vesting could well managed that way.

[rperez89]

Hey, i have been thinking if we could design this vesting thing in a way that the bonus reward that the user gets at the time of the vesting period ends could be in multiple tokens and not just HNY.

Since gardens does not have any revenue streamflow the idea would be to create proposals on each garden to fund this vesting reward pool with for example GIV, BRIGHT , TEC ,etc and this way create a more collaborative dao2dao around gardens where not only HNY is the only token that gets that sell pressure on the market from the gardens development payments.

Wondering everybody thoughts around this, and tagging some members of some biggest gardens to gather feedback. @griffgreen @castall @willjgriff @paul @sem

[paul]

I’d rather us solve this problem in a way the other Gardens can emulate - this feels like we’re just passing the problem onto the other DAOs.

Unless you mean other Gardens would also be able to get these multi-token bonus payments for their work?

[rperez89]

yes that would be a vesting contract that would allow anyone to use it, like for example giveth starts a reward pool and start asking to other gardens if they could collaborate providing some tokens to be used to reward their vestings unlocks.

But anyways i don’t see this as passing the problem to other communities is a way to collaborate with the protocol that those communities use for their governance, and at the end of the day is up to each community if the proposal to top up the 1hive rewards pool pass or not

[sem]

I wouldn’t mix things:

• Honey vesting is a matter of 1hive, and should be dealt within the 1hive realm.
• Gardens swarm funding is something completely different.

We already have received funding from gardens other than 1hive to fund gardens swarm, or other related projects, and we probably will receive more funding in the future if we do things that appeal to those communities.

For me, requesting funds to other communities should be based on a project by project basis, so we can provide value each time and be accountable about it.

There are different alternatives to not charge all the weight of developing gardens on 1hive, we can even post a funding proposal to Aragon Network DAO to fund things such as further development of Aragon Connect (critical dependency of Gardens), Radspec, or other things that can be of their interest.

TL; DR: Gardens Swarm is providing a lot of value to many communities, and it will be easy to get funding for specific projects. It doesn’t have anything to do with how HNY is managed. HNY is a governance token of 1hive, and it should be interesting to hold for it’s intrinsic value.

[rperez89]

But this is not a request for funding is a request for rewards, like the one that we give it to dehive to rewards their staking platform for the xdai cluster.