I want to share why I believe we need to reform how bounties operate in the Polkadot ecosystem, particularly for local and mission-focused programs.
The Disconnect
Some time ago I led a community program in Vancouver and proposed renting a proper workspace in an area where Ethereum and other ventures were developing… a place with AV, meeting rooms, and a professional environment that would attract serious founders and partners. My local network includes influential people across deep tech, crypto, VC and startups, and I believed a quality space would let us build a mature, productive community quickly.
The reviewers pushed back, advising to “start small” with pizza and beer meetups, even though we could have filled a room with relevant people from day one. I tried the “start small” approach anyway, hosting casual meetups in an underground venue. The whole thing was cringe… the venue, the membership, everything. The turnout was mostly opportunistic attendees looking for quick gains… pump-and-dump projects, meme tokens, speculative plays… not the serious founders we needed. The program eventually ran in Toronto instead. I went off the grid for nearly two months, and when I returned I reimbursed the full amount to the treasury to protect my reputation. Vancouver remains underrepresented in Polkadot today.
That experience exposed a core problem: the narrow mandate and one-size-fits-all mindset didn’t match regional needs. This isn’t an isolated misstep but a symptom of how bounty-funded local programs are designed and governed.
Aligning with Polkadot’s Vision
Dr. Gavin Wood’s vision for Polkadot centers on user sovereignty, decentralization, and building systems that enable innovation at scale. He coined the term “Web3” to describe a fully decentralized internet where users control their own identity, data, and digital assets. Polkadot’s architecture… with its heterogeneous multi-chain framework, interoperability, and shared security… is designed to give builders the tools they need while maintaining sovereignty and flexibility. The upcoming JAM protocol takes this further, creating a permissionless environment where anyone can build services directly on the protocol.
Yet our bounty system doesn’t reflect this vision. We have decentralization as ideology but not as a practical tool for better outcomes. When curators lack regional context or impose generic solutions, when processes are opaque and accountability is unclear, we’re not enabling innovation… we’re hindering it.
The Current State: What the Data Shows
My experience in Vancouver isn’t unique. Looking across the ecosystem, only 55% of the 20 active bounties are fully compliant with basic reporting standards. The ecosystem has allocated approximately 4.4M DOT to these bounties originally, with 3.2M remaining, meaning we’ve spent about 28% so far. But here’s what’s concerning about how that capital is being managed:
65% of bounties lack monthly reports. Two-thirds of our funded programs aren’t providing regular updates on what they’re actually doing with treasury funds. 60% have no live tracking systems, making it nearly impossible for the community to see progress in real time. 35% are missing quarterly budget reports, so we don’t even have a clear picture of how funds are being deployed across reporting periods.
There are also discrepancies in the data itself. Some bounties show remaining DOT higher than the original allocation… like the Anti-Scam bounty showing 65k remaining versus 7.5k originally allocated… suggesting either additional funding occurred without clear documentation or there are gaps in how we’re tracking these programs.
Here’s another issue we’ve been too soft about discussing: bounties don’t have rigid boundaries by nature, and they shouldn’t. Most real work is organic and crosses domains. Someone building a community program might legitimately need marketing support, technical infrastructure, and educational content… each potentially falling under different bounties. The current system doesn’t accommodate this reality well. Applicants end up navigating multiple bounty processes with different curators who may have conflicting expectations, or they artificially constrain their proposals to fit a single bounty’s mandate even when the work would be more effective with a broader scope.
The bounties themselves should be flexible enough to recognize when cross-functional work makes sense, and we need coordination mechanisms between curators when applications span multiple domains. Right now we have neither the flexibility nor the coordination, which means good programs either get fragmented or don’t get funded at all.
This isn’t just about compliance or better reporting. When programs don’t report regularly, when tracking is opaque, when budget data doesn’t reconcile, and when legitimate cross-bounty work has no clear pathway, it erodes trust and makes it impossible to learn what’s working and what isn’t. We can’t iterate or improve if we don’t have clear visibility into outcomes or if we’re forcing work into artificial categories.
Mission-Driven Bounty Framework
For bounties to work effectively, we need an overarching mission that each bounty expresses through its specific domain. Here’s a proposed structure:
Polkadot’s Overarching Mission: Enable a decentralized, user-sovereign web through scalable, interoperable infrastructure and thriving global adoption, where individuals control their digital identity, data, and assets without dependence on centralized intermediaries.
How Different Bounties Express This Mission:
Marketing & Communications Bounty
Mission Expression: Build understanding of Web3 principles and Polkadot’s role in achieving user sovereignty. Attract builders, users, and partners who align with decentralization values rather than purely speculative interest.
Success Criteria: Are we reaching audiences who care about sovereignty, privacy, and decentralization… not just price action? Does our messaging explain why Polkadot’s architecture matters for the future of the internet? Are we converting awareness into meaningful participation (developers building, users adopting, enterprises integrating)?
Evaluation Questions for Applicants: How does this campaign or content help people understand what we’re building and why it matters? What audience are you targeting and why are they strategically important to the mission? How do you distinguish between engagement that advances the mission versus engagement that’s purely speculative?
Developer Experience & Tooling Bounty
Mission Expression: Remove barriers to permissionless innovation. Make it practical for developers to build applications that embody user sovereignty, interoperability, and decentralization without needing permission or extensive resources.
Success Criteria: Are we reducing the time and complexity required to deploy on Polkadot? Are developers able to build genuinely decentralized applications, not just technically decentralized but ideologically compromised solutions? Does our tooling enable the kind of cross-chain, composable applications that Polkadot was designed for?
Evaluation Questions for Applicants: What specific barrier to building on Polkadot does this tool or improvement remove? How does this enable developers to create applications that advance user sovereignty? Does this tool or framework make it easier to leverage Polkadot’s unique features (interoperability, shared security, upgradeability)?
Community Building & Regional Growth Bounty
Mission Expression: Cultivate local networks of builders, users, and advocates who understand and advance Web3 principles. Create environments where serious founders can connect, collaborate, and build projects that embody the mission.
Success Criteria: Are we building communities of substance… people who are building, contributing, and advocating for the right reasons? Does the community infrastructure (spaces, events, programs) attract and retain serious founders rather than opportunistic participants? Are regional communities able to adapt programs to local market conditions while maintaining alignment with core mission?
Evaluation Questions for Applicants: What type of community are you building and why does that community matter to Polkadot’s mission? How does your approach ensure you attract builders and advocates rather than purely speculative participants? What makes your regional context unique, and how does your proposal address those specific dynamics? How will you measure whether you’re building a community of substance versus just activity metrics?
Security & Trust Bounty (Anti-Scam, Audits, Safety)
Mission Expression: Protect users and maintain ecosystem integrity so that decentralization can function as intended. User sovereignty requires safety and trust; people can’t exercise control over their digital assets if they’re constantly being exploited.
Success Criteria: Are users able to participate in the ecosystem with confidence? Are we catching and preventing exploits, scams, and vulnerabilities before they cause significant harm? Does our security work enable rather than constrain innovation?
Evaluation Questions for Applicants: What specific threat or vulnerability does this work address, and why does it matter to users exercising sovereignty? How does this security measure maintain trust without creating centralized control or gatekeeping? What’s your response time and what harm are you preventing?
Education & Documentation Bounty
Mission Expression: Make Web3 principles and Polkadot’s capabilities accessible to diverse audiences. Enable people to understand why decentralization matters, how Polkadot enables it, and how they can participate… whether as users, developers, or advocates.
Success Criteria: Are people able to go from curiosity to competence using our educational resources? Does our content explain both the “how” and the “why”… the technical capabilities and the philosophical principles? Are we reaching beyond the already-converted to people who should care about digital sovereignty but don’t yet understand why?
Evaluation Questions for Applicants: Who is your audience and what do they need to understand to participate meaningfully in the ecosystem? How does your content connect technical capabilities to the mission of user sovereignty and decentralization? What does success look like… how do you know if people actually understand and can act on what you’re teaching?
Research & Protocol Development Bounty
Mission Expression: Advance the technical foundations that enable scalable, secure, sovereign digital infrastructure. Solve the hard problems that prevent Web3 from achieving its potential.
Success Criteria: Are we pushing the boundaries of what’s possible with decentralized systems? Does this research address real bottlenecks or limitations that prevent the mission from scaling? Can this research be practically implemented and does it maintain or improve decentralization guarantees?
Evaluation Questions for Applicants: What fundamental problem does this research address and why is it blocking mission advancement? How does this work maintain or improve the decentralization, security, and sovereignty guarantees of the protocol? What’s the path from research to practical implementation?
Cross-Bounty Mission Alignment
When work spans multiple bounties, curators should evaluate mission alignment holistically: Does the combined approach advance the mission more effectively than siloed work? Are there synergies that justify cross-bounty coordination? Does each aspect of the work maintain its mission focus even while integrated with other domains?
A community building program that needs marketing support and developer tooling should be evaluated on whether each component… the community space, the marketing materials, the technical infrastructure… genuinely advances the mission of building serious founder networks that create sovereign applications.
Integrating Mission into Evaluation
In the reformed bounty system, every application would need to articulate: How their specific work expresses the bounty’s mission. What success looks like in mission terms (not just activity metrics). How they’ll measure whether they’re advancing the mission versus just executing tasks.
Curators would evaluate: Does the applicant understand the mission and how their work connects to it? Is the proposed approach likely to advance the mission given the regional/domain context? Are the success metrics tied to mission outcomes rather than just outputs?
This framework doesn’t eliminate curator judgment… it focuses that judgment on what matters. A curator might still disagree about whether a professional workspace or casual meetups better serves Vancouver’s community building mission, but now the debate happens in mission terms rather than just process adherence.
A Practical Solution
Decentralization is powerful, but the idea that everything should operate in a purely decentralized way without structure will never stick. What we need are systems that enable better decisions while remaining transparent and accountable. I propose we create an onchain bounty management application that addresses these issues directly.
The system would work like this: Curator votes and evaluations happen onchain but independently, similar to blind peer review. Curators would not see each other’s comments or scores when evaluating applicants, preventing groupthink and political influence. All decisions become verifiable and auditable, not just informally “open.” This protects both the integrity of the evaluation process and the applicants themselves.
Curators would serve defined terms with rotation built in, preventing capture and bringing fresh perspectives regularly. To qualify as a curator, individuals would need to demonstrate managerial and practical experience in the relevant bounty field… not just crypto credentials, but actual domain expertise. A curator evaluating community programs should understand regional dynamics, growth strategies, and what sustainable community building actually looks like.
The application would also need to handle cross-bounty coordination intelligently. When an applicant’s work spans multiple domains, the system should facilitate collaboration between relevant curators rather than forcing the applicant to navigate siloed processes. Curators could flag when a proposal touches their domain even if it’s primarily under another bounty, ensuring holistic evaluation without duplication. The onchain tracking would show clearly which bounty funds are supporting which aspects of the work, maintaining transparency while allowing the organic, multi-faceted nature of real programs to flourish.
Here’s the critical piece: we implement KYC on registered onchain identities. Right now we can link someone to an onchain identity, but that’s just pseudonymous tracking. If we’re deploying real capital for real work, we need to ensure the person receiving funds is who they claim to be and can be held accountable for delivery. This doesn’t contradict decentralization… it enables it to work properly. You can’t have a functioning grant system without recourse when someone takes the money and disappears.
The KYC could be tiered based on funding amounts and handled through privacy-preserving identity solutions. Curators would see verified credentials without necessarily accessing raw personal data on a public ledger. The point is accountability before funds are released and clear processes for what happens if someone doesn’t deliver.
The application would also enforce the reporting standards we’re currently missing. Monthly reports wouldn’t be optional… they’d be built into the funding flow. Live tracking would be native to the platform. Budget reconciliation would happen automatically onchain. The data discrepancies we’re seeing now would become impossible because the system itself would maintain a single source of truth.
Making It Real
This entire system could be built as an application that operates in a completely decentralized way while protecting both parties in the economic transaction. The onchain nature means everything is transparent and auditable. The blind evaluation prevents bias. The term limits prevent capture. The KYC provides accountability. The required expertise ensures qualified decision-making. The enforced reporting creates the transparency we’re currently lacking. And the cross-bounty coordination enables the organic, multi-faceted work that actually drives ecosystem growth.
We’ve already created a proof of concept for the proposal/bounty manager/voter UX flow that improves on today’s systems. We’ll be testing its usability at Sub0 to get developers involved and gather feedback on how this can work in practice. This isn’t just theoretical… we’re building it.
What we’re really building is a professionalized bounty management system that remains transparent and accountable. This seems aligned with Gavin’s vision… building systems that enable the right outcomes at scale, not just ideological purity.
If we want reliable, region-tailored outcomes from bounty programs, we must move from ad-hoc mechanics to mission-driven frameworks with clear funding categories, competitive evaluation, and accountable roles. Only then can local programs actually deliver the impact they promise.
If you want to play with the adults, contact me.