Thanks for the reminder and for the opportunity to contribute constructively to the discussion.
Since my previous message was removed, I’d like to respectfully reiterate the core points I was raising—this time with full attention to tone and alignment with the Community Guidelines. I believe these concerns are relevant for the community to hear and consider.
1. Context matters when public funds are requested.
SFY Labs has applied for a DApp Staking slot and even UCG support, despite having previously left Astar in favor of Moonbeam. During that transition, many in the community—including team members and ambassadors—felt mistreated, and there was a clear breakdown in communication and trust. A return to Astar, especially with immediate funding requests, naturally raises some questions.
2. Governance awareness appears lacking.
The team’s current participation shows little understanding of Astar’s governance processes, while simultaneously suggesting changes or expectations as if the system were theirs to define. Moreover, it appears they don’t currently hold the minimum amount of ASTR tokens to support referenda deposits—despite having received DApp Staking rewards for months in the past.
3. No product deployed, yet funding requested.
At the time of writing, there is no deployed smart contract or measurable contribution on Astar from this team. Nonetheless, we’ve already seen proposals for 1M ASTR tokens, DApp Staking inclusion, and UCG admission—within a matter of weeks. Without a working product or demonstrated traction, this feels premature and misaligned with the community’s expectations around merit-based support.
4. Avoiding on-chain voting is concerning.
Statements from SFY Labs suggest a desire to avoid on-chain governance mechanisms due to concerns over turnout or potential negative outcomes. In a decentralized ecosystem, bypassing community voting can be seen as undermining the very principles we are trying to build on. If trust is lacking, open voting is the best way to rebuild it—not something to be avoided.
5. Rebuilding trust is necessary before requesting resources.
If a project has previously distanced itself from the network and community, it’s reasonable to expect a period of rebuilding—starting with actions, not requests. Deploy your product. Show measurable engagement. Bring value first, then funding discussions can follow.
To conclude, this is not about attacking individuals but about preserving the integrity of Astar’s governance and treasury. The question the community should be asking is:
“Does Astar currently need this project, or is it the project that now needs Astar?”
Let’s support growth, innovation, and contributions…but in an intelligent way and making the most of the shared memory of what has come before: mistakes are useful for learning and growing!
Thanks again for the space to voice this respectfully.