UCG (Unstoppable Community Grants) is a program created by Astar and promoted as a means to find financial support through dapp staking o a temporary basis. In brief, a teams proposes its participation and subsequent listing by highlighting its milestones, experience, and value it aims to bring to Astar. The community of voters vote to include or not and if in agreement to include, the project is listed in the Astar portal where any user is free to stake on them, while a portion of the Astar Community Treasury is staked on the project to bootstrap rewards. Project must maintain the community informed of milestones completed on a monthly schedule and is allowed to complete up to 2 rounds of UCG participation (each round is 3 months long).
To gather all opinions, feedback, issues, solutions, and ideas around the current iteration of the UCG program.
To help implement more standardized practices/guidelines that help establish accountability and oversight of participating projects and their milestones.
To suggest metrics and other criteria we, as a community, can use to evaluate participating projects, their continued involvement the communities support, and/or their success.
To highlight current community members and teams who seek to improve the program.
Note:
Please feel free to start giving comments on the current program - what is and isn’t working, and any other topic around UCG.
To begin, some open thoughts from my end about some UCG topics:
Alignment with dapp staking Voting Periods - 1 vote period (4- months), cohorts being added at the start of new periods, but if needed removed during period due to xyz circumstances
KPI (Key Performance Indicators) stated and agreed upon with community
Standardized funding report (cost, spends, date of ASTR sell, etc) filled out monthly
The fixed dApp Staking cap of 17M ASTR is too rigid and insufficient, particularly during token price drops. This places undue strain on projects, as the rewards often fail to sustain operations or give teams the opportunity to prove themselves in challenging market conditions.
It has been suggested before to increase the cap to 23–25M ASTR, providing a buffer (“some breathing room”) for dApps during downturns. However, this advice has yet to be implemented. Revisiting this decision is crucial to better support projects and ensure their long-term success within the ecosystem.
Thank you and I agree on the “buffer” zone. This can be a welcomed proposal and I would support it. The push back I have initially as it would decreased the amount of teams now the community treasury can support, but in return I can see that we would be more rigid in our processes and election criteria - as well as more critical - of the teams we vote onto the UCG.
Just thinking out loud and looking to see if this would be supported:
Lets create a UCG-IP (Unstoppable Community Grants Improvement Proposal) that includes 2 or 3 aspects to improve with a simple majority vote here in the forum (with a 10 count (?) quorum in order to make the changes to the program?
It’s a good idea, and I believe UCG should focus exclusively on DeFi projects and ideas that directly enhance $ASTR’s value and utility. Prioritizing such initiatives will ensure the ecosystem’s growth and sustainability.
One potential improvement to consider for UCG eligibility is to establish stricter requirements for projects applying for support, particularly in the game and marketing sectors. Specifically, we could mandate that game projects must not use assets purchased from marketplaces like Envato, Fab etc…, and projects should exclude the use of AI-generated content, such as assets created by ChatGPT, MidJourney, or similar tools. Both types of projects should focus on original works and assets created in-house to ensure that UCG funds support truly unique, high-quality contributions to the ecosystem.
Additionally, projects should be required to provide the sources and raw materials related to asset creation, including detailed documentation of the design and conception process. This would ensure transparency and demonstrate a commitment to originality, especially in the case of game mechanics and marketing strategies. Any external tools or resources used, such as AI, should be properly documented to maintain clarity and accountability around the creative process.
By emphasizing original works and clear sources for asset creation, we would foster creativity, innovation, and authenticity within the community, ensuring that UCG funds support projects that are both unique and sustainable.
Is this a specific guideline to only be applied to gaming and marketing sectors? If so I would like to counter this point for arguments sake and to provide other perspectives on the matter. And I say this as a creator myself and even having an art project built from scratch with no AI components and tools used. I’ve commissioned plenty of 3D art and models before as well so I have some knowledge of time and cost its takes. I do appreciate the sentiment bringing this up though as its speaks to a larger scale phenomenon that is bigger than UCG itself.
In this case such restrictions/strictness might stifle creativity and limit access to tools that democratize content creation - especially as UCG funding doesn’t amount to large amounts throughout its duration. Rather than imposing strict prohibitions, an approach that encourages transparency (as in each team openly saying what assets/tools used) and originality (what was created by without AI) while allowing the use of AI/other external tools and resources might better serve the community’s goals, especially as many UCG projects are in the beginning stages of development.
Not everyone has big budgets or teams. Tools like AI and marketplace assets help smaller creators get started. Banning them could push out talented people who just don’t have the same resources.
Using pre-made assets or AI can save creators time, letting them focus on the big ideas instead of reinventing already existing assets. Originality isn’t about doing everything from scratch, it’s more about how you bring ideas together and how its shown/experienced to viewer.
Great ideas often come from combining existing materials in new ways. Forcing everything to be made by hand might discourage participation, limit creativity.
AI can unlock new creative possibilities. Instead of banning it, we could encourage people to be open about how they use it and focus on how it adds value. This goes for marketplace assets too which are tweaked.
Requiring tons of documentation/proof for asset could make things harder for builders/marketers, especially small teams.
Pushing for total originality is great in theory, but it might slow growth.
All in all, I agree on establishing more requirements and asking teams to be transparent in what assets were purchased/tweaked and what was created in house - then justify it by asking teams what value was added (saved time/money, allow for xyz to be completed faster, etc.) I’d say that in the end, this allows users to determine for themselves how they feel about it. Some may care, some may not and since the product is being developed for them to use, its them that should express this. Mandating “no use of xyz assets from xyz marketplaces, AI tools, etc” will make the program less attractive, especially in this period of AI discovery and excitement.
On this I agree with WakeUp, it seems that 17 million is not enough to give a hand to the project and support its development in the initial stages. Increasing to 25 million could already make the idea of dApp staking more valid.
On the use of AI I think they are very useful tools to increase productivity used appropriately and I would not like to limit teams in using AI platforms. For example, I do not care if the enemy faced in the game is hand-made from scratch or is a pre-recorded asset. The focus must be the gameplay of the game and the benefits it brings to AstarNetwork. However, I would ask to specify its use instead of hiding it.
Another focus of the UCG could be the evaluation of projects missing from the Astar ecosystem and the characteristics they bring. For example, if any Soneium dApp (SuperVol for example) uses the astr token in their products is it enough to consider it suitable for dApp staking? In my opinion yes, but I would also like to hear the opinions of others to define the criteria needed to define “benefiting” Astar Network
Thank you for sharing your perspective. I understand the challenges and costs associated with content creation. I agree that AI and marketplace assets can be valuable tools for smaller teams with limited resources, and I fully appreciate the time and effort it takes to create original works, especially when working with 3D art and models.
However, from a long-term development perspective, relying heavily on AI and pre-made marketplace assets can present significant risks, especially in a creative and competitive space like gaming. Here’s why:
Quality Control and Uniqueness: While AI and marketplace assets can indeed save time, they often lack the customization and uniqueness needed for a truly standout product. Pre-made assets, for example, can lead to a sense of sameness across multiple projects, which ultimately dilutes the value of the project in the eyes of the community. The more a project depends on external assets, the less it reflects the team’s creative identity, which is crucial for building a lasting reputation in the gaming industry.
Sustainability and Ownership: Over-reliance on AI tools or marketplace assets can create issues with long-term sustainability and ownership. If a project is built on assets that are easily accessible to anyone, the sense of ownership, which is important for both the creators and the users, becomes diluted. This can lead to difficulties in differentiating the project from others that use the same assets or tools. In the case of AI, the tools are evolving rapidly, but there remains a risk that they may not always produce the best or most tailored results for a given project.
Innovation and Craftsmanship: The best games come from a combination of great ideas, talented teams, and a deep level of craftsmanship. While AI can certainly help speed up certain tasks, it should never replace the core creativity and artistry that make a game unique. Relying too much on AI or marketplace assets can stifle innovation and the growth of new talent within the ecosystem. By encouraging the creation of original works, we allow developers to hone their craft and push the boundaries of what is possible in gaming.
Market Perception: As the gaming industry evolves, players increasingly value originality and innovation. Projects that rely heavily on pre-made or AI-generated content may struggle to stand out in a crowded market. Transparency is key, as you suggested, but we must also be careful about the message we send regarding the value of originality. If we prioritize accessibility and speed at the cost of uniqueness, we may inadvertently devalue the creative spirit that drives the industry forward.
That being said, I do understand your point about not stifling creativity and ensuring that smaller teams have the tools they need to get started. I believe a balanced approach is necessary. Rather than an outright ban on AI or marketplace assets, we could encourage transparency about their use, while also setting standards for how they can be integrated into the project. By asking teams to justify the value added through these tools and focusing on how they contribute to the overall vision, we can ensure that projects remain creative and authentic while still allowing for flexibility in the development process.
Ultimately, the goal should be to foster an ecosystem where creativity and innovation are celebrated, while also supporting teams in their development process. I think a framework that encourages transparency and originality, while allowing for the responsible use of AI and marketplace assets, strikes the right balance.
Thank you for your input. However, I must disagree with the idea of including Soneium projects, as they already have substantial funding and are benefiting from farming Astar tokens through Astar Surge. It seems unfair to provide additional UCG support to projects that are already receiving significant liquidity and funding, especially when these projects are well-established and have ample resources to continue their development.
To maintain fairness within the ecosystem, we either need to put an end to the Astar Surge and place all projects on an equal footing, or leave these projects where they are. It’s crucial that we ensure all projects are treated equitably… and not give special treatment to those who have already secured large amounts of funding.
Additionally, I believe it’s important to closely evaluate what the projects building on Soneium have delivered with the 100k+ grants they received, as part of their recognition as winners. Alongside this, we should consider the rewards they are farming with the Astar Surge. Before considering them for any UCG support, we need to see tangible results and what these projects have accomplished with the current resources.
There is room for debate on the specific number, but I agree with having a buffer to ensure that we are in Tier 3. If the buffer is made too large, the number of UCGs eligible will be reduced, so I feel that 20M at most would be sufficient given the current threshold. This number could be raised or lowered as needed.
While the UCG provides a powerful boost to empower teams and build the Astar ecosystem, there is so much more it can achieve with refinement to its framework. Standardization of practices and accountability measures will add meaning and transparency to their milestones. This could then be further enhanced by integrating bottom-up community metrics for better project evaluation that leads to more informed staking. Let’s discuss how we can make this UCG even better to serve as a mechanism for the support of innovation and collaboration on Astar. Your feedback and suggestions are really important in shaping the future of this program—let’s make it unstoppable!
@you425, Thank you for sharing your perspective. Limiting the grants to three spots with a total allocation of 170,000,000 ASTR (56,666,666 ASTR per project) creates a more focused approach, ensuring each project has sufficient funding to realize its vision, whether in DeFi, AI, or gaming. The current 17M is insufficient to support ambitious projects, and increasing the cap to align with larger goals could provide the necessary resources for delivering impactful results.
Thanks for providing these details regarding Astar Surge. Still, I must disagree with adding them to the UCG, as they have support in different areas such as increased liquidity, community engagement, visibility, and market positioning. On top of that, they have already received a $100k grant, which should allow them to develop up to 14 dApps within the Soneium ecosystem. So, I’m really confused as to why you would consider providing them with more funding.
@0xRamz, I’d really appreciate your feedback on this:
UCG-IP-01:
• Maximum of 3 projects
• 34,000,000 per project
• Any project that reaches Tier 1 will no longer require UCG (currently Tier 2, which doesn’t align with the dApp Staking v3 due to the reset cycle)
• Projects must provide a comprehensive pitch deck
• Projects should have at least one dApp released on Soneium or Astar
• Projects should establish a recognized presence within the Astar and Soneium ecosystems.
I have a few comments and questions about your UCG-IP-01:
• 34,000,000 per project
The community treasury only holds 105 million ASTR tokens. Therefore, if the grant is 34M, only 3 projects can be supported at the same time (105M/34M=3). However, if you still want to support a maximum of 5 projects, the grant will be 20 million per project.
Can you elaborate? I don’t understand why this doesn’t align with dApp Staking v3.
Your post above indicates that you don’t think Soneium projects should be allowed to join the UCG program, but in these sentences you mention Soneium twice. Do you mean that new projects launched on Astar L1 and applying for UCG must have a track record on Soneium, or have you changed your mind to allow Soneium projects to apply for UCG?
Finally, in your proposal, will the UCG period remain the same (4 months, renewable twice, i.e. a maximum of 8 months) ?
I was actually intending to write 3, not 5 (typo). This would make the competition more intense, encouraging projects to be more serious and prepared when applying for the UCG. It would also help ensure that only the most well-prepared and impactful projects are selected for funding, rather than projects that are not fully developed or coming in without clear proposals.
Imagine a project making good progress and working hard it wouldn’t be fair to remove them from the UCG after reaching tier 2. Relying on luck for the reset could harm their momentum. If they secure VC funding, I’d understand pulling them out. However, the V3 reset system was meant to remove projects that don’t deliver, yet it’s failed, as these projects continue to gain support despite contributing nothing meaningful to the ecosystem over the past three years. This doesn’t align with the long-term growth and stability we aim for in dApp Staking v3
I think there’s a misunderstanding here. Projects on Soneium that haven’t received financial support like those building on Astar without funding should be allowed to apply. New projects joining the Soneium ecosystem should also be eligible. However, projects that have already received 100k grants should not be part of the UCG until they deliver. And believe me, they have the resources to achieve great things. I’m keeping a close eye on them, so they better deliver.
What I mean is that 4 months is simply not enough for a project to deliver a high-quality product, unless you’re resorting to Fiverr and just copying some code and calling it innovation. A 12-month period would be much more reasonable and should be a yes, in my opinion, to ensure projects can truly deliver something meaningful
Certainly, I think it is conceivable that by participating in Astar Surge, we are receiving some marketing support. However, I think the rules should be more flexible and not necessarily limited to Astar Surge.
For example, the following could be considered.
Are projects that are mentioned in X, for example, not covered by the UCG? (There are several projects that are mentioned even if they are not in the UCG)
Are projects funded by VC or other sources not eligible for the UCG? (You mention Soneium Spark’s $100,000 support, but there are different means of funding. Also, just because someone is a Soneium Spark recipient does not necessarily mean they received $100,000)
So instead of deciding “because it’s an Astar Surge participating project”, I think it’s better to judge them individually with a more flexible criteria. Note that I am not recommending that they be eligible for UCG.
I think it is sufficient to just “consider their participation in Astar Surge” when discussing it, rather than “they are not eligible because they participated in Astar Surge.” I am saying there is no need to narrow the options.
So, are you suggesting that Soneium Spark’s $100,000 support was just a marketing tactic or a trap to give false hope to developers? If these projects have already secured substantial funding and additional support like increased liquidity, visibility, and market positioning, why would they need more funding through UCG? Is the intention here to continue providing more resources to projects that are already well-funded, instead of supporting those who genuinely need it?
It feels like a contradiction to continue feeding the same projects with more financial backing when they already have substantial resources at their disposal. At some point, developers need to be held accountable for leveraging the support they’ve already received and deliver tangible results, rather than relying on an endless stream of additional funding. It raises a fundamental question: Are we truly helping developers grow, or are we just perpetuating a cycle of dependency with false promises?
I believe that reducing the number of dApps and increasing the amount of ASTR would be ideal. Considering that the treasury holds 100k ASTR, we could allocate it as follows:
25K ASTR to UCG dApp 1
25K ASTR to UCG dApp 2
25K ASTR to UCG dApp 3
25K ASTR to UCG dapp 4
Alternatively, I think it would be interesting for the treasury to keep 1/4 of its value generating revenue for itself and soon one more 25K slot can be opened as the treasury increases—meaning keeping it staked on the treasury. So, I suggest something like this:
25K ASTR to UCG dApp 1
25K ASTR to UCG dApp 2
25K ASTR to UCG dApp 3
25K staking on the community treasury
The positive aspect of this model is that it increases rewards for the dApps and allows them to become independent of UCG as quickly as possible.
The downside is that there would be a reduction to 3 or 4 dApps accepted per round. If all dApps are renewed (lasting a total of 8 months), there would be only 1 rotation within a year (12 months).
Thus, the scenarios would be as follows:
3 or 4 dApps per round (4 months - no UCG renewal) × 3 rounds per year = 12 or 9 dApps in the UCG program per year.
3 or 4 dApps per round (8 months - UCG renewal) × 3 rounds per year = 6 or 8 dApps in the UCG program per year.
Context