Web3 Foundation announced its active participation in OpenGov in October and has also issued new grant guidelines. The current mandate for the technical grants evaluation team at the Web3 Foundation is to leverage their years of experience evaluating grant applications across all categories of the ecosystem work in the realm of OpenGov and provide public feedback, enabling our community to make informed decisions on Treasury allocation.
We recognize that OpenGov supports a wide range of proposals, and the role of the foundation is to help identify credible, value-aligned proposals and to make our criteria and posture as clear as possible for proposers.
What are we looking for?
Whether technical or non-technical, proposals submitted to OpenGov will need to demonstrate:
Cost-effectiveness: W3F invites all entities planning to submit a funding request to OpenGov to engage early during the discussion phase on the governance platforms and ratify the costs for the deliverables. This applies equally to technical infrastructure work, community initiatives, research efforts, market development programs and others. Budget discipline is the clearest signal that a proposer has thought through what they’re committing to. We expect itemized costs, vendor quotes where applicable and transparent benchmarking against comparable work. Early engagement with our team allows proposers to validate that their spending reflects both frugality and quality. More importantly, it demonstrates respect for community capital. It signals that proposers understand this is not casual expenditure, it is stewardship of a shared, finite resource.
Expertise: Credibility matters. W3F will review the capabilities of the proposer and use the experience and insights from its open and strategic grant evaluations framework to attest to the credibility of the proposing entity in executing the deliverables. For technical work, this means assessing architecture and integration pathways. For community initiatives, this means evaluating track record in community engagement and event management. For research, this means examining methodology and relevant prior publication. For market development, this means assessing relevant market experience and realistic market understanding. In all cases, we require verified proposer identity and credible evidence that the team can execute as promised.
Accountability: We would like to ensure accountability on-chain through a periodic review process of accepted proposals. OpenGov offers automatic milestone-based payouts for proposals. In case the deliverables are not consistently met, it is possible for the community to stop future payouts through an OpenGov vote. This framework applies across all proposal types, and KPIs can all be structured with clear on-chain verification and logic. We strongly encourage proposers to lock their scope and budget in immutable form via IPFS, Git, or on-chain hashes so that the community can verify what was promised and measure whether it was delivered.
Beyond these three core dimensions, we evaluate proposals against a fundamental question: does this create genuine ecosystem value, and is Treasury funding the appropriate mechanism?
We prioritize proposals with ecosystem-level impact over those that primarily benefit a single team or narrow constituency. We ask: would the ecosystem be substantially worse off if this work were not funded?
By demanding that, we signal that OpenGov is a place where quality is expected, where resources are respected, where coherence matters. We aim to attract only builders who care about those principles, in order to cultivate an ecosystem that is intentional and worthy of the technology we have created.
Minimum Standards for All Proposals:
To be considered for an Aye from the W3F, proposals must meet the following standards:
On-chain verified proposer identity
Immutable scope and budget. Final scope and budget locked via IPFS, Git tags, or on-chain hashes, with these hashes referenced in the referendum text.
Concrete, measurable deliverables. Specific outputs with success criteria. “Increase developer engagement” is vague; “onboard 50 new developers with completed tutorials by Q2 2026” is concrete.
Itemized, benchmarked budget, with every line item justified. Vendor quotes or market comparables provided for material spends. No lump sums that obscure cost assumptions.
Milestone-gated disbursement. Structured funding to be released in tranches tied to demonstrated completion of deliverables.
Public discussion lead-time. Generally, at least 14 days of community discussion before referendum submissions,
Responsiveness to community feedback. Proposals should incorporate reasonable refinements based on community input and the ability to receive input on an ongoing basis. Significant scope or budget changes post-discussion must trigger re-hashing and community re-engagement.
(Additionally, we highly encourage proposers to adopt open-source licenses for project code, plan for independent security audits when relevant, and describe how the project will be sustained after the treasury funding ends. While these steps are not strict requirements, they strengthen a proposal’s credibility.)
Thinking through integration pathways or market strategy depending on proposal type
Understanding how to present your work for community deliberation
Engagement with W3F is not a prerequisite for proposal success, but following these guidelines is the minimum prerequisite for W3F to consider voting in favour.
Throughout this process, W3F strives to remain an impartial and transparent participant in OpenGov. We view ourselves as one stakeholder among many in the Polkadot ecosystem, and our aim is to support the community in making well-informed decisions. By sharing these guidelines and our reasoning openly, we hope to build greater confidence in how treasury funds are allocated and encourage proposers to meet a high standard.
