Buy crypto anonymously on the Incognito pDEX   

Pdex slippage issue *feature request*

#11

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.

1 Like
#12

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.

#13

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.

#14

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.

#15

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.

Is pDEX fair?
#16

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.

1 Like
#17

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!

#18

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.

1 Like
#19

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?

1 Like
#20

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

1 Like
#21

I hope it’s added because it was exposed in another post that there is a bot that front-runs every PDEX trade. I experience this too…I ALWAYS get the minimum amount for my PDEX trades. That’s a big reason why I don’t use it more.

2 Likes
#22

I’m not sure if the bot by design aimed to do that, but from the language the team has used to discuss that the arb bot is a good thing / necessary on an exchange to maintain fair prices, it seems maybe it is run by the core team. Regardless, it seems positive they want to fast track the ability to prevent loss of user funds since I posted this.

1 Like
#23

This feature should add a value or slider to set the transaction cost in the app

#24

not gonna chime in on the arb bot - bc anyone can run one (not just core team), and i personally have no idea who is (probably more than a few people).

here’s an update regarding the app tho -

  1. we’ll be adding a field for users to adjust fees paid cc @Fatfaa @Matt6412
  2. a field to adjust slippage % cc @Fatfaa @Matt6412
  3. fees on the first screen (so you can check trade deets even if you don’t have the sufficient balance) cc @marko
  4. ability to input the bottom number (and get minimum sold) cc @JoyRaptor
  5. size impact % (variance in prices due to low liquidity) cc @MrAwesome @fatfaa

note that 5 and 2 are different - 2 allows you to adjust slippage tolerance (difference between price at time of request vs execution - right now it’s fixed at 1% in the app). 5 is more of a display aid - letting you know if you are getting a reasonable price, especially for low liquidity pools.

re timelines, we’ll still be working towards a november release, but this is now a much bigger (better!) update than we had originally planned (just 3 and 5). will keep you guys in the loop.

thanks everyone for the great feedback.

7 Likes
[Shipped] App v.4
#25

Wow!!! I’m so excited @ning :partying_face: :grin:
Thanks to you for gathering and organizing our thoughts and thanks to the overall team for implementing it!!

2 Likes
#26

Wow, this is great! Yeah who knows who runs the arb bot hah all that matters is that you are implementing everything we asked for at warp speed! I look forward to this update!

#27

Is the ability to set the miner fee higher in this update? Just like the how uniswap uses eth gas levels to determine who gets priority in the mempool?

#28

with the new release, there will be 2 types of fees - basic network fee + trading fee (currently there’s just network fee). the trading fee will be implemented as an option to give priority for trade orders. so users can still choose to pay zero trading fees (network fee only), or est. 100 nano PRV or more (to get priority).

incognito currently differs from ethereum somewhat in this regard, because the network does not yet prioritize transactions within the same block by network fee. this will probably change in the future when transaction numbers pick up. so for now, trading fees will fulfill this use case.

for the reasons above, network fees and trading fees will probably be combined in one optionally customizable field, ‘fees’ (the minimum being the network fee). there’s no practical application for differentiating them at the moment. hope that helps!

4 Likes
#30

This is great! Thank you for this update

#31

That’s a great priority design. You guys being able to do that quickly, to your control of the entire blockchain stack shows, how valuable it is from starting from square one. One of the reasons why I’m consistently interested in what you devs will do in the future.

3 Likes