Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

slippage error #3

Closed
iamoskvin opened this issue Jul 9, 2022 · 8 comments
Closed

slippage error #3

iamoskvin opened this issue Jul 9, 2022 · 8 comments
Assignees
Labels
question Further information is requested

Comments

@iamoskvin
Copy link
Contributor

I am trying to trade usdt-usdc.
All the trades fail with Slippage error.
What could I do to escape this error?

@pmioduszewski
Copy link
Collaborator

Hi,
This is not related to our bot.
Slippage basically means that trade that U wanted to execute will result in loss because market conditions has changed so transaction was aborted and your tokens returned to Your wallet.
For more info go to Jupiter Docs or just please type "What is slippage in defi / solana" in the Google :)

@iamoskvin
Copy link
Contributor Author

Hi,

I understand what the slippage is.
My question is: what could I do to mitigate this problem?
I mean the bot configuration parameters.

@pmioduszewski
Copy link
Collaborator

Ok,
Currently bot uses Profit Or Kill strategy for slippage but soon You will be able to manage this behavior choosing between Profit Or Kill and Percentage value.

Profit Or Kill strategy simply means that bot will set slippage amount to Last Balance of the Token that will be result of the transaction. Because of that if market condition changes You will receive not less than Last Balance (Solana fees are not included in this calculation)

From my experience Profit Or KIll will always result in more profit than percentage value.

Everything depends of user strategy. Bot is still raw, it will be much more flexible in the future :)

@pmioduszewski
Copy link
Collaborator

Oh and RPC speed is crucial to avoid slippage error, a lot of people hunting for this usdt-usdc pair that You mentioned earlier :)

@iamoskvin
Copy link
Contributor Author

iamoskvin commented Jul 10, 2022

Thank you for the detailed explanation!
Does the slippage depend on the minPercProfit setting?
If I increase or decrease minPercProfit, will the successful txs rate change?

I use a quicknode RPC. Maybe there is a better option...
I suppose that pingpong mode suits best for stablecoins.
Is it reasonable to use it for other assets?

@pmioduszewski
Copy link
Collaborator

pmioduszewski commented Jul 10, 2022

My pleasure 😄

Does the slippage depend on the minPercProfit setting?

no

If I increase or decrease minPercProfit, will the successful txs rate change?

yes, this is very important parameter impacting Your strategy and results

Is it reasonable to use it for other assets?

Ofc, maybe You will find pair that will be much more profitable that crowded stablecoins.
E.g. You can try renBTC <> BTC
You always need to remember that using Tokens other than stablecoins can result in loss because e.g. BTC price go down. Best market condition for pingpong strategy is when market is going constantly sideways up & down, consolidation. This kind of volatility can result in good profits using pingpong strategy.

@iamoskvin
Copy link
Contributor Author

Thank you. Could you please explain a couple of things?

  1. Regarding fees. I see a tx with a fee of about 0.02 sol on a regular basis. Like this one
    https://solscan.io/tx/5tx7WrwAjpkUpihNVUjtbns8utkmCFjYwo99AbVAShGTk18ny2N3EDR94A11CzdE1D2HDGJ1jrw8NeRJs6wW6Zbv

Can I expect that at some point, all possible accounts will be opened and such txs will no longer be needed? How many of these txs will there be in total?

  1. Did I understand correctly that at each iteration we run jupiter.computeRoutes to find the trade opportunity? We see the consumed time at UI (LOOKUP).
    In my setup, LOOKUP takes 3 seconds on average. What is the bottleneck here? Does the jup SDK make API-calls that take a long time? Is there any possibility to reduce this latency (some optimizations)?

@pmioduszewski
Copy link
Collaborator

1. Regarding fees. I see a tx with a fee of about 0.02 sol on a regular basis. Like this one
   https://solscan.io/tx/5tx7WrwAjpkUpihNVUjtbns8utkmCFjYwo99AbVAShGTk18ny2N3EDR94A11CzdE1D2HDGJ1jrw8NeRJs6wW6Zbv

Can I expect that at some point, all possible accounts will be opened and such txs will no longer be needed? How many of these txs will there be in total?

I have little time, sorry. The bot currently uses execute() (Jupiter SDK) to make swaps. U can check it on Jupiter Docs how it's working. From my experience, Serum has the most expensive fees (I can be wrong). I have on my to-do list the Exclude AMM feature that will allow You to exclude e.g. Serum.

2. Did I understand correctly that at each iteration we run jupiter.computeRoutes to find the trade opportunity? We see the consumed time at UI (LOOKUP).
   In my setup, LOOKUP takes 3 seconds on average. What is the bottleneck here? Does the jup SDK make API-calls that take a long time? Is there any possibility to reduce this latency (some optimizations)?

Yes, the latency that is shown in the UI comes from jupiter.computeRoutes(). You have >1 sec probably because the asset you choose has many possible routes to compute. The more routes the pair have the more time it will take to calculate.

If You have any ideas to improve the bot, don't hesitate to share them with us :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants