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:
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 USDT 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
Jan 2022 update: a new token will not be implemented at this time. Instead, efforts will be focused on the main Incognito token PRV – to be used in the Incognito exchange for liquidity mining and governance. More details >
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.