Every blockchain ecosystem says it wants more builders. But spend enough time talking to the people who actually run these programs and a different story emerges.

Attracting developers has never been easier, especially now that AI tools let anyone start building. The hard part is keeping the right ones engaged long enough to ship something meaningful.

We spoke with ecosystem leads, DevRel, and Growth teams across Base, Celo, BNB Chain, Fuel, AAVE, Avail, Privy, Starknet, and others, drawing on years of hands-on experience running builder programs at Talent. Everywhere we looked, the same tension kept coming up: reach versus quality.

Networks need to reach many builders to discover great talent, but they also need to focus on the best contributors to create lasting impact. To give a sense of that scale: Base alone tracks over 40,000 builders, but only about 500 are rewarded in a given month. That ratio says a lot.

This article distills what we learned into a practical guide for anyone designing programs that need to find, support, and retain technical talent. It explores what actually works, what keeps failing, and how to build programs that retain builders instead of churning through them.

This was the single most repeated insight across every conversation: grants, bounties, and incentive programs can attract builders, but they just as easily attract people optimized for short-term rewards rather than long-term commitment.

The result is high variance. Some funded builders ship great products. Others collect the check and disappear. Programs then invest more in vetting, onboarding, and support, while still struggling to retain participants once the money runs out.

As one DevRel lead at Hyperlane put it: "The biggest issue is attracting quick-money builders who show up for the payout and leave before anything ships."

Spending more gets you reach, not quality. It brings more builders through the door, but without something else in place to separate signal from noise (behavioral gates, progress checks, output-based distribution), more money often just means more churn.

The rest of this article builds on that idea. Incentives work, but only when there's structure around them.

Ask ten different program leads what a "quality builder" looks like and you'll get ten different answers. But dig deeper and patterns emerge.

Some use hard gates. One chain requires projects to be live on mainnet before they can access serious BD support. Others treat quality as something that reveals itself over time, through repeated interaction and follow-through.

The clearest shared insight was that quality reveals itself over time through what builders actually do once they’re in. Motivation, consistency, and skin in the game (things like regular updates, visible progress, and demonstrated commitment) matter far more than hackathon attendance or grant applications.

This creates the central tension we kept hearing:

Ecosystems need reach to discover quality, but they need quality to create compounding outcomes.

Programs that optimize only for reach create noise.

Programs that optimize only for quality can't scale.

The winners build systems that turn broad reach into reliable signal.

Six themes kept surfacing across interviews:

• Retention is the universal bottleneck, not acquisition.

• Quality shows up in behavior, not credentials.

• Incentives only work when tied to real output.

• Activation friction kills builders before any reward can kick in.

• GTM is the cliff most builders hit right after shipping.

• What gets measured shapes everything that follows.

These patterns map onto a natural progression every builder goes through when entering an ecosystem. None of the people we spoke with use a formal framework, but their tactics consistently follow five stages:

Acquire is how builders first find the ecosystem. Events, partnerships, content, inbound interest. Breaks when channels produce audience instead of builders.

Activate is how builders reach their first real win. Good docs, templates, credits, fast paths to shipping. Breaks when friction creates drop-off before anything gets built.

Retain is how builders keep building after that first touch. Ongoing support, progressive programs, local communities, longer build arcs. Cited again and again as the hardest step.

Reward is how incentives are structured. Grants, bounties, quests, retroactive rewards. Breaks when reward design isn't tied to output.

Amplify is how programs turn output into more output. Showcasing winners, distribution, co-marketing, case studies. Breaks when winners don't get visibility and nothing compounds.

The framework is simple. Executing it is not.

Across our interviews, we kept hearing about the same mistakes at every stage, often from people who understood the funnel perfectly but still fell into predictable traps.

You get submissions and hype, but very few teams keep building once the event ends. The ecosystem confuses activity with retention. As a default strategy, hackathons are expensive, low-signal, and weak on compounding.

What works instead: Tie hackathons to a product moment, like launching an SDK, with strong support materials. Avail's ETHOnline push generated over 100 submissions because it gave builders something new and concrete to build with. Not a generic prompt, but a specific product to integrate.

For sustained output, replace weekend sprints with longer build arcs, like Crecimiento’s startup program.

When grants become the funnel instead of the outcome, you attract builders optimizing for "getting the grant" rather than shipping long-term. Aave's grants DAO shows both sides: grants can fund key infrastructure, but the spending can also exceed the value created.

What works instead: Use progressive filtering as a pre-grant layer. PUSH intentionally starts without grants, requiring weekly updates to progress. As the co-founder described it: "If you hand out money first, you attract people who want money first. If you ask for consistency first, the ones who stay are the ones who actually want to build." Behavior becomes the gate, not applications.

For ongoing incentives, shift to impact-based builder rewards that track activity across onchain and GitHub and distribute proportionally to contribution. Base, Celo, and Stacks run variations of this model, rewarding builders who already proved sustained output rather than paying upfront for promises.

Poorly targeted events pull audiences who are there for social value, not building. Conversion from these events is close to zero.

What works instead: Replace untargeted events with ambassador and local community loops. Stellar Development Foundation built a global ambassador network that expanded across multiple regions, creating consistent local presence and quality filtering at the regional level. The key difference is continuity: ambassadors maintain presence, while one-off events disappear.

Even great ideas fail when the integration path is too complex. Privy's experience with gas sponsorship is a clean example: it sounded helpful but added friction instead of removing it. This is especially common for tooling companies where onboarding is already the hardest bottleneck.

What works instead: Focus on low-friction quests for activation. Base calls these out as a specific success because they're informal and don't feel heavy or bureaucratic. The goal is a fast first win with minimal overhead. If builders can't reach that first win easily, no incentive structure on top will fix it.

Some teams track useful numbers like production usage and requests per week. Others reported tracking nothing at all, which makes it impossible to justify spend or iterate with rigor.

What works instead: Measure production as the real KPI. Privy tracks developers moving from dev mode to production mode, giving them a clean signal of real adoption versus experimentation. Infrastructure companies should track developers reaching production. Protocols should track usage. Ecosystem foundations should track active builders, shipped apps, and retention over time.

Some programs turn into a help desk. DevRel ends up answering questions all day. Builders still make progress, but only when the team steps in. As a growth lead at Fuel Network warned: "The problem is when you're still doing all of the work for every builder. That doesn't scale." Quick help is useful, but it doesn’t create momentum.

What works instead: Keep the door open, but add a few simple rules. Ask builders to post one short update every week. Give them a template for updates and demos. Run a weekly check-in so people don’t disappear. And pay rewards for what ships, not for who asks the most questions.

When an ecosystem grows its builder base but doesn't have a way to tell who's actually contributing, everyone gets the same slice of attention and rewards. Top builders feel invisible, low-effort participants stick around for easy payouts, and program leads can't point to real wins.

What works instead: Add a data-driven quality layer. Track what builders actually do (code shipped, contracts deployed, open-source contributions) and reward proportionally. This works like a retroactive filter: builders earn rewards because they already proved they're building, not because they applied.

Some ecosystems already publish this kind of tracking in regular reports. For example, WalletConnect shares ecosystem reports that track builders and real outputs across GitHub repos (integrations, activity, and what shipped).

The takeaway isn’t “stop doing builder programs.” It’s that builder programs only compound when you add structure: clear signals, clear incentives, and clear paths to shipping.

AI tools have made it possible for anyone with an idea to ship a working app in days, not months. The barrier to building has never been lower. People who would never have called themselves developers two years ago are now shipping real products. The builder pool is growing, and its composition is changing fast.

This changes everything about how programs should be designed. The traditional developer audience was narrow, technical, and relatively easy to identify. The new builder population is broader, faster, and harder to filter using old signals like GitHub history or hackathon resumes.

AI is also dissolving one of the oldest friction points in the space: documentation. Docs that were once dense, outdated, or hard to navigate can now be written, maintained, and understood more easily than ever.

Activation friction, which kills so many builder journeys before they start, is becoming a solvable problem rather than a structural one.

But the core challenge this article describes doesn't go away. It gets harder. More builders entering the funnel means more noise unless you have the systems to surface signal.

If you take one thing from this article, make it these three:

1. Pick one production KPI and start tracking it this week.

2. Audit your current incentives: are they rewarding output or attendance?

3. Publish your builder data. Transparency compounds.

The networks that recognize this shift and design their programs for a broader, AI-native builder population will have a significant advantage. They'll get there by being more deliberate: smaller programs, sharper filters, rewards that compound. Not by spending more.

The ones that figure this out won't just survive the current cycle. They'll be the ones that define the next one.

Talent runs builder reward programs and reports for ecosystems. This article is based on independent interviews and internal data. No ecosystem reviewed or approved the content.

We're continuing this research and talking to more ecosystem teams. If you run a builder program and want to compare notes, reach out