hey, GAMA! thank you for your comment. I would like to suggest that we approach this discussion in a constructive manner, and set aside our emotions. It is important to work together to identify what needs to be added or changed to improve the current grant system. when expressing strong criticism, it is also helpful to share ideas and suggestions. we are all working towards the success of the entire ecosystem, rather than just individual projects. therefore, instead of engaging in criticism, let us try to unite everyone and create a single, active ecosystem where we can all interact and help each other. I would like to invite all projects from the Moonbeam ecosystem to join this discussion and express their vision and views. by doing so, we can have a constructive discussion together. Let us unite and work towards the success of a single ecosystem, rather than being divided and trying to insult others 
Hey, SvPatrik, itās amazing that you take the initiative, hereās an interesting sicco note that the community can replace any member of the committee with governance, so if you think you are ideally suited for this role and can really be of great benefit, then you should probably write a separate post where you you can tell the community in detail about yourself and why you deserve to be elected to the committee. I think that a new member has already been found, but this does not prevent us, the community, from considering your candidacy in the future, when 6 months have passed and the community decides that the committee needs to be replenished with new members.
Sorry if I sound insulting. But those numbers are no different from last time. If you think that the projects that claimed last grants wont claim new grants then this is blind ignorance.
My proposal is already given: exclude projects that got level 3 grants the last time. If there needs to be more money given to projects who are getting funding for 1year+ then there is an issue and product doesnāt fit Moonbeam.
Proposal:
- exclude last level 3 grant recipients
- cap last grant level 3 recipients
- define a lower maximum than 2 million
I donāt know what exactly is disrespectful in my message above but thanks for writing me a paragraph and reminding us to have a proper discussion without even discussing my points or concerns 
Its very refreshing to see that the grant program gets revised and updated to keep the ecosystem growing and allow teams to continue adding value to it.
I think I might introduce myself. Iām fron, from the BD team at Beefy. We actually talk with many protocols currently deployed on Moonbeam, and many of their concerns are considered by these improvements so I will not go in detail over it.
I think one important point is to find a way to distribute the grants in a way that fits the new organizational model of DeFi, which is DAOs. Right now some legal requirements are required, KYC team members, and if I recall correctly, also having a company listed in some country. DAOs work in a way far from companies and KYCs, because we are trying to build financial products that cannot be censored or stopped by the whim of a government. I think there is a good opportunity here to leverage the technology that we use everyday, to minimize the risk of losing funds from the foundation, and also keep the privacy of the people building the ecosystem.
Just to put an example, the Fantom foundation distributed FTM to the people building the ecosystem, without requiring names, IDs, or LLCs. They leveraged Gnosis multi-sig capabilities and different smart contracts to ensure that the capital āat riskā was minimal (i.e. distributing the grant in small batches). There are others examples to successful grants. Optimism only required 1 representative to share their name with their legal team to ensure they were not dealing with people doing money laundering, but they deleted the information after performing these checks.
Iām raising this point because DeFi is built by awesome coders, not big companies that have LLCs, legal teams, and huge companies behind. I think finding a way to minimize the trust, and have as much privacy as possible, is needed to get the best people building in Moonbeam.
as for whales, I mentioned this in my comment:
to which I received such detailed answers that the polkadot governance system is arranged in this way:
I agree that when several whales can change the outcome of the entire vote, then the system probably requires changes and configurations.
I was wondering how this could be changed so that whales and ordinary active users have the same vote power. I really liked the idea of Bruno from RMKR, but Iām thinking how technically possible it is to implement this in Moonbeam, and if possible, how long it might take, since the PureStake team is probably heavily loaded with other things.
as for Zircon, it seems that since market conditions dictate their own rules and all activities are concentrated mainly in other larger and more active chains, they probably decided that it made more sense to earn some reputation and a new influx of users from these networks. but of course I canāt speak for them.
it seems that it would be categorically wrong to exclude the possibility of applying for a grant to the stellaswap & moonwell teams, since this would look like centralization. perhaps it is worth discussing such a moment so that it does not happen again that only they will receive this grant, that is, to make an even distribution, it seems that this is a good moment for discussion in the community. I would like stellaswap & moonwell to join this discussion so that they can tell the community what has been achieved with the grant.
in fact, I noticed that the grant went to the maximum benefit, because before that it was not possible to use the ecosystem and make regular swaps without a high price impact, because there was simply no liquidity. it looks like stellaswap did a great job and added things like Pulsar, cross-chain swap, and they introduced meson protocol to the Moonbeam ecosystem. that is, I like how actively these guys work. it seems that Moonwell suffered a lot after Nomad, but they recovered and started gaining new momentum, and it seems that they are still practically the only working lending & borrowing protocol, so it seems that they need liquidity and support so that they can attract new users, and, of course, in order to the project has to some extent become independent of grants. they also recently shared the wonderful news that they will integrate with BASE, which should attract a large number of new users to the Moonbeam ecosystem. but, of course, in order to get a broader overview and see the big picture, I would like representatives of these projects to share their indicators so that the community can get a broader idea of what has been achieved with the grant
Zircon was pretty clear that they are leaving Moonbeam due to Foundation favoring two protocols only.
Why? Stella has gotten more than $12 million last year and so did Moonwell. How is this good for the ecosystem. Donnie left and created his own chain. Zircon left and god knows how many people are leaving behind the scenes or not even coming to Moonbeam for that exact reason.
Also giving an option of 4 million out of 4.5 to two project is centralisation.
Yea and donāt know how that helps Moonbeam who paid for audits invested in Moonwell and they will deploy this tech elsewhere. How Moonbeam is okay with that is beyond me.
I wonāt reply anymore. Expressed myself and all I am saying is same story. People working for Moonbeam trying to justify centralization on chain even more.
Zircon hasnāt even been deployed on Monbeam yet, and also I havenāt seen what youāre talking about anywhere.
here is a clear response from Zircon, which I see in their last tweet:
as far as I can see from the information about the grant, stellaswap received - 7 833 600 GLMR.
I think I explained in the last answer that it became possible to use the ecosystem because new liquidity came, which was so necessary for the ecosystem. if you noticed, protocols such as beefy, lido, curve also received a boost in TVL when the liquidity from stellaswap started moving into these protocols.
it seems that Moonsama / Exosama have grown quite a lot in two years on Moonriver and in their case it was reasonable to create their own separate game chain where they could work faster in this direction and not depend on anyone, so it seems that this example does not fit this topic at all.
A large number of protocols / games are under active development, and I also expect that after incubation on Moonbeam Accelerator, excellent projects will be deployed in Moonbeam / Moonriver. I believe that when the ecosystem is filled with new projects, the distribution of grants will also reach a new level and will look in some other way.
I think the main idea will be that with the help of connected contracts based on Moonbeam, Moonwell can link the liquidity of Moonbeam<>BASE. i.e it looks like the idea is similar to what PRIME is working on, but Moonwell will work in the direction of BASE<>Moonbeam. i.e it will allow Coinbaseās 110 million users to access Moonbeam assets.
this topic was created specifically so that all network members could make constructive comments / suggestions that can help MF make some adjustments based on feedback from all community members.
Hi, this is Andrey from Zircon. Wanted to pitch in to the discussion, also because weāve been mentioned by name.
Overall I think this grant is definitely better than before: shorter duration grants, limits to max grants, removing the first-come-first-serve system.
As for voting system, Iām definitely not a fan of leaving conviction voting in. While it sounds like a nice idea in theory, in practice it makes the voting that much more plutocratic, since only the largest of whales have the luxury of locking large amounts of GLMR (which might be say 10% of their stake).
Itād be great to introduce a Gitcoin-like quadratic funding model, though unfortunately given the stakes involved, there is a 100% guarantee that it will be defrauded through sybil attacks (even if we KYC voters, this still would be gamed). So 1 GLMR = 1 vote seems like the least bad option.
As for our own take: as @turrizt correctly mentioned, we never said we were foregoing the Moonbeam deployment, but rather waiting until the playing field would become more level. As you may know there is not a single DeFi token on Moonriver with more than 1 million market cap, which makes it very difficult to compete with millions of GLMR being injected every month into a competing DEX.
I expressed a similar concern around the time of the first grant discussion: Stella and Moonwell taking the entire 6 month allocation would send a very bad signal to other builders, and I believe weāre not actually the first to react to this signal.
Weāve also had our own experience through a 15K MOVR grant destined for liquidity mining. Our goal with it was to bootstrap the platform and our token, and take it from there. In that we were successful.
Our experience actually taught us two things:
- Each pair needs a ābreakthrough liquidityā amount. Basically, for a median trade size, there needs to be enough liquidity so that the price impact would be at least comparable to the fee. Anything below this threshold means the platform is unable to attract organic taker flow. Any liquidity above this threshold is effectively unnecessary and incentivizing it is wasteful.
- Starting out with some hard value to distribute to early users makes things much easier for projects.
Our grant was excellent for bootstrapping, but not enough for breakthrough liquidity (the entire grant sum was roughly one month of Solarbeamās continuous rewards). In fact beyond the first month, the MOVR grant wouldāve served much better as a rainy day fund for the project, rather than distributed to mercenary farmers. Still, despite being relatively small, the grant was crucial for setting ourselves up and iterating on the product.
I think previous grants suffered from a goal-execution mismatch. They were designed as ācommon goodā grants to create some baseline layer of liquidity (which is a useful goal, especially post-Nomad). Since a breakthrough liquidity level was necessary, the grants were very large.
But:
- They were given to single teams in a particular niche, resulting in preferential treatment and creating an artificial moat against other, potentially more competitive or innovative projects
- They were never pulled to see what would happen. For example on Moonriver, fee revenue makes up around 30-40% of the total APR for the MOVR/USDC pair on Solarbeam. Even we use it because itās an acceptable level of liquidity for MOVR, meaning that all decentralized taker flow is already going to Solarbeam. It will only increase if demand for MOVR as a whole increases, which is however hindered by the inflation from MOVR rewards ā a catch 22.
- The details of how they were applied was wasteful. For example, liquidity incentives to lending platforms do not work in the same way as DEXs. Recursive supply ā borrow generates zero economic value or liquidity, it merely pads the TVL stats. If that is the goal, it makes much more sense to pump rewards for a StableSwap/Pulsar-style pool of stablecoins, which at least lets people switch between token wrappers. While for lending platforms, incentivizing just the supply side actually creates usable liquidity.
So, to give some concrete suggestions for a new way to do grants:
-
Common Good liquidity should ideally be split between different platforms. Even better would be to create a common good DEX/app for it, managed by GLMR holders or something similar.
-
Grants to individual teams should be given on a bursty, iterative basis. For example, I think itād make sense to give Stella a 1-2 months burst of rewards to bootstrap their Pulsar pools. If the liquidity is gone after pulling them, weād know that thereās no pmf and no point in incentivizing it further. Then the same can be done with us, BeamSwap or whoever else can justify this.
Bursts of rewards also generate extra attention and bring more eyeballs. I.e. itās far more valuable to be at the top of the Defillama yields page for a month, than be on page 10 for 3 months.
To modify the current proposal for this itās sufficient to:
- Create a separate track for common good liquidity. Basically create ātender offersā for common goods, placing restrictions to how many of them can be obtained by individual teams. Recirculate the grants between teams based on results/circumstances/time passing.
- Cap the team grant periods at 2 months at most
- Cap the team grant max amount to something that would leave enough liquidity for 5-6 such grants. 500k GLMR maybe?
- Make the process continuous, no need to vote for all grants at once
The purpose of my proposal is to reintroduce consistency between the goal of the grant program and its execution: common good liquidity is covered through shared tenders, and teams have access to a sufficient bootstrapping stash.
Iāll finish with a frank comment. Some people think that the previous grant proposal was a nefarious plot to centralize the ecosystem. I think itās more likely that Moonwell/Stella asked their Moonbeam-focused VCs to vote for it, and the VCs agreed with the spirit of the proposal (restart liquidity post Nomad) but didnāt care nearly enough to go into the details of the proposal or the other builderās outcry (trust me, literally only the Stella and Moonwell teams were in favor of the proposal as it stood).
Voter apathy is a thing, and I think that a little ātechnocracyā in the grants process wouldnāt hurt. The devil here is certainly in the details.
Hi everyone, this is Luke, a founding contributor to Moonwell. I recently had a chance to read through the new grants process proposal and wanted to express my support for this process.
On behalf of the Moonwell community, we applied for an interim grant last year and wanted to thank the community for the thousands of votes and support we received for our grant application. We shared a grants transparency report with the community in December.
The short version is that the Moonwell community has distributed approximately half of the interim grant, or about 2M GLMR so far, to liquidity providers on Moonwell Artemis, and this grant has enabled the community to launch new markets for Wormhole wrapped ETH, WBTC, USDC, BUSD, as well as native xcUSDT, and grow to over $50M TVL. This is an impressive accomplishment considering the devastating impact that the Nomad exploit had on liquidity across Moonbeam.
What we as a community couldnāt have predicted were the widespread impacts of the FTX collapse, which happened almost immediately before these new markets launched, on every part of the crypto industry. Those impacts led Gauntlet Network, another core contributor to Moonwell, that provides risk management expertise, to recommend a ācappedā launch for these new markets that limited the amount of borrowing capacity and collateral ratios to avoid unnecessary risk to the Moonwell protocol and community.
Due to this capped launch, the Moonwell community has been able to be conservative and has only distributed approximately half of the interim grant.
What does this mean? Generally it means that the Moonwell community still has enough grant funds remaining from the interim grant to last until June/July timeframe, so the Moonwell community will not require new grant funding until the second tranche of this new grant cycle.
We want to assure the Moonbeam community and all of the supporters of Moonwell and StellaSwap that weāll continue to be good stewards of the grant funds that the community has trusted Moonwell with and that 100% of all grant funds will be distributed to liquidity providers over time. Our community has never used grant funds for development costs or for any other purpose than liquidity incentives, and 100% of the MOVR and GLMR grants weāve received have been distributed already or will be distributed over time.
The future is pretty bright for the Moonbeam ecosystem and now that weāre starting to see liquidity re-enter crypto markets it validates our communityās strategy to conserve grant funds to get the most impact from them.
TLDR; the Moonwell community will most likely apply for a grant in tranche 2 of this new process, which will leave plenty of room for other projects to apply for tranche 1 while the Moonwell community continues to distribute existing grant funds to liquidity providers.
Having read through all of the posts, I want to express my support for the proposed changes, particularly to the new Ecosystem Grants process. I see these changes as a natural evolution and an application of the lessons learned from the previous Level 3 grants process. Itās apparent that the changes aim to make these large grants more inclusive while still focusing on providing the greatest benefit to the ecosystem and network.
It was great to hear the news from @Trilemma about the successful management of the previous grant received by Moonwell, as well as their likely decision not to submit a proposal in this cycle. If this is enacted, I imagine that absent a proposal from Moonwell, their community will be looking to back exciting projects in an Ecosystem vote. I hope that they would end up supporting teams that have a focus on growing Moonbeam and that want to be collaborative and step out of project silos.
Regarding StellaSwap potentially receiving another large grant in the new process ā I do see this as a possibility with a rally from their community (which in many ways would be a testament to the community they have built). But the new process appears that it has been designed to be inclusive of many teams, where there would still be a majority of GLMR left to be distributed in grants.
I hope the proposal can be looked at objectively, as itās easy to get caught up in emotions which end up distorting the bigger picture. If enacted, this proposal should enable more teams to receive support which will have a downstream effect of helping every team in the ecosystem.
AS @Jim_CertHum points out above, we expect a different and more diverse set of recipients of the Ecosystem grants given the changed structure and participation. The open call for grants and multiple choice voting was designed to address the main issue teams had with the fairness of the last program, and will almost certainly result in greater diversity of recipients. But ultimately it is token holders that need to decide where these incentives go. The role of the Foundation is to create an environment where token holders can express themselves. Excluding available options is at odds with allowing token holders to choose what they want. Keep in mind that Moonbeam actually has a very broad token distribution across a lot of holders, which brings with it a diversity of opinions, including those on this forum. In the end the token holders will get to decide the outcome.
Thank you for the feedback. The foundation will explore if there are ways to adapt the KYC grant requirements currently in place. We, like so many in this space, struggle with how to adapt compliance rules designed for a more traditional landscape to better serve DAO structures and on-chain communities. We do not have that answer yet and the current requirements are based on an adopted KYC policy that has undergone formal legal review. One possible way forward will be to move these activities to OpenGov and remove the Foundation entirely from the process, making it part of the protocol. Until that happens the KYC requirements are likely to remain.
Unlike last time, the key vote that will determine the recipients of the Ecosystem grants will be done using snapshot. And snapshot has no concept of conviction in it. The multiple choice voting in snapshot will result in a weighted set of choices.
Taking a step back to clarify, the Ecosystem grants program itself (this post) will be voted on using the regular substrate functionality, just like last time that has conviction and allows for voting with staked GLMR. Once the open proposal period is over, the vote with all eligible proposals will happen in snapshot. Snapshot has no conviction, and also does not support voting with staked GLMR. Once the snapshot vote completes, the results will be ratified using substrate functionality, to memorialize the results.
The forum is great, and thank you for the great grant proposals!
I have the following comments:
- for the overall goal, how do we check Maintain and Grow Activity? is that the history activity or the future? And is this one time payment or based on milestones from the proposal? If it is a big grant, I would recommend that the team can give out the reward based on the milestones, or different phases.
- In the Overview of Program, the image has the grant amount: Up to 2mm GLMR per tranche, so the 2mm means 2 million or 2 million million? You use 3m in the same image for community committee grant
- For the snapshot voting, why the locked GLMR is not considered? Have the team considered the snapshot voting from opensquare (example here: CP34(GI): Open HRMP channels between Centrifuge and HydraDX)ļ¼ the good thing about that is users donāt need to lock their token and they can also vote with the locked token as long as the token is in their wallet when the snapshot is taken. You can probably attract more ppls participating the governance vote.
- One cent of recommendation, it is great if there is an AMA session for the team before the vote, since a lot of ppls donāt really read the proposal and donāt know the team, it would be great if there is a chance for them to communicate directly
- For the weighted snapshot voting, I am not sure if my understanding is correct, so if I hold 100 GLMR, and there are 2 projects, I can vote 10 to the project 1, and vote 90 to project 2, and finally you will count how many votes project 1 got, and project 2, ā¦, etc., finally, how do you decide if the projectās proposal is accepted? Any threshold like how many total votes the proposal needs? It is not very clear to me.
Idk how i missed this proposal, but i think itās good that i saw it anyway.
Better later then never. 
Iād like also to be included next time in Non-Foundation Community Grants Committee Member.
I saw Turrizt reply so will try myself also.
Will the number of Non-Foundation Community Grants Committee Member be increased in future? Or they should be replaced only?
Thanks
Hey, Extezy, imo, 3 committee members are more than enough, so I think that the number of committee members will not increase. i.e to get on the committee, you need to replace someone from the existing members
Thank you @turrizt for the info, you are the best as always 
Is now up for vote
This is an excellent point - the teams that are applying for the Ecosystem grant program should address this and provide historical KPIs; as well as ways for the community to check this throughout the lifecycle of the grant disbursements and beyond.
2mm means 2 million GLMR
Actually, this has been addressed. When the proposal was written, Snapshot did not support locked GLMR due to technical reasons. Engineers in the Moonbeam community brought this up with them and worked on a solution alongside Snapshot to provide support; so you can now actually vote with stacked or ālocked in governanceā GLMR.
Voting with Conviction, however, is still not supported.
Completely agree that an AMA session and additional education on the draft grant proposal would be great - the Foundation is working on organizing this.
Good question - there is no quorum requirement for how many votes, but there are restrictions on how big or small a grant can be (take a look at the āAdjustmentā section of the proposal) - the maximum grant size is 2mm GLMR and the min is $250k (using a 7-day TWAP when the grant program proposal passes).
āEligibleā Draft Proposals need to submitted in the forum on time and incorporate the required feedback from the Community Grants Committee (for more detail on this, please see āCriteriaā for Eligible Ecosystem Grants Proposals in the Grant Program Proposal )
Thanks for the comments and your interest in serving as a Community Grants Committee Member for the future. The current term is 6 months for a Community Grants Committee Member and it is up to the community how they want this Grants Committee to look and how Community Grant Committee Members are approved / elected for the position. Suggestions here in the forum are welcome whenever, but especially closer to end of term for this project (approx. August 2023, assuming this grant program proposal passes).
Link to the on-chain voting:
This topic was automatically closed after 14 days. New replies are no longer allowed.