[PROPOSAL IDEA] Token Factory + IBC Hooks on Cosmos Hub

Hub Proposals Proposal Ideas
1

Currently, Proposal 1007 is being voted on to allow permissionless deployment of CosmWasm smart contracts on the Cosmos Hub.

Proposal 1007 opens the Cosmos Hub to permissionless CosmWasm smart contracts, allowing any developer to freely deploy applications. The natural next step would be to add the Token Factory module to give these applications the ability to create and manage their own tokens directly on the Hub, without relying on other chains like Osmosis or Neutron.

This discussion would therefore lead to the creation of a signaling proposal for ICL to implement this module in Gaia.

Why the Token Factory module on the Cosmos Hub?

1. Complement to permissionless CosmWasm

CosmWasm enables the creation of complex applications.

Without the Token Factory, these applications would have to rely on external chains to launch a token, which means a loss of value and control.

With Token Factory native to the Hub, a CosmWasm contract can immediately launch an interoperable IBC token, maintaining liquidity and economic activity on the Hub.

2. Direct and native interoperability

The tokens created are IBC-ready from the moment they are created. They can be used anywhere in the Cosmos ecosystem.

No need for wrapping or additional bridges; it’s simpler and more secure.

3. Attracts developers and projects

Teams wanting to create a dApp + a token can do everything in one place.

This positions the Hub as a center of gravity for the deployment of cross-chain projects.

4. Retention of economic value on the Hub

Currently, a Hub project that wants a token often ends up going to Osmosis or Neutron.

With Token Factory, this creation is done on Gaia, which would generate more transactions, more outgoing IBC volume, and higher fees for validators and stakers.

5. Proven and secure technology

Already in production on Osmosis, Neutron, and other chains.

Audits completed, mature ecosystem, best practices already documented.

6. Flexibility for innovation

Governance tokens, algorithmic stablecoins, real-world asset representations (RWAs), access vouchers…

All of this can be developed directly on the Hub, leveraging CosmWasm.

Conclusion:

Token Factory is the key to making the Cosmos Hub a complete platform, capable not only of hosting smart contracts but also of creating and managing the tokens that power these contracts, while remaining interoperable across the entire Cosmos ecosystem.

Benefits

  • Decentralized token creation and management
    Smart contracts (CosmWasm) can create, manage, and distribute their own tokens without relying on a third-party module or manual approval.
    Ideal for quickly launching utility, governance, or synthetic asset tokens.

  • Native IBC Compatibility
    Tokens created via Token Factory are directly compatible with IBC, making them immediately transferable to other Cosmos chains without additional development.

  • Proven Module
    Developed by Osmosis and already successfully deployed on Osmosis, Neutron, and other Cosmos blockchains, benefiting from robust and audited code.

  • Synergy with Permissionless CosmWasm
    Combining Token Factory with permissionless CosmWasm on the Cosmos Hub would provide a highly programmable environment where projects can launch interoperable tokens and dApps directly on the Hub.

  • Reduced External Dependency
    Would allow the Cosmos Hub to retain more economic activity on-site instead of having it migrate to Osmosis or Neutron.

  • Standardization of Cosmos Assets
    Facilitates the creation of tokens that adhere to common standards, simplifying integration by DEXs, dApps, and wallets.

Negative Points / Risks

  • Risk of Token Spam
    An open module could lead to a proliferation of useless or fraudulent tokens.
    Solution: Set a denom creation fee high enough to deter spam, while remaining affordable for serious projects.

  • Security Issues with SendBeforeHook
    This feature allows code to be executed before a token transfer, which can be exploited for complex attacks.
    Preventative Measure: Disable or restrict this feature via governance (as on Neutron).

  • Governance Complexity
    The more tokens there are on the Hub, the more governance could be called upon to manage abuse, disputes, or block requests.

  • Increased Technical Burden
    Regular maintenance and audits are required to avoid vulnerabilities, especially in combination with permissionless CosmWasm.

For a minimum of context and transparency with the community, certain identified teams that will not be mentioned here have this particular need to be able to create new hub/independent products.

Conclusion

Integrating the Token Factory into the Cosmos Hub, especially with permissionless CosmWasm, would be a strategic lever: instant creation of interoperable tokens, increased attractiveness for developers, and the potential to capture more economic value.

Please take part in this discussion which would last 7 days before creating the signaling proposal once vote 1007 is adopted. In the event that prop 1007 is rejected, this topic will probably be postponed until later for the EVM part in PSS which should be created in the coming months.

17 Likes
2

I support adding Token Factory to the Cosmos Hub.

Developers could make apps and tokens in one place.

Tokens would work across the Cosmos network instantly (IBC-ready).

More activity and fees stay on the Hub instead of going to other chains.

It’s safe — already used on Osmosis and Neutron.

Opens the door for new ideas: governance tokens, stablecoins, game items, and more.

Yes, there’s a risk of useless tokens, but a small creation fee can fix that.

This would make the Hub a true place to build AND grow projects. :rocket:

4 Likes
3

Send it Guinch, I’m voting YES!

3 Likes
4

We would like to share our perspective regarding the introduction of the token factory on the Cosmos Hub. While we recognize the importance of experimentation during the current interim phase, we also believe it is essential to remain aligned with the blockchain trilemma and maintain a sustainable balance between security, decentralization, and scalability.

Key Considerations:

  • Scalability Risks: The token factory has a direct impact on scalability. Our primary concern is to prevent abuse and spam, which could undermine the Hub’s stability. Proper monitoring and safeguards should be in place.
  • Acceptable Boundaries: We are open to supporting broader use of the token factory so long as activity remains within reasonable limits and does not compromise network performance on other activities (CW, etc..).
  • Ecosystem Opportunity: Token issuance on the Hub carries unique benefits, notably stronger security, decentralization, and credible neutrality compared to smaller chains. While allowing endless composability of usage anywhere in the broader ecosystem thanks to IBC.

Recommendations:

  1. Risk Mitigation: At present we believe the variable fee mechanism should be a sufficient first line of defence against abuses. We remain open to explore complementary measures if needed (specific gas limit per bloc for the token factory as an example).
  2. Strategic Positioning: Encourage the Interchain Lab (ICL) to design and implement a marketing campaign highlighting why minting tokens on the Hub is preferable:
  • Seamless cross-chain portability via IBC, ensuring broad accessibility.
  • Enhanced security and neutrality, making the Hub the most reliable issuance venue.
  • Reinforced ecosystem trust, as Hub-tokenized assets carry stronger reputational weight.

Conclusion:
We are supportive of further exploring the token factory on the Hub, conditional on effective safeguards for scalability and abuse prevention. At the same time, we see this as an opportunity to reaffirm the Hub’s role as the most secure, neutral, and interoperable chain within Cosmos, and to actively promote this positioning to developers and users.

Thank you for reading,
Govmos.
pro-delegators-sign

8 Likes
5

I personally support the addition of TokenFactory as an obvious follow up of CW becoming permissionless on the Hub.

Also, I agree that there should be some safeguards against abuse prevention, and for security reasons, I would suggest not letting SendBeforeHook available to any contract, in a similar fashion as what’s on Neutron.

If TokenFactory can be added to the Hub so it can be used by CosmWasm contracts, this would allow Moonkitt deploy a project that we have been ideating on for few months, and we hope that it could be part of a great new ecosystem of apps built on the Hub, for the Hub and $ATOM.

Thanks @Guinch_Roze for leading the discussions and putting these props on chain.

6 Likes
6

Hi @Mag

I’d like to discuss Prop 1008, which addresses the “token factory” functionality.

After speaking with several community members, it’s clear that this module is the logical next step following Prop 1007 to unlock development potential on Hub.

Since Prop 1008 directly involves the ICL in terms of design and implementation feasibility, I wanted to ask if you could honor the commitment made in January to add this module to Gaia.

We understand this creates additional workload for your team, but we strongly believe it will benefit the community and the future apps being built on Hub, and I know you value community input.

If the ICL doesn’t have the bandwidth to handle this internally, we could explore having an external team develop it and submit a pull request to Gaia’s repository. Your team would then only need to review and provide feedback until it meets integration standards.

Best regards.

Guinch.

7 Likes
7

Hello, I completely agree with this. Good initiative @Guinch_Roze

1 Like
8

In this vision of a token factory, what is the added value for the atom token?

1 Like
9

Full support. TokenFactory is a must for CosmWasm chains these days. This gives instant access to IBC for these coins, being supported accross the ecosystem and making SmartContracts logic simpler.

The main question is, who will be integrating it. Even if a proposal is passed there needs to be some devs that integrate it. This would most likely be coordinated with ICL and if they are willing to integrate it. And also which version of it, just keeping the namespaces from Osmosis, providing custom bindings like Neutron? I would just prefer to use the original Osmosis namespaces, so contracts would be compatible, between the “standard” version of it.

Have you reached out to ICL?

Implementation discussion could also be started here: GitHub · Where software is built

2 Likes
10

Yes, I sent a message to Mag, he replied to me, we are waiting for his response here on the forum.

2 Likes
11

I’d like to suggest considering the integration of IBC Hooks as well.

This feature would greatly enhance the developer experience by enabling programmable IBC transfers directly on the Hub.

Key benefits:

  • Unlocks new use cases for CosmWasm contracts on the Hub (automated staking, swaps, vault deposits, etc.)

  • Improves user experience by reducing multi-step transactions into one seamless IBC flow

  • Positions the Hub as a more developer-friendly and programmable routing layer, not just a minimal relay

  • Strengthens the Hub’s role in the ecosystem by attracting more DeFi and interchain applications

This could make Cosmos Hub much more attractive for builders who want to deploy on-chain logic directly connected to interchain flows.

5 Likes
12

“The security controls should preserve the ability of the business to operate and grow; otherwise, they will be unnecessary, as the business is potentially headed for obsolescence.” (The Official (ISC)2 CISSP CBK Reference, 6th Edition (2021), By Arthur Deane and Aaron Kraus, page 364)

I’ve got this quote printed out above my desk. I work in security, and far too often security is either:

  • Intel guys who don’t know what they’re talking about regurgitating articles on bleeping computer
  • Cyber vulnerability assessors attempting to force “best practice” concepts, STIGs, frameworks, 800-53 controls, etc. onto systems that affect operations

While there’s obvious risk in enabling these features, I see more risk in allowing the Hub to continue to drift into obsolescence. People who truly want locked down financial tx security will choose BTC. And the Hub’s focus on minimalism for security simply has not translated into a sustainable market condition.

So, I think we should definitely enable these features, and try to give the Hub a fighting chance.

5 Likes
13

We would like to emphasize that enabling new development features on the Cosmos Hub today should not be seen as an irreversible path. This is ultimately a matter of design structure.

If usage of these services grows significantly—such as the token factory reaching a scale where it places undue burden on the Hub—it remains entirely feasible to migrate them to dedicated PSS chains. The Hub already has the infrastructure primitives necessary to make such transitions relatively quickly, should governance determine it appropriate.

At Govmos, we hold the view that security and credible neutrality must remain the Hub’s defining characteristics at all times. While we are supportive of enabling developer-facing features and fostering greater activity, we also recognize that if these features ever pose excessive risks to the Hub’s core mandate, the community should not hesitate to consider migration to external environments.

In short: we support experimentation on the Hub, but always under the guiding principle that the Hub’s role as the most secure and neutral base layer must be preserved.

6 Likes
14

I personally feel excited about the possibilities TokenFactory would bring, the UX is certainly much better than alternatives for creating tokens, like CW20.

From the perspective of Hydro, I feel most excited about enabling other projects building on top of Hydro to make use of the module. We are also currently using it in our implementation of the Inflow vault contracts.

The main con to me is that not only is there an initial setup cost (someone has to integrate and issue a PR to the Gaia repo), but also there is ongoing cost - e.g. what if the Cosmos Hub wants to upgrade to a new version of the Cosmos SDK that the existing TokenFactory module is not compatible with? Any module integrated into the Cosmos Hub should have clear expectations on maintenance and ownership. Just seeing the initial setup cost of it is underestimating the cost a little bit in my opinion.

Still, if the Cosmos Hub wants to offer a competitive DevEx, it needs modules that make it smoother and easier to develop meaningful CW applications on it, and TokenFactory is one of the most obvious improvements, so personally in favor, but keeping in mind the initial and ongoing costs of integration, too.

6 Likes
15

The way I see It doesn’t make much sense to not have these modules enabled with permissionless CosmWasm

  • Missing Tokenfactory will simply force actors that are interested in launching a token to go with CW20. No way to prevent anyone from spamming, no fees for community pool and worse UX for everybody

  • Lack of IBC-Hooks is simply bad UX & DX when dealing with interchain transaction, which isn’t acceptable for a chain that try positioning itself as a hub. There are many infrastructure protocols that rely on then.

    For example our team has been building solutions for Chain Abstraction for a while. They’ve been partially funded by the community pool over the last few rounds on Dorahacks through an allocation that came in proposal #917. If deployed on the $ATOM chain right now they aren’t going to work as intended due to experience not being atomic :drum:

—-

Having said that I’d like to hear the plan on what the initial TokenFactory parameters are going to be for the proposal. I presume there won’t be any genesis denoms nor increased gas consumption. The question is primary about the creation fee:
Free like on Neutron? $ATOM? $USDC? Other? Multiple?

As for IBC-Hooks there is a more complex issue related to the economics. When someone initiate a hook transaction from a remote chain, there is a relayer that picks it up, calls an indicated smart contract and then pays the fees with their cosmos wallet.

This can be used as a loophole by malicious actors to avoid paying themselves. it can also simply get too pricy when dealing with complex smart contracts. In general it’s not sustainable for the relayers in longer term. Here are some options that I have in mind for mitigating this:

  1. Relayers are compensated from the community pool using x/feegrant. This would take establishing an application process, collecting the addresses, issuing the grants and so on.

  2. The transactions are ether partially or fully fee exempted on the hub using x/globalfee. I am not sure whether it is possible to tell regular contract execution calls apart from the ones initiated by hooks. Suspect them using the same message type and not being feasible. Listing it here just in case if I am wrong

  3. Use Neutron’s x/feerefunder. They already have thought about this problem and came up with a working solution. It covers even timeous fees. I believe the module is permissively licensed (like the rest of them). There are existing docs and examples on how to use it and it should be accessible for everyone right away

    The hook module itself in this case will be also coming from Neutron. This is the opposite to what @0xphilipp_eris suggested in an earlier comment about going with Osmosis. I do support his suggestion about moving the discussion about deeper implementation details to another platform though. However it’s good to list the options here for the general public first

  4. A remote actor initiating an IBC-Hook can attach a fee alongside the main payload. My knowledge can be outdated but AFAIK it’s not enforced by the protocol and it is simply what the name implies: a tip. Changing it to be a requirement for hook transactions can solve this issue but the question is what it’s going to take

    1. (4.1) The changes can be made in relaying software like rly and hermes itself (if they don’t exist yet). There should be an option to ignore the transactions without any tip and in this scenario it’s completely on relayers to make sure it’s enabled

    2. (4.2) The changes can be made to IBC-Hook module itself by extending it’s functionality. I’m not a core developer and can’t comment on what it’d take. Leaving this for others

      In case if it’s decided to go this way just want to put out there a thought that it could be beneficial to expand the concept for other types of messages beside wasm execution messages. Since it’s already possible to issue any other message from a smart contract this is a matter of optimisation and is far from being a priority

    An anticipated problem is evaluating whether tips in different denoms (if allowed) constitute adequate compensation in local fee for a relayer. Calculating this might require a deployed dex, a slinky oracle or something like x/txfees by Osmosis

Would be curious to hear the community’s thoughts on this and of also the ICL as it will most likely be on them if anyone. Sharing my thoughts in a separate message a bit later

4 Likes
16

How do you envision governance handling potential token spam or low quality tokens created through Token Factory would denom creation fees alone be sufficient deterrent?

1 Like
17

Might as well just make a Pump Fun clone and have ATOM pairs. Guarantees liquidity for upstart project and locks ATOM in pools. All streamswap is really do right now is sell USDC to founders in exchange to token they minted at no real cost.

18

How does this proposal align with the Hub’s long-term modularity goals?

19

I support adding Token Factory to the Cosmos Hub, it opens the door for new ideas like governance tokens, stablecoins, game items, and much more.

20

Should we adopt Osmosis namespaces for compatibility, or customize bindings like Neutron?