Pdex slippage issue *feature request*

[Fatfaa]

Is a slippage tolerance adjustment in the road map to be added? This is crucial as swapping even in “fairly liquid” main trading pairs / pools I see a lot of slippage but no warnings sent. I know there are slippage warnings but it only seems to go off on smaller pools…

For example buying xmr from btc right now in an order of .08 btc would make you lose around 35 dollars…and thus the higher you go, the worse it becomes. On uniswap it gives you the percentage upfront, the amm is the same one used by uni so I’d imagine it is easy to implement

[marko]

This is a great idea and I would love to see the fiat (probably USD) representation of slippage, fees, or generally any losses to expect. It’s very time consuming to calculate this before and is the primary reason I don’t use pDEX more often.

[Fatfaa]

Yes quoting everything in prv is very hard to understand … a quote in usd makes the most sense when trying to make sure your trade will execute in a logical manner otherwise you can lose some serious money on this platform in a bad trade !

[MrAwesome]

Ya I agree. The slippage percentage needs to be shown with warnings if it goes over a certain set percentage from the user. I hope that incognito’s team will add that feature because it’s really needed.

[ning]

@Fatfaa

the percentage upfront

hey ya - quick update that we’re gonna be prioritizing this for next month’s sprints.

thanks a lot for the feedback and sorry for the delayed response! end of quarter madness.

[Fatfaa]

That’s okay… will the update allow us to make the trade request with 0 slippage ? There’s an arb bot that utilizes that ability on the platform and the only way to execute a trade like that is via rpc with a full node. Here is an example of how the trade request code is inputed, as done with every request by this bot

[Fatfaa]

Example of code sent from the android app from us normal users

As you can see us users that trade from the app, which is like 99 percent of user base, have no chance in competing with bots . And by us entering these trades this way as programmed by the app the bot profits from the slippage with every trade, which is not fair

[Fatfaa]

Here are the txn links for further documentation:

Trade request by Android app user

Incscan

Trade response by pdex for matched txn by android app user:

Incscan

Trade request by bot using rpc commands:

Incscan

(This example the trade command actually says min acceptable amount is ABOVE the quoted , not even matched, because the bot knows one side is inflated and wants to profit.)

Trade response by pdex for matched txn by bot using rpc custom trades:

Incscan

As you can see the community traders who use the app will ALWAYS lose everytime and this bot takes advantage of that. Not hating on an arb / liquidity bot but all users should be allowed fair access to the same tools …if a user continuously trades or makes trades valued over $2,000 value the slippage increases exponentially and it causes great financial loss , which many in the community has unfortunately suffered from.

[Fatfaa]

Example of bot trade again setting coin trade with a loss of 0 percent essentially

[Fatfaa]

Example of bot trade that is programmed to actually acquire MORE coins than trade would deem, because it knows that side of the market is inflated due to an android user executing an order that inflated it

[marko]

Ahhhh…now I know what is happening. @ning swears that it’s possible to get more than the minimum quoted when doing a pdex trade. She’s right, but app users don’t stand a chance against the bot using RPC. That’s why I always get the minimum quoted when I trade on pdex, just compounding the low liquidity already.

Thanks for bringing this to our attention @Fatfaa

It seems that metadata should not be included or should be encrypted somehow not to be easily readable by everyone else, especially the bots.

[Fatfaa]

I dont think the remedy is scrubbing more meta data, it should be allow app users to edit min acceptable amount. The meta data for every trade request will always show what people are trading / requesting to trade. If everyone was allowed to put custom data in that field like the bot does, you can make trades you don’t lose on or even gain from if you see a whale transaction that moved a market one side.

[Fatfaa]

I say this with the obvious knowledge anyone running a full node can also execute an rpc trade with custom input parameters, its just not convenient at all.

[Fatfaa]

Also want to say I get more than what the trade estimate quotes me often, which is more than minimum acceptable field, but the field value for min acceptable is set too low very often. So even if I get a few coins above the trade estimate in the app, I could still have a very large slippage in the trade, which the arb bot comes and balances out right away (balancing out would be a friend way of saying taking your fat fingered trade coins).
Thing is most of the trades have so much slippage purely because it is programed to have them…if min accepted amount is kept tighter to what you want to gain from the trade you won’t have this issue.

[Fatfaa]

Pdex slippage issue *feature request*

Example of bot trade that is programmed to actually acquire MORE coins than trade would deem, because it knows that side of the market is inflated due to an android user executing an order that inflated it [Screenshot_20201102-124137_Chrome]

Just want to post my issue here because this is cross related. Order execution timing is fairly important because there is an arbitrage bot running and every trade not done over rpc with full node cannot compete . So my question is, if 2 users submit a trade request but user 1 submitted 5 seconds earlier than user 2 and they are both in the same block… or at least in the memory pool, how does it get mined? Does it follow timestamp of pdex trade request ? Or does it follow a transaction fee system where the more you add to a miner fee the more likely you are to be accepted and mined in… if so how can we add higher fees to pdex trade requests?

As a user I know when I trade let’s say 1000 prv for usdc, the result after that will be usdc being over inflated and id like to equal out that market by making a counter trade immediately just like the arb bot does so I can minimize my loss per trade.

[duc]

hey @Fatfaa, we understand your concern about this. but in my opinion, an arbitrage bot is normal for exchanges and you could completely compete for the bot with trading fees (and yes, on the wallet you could not input trading fees for now, we’re considering it)

For more details, if 2 trade transactions are processed in the same beacon block then the one with the higher trading fee will be processed first even if the trade submitted slightly slower.

[Fatfaa]

Yes I agree having the bot keeps price stable and is good, was just looking for an easy remedy to execute trades in a similar fashion… so also you answered my question in regards to which transactions get processed first, there is a fee market (good in my opinion, more money to go to miners)

I am just getting started running a full node to try trading this way, is there any example code in json format for manually doing trades via rpc? It seems this is based off eth so could I just use eth rpc as reference? Forgive me if this is documented somewhere, thanks in advance!

[Matt6412]

Is there an update on this yet? When do you think this feature can be rolled out? I agree with what fatfaa has stated and would be eager to trade more actively if I was able to control MinAcceptableAmount in the app.

[marko]

I think some kind of slippage/price impact display is slotted for yet this year. There is a roadmap but I can’t find the link.

I don’t know if it has been decided to implement MinAcceptableAmount in the app but I’d like this added. @ning What do you think?

[Matt6412]

According to @ning it was said this will be prioritized into next months sprint (which is nov, this month) . Allowing the MinAcceptableAmount to be edited in the app is , essentially, just like adding a slider to allow your tolerance for slippage. Only difference is if you see a market is over bought and can be arbitraged you can set the MinAcceptableAmount to a level that is actually HIGHER than the coins output you would normally get let’s say if slippage is set to 0.3 percent… essentially its like saying I want negative slippage (a request of course) to be sent in and if conditions allow for it, the trade response will allow the trade to execute. IMO you could allow the slider to go past 0 for slippage to create this sort of condition and or open up a field where you can input that condition type