I want to kick off a discussion about the Cosmos Hubs current identity crisis. That is, the Cosmos Hub is a Hub in name only. Even with ICS/AEZ.
With the introduction of the AEZ I would’ve thought there would be considerable review and discussion of the Cosmos Hubs role as an “IBC Hub” within the AEZ. Currently, ICS chains can be onboarded using the Cosmos Hub as security, yet the consumer chains can connect to any chain via IBC (as normal). The Cosmos Hub gains very little from this, as consumer chains and other sovereign chains share the majority transaction fees.
Cosmos Hub has long had the ability to be an “IBC Hub” with the introduction of the IBC Router in Proposal 56. I believe it is time for the Cosmos Hub to position itself as the IBC Hub for the AEZ. When onboarding, ICS chains should be required to connect ONLY to the Cosmos Hub (Permissioned IBC?) and route all traffic THROUGH the Cosmos Hub using the IBC Router. Sovereign chains will connect to the Cosmos Hub if they want to interact with a Consumer chain. This will ensure that the Cosmos hub receives its share of the fee revenue (another conversation is needed about current fee values - they’re far too low) from ICS Consumer chains.
The example below explains how I think it should work.
Using USDC as an example, it should look like the below image if I want to get USDC from Noble onto Neutron.
Same with Osmosis to Neutron, that tx should go through the Cosmos Hub.
However, if Osmosis wants USDC, it can get it directly from Noble as the USDC Hub.
In principle, I think this is a good idea. I did try to push for this strategy when I was working at AiB in 2020, and I think it’s unfortunate that this wasn’t executed earlier (and still hasn’t).
Because this is a topic I have had a lot of interest in, I do have a few concerns:
There needs to be an explicit devrels/owner of the Hub’s IBC services.
Maintaining an IBC hub is no easy task and the product ownership structure should be explicitly stated prior to this ‘requirement’ going live. For example, Osmosis spends significant amount of resources coordinating with relayers, talking to chains, monitoring liveness, developing tooling, creating registries, etc. This doesn’t exist for the hub.
Proper vetting of the product owner should happen, and funding should be allocated to ensure this is their full-time job (maybe via AADAO). I attribute most of why this didn’t happen in 2020 to this.
Tradeoff assessment of added latency vs overhead of each chains managing IBC connections need to happen.
What about for non-ICS20 IBC channels? (i.e. ICS-27, ICS-721, etc) What if the hub fails to adopt these new features at an adequate speed where ICS chains feel they’re blocked by the hub?
Tbh most of these issues can be solved by heaving a clear ‘Hub IBC GTM’ ownership. But just adding a few concerns as I don’t want people thinking “oh if we enforce this, things will magically happen”
Generally speaking Cosmos technology needs to develop along 2 strategies:
Maximum decentralization of chains
Generating value for ATOM
The two are closely related because it takes money to build common good services. In every society that is why you have taxes, bond sales and inflation seignorage - all of them are method to raise money to fund the creation of public goods. In the case of Cosmos, the public goods token is ATOM. ATOM is the tax that the interchain has to pay and in return get public goods in return. At present, a lot of public goods are delivered but no one is getting paid via ATOM appreciation. That circle of decline needs to be ended. Everybody needs to eat - including developers and investors. I don’t understand why people associate altruism with no monetary incentives. Money is allocation of resources. If you deprive things of money you want to kill them. Nothing can survive without proper economic incentive. Effort needs life energy and life energy doesn’t come out of nothing. People need to live and have to be able to pay their bills to work on Cosmos. Economic incentives are important and Cosmos teams need to do a signfiicantly better job on crafting economic incentives. That means making the ATOM token an attractive investment. People on Cosmos need to get out of the VC mentality where some VC pays them to live. Dumping tokens on people is asking the public to fund your hobby. I am not here as an investor to fund your hobby. Cosmos Hubs devs are not my girlfriend. ATOM needs to be treated as an investment in which outside investors will want to invest.
This proposal makes so much sense that I am surprised it doesn’t work this way already. I was sold that the Cosmos Hub is the main Hub through which interchain commerce flows because it is more efficient to have N*2 connections (all nodes connecting through a hub) instead of N squared (all nodes connecting to each other). Cosmos tech should be forcing all Cosmos chains not just AEZ chains to communicate with each other through the Hub. At THE VERY MINIMUM the ATOM Economic Zone chains absolutely need to make IBC connections through the Hub.
Honestly, I can’t believe this has to be discussed. This is an obvious feature. The Cosmos dev teams need to stick to what they wrote in the whitepapers. Cosmos Hub needs to be the default hub of all IBC traffic, the IBC fee has to be paid in ATOM. Chains can be allowed to use other Hubs and pay other tokens, but the default behavior has to be preset to be Cosmos Hub and ATOM. And for AEZ it has to be the only option.
I think this will be potentially harmful to the Hub as it is just one additional barrier to entry to joining the AEZ (in addition to increasingly draconian economic requirements to join as well as the general hub drama). I’m concerned it will push potential consumer chains away. When mesh becomes an option and is much more value - reciprocal, why go with replicated?
Though, i’m not strongly against it if there are consumer chains that want to opt in.
One, more important question. This will not work for existing consumer chains correct? Due to IBC path dependency requirements, consumer chains with existing liquidity on other chains (like stride and, to a lesser extent, neutron) wouldnt have that liquidity fungible with new liquidity transfers routed through the hub. An attempt to migrate liquidity would be nearly impossible and likely cause significant damage to those consumer chains’ TVL.
If that’s the case, i’d just ask that any proposal take this into account and not make this a retroactive requirement.
I’m not totally sure that IBC fees were intended to be paid in atom. If you’d like to link to the white paper that your referencing I’m more than happy to check it out.
I tend to agree with you. Also we would have to consider things like the existing IBC channels on neutron and stride… And even how to create channels on duality.
Point blank, IBC channels are the stickiest asset in cosmos. I think there’s exactly zero chance of stride wanting to recreate all of its channels and in fact the onboarding procedure was mainly focused around ensuring that stride did not need to recreate all of its channels.
Yes, exactly this. I think that there’s also a serious question about latency, which you also mentioned in your post.
The diagram is super logical and super sensible, but but I’m beginning to have some concerns about this proposals viability mainly due to the technical challenges, and that’s without even getting into the economic challenges, and the fact that it changes the network topology that the existing consumer chains elected to join.
IBC traffic was supposed to go through the Cosmos Hub which uses ATOM for transactions. Payment in ATOM was not explicitly outlined but logically usage of the Cosmos Hub as IBC Hub should lead to usage of ATOM.
I also just realized that due to the path dependency issues i mentioned above, existing cosmos chains like umee that already have liquidity would not be able to onboard to ICS either (unless exempted from this requirement).
ICS would effectively only be open to new, untested chains which places additional risk on the hub in terms of ROI.
If we want Cosmos hub to be IBC router shouldn’t Cosmos then have latest version of ibc? Right now Cosmos has some version of 4.2.*. My question here how would this affect other chains?
For example Stride can work with any chain that has ibc v3 and up but could this be done through cosmos if this is the case? It this example instead of the direct route from Stride to other chains would need to go to Stride>Cosmos>Chain A. Could this be done? As far as i remember Stride has ibc v7.2. So could this even work with cosmos being ibc router? This is a genuine question since I think stride is unique on how it utilises ibc.
So I think Cosmos hub should have latest ibc version so other consumer chains could work properly. Not all chains will do the same as stride but their operation should not be limited by cosmos hub.
I am up for making cosmos hub a ibc router but it should not be forced, instead offer it as a choice. Let’s say in theory ICS has around 50 chains 10 years from now having connect to osmosis and cosmos hub would be 100 different connections needed to be set up and this is only for 2 chains. Imagine that at avarage every consumer chain needs 4-5 ibc connections. This is unnecessary complexity for relayers. It would be easier in this example if everything could go through cosmos hub. It would be a lot cheaper and less time consuming , and most chains are connected to the hub at this moment.
Second this question. Currently Astroport uses a contract-to-contract channel / custom protocol to govern the Neutron outpost from Terra. Seems like this proposal would remove that flexibility for contracts? Or how would that work?
