[DRAFT] An R&D Grants Fund for Licensable SDK Modules

Summary

I am proposing the Hub create a dedicated R&D Module Grants Fund — a governance-overseen program that funds ecosystem builders to design, build, audit, and maintain SDK modules. In return, the Hub gets a pipeline of licensable modules that accrue value back to ATOM.

Cosmos has achieved EVM parity, but our actual moat — the SDK and the modules on top of it — is stagnating. Cosmos Labs is the sole maintainer and developer of new modules. There is no clear path for ecosystem builders to build, monetize, or license modules. Net-new module development has effectively stopped. App chains are migrating out. An R&D Grants Fund is the cleanest way to change that.

This is not ecosystem charity, and it is not seed-investing in projects or dApps. It is direct investment in the SDK as a product — with concrete deliverables (modules), a licensing path, and ATOM accrual built in, in alignment with the enterprise module licensing roadmap.

The fund financially aligns developer incentives with real Cosmos-specific problems that may not otherwise have a sustainable business model on their own. For example, a vault module for ATOM and ICS20 assets is not economically viable to build as a standalone app-chain, but is valuable as a Hub-licensable module.

The exchange is simple:

What developers get:

  • Funding to design, build, audit, and maintain SDK modules

  • A path to distribution and monetization through the Hub’s licensing / marketplace framework

  • A sustainable economic model for solving high-impact problems that do not have a standalone business model on their own

What the Hub gets:

  • A pipeline of net-new, licensable SDK modules that extend the product suite

  • ATOM accrual via licensing revenue, in alignment with the enterprise module licensing roadmap

  • Decentralized module development beyond Cosmos Labs as the sole maintainer

  • Strategic positioning and Cosmos-exclusive R&D on the industry’s largest problems and trends — tokenization, agents, payments, compliance — that define the next five years

What this fund is NOT for:

  • Seed-investing dApps or standalone projects

  • Subsidizing ongoing chain operations or maintenance

  • Research grants unrelated to SDK module deliverables

  • Marketing, events, or general ecosystem growth budgets

This is a signal proposal, not a finalized spec. I am looking for discussion, pushback, and refinement.


Why This Matters: The Strategic Case

Before the mechanics, I want to lay out why the fund is needed. I think this is the single highest-leverage thing the Hub can fund right now, especially given recent events.

Six core insights.

1. Feature parity has been achieved via EVM. For the first time, Cosmos has feature parity with the rest of the industry. The technical blockers that kept developers, enterprises, and integrations away are gone.

2. Feature parity is not enough. Unique value add is still the entire moat. The reason to build in Cosmos is not EVM — it is IBC, the SDK, chain sovereignty, and the module ecosystem. Parity gets us in the door. Unique value keeps us in the room. The argument for why modules specifically are the moat is the next section.

3. EVM chains will be commoditized. Every new blockchain stack ships EVM, and there are a growing number of them. In five years, “we support EVM” is table stakes. If our identity rests on being one of many EVM stacks, we lose.

4. Cosmos wins by being the center of the next five years of trends. Tokenization. Agents. Payments. Compliance. To attract serious developers, institutions, and capital, Cosmos needs to be the obvious home — not at a partnership or integration level, but at the product and SDK level (new innovative modules). On the bleeding edge of innovation.

5. Lack of net-new innovation is a real problem today. App-chains are migrating out or going dormant. CosmWasm is largely abandoned. Net-new modules are not being built. We are stagnating, and our identity is collapsing into “an EVM stack.” This is not a good thing.

6. Builders are cornered. The root cause of #5 is that there is no clear destination for an ambitious builder in Cosmos today.

A Grants Fund turns #5 and #6 from symptoms into something we can actually fix, while aligning directly with the moat thesis in #2, #3, and #4.


The Paradigm: We Still Sell the SDK, Not Just EVM

Cosmos is drifting toward a paradigm where EVM is positioned as the product. It is not. EVM is a critical feature — it unlocks enterprise integrations, tooling, and liquidity — but letting it become our identity is where we lose.

We sell the SDK. We sell IBC. We sell chain sovereignty. We sell things structurally impossible on any EVM chain. EVM is the doorway, not the destination.

Our actual moat is modules. Every Solidity contract can be redeployed on any EVM chain in minutes — zero moat. Modules cannot. Every module we ship is a permanent differentiator exclusive to Cosmos. That sentence should be tattooed on every roadmap discussion.

The goal: EVM + SDK is the product, not EVM only. Cosmos should be the best place to launch an EVM chain — not because it is EVM, but because of the modules around it. A Grants Fund is how we make that real.


Goal: 1000x Quantity & Quality of SDK Module Development

If the SDK is the product, modules are the feature set. Today, that feature set is not growing.

The enterprise module licensing direction is directionally correct, but licensing 1-5 modules is not enough. If we want to pursue it, the goal should be way bigger: 1000s of high-quality modules, a full marketplace of ideas and solutions to every identified problem in the industry, all accruing back to ATOM. Best ideas win.

A Grants Fund targets both quantity and quality directly: it opens the channel, and it sets the bar through scoped deliverables and audit requirements.


Take Risks: Innovate with Zero Downside

EVM and most industry standards are still in their infancy — enormous technical debt, obvious gaps, huge unclaimed opportunities. A handful of flagship modules would change how Cosmos is perceived overnight.

Done well, the pitch writes itself: Cosmos becomes the safest, most secure, most compliant, most agent-friendly, most payments-native, most tokenization-native, most battle-tested ecosystem in the industry. Not a marketing claim — an actual architecture backed by a module catalog, pre-built for any chain developer.

Zero downside to innovating. Why? Worst case: our R&D investment doesn’t pan out and an EVM equivalent does. We still have EVM!


Where the Fund Should Focus: The Largest Opportunities

The fund should not focus on stuff that has already been solved by EVM. We should focus on the biggest problems facing the industry today, as well as the trends of the next 5 years.

Three massive, Cosmos-solvable opportunity categories:

1. Architectural gaps in EVM (EVM+ Mindset). EVM was not designed for where the industry is heading — compliance, programmable transferability, agentic workflows, payments at scale. ERC-20/721/3643 need a redesign. EVM has no chain-level primitives for vaults, safety, or security. Wallets are one signature from full drainage. Every gap is a module-shaped hole.

2. Security and safety. The industry runs on broken assumptions — private keys never leak, social engineering is impossible, zero-days don’t exist. In the age of AI, these are obviously false. The only defense is in-depth and on-chain guardrails.

Ethereum does not have the agility to ship these. Cosmos does. The SDK even has angles EVM cannot match: BeginBlockers, EndBlockers, Go-level flexibility, chain-level primitives.

3. Modules at the center of major trends. Tokenization, agents, payments, compliance, DeFi — none of these are fully built out. Become the default home for even one and we are golden. It is worth investing into R&D into these major trends.


Why Modules Are the Right Design: Standardization Wins

Standardization wins. HTTPS. TCP/IP. JSON. “You can program anything with smart contracts” is not the end game — standards and abstraction layers are. Existing standards are 10+ years old. Modules are how we redesign them.

1. Safety and security. A new smart contract per use case does not scale — every one is a new attack surface, ABI, and audit bill. A standardized module beats custom contracts every time.

2. AI-agent readiness. Agents learn primitives once and reuse everywhere. They are not going to write, audit, or parse custom contracts at scale — they need primitives one CLI command away. Cosmos modules are already CLI- and API-first by construction.

3. Developer experience. Modules are an API-like on-ramp, not a Solidity or CosmWasm gauntlet. They lower the barrier dramatically, especially for AI agents.

Standards, knowledge, trust, and dev speed all compound. The standardization snowball is a powerful force in an AI-first world.


Discussion

This is a signal proposal, not a finalized spec. There are plenty of open questions — sizing, governance, RFPs, eligibility, licensing mechanics, accountability, I think the best way is to work through them via discussion. The goal of this post is to open the conversation.


2 Likes

I want to offer my constructive support for this proposal. Bringing forward creative ideas that aim to generate real value is formidable, and I believe we should now dedicate our time and energy to maturing concepts like this one, which actually bring something tangible to the ecosystem.

However, for this not to remain just good intentions, we must mature the idea with realistic data and projections. The next step should be to actively seek out and consult with institutional investors or real enterprises to see if they would actually find paying for these licenses attractive. If we are going to invest community funds in R&D, we must structure it so that these costs are reimbursable or generate a return on investment (ROI) within a reasonable timeframe.

This is everyone’s job. Our duty as a community is not just to wait for a vote and press a button, but to anticipate the hurdles we might face along the way and brainstorm solutions together (such as who will audit the code, how license pricing will be set, etc.).

I genuinely really like this vision of continuing to evolve and seeking real business models for the Hub. Thank you for the proposal; let’s work on the numbers.

1 Like

Same opinion that TRAVE. How to make sure we don’t just pay for modules that end up never being used and generate zero revenue?

The only way I could support something like this would be to release to fund once the module is being brought / use and generate money.

If not we may just pay for air

1 Like