How to lose PRV by adding and removing liquidity

This is what I did:

+0.414064284
+1

Put liquidity:
0.414064284 PRV
2 QUEST, but 1 QUEST was re-founded

+0
+0

I removed two times without getting QUEST for it:
0.205604333
+0.208459949
----------------
0.414064282

+0.414064282
+0

I bought 1 QUEST for 0.207032141

+0.207032141
+1

Basically I lost money.
0.207032143 PRV, to be exact.

image

I think letting people remove liquidity from one side without removing anything from the other side can be problematic and could be fixed.

2 Likes

Thanks @J053. Let us have a check.

1 Like

Hi @J053 I see that one is still pending from your screenshot. How is its status now?
If it is failed, has the fund removed from the liquidity balance?
If your QUEST and PRV are still there, could you please re-try it?

All were successful

Hi @J053, if all transactions were successful and funds received, I will close this case.
Let us know if you still experience any errors when adding/ removing the liquidity.

I mean, all were successfully in the sense that I was able to remove liquidity without getting Quest, only PRV.

1 Like

Hey @Peter,

I think @J053 asks why the liquidity addition/removals create 2 (one tx for each side) transactions. He thinks/shows that this may create financial problems.

Here is an example.

Liquidity removal request:
https://incscan.io/tx/4e9c9ef29221e865e9116628a40bc2727150fa187c45fd219e12d7926914b7be (PRV/MATIC)

Liquidity removal responses: https://incscan.io/tx/f4743271ccda2cd22e1a4a74f9ff82bd2518ebe6c50d77447396cc7339eda5d2 (PRV)
https://incscan.io/tx/0a370716b4ab51cad5ea68c16902e36c7912a59090d8be9bfddfdbf1854aa34f (MATIC)

While I was developing IncogWhaleBot, I’ve noticed this issue too but I didn’t have time to focus on it. Thanks for reminding @J053

3 Likes

Thanks @J053. Let us have a check.

1 Like

Hi @J053, this pool (PRV/ QUEST) is small. When there is another user that makes a trade on this pool, you may lose the QUEST in this case.

I am not sure 1 - side removing liquidity could help to preempt this case. I hope that @duc could share some insights into it.

1 Like

There were no trades while I was doing this experiment. The trick here is to select the maximum number of shares that will give you only PRV in exchange. If QUEST had decimals, that would have given me around 0.9999… QUEST, but those decimals got truncated and it gave me 0 QUEST.

I was thinking that maybe removing liquidity without getting something from the other side is needed, because if the price were to be modified and your shares don’t allow you to remove at least 1 QUEST, then I would be impossible it that moment to remove liquidity. So that is a loss that you would have to accept.

Now, there is one thing that can be done. I guess you know by now that the pDEX has a constant value that is obtained by multiplying the PRV and QUEST in the pool, and that constant must not change when a trade is done, but it actually changes when someone buys QUEST with more PRV than the actual price of a QUEST.
For example, supposing the price of a QUEST is 0.7, and someone ask to buy 1 with 1 PRV, then that 1 PRV gets to the liquidity, and while that could mean he would get around 1.3 QUEST, he only can get 1, so the remaining 0.3 PRV that went to the liquidity affect the constant value, and so the price. My idea here, is that the blockchain should give you your change, those 0.3 that remained of that 1 PRV, because you could only buy 1 QUEST that had a cost of 0.7 PRV, not 1 PRV.

1 Like