[Call for feedback] pDEX single-sided liquidity design

[duc]

Based on community feedback as well as core team research, there are 2 problems with the pDEX AMM mechanism.

1. Friction in liquidity provision - providers must contribute both sides of a pair. This requires LPs to forfeit long positions on their tokens and take on exposure to other assets in the pool.

2. Impermanent loss (IL for short) - the difference between holding tokens in an AMM and holding them in your wallet.

The Provide feature currently allows LPs to contribute single-sided liquidity, but can be improved significantly in terms of sustainability and autonomy. This topic briefly details a new idea for an economically sustainable design that eliminates potential loss from IL; a LP mechanism that enables single currency contributions, supported by trading fees and possibly liquidity mining rewards (TBD, please see the final paragraph for initial thoughts).

It is important to note here that contrary to other AMM protocols, pDEX v.2 uses its protocol token, PRV, as the counterpart asset in every pool. This enables the protocol to co-invest in pools alongside liquidity providers (LPs).

Non-PRV contribution

If a liquidity provider (LP) only wants to contribute a non-PRV asset (let’s take USDC as an example), then the Incognito protocol will provide PRV to match that contribution as a co-investment. That match happens at the current pool exchange rate, meaning the relative pool balance will not change pre or post contribution.

Contribute pUSDC (privacy USDC in Incognito)

The process for contributing pUSDC is as follows:

• LP supplies an amount of pUSDC. If it is verified that the protocol holds less PRV than the required limits (specific to the pool), this action will fail until more PRV is freed up from the protocol by LPs providing PRV.
• According to the current pool rate, the protocol provides the same value of PRV tokens as deposited pUSDC.
• pUSDC from the LP and PRV from the protocol are supplied to the pool
• LP’s Share balance is updated (increased by 50% of the issued shares)
• Protocol’s Share balance is updated (increased by 50% of the issued shares)

After this process, both the LP and the protocol have increased their Share balance. Note that Shares owned by the LP and Shares owned by the protocol earn fees from swap transactions in the pool.

Remove pUSDC

When a LP decides to remove the single-sided pUSDC position from the pool, the following steps are executed:

• LP inputs pUSDC amount to be withdrawn, up to 100% of their contribution.
• Based on the percentage of Shares owned by the LP correlating with their contribution, the system determines the amount that can be withdrawn by the LP from the pool.
• If there is sufficient pUSDC in the pool to pay the LP fully in pUSDC, then pUSDC will be the only settlement currency. Otherwise, the settlement amount will include an amount of PRV based on the delta to the withdrawn amount.
• When the LP receives PRV, tokens are locked for a set period of time (e.g. 24h), to disincentivize panic liquidations.
• New Pool amounts are updated.

PRV contribution

PRV contributions can be made at any point, but amounts must correspond to how much pUSDC is currently supplied by LPs. It is only possible to make PRV contributions when the protocol holds the corresponding Shares (as a result of pUSDC contribution in this example).

Contribute PRV

The process for contributing PRV is as follows:

• LP supplies an amount of PRV.
  • The value of PRV in Shares is calculated according to the current rate.
  • If it is verified that the protocol holds enough Shares, the action will be executed. If not, it will fail.
• PRV deposited is burned.
• Shares held by Incognito Protocol are transferred to the LP.

Remove PRV

When a LP decides to remove the single-sided PRV position, the system will compute how much PRV the LP needs to receive:

• LP inputs the amount of PRV to be withdrawn, up to 100% of the PRV contributed.
• The associated Shares are moved under the protocol’s ownership.
• The settlement value is equal to the amount withdrawn.
• PRV is distributed to the LP according to the settlement value from the Incognito Protocol reserve.
• When the LP receives PRV, the tokens are locked for a set period of time (e.g. 24h), to disincentivize panic liquidations.

Call for feedback

This topic simply outlines an initial idea for redefining the pDEX LP mechanism. There are a few open questions yet to be answered. Feedback is always welcome.

1. PRV is needed to match a non PRV contribution as a co-investment. A straightforward and decentralized source is a percentage of the block reward. If this route is pursued, block mining rewards for validators would decrease by the corresponding percentage. A preliminary tokenomic document for pDEX v.2 will be published soon, with more concrete numbers for further discussion. In the meantime,

What do you think about this approach to protocol sustainability that rewards all forms of contribution?

2. In addition to withdrawing non-PRV tokens, the single-sided LP may sometimes receive additional compensation in PRV based on the delta to the withdrawn amount (see the section on removing pUSDC for more details).

If PRV must be locked for a set period of time (e.g. 24h) to mitigate panic liquidations, how can we mitigate the impact on UX?

If you have any ideas or questions, please share them. We’d love to work out the answers with you.

[KO-WEI_TSENG]

This Single Side AMM design looks good.

My first though is about the price oracle. Banocor and DODO on Ethereum tried to solve the oracle problem of single side AMM by Chainlink. And for now the price oracle is feed by the Incognito team since there is no decentralized price oracle like Chainlink on Incognito.

Second, If the plan is to separate the pdex/prv governance in the long run. Below is my proposal by offering a new governance token.
The new governance token is for the pdex asset listing/fee structure etc. , then a reasonable liquidity mining program can attract liquidity without spending the DAO fund.
For the incentive, we can try a hybrid approach. Use PRV DAO fund to fund PRV side liquidity like what we have for ‘Provide’ now(the PRV pool will match the pdex and vnode just like now). On the other side (non-PRV), we provide new governance token liquidity mining program. The initial coinlist can be picked by the incognito team, and later will be decided and voted by the pdex governance token holder.
As a result, we maybe no need to reduce the PRV block reward from the nodes. The pdex will sustain itself and be a new DAO after the initial liquidity mining period. PRV can focus on network level activity like running nodes, being the collateral asset for the coming bonding contract.

[marko]

@duc

If a liquidity provider (LP) only wants to contribute a non-PRV asset (let’s take USDC as an example), then the Incognito protocol will provide PRV to match that contribution as a co-investment.

emphasis added

Does the team have enough PRV for this? Am I correct in that the protocol can’t really provide this as PRV is generated through consensus rewards? Thus it would need to come from somewhere (the team’s stockpile).

Along this line, why does it need to be PRV rather than a placeholder token or even some smart calculations rather than an actual token?

[wangfeng]

It’s better to give feedback by creating polls, then it’s easier to know what you should improve

[duc]

hey @KO-WEI_TSENG, thanks for your thoughtful feedback. To the best of my knowledge, Bancor was using a price oracle for Dynamic Reserve Weights and Amplified Liquidity, but as you can in our post above, we’re only trying to address single-sided liquidity problem first that is fairly a different approach from Dynamic Reserve Weights and not touch to slippage reduction (by using Amplified Liquidity or something else) yet. So I don’t see the need to have a price oracle yet, feel free correct me if I’m wrong.

Governance is also an interesting thing we’d love to think of but it’s likely a bigger topic and out of the scope of the post since it may be relevant network-wide not only pDEX. We can always switch to voting for things like tokens listing, fee structure later on.

Remember our goal is to limit PRV cap to 100M, and theoretically, it’s being split into 2 parts: mining rewards for block validators and DAO fund, so the question is that where the protocol’s PRVs come from to match a liquidity contribution and still remain the cap. That’s why we make the post to hear your opinions. Also, we’re pretty sure that PRV for pDEX reserve won’t be the only thing we’re considering to “extract” from mining block rewards so this could be a good opportunity for discussion.

[duc]

@marko, PRV won’t come from the team but the network. It’s a kind of reserve to match a non-PRV liquidity contribution as a co-investment. For example, if we reserve 9% of the total PRV cap for pDEX then 9M would be an overall limit of PRV that can be minted across all pools to match token-only contributions.
Once a trade executes (say selling BTC for PRV), the PRV would actually be minted to the trader’s address and circulated to the blockchain even if those might come from pDEX’s reserve.

[sop]

As someone who likes to provide single sided liquidity, my main concern on UX is just that its clear up front. As long as it says something like “Note: there is a 24 hour delay on withdraws” on the provide page, then I think most people will be okay with it. And if there is an unexpected delay, something clearly in the withdraw interface explaining how long and why. And I would stress the interface part. Putting notices on Twitter or the forums causes a lot of people to miss it or get worked up before they see the message.

What causes panics is uncertainty. When you want to withdraw, but your coins don’t show up and you don’t know why. Then people starting worrying about hacks or scams.

[duc]

yes, we understand your concern. And if your concern is just about UX then you may not need to worry anymore as we’re having one of the best product designers in the field (a.k.a @ning) - she always puts herself in the user’s shoes on empathy-centered UX/product design so you can count on her i think.

[Matt6412]

I really like this idea… this solves the problem of wanting to earn on the prv listed in liquidity.

If this were to roll out the next part that would make sense is to actually have real trading fees, not .000001 prv. The LP should be rewarded for insertion of liquidity in the form of trades just like other amm systems.

Lastly, putting a restriction on moving the prv that gets given back as a form of preventing / mitigating impermanent loss seems fine, as long as its clearly labeled. Its not like you had that prv to start and this feature is helping your liquidity risk.

[duc]

yes, I totally agree with you that an AMM system should have trading fees. The fees will be the main incentive for LPs to provide liquidity to the pDEX. When there are many trades happening, the fees would increase naturally as a competition among traders.

[Globallager]

@duc

According to the current pool rate, the protocol provides the same value of PRV tokens as deposited pUSDC.

Using the instantaneous current pool rate as the asset matching basis might open up exploitation opportunities, especially for pools with low liquidity.

A typical exploitation could be:

1. Manipulate pool price with trades
2. Provide a large amount of asset to the pool single-sidedly
3. Receive a “disproportionate” asset match that is based on the manipulated price

Considering that there are no flash-loans on Incognito yet, the exploiter has to own a considerable amount of a certain asset for the exploitation to be successfully performed. The exploitation could still be performed nonetheless if we simply draws the current pool price for liquidity matching.

[marko]

I haven’t been able to come up with the best solution but I think this is not it. I don’t know that the PRV really needs to be minted or whatever…it just needs to be allocated mathematically/programmatically.

Maybe the pdex requires a PRV pair listing similar to uniswap v1? That’s the only reason I can think of that requires PRV pair listing.

There are lots of projects that are working on single sided liquidity…has anyone researched what they are doing for inspiration?

[Matt6412]

Will this design be applied to all liquidity pairs? Or only popular coins? I ask this because I plan on bridging a few projects into incognito and having this single sided liquidity feature would make it very easy for a project to add their coins in to establish sufficient liquidity for proper trading with minimal slippage.

Also, when is this new design going to be deployed you think? I am eager for it to be released

[duc]

hey @marko, one of the reasons the pdex v2 requires PRV pair listing is that PRV is the only mintable token by the protocol. And yes, we referred to the other projects as well and learned something from them, to be honest.

@Matt6412, the design is still in the research stage, not finalized yet, that’s why we posted it here for discussion. It’s likely a sort of “whitelist” listing that only approved coins can be matched to protocol’s PRV.

@Globallager, thanks for pointing it out, we’re really appreciated it, I was thinking of a few scenarios and ways to mitigate the problem (yep, low liquidity is a problem for AMM system generally) but could you please give me one or a few concrete examples so that we can start discussing on…

[Globallager]

@duc

but could you please give me one or a few concrete examples

Sure thing!

Let’s assume the market price of PRV is $1, and the liquidity in the PRV/pUSDC pool is $200 (i.e. 100 PRV + 100 pUSDC).

An exploiter can then:

1. Crush the price of PRV in the pool by selling, e.g. 1,000 PRV

• As a constant product pool, pool liquidity becomes 1,100 PRV + 9.09 pUSDC, PRV price of the pool becomes $0.0083

2. Add a relatively large amount of pUSDC single-sidedly, e.g. 10,000, and get matched with 10,000/0.0083 = 1,204,819.28 PRV

• Pool liquidity then becomes 1,205,919.28 PRV + 10,009.09 pUSDC, PRV price of the pool remains $0.0083

• When the pool is traded against other and balances out, the PRV price of the pool would approach its market price of $1, i.e. pool liquidity would approach ~ 607,964.19 PRV + 607,964.19 pUSDC

3. Withdraw entitled share, i.e. ~50% of the liquidity, equivalent to 607,412.05 pUSDC

Based on the above arbitrarily simplified scenario, the exploit takes 1,000 PRV + 10,000 pUSDC to pull off a $600,000 value extraction from the protocol.

Realistically, the actual results would also depend on pool fees, pool sizes, refined exploit parameters, market inefficiency, etc., but you get the idea.

[denaliDS]

Unfortunately, customer aquisition costs remain the highest single cost to profit ratio when it comes to running a business. The low trading fees allow the Incognito trading platform access to massive amounts of customers that would otherwise trade elsewhere. Especially when offloading coins can be very expensive. Ideally every trader would keep all their coins on the network, but again it’s a small percentage of the globally community that is willing or able to do so. Thus I have to disagree that a much higher fee be charged to trade on Incognito be implemented. Especially when we already have the Uniswap platform as a backup trading mechanism built in.