[PROPOSAL IDEA] Token Factory on Cosmos Hub

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…

Excerpt (1198 of 5209 characters). Read the whole post on the forum ↗

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.

Send it Guinch, I’m voting YES!

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: • Risk Mitigation: At present we believe the variable fee mechanism should be a…

Excerpt (1196 of 2201 characters). Read the whole post on the forum ↗

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.

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.

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

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

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

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

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.

“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.

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.

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.

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 —- 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…

Excerpt (1196 of 4438 characters). Read the whole post on the forum ↗

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?

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.

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

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.

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

More is better than less. Your own is better than the narrow one. I support)

button connect wallet doesn't work

Whoever does this, please use one that is compatible with the osmosis tokenfactory spec. I was maintaining this for years here (and it’s audited & running on multiple mainnets) → GitHub - strangelove-ventures/tokenfactory: SDK v50 tokenfactory w/ optional Sudo Minting .

It also includes CosmWasm bindings which are Osmosis & Juno compatible too (leveraged by DAODAO for the past ~2 years)

The ICL has 43 employees, they should have someone that can support adding this to the hub in about half a day of work.

Would you or @0xphilipp_eri happen to know if versions by Neutron and Osmosis are indeed incompatible? AFAIK the namespace hasn’t been changed (if we are referring to message URIs)

Another reason I am pushing for it is CosmWasm binding to interact with custom modules (like TokenFactory). There are osmosis-std and neutron-std and the latter has much more frequent updates. It also more likely to have support for the latest CW version and it’s the only one to have binding for Slinky Oracle that ICL should know very well. It’s useful to have if there is interest in it in future

It’s possible to talk to custom modules without those binding through manual encoding (e.g using anybuf) but I am not optimistic about many teams being able to do that

I just want to flag that the hub already has the callbacks module integrated, which is likely not a good idea to mix with ibc-hooks - but you wouldn’t really need ibc-hooks when you have callbacks. You just need to integrate things slightly differently.
There are already contracts on the hub using this, so I would not recommend swapping them out either.

Why would Osmosis have created IBC hooks if they already had a solution?

Indeed, I wasn’t aware of this point, but after some research I found that Gaia does initialize the Callbacks middleware with an IBC handler for CosmWasm, both for IBC transfers (ICS-20) and for ICA: https://github.com/cosmos/gaia/blob/main/app/keepers/keepers.go#L519 On the contract side, in order to receive these callbacks you need to implement new dedicated entrypoints , as described in the CosmWasm documentation: https://cosmwasm.cosmos.network/ibc/extensions/callbacks Finally, the middleware uses the information passed in the `memo` field of IBC transactions. The IBC-Go documentation explains how to format this field so that the Callbacks module can properly trigger the expected call: https://ibc.cosmos.network/main/middleware/callbacks/end-users/ Example: ``` { "src_callback": { "address": "callbackAddressString", "gas_limit": "userDefinedGasLimitString" }, "dest_callback": { "address": "callbackAddressString", "gas_limit": "userDefinedGasLimitString" } } ``` The key difference is that, unlike IBC-Hooks , a contract must be explicitly modified in order to support callbacks. But you’re right, it’s probably better not to combine…

Excerpt (1195 of 1447 characters). Read the whole post on the forum ↗

I believe ibc-hooks was created first.

Callbacks was created to have 1) an IBC-team maintained solutions and 2) a more flexible and powerful implementation that supports more use cases. Ibc-hooks is essentially transfer + callback only, while callbacks enable callbacks from any IBC application that are aligned with the IBC packet lifecycle flow. It is also the callback solution integrated into x/evm.

It is true, however, like @Victor118 mentioned, that it requires implementing a handler for this.
If you want to add support for contracts that don’t implement this, you could create a proxy that handles it.

Skip:Go uses Callbacks for forwarding on the hub today, for instance.

Can IBC hook and callback work together ?

or does it require choosing between one or the other exclusively?

I’ve been exploring how to replicate the behavior of IBC-Hooks on a chain like the Cosmos Hub, which already supports the IBC-Callbacks middleware . The idea is to deploy a single proxy contract that acts as the `dest_callback` in the IBC packet `memo`. Alongside the `dest_callback` information, the `memo` would also include a `wasm` section (similar to how IBC-Hooks works) specifying the target contract address and the message to execute. When the packet is received, the proxy contract (via `ibc_destination_callback`) parses the `wasm` field and executes the provided `msg` on the specified contract address. The only real difference compared to IBC-Hooks is that transactions must include the `dest_callback` section in the memo. For example: ``` { "dest_callback": { "address": "cosmos1proxycontract...", "gas_limit": "500000" }, "wasm": { "contract": "cosmos1targetcontract...", "msg": { "swap": { "out_denom": "uatom", "min_out": "12345" } } } } ``` This way, we can simulate IBC-Hooks behavior using IBC-Callbacks, enabling a “send tokens + execute contract” UX with just one IBC transaction, without requiring native…

Excerpt (1195 of 1450 characters). Read the whole post on the forum ↗

I cannot confirm or deny with certianty, but I would strongly advice against it - because they are not designed or tested for that, and we might introduce nasty bugs or security issues.

So you’re suggesting that we push the “token factory” proposal on-chain without the part concerning the IBC hook, and instead use the callback functionality.

Right ?

Context Following the discussions on the initial post, it has become clear that the IBC Hooks functionality is not essential for the Cosmos Hub. In fact, the callback functionality is already enabled on the Hub, which addresses much of the original need. Updated Proposal Given this, the signaling proposal should be refocused. Instead of requesting the activation of IBC Hooks on the Cosmos Hub, the emphasis should now be placed on implementing a Token Factory . This is the most relevant and impactful feature to strengthen the Hub’s role and interchain interactions. Why a Token Factory Makes Sense • Complementarity with Existing Features • The existing callback functionality already covers the key use cases that were driving the need for IBC Hooks. • The Token Factory would therefore complement the Hub’s current toolkit without creating overlap. • Native Token Creation and Management • Enables projects and communities to create and manage tokens directly on the Hub, without relying on external solutions or smart contracts. • Improves security, transparency, and governance of newly created assets. • Strengthening the Cosmos Hub’s…

Excerpt (1187 of 1933 characters). Read the whole post on the forum ↗