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, 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.
2 Likes
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.
1 Like
bad idea looking like being good idea.
would love to read @cwgoes’ take on that x)
here is what I would like to see
-
I would like to see the Hub build the necessary tooling an infrastructure for this/
-
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.
-
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.
6 Likes
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.
6 Likes
I believe this should be possible now using the packet forward middleware
I would just like to say that I think that this is very high quality feedback.
Are you considering a process like:
- consumer chain makes a public proposal
- negotiating committee is paid in some sort of a streaming format by the hub to negotiate the best possible deal for the hub
- final proposal is put to vote
Or did you have something else in mind?
1 Like