DeX on the Hub discussion

Governance
#1

There exists some discussion about DeX on the Hub subject in telegram and discord channels. I would like to sum up the status and make this discussion continues in more constructive way.

Why DeX on the Hub

  1. more activities and growths directly on the hub
  2. potential value added to ATOM
  3. benefit zones around cosmos ecosystem by providing DeX utility on the hub

DeX on zones

  1. they does not directly benefit ATOM value
  2. they have less representativeness and much less staked security

What prevents DeX on the Hub

  1. impact on security of the hub
  • DeX as a native module in SDK : relatively more security risk and difficult to manage
  • DeX as a permissioned CosmWasm contract : relatively less security risk
  1. regulatory constraints on AiB and ICF
  • they cannot fund DeX projects
  • community fund is an alternative approach

Market potential

  1. DeX is very competitive market
  • it might be difficult to bring significant use-case considering current competition
  1. Ethereum oriented DeX is the center of the market
  • how can we attract traders in Ethereum ecosystem?
  • it is relatively indirect to connect the Ethereum network than DeXs on Ethereum
  1. market timing
  • is it too late to pursue DeX application market?

Important qualities of DeX on the Hub

  1. performance
  • block time and tps of the hub is not an enough figure to utilize competitive DeX
  1. privacy
  • no privacy protected at all
  1. liquidity
  • need to figure out how to bring liquidity to the DeX

Miscellaneous

  1. UX
  2. technological design of the DeX
  • automated market making like uniswap
  • plain on chain order book exchange
  • other type?
  1. DeX on a zone secured by ATOM via shared security
  • more customized blockchain application and performance
  • less impact on security of the hub
  • still economically benefiting ATOM holders
3 Likes
#2

Without going into detail, I love this idea. A more radical (and hence controversial) viewpoint is Cosmos Hub HAS TO BE a DeX. If Cosmos Hub is the most decentralized, public, open and secured hub (at this moment), it should work as a DeX for the tokens in the ecosystem.

2 Likes
#3

hi terence. thanks for the reply.

so you mean the hub should itself possess the DeX module inside the gaia so that it should provide DeX application all by hub self?

as a context of this, the reason why this matter is controversial is that we really don’t want to congest or risk the stability and scalability of the hub by utilities other than IBC transactions.

I am curious how other community members think about this matter. If we really need a hub DeX, should it be directly on the hub? or implemented as a second layer to protect the hub from noise created by DeX application?

#4

Yup. This is controversial but also interesting. I may have conceptual misunderstanding but I don’t mind sharing my view:

When we talk about decentralized exchange, it is about the exchange between two tokens (selling token A and buying token B). To me, interchain-communication should also cover the exchange between different tokens where their chains are connected by IBC.

I expect the security for a DeX in Cosmos should be as high as Cosmos Hub due to the close relationship between exchanging tokens and inter-chain communications. So far, this is not achievable as validators’ resources are limited and a lot of base layer protocols are competing for the very limited validators’ attentions.

By directly implementing DeX on Cosmos Hub, we can

  1. save a lot of effort to cultivate the validators community for the DeX and hence more focused on building a great DeX
  2. improve the value of atoms and hence improve the economics of validators which will in turn increase the security budget of Cosmos Hub to cover the DeX functionality.
1 Like
#5

Another feature/benefit of this proposal is that chains built with the cosmos SDK would enjoy instant liquidity.

I think that this would bring many projects into the ecosystem.

#6

If having a DeX on a hub, impacts the security of the hub, and there isn’t not enough funding/resources (team) available.

Why not focus on supporting cosmos projects such as Kira Ex, which has the privacy, open source and decentralization and which will provide value to atom and make staked tokens tradeable?

or is the aim to put everything on cosmos hub and weed out other projects. It would be better to support projects that have the same values of cosmos and benefit cosmos.

#7

e-money is going to be the first one.

Then Kira maybe the second one.

Dex native in cosmos is not ok.
Dex in zones yes.
Build your DEX and unisawps in Cosmos SDK or use cosmwasm

Binance is running Binance Dex long time ago.
Check daily volume and orders books.

#8

I want to clarify the difference between 1) DeX on an independent zone and 2) DeX on the hub with hub-level-security. Below is an explanation of reasoning of DeX on the hub.

DeX is all about Liquidity and Strong Security

DeX is all about liquidity concentration. Liquidity is the key ingredient for successful DeX.

In Ethereum space, most successful DeXs are providing layer1 security, because as a liquidity pool, the users want layer1 level security when they peg in their precious assets.

DeX Competition across the entire blockchain space

DeX is a universal use-case across the entire blockchain space. We have to compete with 0x, kyber, omg, uniswap and more. Cosmos has a good advantage, IBC, which connects different kinds of networks. So, as a network with primary utility being interoperability, DeX should be one of the main utility provided by the hub.

DeX on Independent Zone is Not Providing Enough Security to Absorb Significant Usecases

However, decentralized approach of DeXs with second layer security will not give us enough competitiveness against booming Ethereum DeXs with layer1 security. DeX on zone is not same as kyber because the security guarantee lies on different size of trust.

With similar analogy, DeX made by centralized exchanges such as Binance Chain will not provide us enough decentralized security because it is a giant corporation without any intention to decentralize their possession of network. It is not the alternative approach of DeX on the hub either.

DeX and IBC Usecase Growth

We need a strong DeX utility with hub-level-security so that the liquidity can be concentrated in one pool to have enough momentum to compete with other solutions.

If we lose this competition, IBC will lose one of the main purpose of interoperability, trading. Solutions from Ethereum community will absorb liquidity from networks including Cosmos networks, and it can be a disaster for IBC usecase growth. I agree that IBC has much broader potential of usecases besides trading, but we should admit that it will be the main usecase for at least several years.

How to Build DeX on the Hub

There are two different kinds of approach regarding DeX on the hub.

  1. Direct implementation on Hub’s module
  • adv1. simple implementation
  • adv2. more direct connection between IBC and DeX utility
  • disadv1. security risk of the hub
  • disadv2. congestion of tx on the hub
  1. A DeX zone providing Hub level security and sidechain scalability with zk-rollup technology
  • adv1. keep the Hub-level-security
  • adv2. theoretically unlimited scalability without congestion of the Hub
  • disadv1. relatively complicated and indirect connection between IBC and DeX usecase
  • disadv2. very difficult to implement zk-rollup application

Why we need to seriously discuss this topic right now

  • Successful DeX on the hub is one of the most important thing regarding the growth of IBC use-case
  • DeX on independent zones will not become a significant usecase of Hub’s IBC utility
  • Considering booming usecases of DeFi and DeX on Ethereum community, we are already late to compete

Co-Existence of DeX on Hub and DeXs on Zones

Although DeX on Hub will generally provide better liquidity and better security, DeXs on Zones can co-exists on their localized domain and specialties. Liquidities on the Hub and on Zones can be borrowed from each other with advanced IBC technologies to form better connected utility of liquidity.

So, those two approaches are not competing each other. They should co-exist with different specialties. What I have argued in above paragraphs are that we should have at least one Hub-level-security DeX to compete with DeXs on other networks. And the DeX should directly benefit Atom holders and directly controlled by Atom holders to maximize the utility of Atom, hence increase the value of the Atom.

Why it should be community driven?

ICF and Tendermint has a regulatory position which advices them Not to directly participate on any financial utilities(Please correct me if I am wrong). So, in order to proceed this topic, only community members can drive the actual movement. Passive attitude to this topic will not bring us anywhere, because of such regulatory status.

It has been very successful journey for us, and now finally we are looking at very near future of real IBC on the Hub. Now is the right time to think about its usecases, and now we cannot run away from usecase discussion anymore. It is time to figure out to actually attract usecases of IBC.

#9

It has been very successful journey for us = are you referring to your validator service?

My posicion is the same anyway. I don’t think is a good idea convert the hub in a DEX.

I don’t see this. More when the hub is still centralized and controlled for a few folks

#10

  1. there is no B-Harvest in this topic, at least yet. Us means our entire cosmos community, especially holders and validators of Atom.

  2. did you also consider the second implementation option? Hub not directly performing DeX application, but providing support to a zone with zk-proof to acquire hub-level-security. zk-proof is so light that it will never congest the hub with txs

#11

Us means our entire cosmos community, especially holders and validators of Atom.

Not sure why you consider this.

After work every day for Cosmos and very hard. Still not see delegations come to my validator or I can said my validator in Cosmos is having successful journey . sorry but not on my side.
Im worried every hour to get out validator set for this bug, where no cares your work to get delegations.

Maybe others validators yes. But Im sure just a few having successful journey

The second part. Cosmos supporting build zones with community founds. Is a governance call. My vote depends of the proposals like always.

1 Like
#12

Hub will barely be able to handle the connections to hundreds of zones out there as GoZ already showcased, DeX or StakingDAO is not going to solve the problem of insufficient revenue for operators, what could solve it lets say “IBC DNS-like registry” or some other “utility” modules, token issuance module, decentralized-development / contracting module etc.

I just wonder, why not make the hub better at what it was supposed to do best rather than add utility that is already being filled by dozen other projects in the ecosystem.

#13

  1. I provided the second implementation option for the sake of scalability issue. zk-rollup can solve scalability issue while keeping the security in layer1 level.

  2. why we have to consider DeX on the hub : because current DeXs on zones do not provide hub-level-security. it does not mean that DeXs on zones are not necessary. It means that we still need a DeX with enough security assumption to attract the main usecase of IBC, trading.

  3. my arguments on this thread is mostly focusing on value of atom and attracting IBC utilities, and building strong business model of the hub. because, i worry that if the hub cannot provide hub-level security DeX in near future, it will not be possible to gain significant IBC usecase for a long time.

#14

MBPoS for zones and shared security can definitely match the hub or provide any standalone chain with security it needs. I think we should then focus on building base security layer and sell that to zones. There will always be dApps that do something better regardless what dApp that is. Hub should have a functionality that no zone designer would want to bother with so that the expirence of building your business is more friendly for the entire ecosystem.

#15

  1. yes. Shared security is one way to partially utilize the hub’s security to a zone. That is why B-Harvest was initiating community discussion about the design perspective of the feature. Unfortunately it attracted little interest, and it is still in vague definition level.

  2. zk-rollup is another way to achieve this with full hub security, without shared security feature which is not moving anywhere at this moment. Also shared security has very limited resource to share the security to zones. zk-rollup on the other hand does not spend such resource if the level of tx amount is bounded well.

  3. atom holders might like to differentiate “any dapp” against “primary hub utilities which need maximal security” which are DeX, Ethpeg and IBC utility. Those dapps should be directly provided by hubs security to have enough competitiveness for global blockchain space. Also, the growth of such dapp should directly align with atom holders’ incentive. Independent zones are not directly incentivize atom holders, hence lack of representativeness of the hub.

  4. permissioned cosmwasm contract and zk-rollup dapps should be allowed by hub’s governance. Holders will decide whether each proposal is validly align with their interests. Selling slots can be another approach like polkadot, but it seems too financially biased solution. I think hub governance with appropriate tx taxation and limitation can be better option.

  5. I agree that friendly approach for entire ecosystem is important. But i think for this topic, atom holder’s value is more important because this is about the immediate primary usecase of IBC and the hub. We should consider it with more broader viewpoint - how the hub can become competent as a IBC utility provider and potentially attract more users. I also feel uncomfortable to argue this discussion, but someone need to raise a question.

  6. in United States alone, there exists a lot of exchanges, s&p, nasdaq, commodities, fixed income, otc, … exchanges co-existing with different utilities. DeX on the hub does not necessarily mean a unique DeX in cosmos ecosystem. Even several DeX can exist on the hub, which is a decision by atom holders. We cannot stop having DeX on the hub because it is unfriendly to some zones. Atom holder’s decision should stand first.

#16

I think that lack of consensus regarding shared security and other changes for the hub is simply a result of impediments of a governance system, which when addressed would allow the hub to boost its ability to pass changes and incentivise development of features it needs most. I strongly believe that a well designed on-chain contracting is the most logical module to go for along improved gov/sub-gov/multicamerial-gov to ensure both incentivisation for all actors and clear responsibility for pushing new features regardless what those features would turned out to be.

For example the discussion you created here or the one regarding shared security, if it was incentivised would result in much better turnout, and if gov worked properly there would already be assigned people to write down initial spec or maybe even push the development with on-chain contracting.

Instead, we are having a discussion that no one is going to act upon, just like with previous one, as there is no responsibility and no clear incentivisation for anyone involved. All this is a result of a deeper issue. What we are doing now is only trying to fix the symptoms of the disease, not the root cause. It will all come back and bite us again over and over again.

#17

  1. I agree that the mechanism to decide which cosmwasm is allowed to be operated on the hub is a great topic to discuss, but it is slightly out of topic for the DeX topic, so I think it deserves another post on the forum.

  2. in shared security case, B-Harvest has a 50% willingness to actually drive the designing and implementation act. We decided to stall it because of lack of community’s response. But it is not only B-Harvest that can jump into implementation. Discussions here is not illusional. Proper incentives can be given by any participant so that community can decide. Don’t be too pessimistic :slight_smile: