I am all about giving to Cesar what is Cesar’s, however, I propose that a limit in USDT be put in place, for example a maximum of $1 million (purely arbitrary, this can be subjected to change) as a threshold per month for development purposes or if the threshold is not reached, the full 12.5%, the rest up to 12.5% going either to the treasury or being burnt.
By doing this, we effectively eliminate the possibility that the team might be seen by the community as receiving too much of an allocation, thus giving an even fairer view to the project.
Please let me know if this idea resonates with you too.
Understandable, however the 12.5% share comes at the sacrifice of any share of exchange fees and enables us to use the funds for the overall operational cost of EasyBake, including dev pay, but also all other aspects associated with the costs of running a cryptocurrency project, including marketing, exchange listing, etc.
In my opinion is to much and a little greedy to receive every day that amount on OVEN. Don’t BE GREEDY!!!
I think this is not a problem. It is in line and better for community than many projects. Allows them to attract the best development talent and continue to develop product with funds to do so. They will control a decent share which will prevent project being control by whales too much.
I think the 12.5% is fine to start, most other tokenomics have this much going to the team of total allocation. I think the concern comes in that as the project progresses and grows or becomes very successful. The 12.5% is just notated as for the Team, maybe have restrictions on what the funds can be used for? Or possibly have the amount tail off after the first year once certain milestones are achieved allowing more tokens for the community and decentralization. While providing enough tokens for the team to initially get exchange listings and marketing started.
I think 12.5% is acceptable, especially when compared to other projects.
Yes, this was exactly what I had in mind too. If the project becomes (and it will most certainly will) successful, 12.5% might amount to a ‘yuge’ balance. Still, as Chef Buns said, the team doesn’t get anything in the form of fees, so it might be, after all, fair enough as it is.
This is often a point of contention with crypto projects. I fully understand what you’re saying (as I am building my own project, so get exactly what you mean.) I think what might need to be done is simply a more detailed breakdown.
If people can see what is allocated for each various category, operations, ongoing daily costs, marketing, etc. up front, rather than trying to explain afterwards (and only to those who ask, missing the vast majority) it might alleviate some misconceptions of what it takes to run a business. Many simply picture the “team” making a million dollars a day. lol
Within an explanatory breakdown, perhaps even add a cap to the team “profits” (after standard salaries for those engaged in daily operations) and show that anything above that threshold will be used for extended marketing, added to liquidity where needed, added to company reserves, staker rewards, competitions, games, or burnt, whatever.
I just think without a detailed breakdown, it’s easy for people’s imaginations to run away.
I think 12.5% is a reasonable amount. As others have stated, it’s not just team salaries. The funds will be used for all operations ensuring Easybake has the tools and resources to be successful. Chef Buns and the team, with community input, have put a lot of thought into what needs to happen in order to operate on the scale we will grow to and I don’t see any greed in this design.
I do think it would be wise to change the wording from “Development Team” to “Operations”, “Business Development” or something else that is more encompassing of the full uses of the 12.5%.
Yes, good points, perhaps calling the whole lot ‘team’ perhaps should be reconsidered then.
I don’t have a specific suggestion, but maybe consider separating it out?
I want the team to get rich. They need to be motivated and I want the team to be able to afford to keep and acquire the best devs in the space so they can constantly innovate and stay ahead of the competition. So, I have no problem with this amount. As long as our incentives are aligned and we earn when they earn, so we’re al on the same team, I’m good with the team making serious money. I can’t code this shit, so anyone who can deserves to get paid.
The percentage is reasonable ok.
Yup. I’ll reiterate, if the team cannot get wealthy from this, what’s their motivation. They deserve to make many, many millions off of a project that will be valued in the billions. We’ll all get our small piece. They did the work. They should get their proportional piece, which should be 100x whatever I get. Capitalism, kids.
I think it’s fair. If we want a top notch project we can’t be cheap. If the project takes off it will be in large part because of development so I don’t see any issue at all with the percentage.
Yes I have mentioned this as well, because I have had people ask me why the team is getting so much. Then I have to explain that it’s not all for “the team” as they think… it is the entire operations budget.
So in a way, most of it is actually coming back to the community anyway as further development, marketing, etc.
Very true, I think most agree in that regard. The only change really being suggested is to the wording, to better clarify the breakdown and use of the allocation to hopefully head off the typical objections from so many who won’t see past “the team” taking that big percentage.
I think part of the 12.5% should be separated and earmarked specifically for ‘interoperability.’ I think having a separate fund for this alone is inherently bullish to outside observers. This signals to outsiders that we’ll be on many chains and take it seriously by allocating funds to it on a daily basis. This also speaks to future volume. If we could be on 12 chains, we could generate 12x the volume…if I were a VC, that would make the difference for me.
12 Chains with separate liquidity pools? Or are you talking shared liquidity pools somehow?
Shared liquidity over mutiple chains over multiple chains is possible - but tricky.
Pancakeswap (and probably Uniswap, but i don’t use it much) does multiple stage swaps.
If I try and buy something with $CAKE which doesn’t have a liquidity pool for that pair, the ‘route’ tells me that (for example) it’s fulfilling the swap by converting the $CAKE to $WBNB and than swapping that for the token I want, because a $WBNB pool exists.
You could do the same for multichains - have all the liquidity on one chain and if anyone tries to swap (or add liquidity) from another chain, automatically do the conversion steps in the background, and wrap tokens where needed.