Draft Proposal: Compensation for Core Team & Contributors

I don’t think we should try to release more yams at any time, which is unfair!

1 Like

I think 300k is more appropriate. If the ratio is too small, it will not provide incentives.

At current scalingFactor of 5.13x, basically all these numbers mean they are receiving 5x the amount of YAM.

So to be clear, at present it’s basically

  • 250k YAM
  • 500k YAM
  • 750k YAM
  • 1M YAM
  • 1.25M YAM
  • 1.5M YAM
1 Like

More discussion on this 3-year period would be beneficial.

I think there should be at least a 6 month cliff, maybe even 1 year. Really need to align incentives.

Something like 6 month cliff, and then vesting weighted more heavily towards the end is what makes the most sense to me.

Any of this numbers can be covered with the current treasury holdings…

Reading trough all the comments it seems community is pretty divided about the extra supply, it is something that had caused strong rejection in the past so I think we should at the very least have the option of using the treasury for the Core Team Rewards in the proposal.

I think everyone agrees that the Yam Market Cap will bleed if the team leaves @Wigglez, nonetheless it will also bleed if we keep minting in an already bleeding scenario. The good news is that everyone wants to reward the team, so this is something that will happen one way or another, which will make the team stay and keep working for YAM, it is just an issue of how to do it.

1 Like

my original thoughts regarding funding development through treasury vs printing can be found here, relating to the decision to eliminate the Community Fund proposed in V2 governance:

i think it’s helpful for thinking through this issue.

the tl;dr is that printing on an as needed basis was always a known option and is the best capital management strategy for the protocol imo

1 Like

@fewture I think this idea is interesting. It helps alleviate any short-term concerns of inflation or extra sell pressure (at least for 6 months). That’s sufficient time to recover (market cap) and prove that YAM is something special (insurance protocol, etc). So this idea is certainly worth exploring I think.

However I think the rest of the vesting should be linear, block by block.

Yup, I’m starting to believe for the actual snapshot page voting options, we should maybe remove the bottom option (50k YAM BoU) and add a few options that are higher (350k, 400k). As @ross shared the actual percentages on these numbers, I think we can compensate the core team even better and more fairly.

1 Like

It’s important to remember that this would be vested over three years. So the perceived voting power does not match reality.

But even so, once they are fully vested, the numbers that we’re talking about here do not give them disproportionate voting power. Taking a quick look at the YAM holders page (not counting LPs), there are plenty of other YAM token holders who have similar YAM holdings. And plenty more that are not on this list because they are LPing. So their voting power is not anything imbalanced. I’d much rather the core team have this voting power than some random whale who isn’t actively involved in the project. This is the core team we’re talking about, the people who are actively helping our YAM tokens grow in value.


I don’t think extra Yams should be minted for dev pay and dev fund it should come from treasury.
My proposal:

  1. Pay the current devs and on going supporters a flat rate for x months to be paid from the treasury according to their time commitment to the project.
  2. Set aside a small % of treasury for the core devs to directly manage and distribute without direct voting but just transparency reports. ie for things like creating new meme or small code audits simple stuff that doesn’t necessarily need entire community to be voted on.
  3. Setup bonus milestones for current employees being paid from #1

Things that I agree with:


Agreed. You have a very strong argument there. Now the real question is what will be the % allocation for this community/salary fund and how will the community would like to outsource this subset. I concur with @Chitty that unanimously the community signals a great response to compensate core and contributing team. This already includes future employees for the sustainability of the YAM Protocol.

How does the combination of Treasury buyback and lowering the LP incentives sound like? Anyway, whale LPers are just farming them massively, making them more of a whale than they are already. Worst case, small yam holders are being diluted heavily. At least if we are to compensate the teams that helped yam tokens grow its value… might as well align it with the community that supported the project and held through this supply contraction.

Minting additional yam tokens is a no-go. It defeats and forfeits the core advocacy of YAM as a fairly launched governance token farming.


I agree with this too. Treasury need to have a percentage for the development. And the team compensation should come from this part. Increase supply is super sensitive as it dilute every holders value.

A good circle would be: treasury funds development/asset allocation -> generate value for yam holders -> increase prices to positive rebase -> treasury increases and funds more products/asset allocation.

1 Like

The pay for current dev and supports don’t come from this, this is a “core dev managed fund” where we give control to core devs to pay for misc development with a monthly or x days transparency report.

So putting aside whether this YAM is “from the treasury” or not, what you’re suggesting on 1 & 2 is exactly what this proposal is.

1 Like

Yep, just agreeing with community.
I think the only additions is that the pay is fixed per person for a fixed amount of time and the dev slush fund.

We do have a fixed time on this YAM allocation (3 years). As for the exact pay per person, I don’t think that’s within scope of this proposal right now. It’s unrealistic to try and set that as the core team is still small and being established. This setup gives them the flexibility to be aggressive in bringing on new talent, recruiting people, etc. And as you said, it would certainly be understood/expected to have full accountability/transparency on where the funds go.

1 Like

Yeah, I guess I would like the time constraints to be a bit shorter and also spending to be a bit more definitive rather than giving the core devs carte blanche for 3 years.
For example:

  1. Core devs get $10,000 per month for 6 months or a year with a full time commitment to the project.
  2. Core devs get a slush fund of 2% of current treasury and future rebases to spend on the community supporters and anything else they need.
  3. These items are adjusted every 6 months or a year.
  4. The core devs should run like a business or a board of directors to make decisions on how to spend the money from the slush fund.

The numbers are examples, but I would prefer this solution.

1 Like

In most early-stage startups, the primary compensation come in these forms:

  1. Base salary – what’s required to pay your bills (rent, food, etc)
  2. Ownership (in the form of equity grants/options) – the incentive alignment, the upside potential, the type of thing that could make you filthy rich if it works

Due to legal/tax/regulatory considerations, for US workers (currently most of core team), we cannot have #1. However, we should certainly expect that core team still has to pay bills and may need ongoing support so they can stay focused on YAM. This is why we’re trying to set the precedence that contributors can get paid retroactively for that type of work. See this proposal for precedence to be set: Draft Proposal: Retroactive Compensation For YAM Contributors

So this proposal here is really about #2. The upside. The ownership. The YAM token incentive alignment. This is not meant to be the “pay your bills” compensation. This is meant to be the “core team will get filthy rich if they make YAM protocol a success.” And that’s good. Because that’s what we want. If they get filthy rich because of YAM tokens, then so will we! That’s aligned incentives. That’s a beautiful thing.

When new protocols launch, they reserve n% for the team to have. This is the equivalent of that. It isn’t salary. It isn’t to pay for groceries. It’s so that they have a big, juicy carrot in front of them to chase. And if they are successful in that chase, we ALL win.

1 Like

I have a clearer understanding now, but I am still cautious about:

Best case this is great for everyone, worse case this could be a disaster that will end up with Devs dumping on Yam hodlers.

I need to rethink this and offer a suggestion.

This proposal includes the compensation vesting over 3 years. Kind of hard to dump with that