[PROPOSAL IDEA] Token Factory on Cosmos Hub

Hub Proposals Proposal Ideas
21

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

1 Like
22 
button connect wallet doesn't work
23

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.

6 Likes
24

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

25

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.

3 Likes
26

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

27

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:
:backhand_index_pointing_right: 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:
:backhand_index_pointing_right: 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:
:backhand_index_pointing_right: 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 both solutions and instead use Callbacks, which seems to be the standard solution developed by the IBC team.

I’d be curious to hear feedback from teams that make heavy use of IBC-Hooks to know whether the callback mechanism is a limitation for them.

28

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.

4 Likes
29

Can IBC hook and callback work together ?

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

30

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 IBC-Hooks support on the chain.

What do you think ?

EDIT : The contract should handle failures. One approach is to wrap the downstream call in a SubMsg with reply_on: ReplyOn::Error and, in the reply handler, initiate an IBC refund to the user.

1 Like
31

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.

1 Like
32

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 ?

33

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

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

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

  3. Strengthening the Cosmos Hub’s Attractiveness

    • A native Token Factory makes the Hub more competitive and central within the Cosmos ecosystem.

    • Encourages projects to use the Hub as a primary anchor for their interchain tokens.

  4. Interoperability and Simplification

    • Combined with the existing callback functionality, a Token Factory would streamline automation and interchain asset flows.

    • Reduces infrastructure complexity and costs for developers and operators alike.

Conclusion

By focusing solely on the Token Factory, the proposal becomes sharper, more pragmatic, and fully complementary to what is already in place. It addresses actual ecosystem needs while avoiding duplication and maximizing impact on the Cosmos Hub’s development.

1 Like