[Referendum: 87] Revised Grant Program

[GAMA]

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

[frondoto]

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.

[turrizt]

as for whales, I mentioned this in my comment:

@turrizt

I really liked that the process has changed and is no longer first come, first served, but instead has a certain deadline when teams have the opportunity to submit their projects. After that, a general vote will be held where everyone has an equal chance. The only thing that bothers me is whether there is a limit on the number of tokens with which one user can vote? It seems that if one of the communities has a large whale as an ally, then this whale can affect the entire outcome of the vote. What do you think about this?

to which I received such detailed answers that the polkadot governance system is arranged in this way:

@liv_moonlife

Re: the question of whales and voting is something that I think all governance systems are struggling with right now. I think it’s good to discuss and call out if that’s happening and to suggest alternatives. Right now, substrate governance doesn’t have obvious solutions to this issue that im aware of (but pls correct me if Im wrong). My hope is that with OpenGov Agile Delegation, maybe smaller token holders can more easily band together via delegation to be more active in votes against whales.

@sicco-moonbeam

Vote Weighting & Whales
As liv_moonlife mentioned, this is a problem across a lot of the web3 protocols and somewhat inherent in a proof-of-stake system. It’s also somewhat subjective and relative - your smaller token holder is someone else’s whale. I think this is something we should all continue to think about and discuss; and we should continue to provide opportunities for smaller token holders to contribute to governance in a meaningful 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

[GAMA]

@turrizt

as for Zircon, it seems that since market conditions dictate their own rules and all activities are

Zircon was pretty clear that they are leaving Moonbeam due to Foundation favoring two protocols only.

@turrizt

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.

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.

@turrizt

they also recently shared the wonderful news that they will integrate with BASE

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.

[turrizt]

@GAMA

Zircon was pretty clear that they are leaving Moonbeam due to Foundation favoring two protocols only.

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:

@GAMA

Stella has gotten more than $12 million

as far as I can see from the information about the grant, stellaswap received - 7 833 600 GLMR.

@GAMA

How is this good for the ecosystem.

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.

@GAMA

Donnie left and created his own chain.

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.

@GAMA

Zircon left and god knows how many people are leaving behind the scenes or not even coming to Moonbeam for that exact reason.

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.

@GAMA

Yea and don’t know how that helps Moonbeam

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.

[shvandrew_Zircon_Fin]

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.

[Trilemma]

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.

[Jim_CertHum]

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.

[sicco-moonbeam]

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.

@frondoto

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

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.

@shvandrew_Zircon_Fin

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).

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.

[DrCAO]

The forum is great, and thank you for the great grant proposals!
I have the following comments:

1. 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.
2. 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
3. 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.
4. 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
5. 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.

[extezymr]

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

[turrizt]

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

[extezymr]

Thank you @turrizt for the info, you are the best as always

[jose.crypto]

Is now up for vote

Revised Grant Program

[sicco-moonbeam]

@DrCAO

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.

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.

@DrCAO

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

2mm means 2 million GLMR

@DrCAO

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.

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.

@DrCAO

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

Completely agree that an AMA session and additional education on the draft grant proposal would be great - the Foundation is working on organizing this.

@DrCAO

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.

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 )

[sicco-moonbeam]

@extezymr

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 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).

[turrizt]

Link to the on-chain voting:

Revised Grant Program

[turrizt]

@sicco-moonbeam

Any Eligible Draft Proposal receives fewer than the equivalent of $250k worth of GLMR (calculated with a 7-day TWAP from the date this proposal is enacted) will be not proceed to an on-chain vote and the funds allocated to that Eligible Draft Proposal in the Snapshot Vote will be deemed “Leftover”

Hey sicco, I wanted to bring to your attention that the community has started discussing the selection process for projects eligible for on-chain voting. there seems to be some confusion on whether projects should achieve a certain % of votes or reach a GLMR score of $250k. could you please clarify this by providing an example based on the current results? I have included a screenshot for your reference.