Discussion on Gravity DeX Model

Miscellaneous
1

This forum post is to extend the discussion around the characteristics of Gravity DeX Model.

Lite paper : liquidity/LiquidityModuleLightPaper_EN.pdf at develop · tendermint/liquidity · GitHub

In short, it has three main unique characteristics compared to other existing DeXs.

  1. it combines AMM(liquidity pool model) with orderbook system
  2. it does not use CPMM(Constant Product Market Maker), but ESPM(Equivalent Swap Price Model)
  3. it does not handle orders in serial manner, but in batched auction manner

We hope to continue the discussion about the consequences of these unique characteristics, and explore possible improvement of the model.

Argument : ESPM with Batched Execution significantly increase profitability of pool investors by reducing value extraction by arbitrageurs and dishonest validators

  • Reasoning
    • Batch execution results in swap price competition among arbitrageurs because it does not prioritize orders by transaction sorting in a block (every order in a batch treated equally)
    • Arbitrage orders with more competitive order price will have better chance to be executed
    • This order price competition among arbitrageurs will result in swap price which is very close to the global price (less profit chance to arbitrageurs)
    • Unlike CPMM, ESPM allows pool investors to accumulate additional profit from price volatility because it is not path independent.
  • Path Independency vs Path Dependency
    • Assumptions
      • There exists no censorship of order transactions
      • There exists some order price competition among arbitrageurs
      • no cost on swaps(gas fee, swap fee)
    • CPMM
      • Swap Price = (X+dX)/Y or X/(Y+dY)
      • Reserve : X=100, Y=1
      • If external price moves 100 → 102 → 100
      • Arb swap amount : 1X and 0.01Y
      • Swap price : 101 and 100.99
      • Result
        • Arb profit : (102 - 101)*1/102 + (100.99-100)*0.01 = 0.0098 + 0.0099 = 0.0197X
        • Pool investor profit : 0 (path independency)
    • ESPM with Batch Process
      • Swap Price = (X+2dX)/Y or X/(Y+2dY)
      • Reserve : X=100, Y=1
      • If external price moves 100 → 102 → 100
      • Arb compete each other with order price to get the profit
        • Assume that the competition results in swap price with 0.5% price difference against external price
      • Arb swap amount : 0.745X and 0.00745Y
      • Swap price : 101.49 and 100
      • Result
        • Arb profit : (102-101.49)*0.745/102 + (100-100)*0.00745 = 0.003725X
        • Pool investor profit
          • X → 100+0.745-0.00745*100 = 100
          • Y → 1-0.745/101.49+0.00745 = 1.0001
    • Comparison
      • Arbitrageurs in our model get less profit from price moves because of arb competition and ESPM
      • Pool investors in our model get extra profit from price moves

Challenging Assumptions

  • Transaction censorship will occur

    • When there exists arbitrage opportunity, the block proposer can remove other transactions and include only his/her arbitrage order transaction to avoid competition with other arbitrageurs
    • The block proposer can earn arbitrage profit without any order price competition
    • If the price difference is d% between pool price and external price, then the optimized order amount is d/4% of pool size
    • The expected profit of the block proposer is roughly half of what can be achieved in CPMM

  • Longer batch period will not prevent the problem

    • Assume 20% of validators are dishonest
    • Assume one batch is composed of 5 blocks
    • Only the last blocks of each batch is at manipulation risk
    • Out of 100 blocks, dishonest validators can perform uncompeted arbitrage 4 times
    • Compared to 20 times with 1 block batch assumption, the risk is reduced to 1/5

  • Path dependency is risky ?

    • Unlike CPMM, ESPM is path dependent
    • (reserves of ESPM - reserve of CPMM) is monotonically increasing for any price path
    • Therefore ESPM pool is always safer than CPMM pool
    • Hence, ESPM does not open risk exposure by path dependency, but it always accumulates more reserves than CPMM

  • Forecasting the Effectiveness of ESPM with Batch Process

    • Assume 20% of validators are doing this strategy (dishonest)
    • For the blocks with honest validators, we assume fairly good competition among arbitrageurs, result in 80% of arbitrageur profit in CPMM can be accumulated in pools
    • 20%*50% + 80%*80% = 74% of arbitrageur profit in CPMM can be accumulated in pools in ESPM

  • Arbitrageurs profit and MEV(Miner Extractable Value) is practically not very big

    • If it is true, the advantages of ESPM and batch process is not significant
    • Is it really not significant? We need statistical analysis on Uniswap

Other Efforts

  • To minimize dishonest validators
    • We can monitor and compare mempools in public nodes and committed blocks to statistically observe possible censorship from certain validators
    • It will not give us hard evidence of censorship, but it can give us good hint about the issue
  • Improve consensus algorithm
    • Leaderless consensus : there exists no single block proposer
    • Additional transaction included in the block from non-block-proposers
    • Threshold encryption : hide contents of transactions to prevent selective censorship
    • Do we need to improve consensus only for DeX in Cosmos Hub ?
      • DeX Zone is more proper to pursue this kind of goal ?

Disadvantages

  • More slippage cost to ordinary traders

    • Traders pay exactly twice more slippage cost than CPMM
    • Cost of swap
      • Gas Fee : fixed amount
      • Swap Fee : 0.3% of order amount
      • Slippage Cost
        • CPMM : orderAmount*(orderAmount / poolSize)
        • ESPM : 2orderAmount(orderAmount / poolSize)
    • When orderAmount/poolSize is small, slippage cost is negligible
      • if it is 0.01% then the slippage cost is 0.02% of order amount (0.01%p larger than CPMM)
      • if it is 0.1% then the slippage cost is 0.2% of order amount (0.1%p larger than CPMM)
    • When orderAmount/poolSize is big,
      • the trader is a whale
      • the trader is an arbitrageur
      • pool is too small

  • And more?

2 Likes
2

So this is maybe not about the gravity dex model but it’s going to affect the gravity dex a great deal, specifically, these AMMs are going to interact.

Also, it is likely that cosmwasm contracts will be written that span the whole network, and that is without getting into the kinds of automated systems that I figure will crop up for trading that live external to any one chain and interact with many chains.

Then, we have the question of onramps and offramps.

I think it’s likely that blockchains will choose to issue assets and then offer them on the hub and other dexes.

1 Like
3

Next phase of gravityDeX is to link liquidities from different networks. Just like orderbook sharing among CeXs, but more elegant and decentralized way, by utilizing ibc infrastructure. This is our roadmap in 2022. Cosmos Hub should lead this expansion of liquidity connectivity, to become the center of interchain liquidity environment.

It will differ ibc with other pegging technologies. IBC allows us to build connection of blockchains with multiple dimension, not bounded by one dimensional token transfer

1 Like
4

Strongly agree that liquidity can be shared over IBC.

Worked on this last year.

1 Like
5

it provides some problem definition, but practically this approach is not very useful.
limit order should not be directed to particular chain or liquidity pool.
the module should search best available pool to be executed and deliver it to the user.
like a search engine for liquidity.
i think the service should be provided from the Cosmos Hub.
the liquidity search service can find liquidity from interchain liquidities for the user and bring the execution.

this definition of IBC-Liquidity brings a lot of obstacles, but very exciting challenge.