[PROPOSAL #38][ACCEPTED] Proposal to Adopt the Liquidity Module onto the Cosmos Hub

• Moderator edit to add link to on-chain proposal: Mintscan Hi Cosmonauts! This document is the draft signal proposal to adopt the Liquidity Module(DeX) onto the Cosmos Hub. Please share the valuable thoughts and suggestions about the Liquidity Module! The proposal will be submitted to the Cosmos Hub after two weeks(25th Feb) from today. Thank you! Proposal to Adopt the Liquidity Module onto the Cosmos Hub Summary: Tendermint ( https://tendermint.com ) and B-Harvest ( https://bharvest.io ) have joined forces to produce and develop a Liquidity Module ( GitHub - tendermint/liquidity: Cosmos SDK Liquidity module ). This signal proposal is a Request For Comment to the ATOM community regarding the addition of this Liquidity Module into the Cosmos Hub source code. By voting YES to this proposal, you will signal that you approve of having a DEX based on this specific Liquidity Module deployed on the Cosmos Hub. 2020: The Year of DeFi For the crypto community, 2020 has been the year of DeFi. Websites like DeFi Pulse have recorded a transition from centralized, custodial exchanges onto DEXs like Uniswap . In September of last year, trading volume on Uniswap surpassed…

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

I’m very excited to the liquidity module come to life as fulfillment of part of the ATOM2021 vision.

cosmosdevs/atom2021

Repo for the ATOM 2021 Intiative. Contribute to cosmosdevs/atom2021 development by creating an account on GitHub.

There will be many DEXes in the Cosmos but permissionless price discovery is a core function of the Interchain and the HUB must play a role.

Thank you for sharing your support @zaki_iqlusion !

Yes, there will be many trading platforms in Cosmos and also in other blockchain networks. Each will have its own advantages to attract different kinds of trading/investment demands.

B-Harvest has a bigger vision for the Liquidity Module to connect all liquidity from such different blockchains and trading platforms, aka “ibc connected liquidity module”.

Cosmos Hub can become the center of trading environment which connects many DeXs in the interchain world.

This Liquidity Module is only the very first step towards greater utilities for interchain users.

Thanks Hyung this is awesome! Amazing work. Very clear proposal and light paper. Is there a more formal analysis of Equivalent Swap Price model somewhere or is this the first place it’s introduced? Maybe more specifically, what are the consequences of path dependence for pool reserves (the linked Vitalik post suggests it could be dangerous, but I haven’t thought it through). Would it also be possible to link to more details on the simulation tests and the agent based models, or at least a short description of the work and who’s doing it if the details are forthcoming in a report (seems the report is due towards the end of the voting period for this proposal)? We’re also going to want to keep a close eye on how the yields here compete with staking. We should probably land the update to the “inflation rate change” param before the AMM goes live at least to make the inflation more responsive to changes in stake, and may need to think a bit more about how AMM and staking parameters will intersect. There may be a need for a more advanced inflation rate controller (eg. PID?) or maybe there are ways for the AMM itself to balance fees distribution between LPs and staked atom or…

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

Thank you @ebuchman for great questions!!! Let me briefly answer your questions. • Thank you again for asking about one of the most important aspect of Liquidity Module matching engine! Yes, we are very aware of the path-dependency topic Vitalik raised several years ago. Let me describe some important aspects of this topic as below • Path independency guarantee pool investors that when the pool price changes and come back to original price, the pool investor will have exactly same reserve asset portfolio, except for fee returns. Therefore, attackers cannot fool around the pool investors by moving the price. Whereever the price goes, as long as the price comes back to “unmanipulated” price, which is the global price, (because of arbitrageurs) pool investors will end up with the original portfolio plus fee earned. • Path dependency means that, the portfolio can change even though the price comes back to original price. The portfolio is dependent to the path of the price. Vitalik explains that this will open attack vector by manipulating pool price. • But, this risk is only bounded to a situation only if there exists any chance that the any one token in the portfolio…

Excerpt (1198 of 5054 characters). Read the whole post on the forum ↗

Thanks very much for the details Hyung!

I understand that in practice Uniswap is path dependent because of the fees, but it seems straight forward to reason about how that’s in favour of the LPs (“monotonic increasing” as you say). However it’s less clear to me how to conclude that the ESPMM (before fees) is also monotonic increasing. Is there an argument for that somewhere I can follow? I will look at the slides you linked.

Otherwise I think the design you have here of marrying the AMM with an Order Book is really interesting, and adjusting the AMM design to facilitate order book execution so that we can have the best of both worlds is very clever!

Let me clarify by providing mathematical proof on “monotonic increasing” as follows: • Assumption • No limit order participates in this process • There is no fee for swaps • Process • Let the pool has two reserve tokens, A and B • Amount of token A,B in reserve is NA,NB respectively • An attacker buy B token by sending in n amount of A token • If all n amount of A token is swapped, then the best swap price he/she can get is (NA+2*n)/NB from ESPM • Hence, the received amount of B token for attacker is NB*(n/(NA+2*n)) • In CPMM, the received amount of B token would be NB*(n/(NA+n)) • If you compare those two, you can see that the attacker “always” gets less B token from the swap, compared to CPMM • Opposite direction swap process can be described vice versa • Conclusion • Therefore, ESPM guarantees to pool investors that in any price path, they pay less B token than CPMM to swap requestors • Because CPMM is path independent, ESPM is monotonically increasing • Fun Fact • If attacker want buy B token from A token, (because it is cheaper than global price) , by splitting swap orders (n) to epsilon amount, submit each order per batch, then,…

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

Ah thanks for explaining that should have been clear. The price for a buy is always higher in ESPM than CPMM. So can it just be modelled as an extra fee? ie. of n/NB ? That might also clarify where the larger slippage cost comes from.

You CAN see that as an extra fee, but it is not what I intended. As the slide shows, the derivation came from SwapPrice=(postswap)PoolPrice. Very natural equation for any matching system.

Extra fee(twice slippage cost) is just a consequence of such natural reasoning. So ESPM is not just one model with extra fee. It is the only model where swapprice equals poolprice.

Another way to see CPMM is to model it as swapprice = (lastpoolprice+thispoolprice)/2
Swapprice defined as midpoint of last and this pool price. ← this is how I see CPMM. From this, I can intuitively see why it is path independent.

These series of talks should be very interesting, because I also was during design works. Great chance to understand AMM mechanism better.

I want to raise an important question towards our Cosmos Hub community. Do we want to “Limit” the amount invested in Liquidity Pool, until we have enough confidence to remove the limit? Although we have enough confidence on our implementation quality cross-checked by various testing procedures, for this important network, it is healthy to have as conservative approach as possible upon launching new features on our network. B-Harvest thinks users’ safety as the first value for any utility developed from us, so we think this limit feature is necessary at the early stage of adoption on Cosmos Hub. This is how the “Limit” feature can be implemented on Liquidity Module. • Each liquidity pool will have the same limit of reserve token amount as “LiquidityPoolLimitAmount”. • All deposit transaction which makes a pool having more reserve token than “LiquidityPoolLimitAmount” will be failed. • Other transactions such as swap or withdraw will be functioning as normal. • When we have enough confidence on robustness of Liquidity Module, we can have a parameter governance to increase “LiquidityPoolLimitAmount” to much greater value, or modify the value to “-1” so that there exists…

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

What if atom will cost $1000 ? It will take $100,000 to create a pool?

Thanks for raising the question.
Because the value of Atom has increased over recent months, we would like to suggest lower initial amount for creating new pool.

100ATOM → 40ATOM

It is about $1,000 with $25 Atom price.
As you suggested, higher Atom price will result in more expensive cost for creating new pool.

If we remove this fee, the module will open a spamming attack vector to create thousands of pools, which might delay the performance of the network. So, I think some level of new pool creation fee for preventing spam attack is necessary.

Thank you Hyung for this great proposal.

Would the cost for creating a pool adapt to the price of ATOM, or would it be set at release and only be able to change through governance?

Cant wait for this proposal to be love on the 25th!

Only be able to change via governance. It can be upgraded in the future to have fixed dollar amount by using the biggest atom pool with stable coin as oracle. Currently, dex is not launched yet, so we can’t apply that yet.

Thank you for your question!

In the bull-case for ATOM and the hub, there are surely thousands of pools.

As the number of pools increases, how much does resource consumption / computational load increase when using the liquidity module?

Currently there are just over 30,000 pairs on Uniswap, and it’s probably not grown to its full potential.

How many pairs/pools is too many?

Should we make the cost to open a pool itself a bonding curve based thing ? And will there be a way to close out a pool ?

As for pool limits, in general I’m in favour of such conservativism to start, but I wonder how effective it can be, since folks can always redenominate their tokens on a zone so that each unit is 10x or more the original unit. Eg. if there’s a limit of 1M, I can send my ATOMs to a zone that will let me make a new token where each token is 10ATOM or 42ATOM or whatever, and then start a new pool with that token as the reserve, effectively upping the limit. Of course people would need to be aware of this so that they’d trade on that pool and thus they’d know we’re skirting the limit.

In any case, I’d say an initial limit that can be progressively increased is a good idea.

The computation burden actually is not dependent on the number of pools, but on the number of “alive batches” at certain height.

Pools without any order will not create a batch, hence no computation engaged.

So the computation burden is dependent to number of orders and alive batches within a block.

Our performance test suggest that 1k orders in a block results in 0.3second block time delay. But this delay is similar with sending txs simulation. We have to test multi-batch scenarios though.

In the super bull case when we see thousands of orders in a block quite often, we might want to have a flat order fee so that we can discourage low amount orders. But I think we are quite far from that

Also we have plan to compute each batch in parallel computing, hence increasing number of cores for fullnodes and validator nodes will horizontally expand our capacity to handle the orders.

Also in further plan,b-harvest will develop zkrollup supported dex zone, which will allow gravity dex to move to a zone secured by the hub via zkrollup. This is also quite far away roadmap(2023)

Yes. There exists many open risks, but still the limit relatively reduce the risk of systemic failure significantly. The limit will only last for several weeks, so the simplest one can do its job enough

Thanks for the detailed reply!

I am also curious about your thoughts re: state growth on Gaia-- I guess it’s fair to say that I prefer a high-fee world, where Gaia grows more slowly with respect to storage capacity… and even in a high fee world, we are still likely much more affordable than Uniswap is these days, for example.

TBH, I made a song / propaganda video about it:

Blurt Propaganda Jam Session #001 — Blurt

I was singing to my son and then he and I started singing and then I checked the sync process on my tiny little pi. And it's done It's fully synced and it can probably easily be used as a witness… by jacobgadikian

Only alive&unexecuted orders are stored in the state. If so many orders are unexecuted and accumulated in orderbook, it is a great burden to the state indeed.

We might want to adopt MaxOrderLife parameter so that any order cannot stay alive more than this number of height(orders alive more than this period are immediately cancelled)

Hi, when the proposal will be submitted?

I’m about this. All I really need is someone or something to inform me when the vote is done (or how I actually cast a vote myself) and how I take my ATOM and make a liquidity pool with it; ATOM is the primary coin I believe has legit long term (1-3 years) benefits for investing.

It was planned at 25th, but it is delayed to 1st March. Please stay tuned and ready to vote!

What does “ready to vote” mean? How does one vote?

I love this idea! Hope you update us once it launches!