Signalling Proposal: Cosmos Hub as an IBC Hub for the AEZ

This proposal aims to gauge the interest of the Cosmos Hub and AEZ Community in repositioning the Cosmos Hub as the “IBC Hub” for the AEZ. Cosmos Hub has long had the ability to act as an IBC Hub since the passing of Proposal 56. Having the Cosmos Hub as an IBC Router for all AEZ chains would ensure ATOM accrues value for the AEZ transactions and 50% of the transactions coming to/from it via sovereign chains. A transaction from Consumer Chain 1 to Consumer Chain 2 would route through the Cosmos Hub. A transaction from Sovereign Chain 1 to Consumer Chain 1 would route through the Cosmos Hub to Consumer Chain 1 and visa versa. A transaction from Sovereign Chain 1 to Sovereign Chain 2 would route as per existing transaction paths. This implementation would ensure that sovereign chains remain sovereign while ATOM accrues value for the AEZ and the transactions coming to/from it. Implementation of this work would need considerable technical review for existing AEZ chains, analysis of the impact and potential plan to transition to this model. Additionally, ongoing support of the IBC infrastructure to ensure the Cosmos Hub and other chains are coordinated, monitoring liveness,…

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

If there is no technical issue, I vote YES on this signaling proposal.

How does this accrue value to the hub though?
What are the benefits to consumer chains?
How does this mechanism get implemented without breaking the entire point of Neutron’s cross-chain infrastructure?
IBC is permissionless, is the Hub ready to force upgrade consumer chains to enable this restricted system?

The economics of relaying/routing packets in Cosmos are still very dubious. The only reason relayers relay are (1) devotion to the network (operating at a loss) or (2) off-chain contracts to support the activity (being paid by foundations or such).

I strongly doubt it will make the Hub any money, especially if taking into account the added responsibility (spinning up new channels as required for the AEZ’s economy to function) and cost (the Hub would need to pay for relayers to actually relay these channels).

Forcing an additional hop will also increase latency and failure rates in most cases, which UX will suffer from.

This proposal as it currently stands seems more value destructive than profitable for the Hub. I think the Hub is much better off pushing these costs onto consumer chains.

This decreases competitiveness of consumer chains and the AEZ as a whole because it 1) doubles IBC transaction time and 2) doubles fee costs for IBC transactions.

Not even gonna start on the added complexity for clients and the fact that this is super difficult to enforce.

No.

Noam:

doubles IBC transaction time

1 → adding 6 seconds to IBC transaction time should not be as much of an issue
2 → we can reduce fees by half on both chains. The important part is Cosmos Hub taking part in AEZ transaction economy

Enforcement can be a social consensus for now since consumer chains are limited and ultimately Hub validators are running consumer chains.

Before we get deeper into the conversation - can anyone describe specifically why they believe / how this would drive any amount of value/revenue to the Hub?

This accrues value to the hub through TX fees. The plan is to have enough demand for ATOM for TX fees to give it moneyness.
Benefits to consumer chain is the solution of IBC path dependency within AEZ, leading to a much better UX for IBC transfers within AEZ.
Another benefit is only one channel connection to the Cosmos Hub gives IBC connection to the entire AEZ. So CCs dont have to open 10 connections to 10 other CCs

Relaying costs should be transferred to the consumers sending IBC TXs in the future. In the short term if costs seem high, we can reduce default fees within AEZ.

6sec latency on IBC TXs should not be as big of an issue. We can even consider reducing block times in future?

Based on this post I believe that Rarma’s idea is that IBC fees are in general too low but that ensuring volume through a hub router and raising prices over time it will create a revenue stream while also lower costs because relayers are already connecting the hub to the rest of cosmos.

Atomic IBC within the AEZ would remove the additional time problem. But I believe that is still early days.

6 seconds is a big deal, especially when we’re more and more competing in a world where we see sub 1s block times on rollups. The future of blockchain is near-instant execution, this is a step in the wrong direction.

The whole point of this thing is silly. We can achieve the same outcome by renegotiating the fee deal with consumer chains.

Will Neutron and Stride be willing to renegotiate the existing deal ?

6 sec block time is the current status. We can further reduce Hub block times in the future if this becomes much of an issue. As of now there’s not much of activity within AEZ so this should not be as big of a deal. In future I expect some more optimisations to land within the interchain to further reduce latency

The same social consensus applies to renegotiating the fee deal or forcing them to route through the Hub. The former option is just more beneficial to the AEZ’s competitive position in the broader Web3 space.

Renegotiating a deal sets a bad precedent in my opinion. Future consumer chains will not be able to have confidence that hub governance won’t force them into a different deal than what they signed up for.

Taxing IBC will weaken the Hub’s value prop, won’t generate any meaningful amount of revenue and will damage the AEZ.

Agreed.

But then again, IBC routing through Hub is also a highly disrupting change that would warrant concern for future consumer chains.

I do think we rushed ICS without really considering the contracts between the chains, the incentive alignment, and the impact on ATOM revenue generation.

However, we’re still super early stage with ICS, I don’t mind us figuring it out. Ideally we get to some kind of point where we have an agreed up on system of setting up these contracts in the future. This is something RMIT is working on as part of the Tokenomics RFP Grant as well btw.

Btw, also totally agree with @Spaydh, how much are we actually talking about? Stride 30d IBC tx count = ~27k, and Neutron 30d IBC tx count = ~20k.

With IBC Tx fees being around $0,001, we are literally here arguing about $47,- a month right now lol.

Even if this goes 100x, we’re talking about 5k a month

The way I see it is that the Hub already made this mistake once when the Cosmos ecosystem was nascent. The Hub had the opportunity to enforce all IBC transactions through it and chose to not enforce it. At that time if we looked at the number of IBC transactions we would have made a similar conclusion - that it is not worth it to route the transactions via the Hub.

Similar to how the Cosmos ecosystem grew, I expect AEZ to grow in the future. Neutron itself is shaping upto be a very promising chain. 3-4 years from now, I really doubt if the revenue from AEZ IBC will be meaningless.

In my opinion, we shouldn’t let the current numbers shape our decision for the future.

Its not the short term revenue projection I am interested in but a vision change.

If the hub is to remain minimalistic, it has to enforce some value accrual. And if you squint hard enough, value accrual looks a lot similar to value extraction. The real question is which chain you are fine with giving value extraction to

Considering IBC is permissionless and that’s how it will continue being, why would a consumer chain do this? See no way to enforce it.

Furthermore as others have mentioned it just add operational complexity and worsens UX, when what should matter is making THE UX better and keeping operations at simple as possible.

Just curious, if I run an IBC with slightly lower fees that’s token agnostic and direct from chain to chain…there’s nothing the hub can do to prevent this right?

I feel like purposefully forcing a token use case is a bad way to go. I’d rather see ATOM just move to be a decentralized VC for cosmos chains and then slowly fade into irrelevance as mission completed.

the value of the hub tends to fall no matter what if it is not respected and does not present any major advantage for the stakeholders. We should perhaps wait for the revelations of the new tokenomic and thus adapt to it.
But time is running out, these phases must be discussed as soon as possible and well coordinated.

and once all the chains are established its value will tend to 0 right?

I agree but in this case to remove Duality from the hub in favor of neutron when it was agreed like that? it works both ways.

what’s its purpose? I feel like supporting the growth of the ecosystem (either through open source development, security bootstraping, or tackling other coordination problems). Once it no longer is the ideal way to go after those problems (or if “all the chains are built” (which I don’t think will ever happen)), then yeah, it should go down

tell it to the investors, and the hub goes to 0 next 12 month

Re-adding my thoughts here as it seems they were ignored in the previous discussion: 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 also just realized that due to the path dependency issues i mentioned above,…

Excerpt (1194 of 1457 characters). Read the whole post on the forum ↗

You raise some excellent points.

You’re absolutely right in that this would require every user with liquidity on existing consumer chains to reroute their assets back to the originating chain and then back to the consumer chain.

Same would apply to any existing chain that would want to convert to ICS, correct.

This is becoming quite obviously a terrible idea imo.

bad idea looking like being good idea.

would love to read @cwgoes’ take on that x)

here is what I would like to see

1. I would like to see the Hub build the necessary tooling an infrastructure for this/

2. I would like to see as option for consumer chains that want to retain more fees. A one size fits all economic model doesn’t work for ICS. Each zone will be different. The Hub needs a variety of alignment modules ICS-20 routing, block space auctions, protocol owned liquidity, token grants to the community pool and more.

3. To navigate the above, the Hub needs to create negotiating committees to negotiate the best possible deal for ATOM holders and they need to get assigned ATOM rewards for being in the committee if KPIs are met.

who is doing it? build a team. a few initiatives, we have ideas, we have to make them a reality

I think that using the Hub to route IBC transfers for consumer chains is a great idea. It could allow consumer chains to save money on relayers by not needing to maintain so many connections. It also builds long term alignment with ATOM because switching denoms after the fact will be very hard.

However, forcing existing consumer chains to switch is a very bad idea, as many here have pointed out.

I also think that it would be bad to make a blanket condition that all new consumer chains use the Hub as an IBC router. Every deal is different, and different things might make sense for different consumer chains.

So if voting YES just signals general support for the use of the Cosmos Hub as an IBC router, and support for prospective consumer chains making that part of their offer, then I would vote YES. If voting yes signals support for making it a blanket requirement, then I would vote NO.

I believe this should be possible now using the packet forward middleware

zaki_iqlusion:

To navigate the above, the Hub needs to create negotiating committees to negotiate the best possible deal for ATOM holders and they need to get assigned ATOM rewards for being in the committee if KPIs are met.

I would just like to say that I think that this is very high quality feedback.

Are you considering a process like:

1. consumer chain makes a public proposal
2. negotiating committee is paid in some sort of a streaming format by the hub to negotiate the best possible deal for the hub
3. final proposal is put to vote

Or did you have something else in mind?