[Discussion] Adjustable emissions Cap

The cap on emissions has helped make the allocation process faster and easier to coordinate every epoch. This comes at the cost at capping incentives as well

This discussion is to move towards a cap setting that is connected to 2 variables that will help better align incentives.

-Existing holdings
-Emissions held from last epoch

One example is

User X has 4 skill roles - the emission for those is 80,000 GRAPE
They are holding 100,000 GRAPE
They received 30,000 GRAPE last emission and sold 0 GRAPE
Gorilla = 20,000
Emission ladder = 10,000
Cap amount = 20,000

Max emission is then calculated (this is an example formula)
(holdings/gorilla)( ladder)(last epoch emission remaining/last epoch emission sent)
(100,000/20,000)*(10,000) * (20,000/20,000) = 50,000

Using this formula the user would receive 50,000 + 20,000 = 70,000

This is a STUPID formula – its just an example for how the variables could be used

For discussion to be valuable - DO NOT FOCUS ON THIS FORMULA - some things I think are valuable to discuss:

Variables to use
Formulas to propose
Data points needed to explore this concept
Reasons why we should not have emissions calculated using any formula


I have a vault wallet where most of my emissions are sent, I only keep enough in my wallet to maintain my membership, as am not a fan of keeping my eggs in one basket. This is a phobia I have as I really don’t want to lose all assets by holding in a single wallet.


Exactly what I pointed out during todays meeting. Papa Dean said something about safewallet equals no added emissions.


would this be solved if you were able to link multiple wallets to your grape verification?


yeah it will be solved. i hope to see that feature

1 Like

In this case, I guess it’s safe to say that we should only look the way of this formula once the multiple wallet function is up and running, for the benefit of members like us

1 Like

I can’t think of any other variables to use.

I can’t help but think that any equation we come up will be arbitrary because we don’t have a target variable that we’re trying to optimize for. And to that point, I’m not sure why the cap is needed. Is it to prevent concentration? Would it really be that significant? Because the downside is that it skews incentives – if you are at the cap, you are incentivized to not contribute anything more, and if one role you have already makes you reach the cap, then you are incentivized to quit your other role (I’m in this position btw).

One different type of solution is to delay distribution beyond a cap so that you will have to wait until others have gotten more GRAPE to get yours, reducing concentration.

Would love to see a list of people who went beyond the cap and by how much to get an idea of how much concentration this would cause.


A good target variable could be skillforce holdings as a percentage of circulating supply

Or something similar

Seems pretty hard to know what the ideal % should be, especially since I wouldn’t expect it to be static. % of skillforce workers should be higher earlier on in Grape’s lifetime (since Grape has fewer things to offer compared to later), and % of non-skillforce should increase later. But ultimately it’s about how much GRAPE each person has, so we also have to take the initial distribution into consideration too. Quite complex.

What percentage of the GRAPE workforce would this actually affect?
I would agree with Durden on the grounds that there shouldn’t be a cap if the number of emissions towards these members isn’t significant… especially if the target variable skill force. If a member is putting in the work, then they should be recognized in this meritocratic group.

From my short time observing, I would further add that policing the GRAPE workforce needs to be figured out as we progress towards this revamp…I need to think about this more and figure out what can be done about it.


I agree that this is probably one of the greater issues in this discussion - role assignment needs to be better and incentives need to help make that happen


I think Durden is right on his approach but maybe we can see it as two separate issues

We are trying to solve two problems with one move:

a. Allow those who work more to earn more
b. Incentivise those who earn to hold

Trying to solve each individually is easier. (examples)
a. When someone hits the cap, the cap increases by 10%.
b. Single Staking Pool that distributes extra emissions. The more grape you stake the more you make.

So the person working more (consistently) will receive slightly more Grape, staking it will allow them to make even more, as long as they held.


I’m going to rephrase my position.

The need for a cap is not at all obvious to me. To my knowledge, no reasoned argument for it has ever been put forth; it was just implemented in the early days of Grape. I still don’t know what its rationale is.

In my mind, the default should be “reward everyone according to how much they contribute”. A cap is a modification to this straightforward concept, just like “every skill role should have a minimum amount of emissions they receive” would be a modification (that’s just an example, I’m not suggesting we should do that). So the burden of proof is on those who want to modify (what at least I consider to be) the simple and obvious approach.

We shouldn’t be having a conversation about how to adjust the cap when we haven’t even established that the cap is necessary or even a good idea. And if no one can give a good reason for it, then we just get rid of it, problem solved!

1 Like

In general, I support the idea of a more differentiated view on emissions and the emissions Cap. As I mentioned during the meeting, in order to get a better grasp of what would be a good Cap, we should calculate some examples based on our actual numbers. If I remember correctly @BloodBath1 was so nice and offered to do that and I’m curious to see how this develops.

I’d also like to add that we should keep in mind that a fixed amount of emissions per Skill Role implies that everyone with this Skill Role does the same amount of work. People with two or even three Skill Roles of course can do the work of two or three others with just one Skill Role but I’d guess that this isn’t the case.
So if we keep the assumption that all members with a given Skill Role get an equal amount of emissions due to similar merit, maybe we need to consider an additional modifier for the emissions of the second/third Skill Role. The Skill Role with the highest emission would be considered as their first role.

A moderate reduction could be:
1st Skill Role = 100% (of emissions)
2st Skill Role = 75%
3st Skill Role = 50%

With a more aggressive reduction, this could also be a more simplified version used for Cap-removal. Maybe you could check this too @BloodBath1 :slight_smile:


  • Skill Role A = 10,000
  • Skill Role B = 20,000
  • Skill Role C = 15,000

2nd Skill Role = -60%
3rd Skill Role = -80%

Member with Skill Roles A and B = 20,000 + 10,000 x 0.4 = 24,000
Member with Skill Roles A and C = 15,000 + 10,000 x 0.4 = 19,000
Member with Skill Roles A, B and C = 20,000 + 15,000 x 0.4 + 10,000 x 0.2 = 28,000


Will be reviewing in greater detail, but these are points I think define the potential template → Looking for the simplest method to avoid complicating it.

A.) Holding
B.) Roles
C.) Activity
D.) Emissions
E.) Epochs Elapsed
F.) Caps
G.) Adjusted % to Reduce Emission by Holding
H.) Ladder

Draft Template → Still working out some of the details.


I suggested caps in the first epoch emissions because I could see examples of inactive people with roles allocated to them AND no one had suggested those roles be removed

Instead of waiting on subDAOs to police the role attribution, my suggestion in that epoch had been to cap.

I believe it was continued because of this reason – but thats just my opinion

Anyone could take the initiative and create emissions for an epoch without a cap. I think once someone goes through that exercise they quickly see that role allocation is the tougher issue.

I am neither for or against a cap for this next epoch - but i can understand how it is a bandaid for the underlying issue of role allocation (and the difficult nature of role removal)

1 Like

i like this model and it solves for a few issues without being overly complex

love this initiative. hope more people will comment on this formula

That makes sense in the early days as there was little organization, and there was a transition period where a bunch of people got roles for the OG airdrop but stopped contributing afterwards.

Speaking from my experience in the community creator and researcher subDAOs, it took a couple epochs, but we have removed the members who we deemed to be unworthy, usually because they had stopped contributing at some point. I’m assuming other subDAOs have had a similar progression and that now we are all pretty good at self-policing. So I doubt this is a problem today. If you’re in a subDAO where it is, please let me know.

If it’s really a concern, I think there’s an easy way to see if the cap is accomplishing that particular purpose: create a list of everyone whose emissions were over 30k (I assume it’s not that long) and see if there are any bums (people who have a role but don’t really do much).

So from my point of view, I still don’t see a need for a cap.


FYI, the community creators and researchers subDAOs have emissions based on tiers so that those who contribute more receive more. This is something I pushed for in both subDAOs because equal emissions for all is poor incentive design. In particular, it incentivizes members to contribute just enough to not get booted from their role but nothing more. So I hope other subDAOs eventually move away from the equal emissions model as well.

I think this solution works better than the universal modifiers you suggested that would apply to all subDAOs because in that case the reduction amounts would be arbitrary percentages, whereas if each subDAO can adjust the amounts each tier receives themselves, they can accurately account for how much of a difference in time and effort there is between each tier.

But before all this, if you’re in favor of a cap to begin with, I would be curious to hear your case for why we should have one.