DeX on the Hub discussion

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 • more activities and growths directly on the hub • potential value added to ATOM • benefit zones around cosmos ecosystem by providing DeX utility on the hub DeX on zones • they does not directly benefit ATOM value • they have less representativeness and much less staked security What prevents DeX on the Hub • 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 • regulatory constraints on AiB and ICF • they cannot fund DeX projects • community fund is an alternative approach Market potential • DeX is very competitive market • it might be difficult to bring significant use-case considering current competition • 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…

Excerpt (1197 of 1921 characters). Read the whole post on the forum ↗

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.

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?

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.

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.

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.

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.

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…

Excerpt (1199 of 4568 characters). Read the whole post on the forum ↗

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

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

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.

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.

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.

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.

• 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. • 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. • 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. • permissioned cosmwasm contract and zk-rollup dapps should be allowed by hub’s governance. Holders will decide whether each…

Excerpt (1191 of 2301 characters). Read the whole post on the forum ↗

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…

Excerpt (1196 of 1245 characters). Read the whole post on the forum ↗

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