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, development of tooling to support, and creation and maintenance of registries.
Vote options
Vote YES to signal support of making the Cosmos Hub an IBC Hub for the AEZ
Vote NO to signal no support of making the Cosmos Hub an IBC Hub for the AEZ
Vote ABSTAIN to express no opinion
Vote NOWITHVETO to to contribute to a veto tally. If the veto tally reaches one third, then the proposal will fail and the deposit on the proposal will be burned.
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.
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.
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.
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.
