Hello PermanenceDAO,

Thank you for sharing your concerns above. I would like to take a moment to respond to them here, and I would also be glad to discuss everything with you during your open office hours next Wednesday. I hope you will be able to join the meeting.

Please allow me to address each of your points in turn:

• Regarding the “very steep price”, mentioned by Jose:

  • We believe this proposal is highly cost-effective in every respect, especially given our responsibility to represent and advance Polkadot’s interests in our region across multiple fronts. Our work spans a wide range of initiatives, from organizing events, hackathons and managing marketing efforts to representing Polkadot at key conferences, integrating PBA-X into academy and engaging in high-level governmental outreach.

    Furthermore, OpenGov has already approved the same rate of 40 USD/hour for management-related tasks in the cases of Polkadot Africa and OpenGuild (SEA region). There are individuals and DAOs who support this request and consider the proposed financial compensation to be fully reasonable.

• Regarding the impact of the proposal, as asked by Yongfeng:

  • Measuring community building and the time, effort, and energy required to keep a community active, integrate local developers into the ecosystem, and keep them informed is inherently difficult. Creating meaningful KPIs for this is even harder, as every community builder and event organizer knows. Building a community, integrating into the local crypto scene, and showcasing Polkadot technology there is the result of years of consistent, behind-the-scenes work. It is fundamentally different from development projects, which can be easily tracked through a GitHub repository.

  • That said, we do have concrete achievements to show from the past, results that we believe, and many others believe, are valuable and meaningful. Much of this work has been provided freely and voluntarily simply because we love doing it. Our goal is to continue this work with significantly more focus and capacity. We want to keep preparing the ground so that we can bring more and more people into the Polkadot ecosystem, because we truly believe Polkadot is built for people, and it needs knowledgeable people, us to present, explain, teach and market the technology.

    We will continue the projects we’ve already started, including organising hackathons and events, and we plan to expand with what might be our most valuable contribution: bringing Polkadot technology education into local universities through PBA-X curriculum integration. We genuinely believe that if we do not carry out this work, then it may simply not happen at all.
    Please take all of this into consideration, Yongfeng, and reconsider your decision.

Regarding the request for “other results first” and the suggestion to limit the proposal to three months instead of half a year, raised by Ezio:

• We kindly encourage you to take another look at our full proposal, where we have listed all of our results to date. You can find the achievements section here.
• For clarity: the first tranche of the batched payout covers three months, and the second tranche also covers three months. The second payout can be stopped by anyone, and there is now an excellent UI available for this purpose, the Treasury Guardian so there is no longer any need to rely on more complex tools such as Polkadot.JS to cancel payouts.
• If we think about this from a practical standpoint, it is neither reasonable nor efficient for any team to submit treasury proposals every three months, especially given the 28-day evaluation period on OpenGov. This would effectively require proposers to demonstrate successful project execution every two months while simultaneously spending almost an entire month of that cycle explaining and defending the same proposal to voters. This is an immense and unsustainable burden in terms of time and energy.
• It is also worth noting that the last proposal of Polkadot Africa was also covering six months. And OpenGuild’s last proposal covering an even longer, 12 months periods. We believe that a six-month period for community building, activation, and education, with payouts batched into two three-month tranches, is both reasonable and rational.
• For reference, the second payout is scheduled for March 19, which means that, to the best of our knowledge, a proposal to stop that payout would need to be submitted in February.
• Taking this into account, we respectfully believe it would not be reasonable for our proposal to lose your Aye due to such a minor technical detail. Therefore, we kindly ask you to reevaluate our proposal.

Regarding why we would like to request a batched payout covering six months (in two tranches of 3 months each), rather than only three months, asked by Kukabi:

• We believe that effective work is only possible if we can plan projects and their associated costs at least half a year in advance. Planning events, hackathons, community outreach, marketing strategies, development projects and academic integration with only a three-month horizon is far more unpredictable and difficult than working within a six-month timeframe.

• Additionally, we don’t fully understand what the concern is regarding batched requests. On our last call, you mentioned that OpenGov has never stopped subsequent payouts of a previously approved batched request. However, this doesn’t mean it couldn’t happen in the future. Until now, these payouts were likely not stopped because they were opaque (nobody could easily see when the next payout was scheduled) and because creating such extrinsics via Polkadot.JS was cumbersome. But this has changed. The Polkadot community now does have the tools for this. The Treasury Guardian makes it easy for anyone to halt batched transactions and upcoming payouts.

  Furthermore, the batched payout structure was strongly recommended by the W3F, which is why we proposed two tranches: one in December and one in March 2026.

  It’s very challenging for us to navigate and assemble a proposal that satisfies the wide range of often conflicting expectations from many respected community members. Taking all this into account, we kindly ask you, Kukabi, to reconsider whether it is necessary to vote Abstain instead of Aye over such technical details.