[IMAGE: https://files.peakd.com/file/peakd-hive/deathwing/48JcAbxeyFT2mArUhj4XjLeCuWQgmgufigjXwZMUgvQ2mCeq69hTAxXjUs2fxGdvXs.png]
Hi everyone! Long time no see.
Today, I am here to tell you all about a plan, initially proposed by @blocktrades and has been in discussion for a bit now.
Hive Dev Fund: AI Agent Developer Tooling Pilot Program
TL;DR
A pilot program to fund LLM code assist/agent subscriptions for Hive developers, starting with Claude Code. The goal is to boost programming productivity across the ecosystem. $10,000 total over 2 months (~170 HBD/day) until it ends.
What is this?
This proposal creates a Hive Dev Fund a pilot program that provides LLM code assist/agent subscriptions to qualifying developers. The idea is simple: AI coding tools have reached a point where they can realistically multiply a developer's output by 10x (see 10x engineers, used to be a meme, but now quite the reality). At $100–200/month per developer, this is one of the most cost-effective investments the DHF can make in Hive's development/programming capacity.
As mentioned before, the idea was initially proposed by @blocktrades and evolved through discussions.
Why does this matter?
Quite a few devs on Hive (especially those in countries where $100–200/month is a significant expense) are either not using AI coding tools at all or are cobbling together free alternatives that don't deliver the same results. The difference between using the best available tools and using free alternatives is massive.
How does it work?
Application Process
Developers apply through a straightforward process:
- Apply - Submit an application demonstrating your involvement with programming as a whole (bonus points for Hive related dev) (existing projects, Git contributions, known track record, etc.) or a clear plan for what you intend to build.
- Review - Applications are vetted based on developer history, quality of prior work, and the viability of proposed Hive contributions.
- Approval & Disbursement - Approved developers will receive funding for their subscription.
During the pilot program, please write and share a post on Hive why you'd like to participate in the program and receive funding and what are some of your plans. It doesn't have to be a lengthy "explain yourself" post, but something basic, with your credentials. GitHub link, past projects etc.
Should the program continue, I will be creating a dedicated website for it with a much more appealing/data rich system.
If you are a brand new user without a Hive account and would like to apply to this program, please send me a message on Hive's Discord server and I'll help you create one.
Tiers
For the time being during the pilot program, we are focusing on Claude Code subscriptions, which have two tiers. $100 (5x Max) and $200 (20x Max) applicants will be granted either of these packages depending on their application.
Accountability
After each month, recipients are expected to show tangible progress whether that's reaching a close-to-MVP point on a new Hive project, meaningful updates and maintenance on an existing one, or concrete contributions to Hive core infrastructure. This isn't maintenance for the sake of calling it maintenance, we're looking for real, verifiable output that reaches the hands of the users.
Funding will continue as long as the developer is producing good work and the Hive Dev Fund is able to cover it. The goal isn't to kickstart someone and cut them off, it's to remove the financial barrier that prevents developers from using the best tools available.
Scope
We are currently looking for development in the following:
- dApps and frontends — New applications, features, and improvements
- Core infrastructure — Contributions to hived, HAF, Hivemind, and related systems
- Open source tooling — Libraries, plugins, and developer tools that benefit the ecosystem
Why Claude Code specifically?
There was some discussion about whether to be tool-agnostic (like OpenAI Codex). The decision to use Claude Code comes down to a few practical reasons:
- Core team alignment — The core Hive development team already uses Claude Code, and repositories are being optimized for it.
- Ease of Use — Claude Code is currently the "easiest" (debatable, ofc) tool to start using AI coding agents.
Of course, these are subject to review at later.
Budget
Item
Amount
Total Proposal
$10,000
Duration
2 months (~60 days)
Daily DHF Rate
~170 HBD/day
This is a pilot program, therefore, the budget is intentionally conservative to keep the barrier to approval low and demonstrate results before requesting additional funding. Therefore, any funds that are not used (and should the program be cancelled after approximately 3 months funding plus some extra time) will be returned to the DHF.
Why a pilot?
This is deliberately small in scope. A pilot program allows us to:
- Prove the concept
- Establish evaluation criteria
- Generate tangible results
If the pilot is successful, a follow-up proposal with expanded scope and budget can be submitted based on real data about developer output and program effectiveness. Honestly, in the future, I would love if Hive Dev Fund became something like a "small scale DHF" that can help fund developers' contribution to the Hive ecosystem, on a smaller scale, yet faster and hopefully more effective than the DHF itself as there are no vote thresholds.
Who is going to be the manager of this?
Many of you may know me from my work operating api.deathwing.me, one of the most used public API nodes on Hive, serving over 180k unique users monthly at one point. I've also developed Drone (a custom API middleware, now replaced Jussi) as well as FRIDAY (a notification bot for Discord, operating for 5 years at this point), and have been a consensus witness (top 20) and active contributor to the Hive ecosystem for years.
I'll be handling the application review process and fund disbursement. Administration costs are relatively minimal. (AI agents, LLM spendings, we're aiming to have minimal "human" administration cost as much as possible, especially during the pilot program)
Your Feedback Matters
This is a community-funded initiative and your input matters. If you have questions, suggestions, or concerns, please share them. The goal is to make Hive development faster, more accessible, and more productive for everyone involved.
Vote for the Proposal
No EVM or smart contract compatibility is probably the single biggest barrier to Hive being adopted and has been for years now.
Ethereum has Solidity. Solana has Rust-based programs. Both have massive ecosystems of tooling, tutorials, and developer infrastructure around their smart contract platforms.
Hive doesn't have general-purpose smart contracts at all.
Everything is built around custom operations and layer 2 solutions like Hive Engine, which is useful but nowhere close to the flexibility or composability that smart contracts offer. A developer who knows Solidity has zero transferable skills to Hive. That's a massive friction point.
That's not to say that we have to ditch the current custom JSON operation approach, but layer 2 solutions are a bandaid, not a true solution to the smart contract difference compared to other blockchains.
I also think our wallet and tooling UX is dated. Metamask, Phantom, Backpack. These wallets are polished, well-known, and integrate with thousands of apps. Hive Keychain works and stoodkev did solid work, but it doesn't have the same level of polish or recognition. The account creation process alone, with keys and resource credits and account names, is confusing for people coming from other chains where you just install a wallet and go.
And one of the bigger things is we have noo mindshare in the broader crypto developer community.
Solana and Ethereum have hackathons, grant programs with serious money behind them, accelerators, VC ecosystems feeding into them, and cultural presence on crypto Twitter. Hive has a loyal community, but outside of that community, most crypto developers have either never heard of it or think of it as "that old Steem fork for blogging." That perception problem is real and it compounds everything else.
We could easily fund these efforts. Heck, if I knew there was the opportunity to me to be able to work on these efforts and get funded for them, I would do it in a heartbeat. I build fun tools and dApps for Hive, but large and ambitious things we actually need require time and for many of us, we're working other jobs so that time needs to be funded. Right now where do devs go to even get funding for these things, a proposal that won't be seen?
I don't want to come across as negative here, because I love Hive. I've been around since the Steemit days, and the developer community is genuinely strong even if it's smaller than other blockchain ecosystems. And I appreciate that this is a modest pilot with a conservative budget. That's the right way to test an idea.
But I'd honestly rather see proposals funding specific projects and developments on Hive than AI subscriptions, even at this scale.
The proposal does mention accountability, and I think that's good. Developers showing tangible progress after each month is better than nothing. But here's where I get stuck: if we're measuring success by output anyway, why not just fund the output directly? If someone builds a great dApp or contributes meaningful infrastructure work, fund that. You skip the middleman of monitoring whether a subscription is actually being used for Hive work, because you're paying for results instead of tools.
And that's the core issue for me. There's no way to verify that these subscriptions are being used for Hive development specifically. A dev could use 80% of their Claude Code usage on freelance work and 20% on a Hive project, show the Hive project as their monthly progress, and nobody would ever know. I'm not saying people will do that, but when you're spending community funds, the structure should make that kind of thing difficult by design, not just hope it doesn't happen.
What I think would be more beneficial is starting with a list of things the community believes Hive actually needs. Tools, dApps, services, infrastructure layers, documentation, onboarding flows, whatever. Then fund those efforts directly with clear scope and milestones. Tie the money to deliverables. That way the community sees exactly what it's getting, and developers have something concrete to be accountable for.
I also want to push back a little on the 10x productivity framing. AI tools in the hands of a skilled, experienced dev are an absolute force multiplier. I've seen it firsthand. A senior developer who already understands architecture, system design, and debugging can use these tools to move at genuinely impressive speed. The AI handles the repetitive stuff while the dev focuses on the decisions that actually matter.
But for inexperienced juniors, or even some intermediate devs I've worked with over the years, these tools can be a trap. They generate code that looks right, passes a quick review, and then falls apart in production because nobody involved actually understood what was being built. The 10x claim assumes a baseline level of competence that not every applicant is going to have. AI doesn't replace the need to know what you're doing. It accelerates people who already do. That's a big difference, and the vetting process would need to be pretty rigorous to account for it.
None of this is me saying the idea has no merit. I get the reasoning, and I respect that it's being pitched as a small pilot rather than a massive funding ask. But if we're going to spend community money to grow the developer ecosystem (especially during what appears to be a bear market and negative sentiment in crypto), I'd rather see it go toward bounties for specific features, grants tied to shipping working software, or direct funding for projects that people on Hive can actually use. That feels like a more accountable path to the same goal.
In my case, I'm a senior dev and I already use these tools, so I don't need a subsidised subscription. I would rather be paid to work on a problem or task instead.
That's a really fair point, and I think you've actually identified the exact same problem I'm describing, just from the other end.
You're right that project-based funding has burned Hive before. People pitching big ideas, collecting six figures, and delivering nothing or next to nothing. I've watched that happen too and it's frustrating. So I get why the instinct is to go smaller and more controlled, and honestly, I respect that this proposal is designed that way. Conservative budget, pilot scope, vetting applicants. That's all sensible.
But I think the lesson from those failed projects isn't that we should stop funding projects. It's that we were funding them wrong. The reason people walked away with $100k and no results is exactly what you said: no one was actively managing it from an investor perspective. No milestones, no stage gates, no "deliver phase one before you get phase two money." The accountability structure wasn't there, so the money just flowed until someone eventually noticed nothing was happening.
That's a fixable problem. If you fund a project in stages tied to deliverables, the worst case scenario is you lose one milestone payment before you cut someone off. That's a completely different risk profile than handing someone a year of funding and hoping for the best.
The other thing milestone and task-based funding does is open up a single feature or problem to multiple contributors. Right now, most proposals are one dev, one project. If that person gets busy with their day job, burns out, or just disappears, the whole thing stalls. But if you break a large feature into discrete tasks, three or four developers can work on different parts of the same problem in parallel. You're not betting everything on one person's availability and motivation. The work keeps moving even if one contributor drops off. That's just a more resilient way to build software, and it's how most serious open source projects operate outside of Hive already.
And what you described wanting for the future of Hive Dev Fund, a smaller scale system where tasks and small projects can get funding without the massive overhead of the DHF, that's basically what I'm arguing for too. I think we're on the same page about where this needs to go. I just think we should start there now instead of routing community funds through AI subscriptions first and evolving toward it later. The task-based model is the stronger foundation, and I'd rather see the pilot built around that from day one.