Introducing the new pDEX

Let’s start the topic with problems of the current pDEX and its sibling - Provide.

With the current pDEX:

  • No trading fees are collected, the pDEX cannot operate itself, and the core team has to subsidize the high APY(s) to incentivize people to provide liquidity for pDEX.

  • The current Automated market makers curve is inefficient resulting in high slippage (or requires huge liquidity to reduce the slippage)

  • It doesn’t allow placing a limit order but instead, it requires users to observe the market actively for a desired price.

With Provide, besides obvious pros such as providing liquidity frictionlessly with no impermanent loss, it also has the following problems:

  • Centralized, a system that has any centralized elements always carries risk.

  • Unsustainable - economically risky for operators (the core team) in case people massively sell PRV to take assets out of the network.

  • Limited options for liquidity providers with PRV rewards. Currently, PRV holders can only stake to become a network validator or cash out.

For these reasons, the pDEX protocol has been re-designed with the focus on the following improvements: 1) Capital Efficiency with multiplied pricing curve setups. 2) Trading Experience with a hybrid of order-book and automated market-making (AMM) for slippage reduction. 3) Liquidity Mining with competitive rewards for liquidity providers (LPs) on multiple liquidity mining programs.

Improvement details

The AMM has recently gained extreme adoption mainly because of liquidity mining’s notable growth. However, there is still room for further improvements. In this section, we will go through every improvement in detail to see what benefits the protocol offers as well as how it works.

Capital efficiency

Inherent problems

Automated market makers (AMMs) are agents that pool liquidity and make it available to traders. Constant function market makers (CFMMs) as they are implemented today are often capital inefficient. In the constant product market maker formula used by the current pDEX, only a fraction of the assets in the pool are available at a given price. This is inefficient, particularly when assets are expected to trade close to a particular price at all times.

Specifically, liquidity was distributed uniformly along the 𝑥 · 𝑦 = 𝑘 reserves curve, where 𝑥 and 𝑦 are the respective reserves of two assets X and Y, and 𝑘 is a constant. In other words, it was designed to provide liquidity across the entire price range (0, ∞). This is simple to implement and allows liquidity to be efficiently aggregated, but it also means that much of the assets held in a pool are never touched.

Concentrated liquidity

Having considered this, it seems reasonable to allow LPs to concentrate their liquidity to smaller price ranges than (0, ∞). A pool only needs to maintain enough reserves to support trading within its range, and therefore can act like a constant product pool with larger reserves (we call these the virtual reserves) within that range.

There were a few approaches trying to solve the problem, one of them is allowing LPs to have more control over the price ranges in which their capital is used. Unfortunately, this approach requires LPs to be more active to update their positions over time if they don’t want their liquidity to be inactive and no longer earn fees, especially in volatile markets. This also increases the friction of liquidity provision.

We present a simpler approach called multiplied pricing curves that still tries to improve capital efficiency but make it as easily understandable as possible. The curves are still a constant product but of virtual reserves instead of real reserves. Thanks to the virtual reserves, which are significantly multiplied from real reserves, the multiplied pools can achieve better slippage rates as compared to the previous version given the same capital.


An illustration of the original and multiplied AMM curves

Given 𝑥0 and 𝑦0 to be the liquidity providers’ initial contributions to the pool, such that 𝑥0 · 𝑦0 = 𝑘. This is the familiar simple constant-product function.

We now introduce what is known as the multiplication param a and a > 1. As its name suggests, it multiplies the real reserves into virtual reserves. Hence, we can define virtual reserves 𝑥'0 and 𝑦'0, where 𝑥'0 = 𝑥0 ⋅ a and 𝑦'0 = 𝑦0 ⋅ a.

The pool with a multiplied pricing curve will maintain a constant product of these virtual reserves by using the new inventory function:

𝑥’ · 𝑦’ = 𝑘’

So the constant 𝑘’ can be easily derived from the 𝑘 as 𝑘' = 𝑘 · a · a

We see that users will benefit from lower slippage when the pools use the new pricing curve. However, this comes at the expense of the price range no longer being unbounded, but being restricted between a fixed price range (Pmin, Pmax).

Mathematically, the price range (min & max price) can be computed as follows:
image
Where P0 = 𝑦0 / 𝑥0 and P is the price of X against Y.

For example, suppose a pool with multiplication param = 2, where the virtual reserves double the real reserves in the original constant-product formula. The price range support for this is from 0.25x to 4x the initial price set. Should this price range be exceeded, it would result in the pool being depleted of one of the tokens.

Adding/Removing liquidity

Anyone can become a liquidity provider (LP) by depositing an equivalent value of each underlying token. The protocol tracks pro-rata LPs’ shares of the total reserves, and can be redeemed for the underlying assets at any time. Adding and removing liquidity are pretty similar to what LPs have done in the previous pDEX.

For each token pair, there are possibly many multiple pools with different configurations (a.k.a multiplication param) for the pricing curve and the param are chosen by pool creators based on stability of price between the pairs - the higher the stability of prices between the pairs, the higher the multiplication can be. We categorize token pairs into 3 main types:

  • Similar asset pairs such as stable coin pairs (USDC/USDT, USDT/DAI, etc) and similar token pairs (Ethereum’s ETH / BSC’s ETH), we will be able to leverage multiplication params of well about high. For example, with a multiplication of 100, a pool of 1M Ethereum’s ETH and 1M BSC’s ETH will be able to achieve a slippage equal to a previous pDEX’s pool of 100M Ethereum’s ETH and 100M BSC’s ETH, essentially achieving a capital efficiency gain of about 100X. With that multiplication, the price ratio between the pair can fluctuate around [0.98 - 1.02] of the initial price ratio. In this case, Incognito users will especially benefit from the low slippage while swapping their Ethereum’s tokens to BSC’s tokens to achieve a cheap unshielding fee via the Incognito - BSC bridge.

  • Correlated asset pairs such as major token pairs (BTC/ETH) where price movements tend to be correlated. It is unlikely to be optimal to create an aggressive multiplication param here, given the high risk of the resulting pool being inactive.

  • Uncorrelated asset pairs such as most token pairs, whose value have no correlation to common quote tokens, such as ETH or USDC. Multiplication is not suitable for these token pairs due to significant price volatility. We expect no improvement in capital efficiency for token pairs of this nature.

Trading Experience

Inherent problems

In the previous version, the pDEX users suffer a bad rate for a big trade (say trade token A for token B) taking place in a small pool since such trade depends solely on liquidity added to the pool. Similarly, another big trade (say trade token B for token A) has the issue as well. In this situation, it’s a pity if pDEX loses those users only because of a lack of liquidity from the AMM pool although there is demand for trading on the pair.

Additionally, from the user experience perspective, users do definitely have a demand of placing limit orders on desired prices. Especially, in an AMM exchange, the demand would be even larger due to its high slippage nature (so does high spread).

A hybrid approach

So it seems like a hybrid approach of order-book and AMM will be a rescue for both issues above because: 1) slippage reduction by aggregating both the investing capital (a.k.a the multiplied liquidity) of LPs and the trading capital of traders, this also helps reduce the dependency of AMM liquidity where trades will still be possible even in the case lacking liquidity provided by LPs. 2) a familiar trading experience (e.g. placing limit orders) just like what a traditional exchange did.

Looking into the following example to see how a trade works in the hybrid approach:

Suppose we have a pool of ETH/USDT with an AMM pool size of 50 ETH + 100,000 USDT (multiplication param = 2) so the virtual pool size is 100 ETH + 200,000 and the rate is 2000 USDT/ETH.

An order-book with existing limit orders placed by users as follows:

Sell orders
rate (quantity in ETH)
2011 (2)
2019 (1.5)
2025 (4.2)
2034 (3.7)

Buy orders
rate (quantity in ETH)
1998 (0.4)
1956 (3.8)
1912 (2.2)

When a user makes a swap of 2.5 ETH for USDT, it will be executed by:

  • Swap 0.05 ETH for 99.95 USDT with AMM pool, the rate changes from 2000 to 1998.
  • Then match 0.4 ETH for 799.2 USDT at the rate of 1998 with the 1st order in the Buy orders list (the 1st order is filled 100%)
  • Then swap 1.06849 ETH for 2,112 USDT with AMM pool, the rate changes from 1998 to 1956.
  • Then match 0.98151 ETH left for 1,919.83 USDT at the rate of 1956 with the 2nd order in the Buy orders list (the 2nd order is partially filled)

After completing the swaps above, the virtual AMM pool will have 101.11849 ETH + 197,788.05 USDT with a rate of 1956 and the order-book should look like:

Sell orders
rate (quantity in ETH)
2011 (2)
2019 (1.5)
2025 (4.2)
2034 (3.7)

Buy orders
rate (quantity in ETH)
1956 (2.81849)
1912 (2.2)

So the user will get 4,930.98 USDT from the swap of 2.5 ETH at the rate of 1972.39. If it’s solely swapped with the AMM pool, the user will only get 4,878 USDT. Apparently, the hybrid approach of Multiplied Automated Market Making and Order-Book will help significantly reduce the slippage.

Routing trade engine

In the new pDEX, it no longer requires LPs to create a PRV pool (e.g. PRV/BTC, PRV/ETH, etc) so the old-style cross pool trading via PRV won’t be applicable for any trade. For this reason, it led to a requirement of searching for a reasonable (in terms of price) route over multiple pools to perform a trade. Basically, the engine will query multiple paths a token takes to exchange into another, consider rate in a graph topology to generate a good price for a trade.

This will be done off-chain, and the protocol will accept a route (up to 5 pools) to perform a trade on-chain.

Liquidity Mining

Inherent problems

This section is probably a part that investors wanted to know most, especially when there were some rumors around the future of Provide. Even when having extra liquidity from limit orders, LPs still play a crucial role in pDEX so we still need a better or at least equivalent alternative of Provide in terms of APR, but it’s difficult to achieve this if reward solely comes from trading fees.

PDEX token

We’re introducing a dedicated mining token for pDEX called PDEX. Its tokenomic would look like:

  • Hard cap of 50M tokens.
  • Premine: 5M tokens, mainly for market making for PDEX/PRV pair that will help maintain a desired APR for pools.
  • These tokens are minted every block to LPs providing liquidity to eligible pools in 5 years by a decay function (a.k.a the sooner an LP provides liquidity to a pool, the larger PDEX amount he/she can earn).
  • Each pool may have a different PDEX distribution percentage and the percentage may be adjusted.
  • The core team will do market making for PDEX tokens by creating a pool of 5M PDEX + 294,117 PRV so that LPs can earn an extra reward along with trading fees.
  • PDEX holders can also participate in voting to adjust pDEX’s key parameters that will be mentioned in the next section.

The following table shows information of top 6 pairs having the most liquidity in pDEX (at time of the writing)

Supported pair Current Liquidity Trade volume APY
PRV/BTC $4,500,000.00 $36,000,000.00 10%
PRV/ETH $750,000.00 $31,500,000.00 10%
PRV/USDT $1,500,000.00 $55,000,000.00 10%
PRV/DAI $600,000.00 $34,000,000.00 13%
PRV/USDC $750,000.00 $22,500,000.00 8%
PRV/XMR $1,500,000.00 $31,500,000.00 13%
$9,600,000.00 $210,500,000.00

With a pool of 5M PDEX + 294,117 PRV (where 1PRV ~ $1.7 and 1PDEX ~ $0.1) and PDEX distribution percentage for each pool as below, the APY that LPs may earn will be:

Supported pair Liquidity PDEX token distribution APY from PDEX distribution
PRV/BTC $4,500,000.00 30.00% 6.08%
PRV/ETH $750,000.00 10.00% 12.17%
PRV/USDT $1,500,000.00 20.00% 12.17%
PRV/DAI $600,000.00 10.00% 15.21%
PRV/USDC $750,000.00 10.00% 12.17%
PRV/XMR $1,500,000.00 20.00% 12.17%
9,600,000.00

Staking pool for PDEX token

The mining PDEX token may help address centralization problem of Provide but the core team still needs to subsidize more PRV monthly (~38,363 PRV if PRV price ~ $1.7) in order to remain PDEX price around $0.1 (so do pools’ APYs) when LPs tend to sell PDEX immediately.

In order to encourage LPs to hold PDEX, we’re introducing a staking pool program for PDEX. Stakers may earn a portion of the trading fees when they stake their PDEX to the pool. In other words, LPs won’t earn 100% of trading fees if they don’t stake and we believe the fees collected from trades will increase significantly by aforementioned capital efficiency and trading experience. This program does likely stimulate people to buy PDEX since they may earn trading fees right away without requiring to provide liquidity.

Hope that, in the end, by combining rewards from trading fees, PDEX mining, and staking programs, the pDEX no longer needs subsidization from the core team and will be able to operate itself automatically.

Parameters

As mentioned earlier, there are a few key parameters that PDEX holders can vote on:

  • Min trading fee (initial value: 0.01%). The fee is paid by the selling token or PRV (with a discount of 25% if the selling token has been pairing with PRV)
  • Proportional of trading fee extracted for PDEX staking pool (initial value: 10%)
  • PDEX distribution percentages for pools

In the beginning, we can do this manually. It means the community can vote on a proposal submitted by anyone at off-chain, the core team will update the agreed parameters to the chain. We will figure out a more decentralized way for this later.

Closing thoughts

The new pDEX will be the next big update after the Privacy v2 protocol. If Privacy v2 helps increase the privacy level of the whole network generally then the new pDEX will help increase the usage particularly. Both traders and LPs will benefit from the update: LPs can earn more with less capital in a decentralized manner, traders can have a better trading experience with limit orders and lower spread and slippage.

ETA for the new pDEX is a maximum of 2 months from now. We’ve actually started working on this for a few weeks but are still open to feedback from you, please share your thoughts so that we can make it even better. Thanks.

P.S. You can find the new pDEX’s initial UI design here.

23 Likes

The forum is very bad at displaying math formulas, sorry for the ugly appearance, but hope you will like the content instead.

5 Likes

My initial feedback is that this requires a really good UI/UX containing every trade details (mult. param, limit orders etc.) so that a trader (taker) can confirm/envision his/her trade result manually too. Thanks for your efforts.

5 Likes

The webpage is not loading for me.

You mean 𝑥0, right?

1 Like

Hey @J053, thanks for pointing those out, fixed. I also updated the link for AMM explanation (to be honest, that post inspired us to consider an idea of combining AMM and order-book)

4 Likes

Hey @duc,

I have a question for this part. Can the path be hybrid? For example, let’s have two pools for eth/usdt and their multiplication params are 1 (pool1) and 2 (pool2). If the limit orders didn’t exist, ofc the path would be pool2 while selling eth. What if the limit orders of pool1 are better than pool2? In such cases, can the engine select pool2 for amm trading and pool1 for matching limit orders?

And my second question on this:

Here I understand the user (rpc or app user) will be able to select those 5 pools. Am I right?

Thanks.

2 Likes

Hi @abduraman, thanks for your very good questions.

Any client (app, bot, etc) can specify path for a trade. Yes, it’s max of 5 (or another limited number) pools to eliminate overhead for the Incognito nodes.

The protocol has to use both matching limit orders and amm trading on the same pool before moving to another pool in a path because the price of a pair on a pool is determined by amm pool’s rate. Also, we don’t expect there will be such defragment situation when at the end of the day, LPs do likely move funds to a reasonable multiplied pool to avoid pool inactive risk and users do likely trade or place limit orders to a good pool with lower spread and slippage. Otherwise, if this happens, it would be an opportunity for arbitrageurs (neither LPs nor “real” users) to take some advantage.

3 Likes

I’ll upload the UI we designed for the new pDEX to the topic soon, it’s not perfect for sure, so feedbacks from the community will be too valuable for us to make it better. Thanks again.

5 Likes

As promised, I uploaded the new pDEX’s UI design here, thanks.

4 Likes

Looks great

1 Like

Hey @duc,

I have some more questions.

How will this run for the multipool paths? For example, someone will buy ETH for BTC using BTC-PRV and PRV-ETH pools. So will the user pay the fee with 25% discount for both pools or just BTC-PRV trade? I’m asking since you have used “selling token” in the explanation. According to it, it seems that the discount will exist on just BTC-PRV side.

One more thing about Parameters that can be voted. I think the multiplication param should also be voted. Since multiplication param is to fix liquidity depth problem, as the liquidity changes, the multiplication param may have to change. So it should be dynamic. Otherwise, in such cases, first the pool should be emptied and then a new pool should be created. If the dynamic multiplication param scheme is applied, to prevent the liquidity providers to manipulate the other pools, I think PDEX holders of “only” liquidity providers of the corresponding pool should be able to vote for changing the multiplication param.

1 Like

I don’t get the need of another token. What can PDEX do that can’t be done with PRV?

How will this run for the multipool paths? For example, someone will buy ETH for BTC using BTC-PRV and PRV-ETH pools. So will the user pay the fee with 25% discount for both pools or just BTC-PRV trade? I’m asking since you have used “selling token” in the explanation. According to it, it seems that the discount will exist on just BTC-PRV side.

I guess we can make it simple like this: if the trader selling BTC, he can pay X coins in BTC or 75% of X coins in PRV as trading fee. The fee then will be distributed evenly to pools of trading path (in your example, 50% of the fee will be paid for BTC-PRV pool and the other 50% will be paid for PRV-ETH pool regardless it’s in PRV or BTC)

One more thing about Parameters that can be voted. I think the multiplication param should also be voted. Since multiplication param is to fix liquidity depth problem, as the liquidity changes, the multiplication param may have to change. So it should be dynamic. Otherwise, in such cases, first the pool should be emptied and then a new pool should be created. If the dynamic multiplication param scheme is applied, to prevent the liquidity providers to manipulate the other pools, I think PDEX holders of “only” liquidity providers of the corresponding pool should be able to vote for changing the multiplication param.

Multiplication param can’t be changed since this will make the current rate of a pool change too. The rate of a pool should not be changed by any actions but trades. Also, a pair may have multiple pools with different multiplication params. Anyone can create pools with desired multiplication params as they want, LPs and traders will decide with which pools they want to interact. (Please have a look at the “Adding/Removing liquidity” section in the topic for more details)

2 Likes

PRV is the native token of Incognito, it is used as fuel for any events in the network (e.g. paying fees for transfers, swaps, unshields or staking to become a validator) and it did have a fixed tokenomics since the network’s inception. And pDEX is an application in Incognito network, probably we will have more applications in the future so we should not change PRV’s tokenomics to cater a specific application because we don’t know whether we will change it again for the other applications.

Also, liquidity mining is a big part of yield in DeFi projects nowadays (besides trading fees), we can’t dismiss it as a way to attract LPs to invest capital to pDEX. So with PDEX token, we can achieve both goals: still have a liquidity mining program and don’t need to change PRV’s tokenomics. Of course, we also need some methods to make PDEX have utility (so value) to contribute to total APY for LPs.

3 Likes

I like this. As I remember, Uniswap-style AMMs cut more fees as the path becomes longer since each pool cut its own trading fee. In our case, the fee won’t be affected by the length of the trade path. Right?

OK but this may cause deconcentration of the liquidity. Anyway, we will see what will happen after the new pDEX is effective.

Exactly!

OK but this may cause deconcentration of the liquidity. Anyway, we will see what will happen after the new pDEX is effective.

Yes, perhaps this may happen some time in the beginning but I believe the rational LPs and traders will only concentrate on the biggest/efficient pool eventually, a pool with an unreasonable multiplication param will unlikely be used by users.

5 Likes

Hey @duc,

This is for future growth campaign but since related to pDEX, I want to write here. I think some PDEX token can be reserved for PancakeSwap or another DEX farming in BSC. A coin equal to PDEX token (e.g. wPDEX) can be minted in BSC. So we can hit three birds with one stone: awareness of Incognito, BSC bridge and new pDEX.

6 Likes