I recognize some arbitrage opportunities on the Polygon network and tend to include my transactions in the next block. Since Polygon's transaction time is too low, I know that I have to do it quickly and efficiently, so I highly optimized all aspects that I thought might affect the overall process and I am now able to recognize discrepancies almost in real-time (Before sending my transaction to the blockchain, I even double-check that it is still profitable). Yet, I have a big problem that causes almost all my tries to fail and I could not find out the reason. My transactions are not getting included in the next block and it causes all of them to fail (they are usually processed within the next two or three blocks). Increasing the gas fee (even to an unreasonably high amount) had no effect and does not guarantee my transactions to get executed at the beginning of the next block. On the other hand, however, I track some other guys that use a similar technique, but seem easily include their transactions in the right block (event with a low fee) and take the profit.
My guess is that they are also counting pending transactions on their calculations, which I currently do not. The other probability is about my provider which of course I am not sure about it.
Is there any special note, trick, or technique that I miss in between?

  • @Ismael Thanks to his hint, I'm parallelizing my CPP code on CUDA and I hope I can get the desired result very soon ;) However, I still appreciate any extra information of any kind in this regard. Aug 8 '21 at 17:06
  • 1
    I don't know how it works on Polygon, but on Ethereum's mainnet it is not something that can be solved with more computing power, or inspecting the mempool's pending transactions. You have to use something like flashbots to communicate with miners to privilege your transactions.
    – Ismael
    Aug 8 '21 at 17:30
  • @Ehsan how Cuda is involved here ? Is your application running on GPU ?
    – jagstock
    Aug 9 '21 at 0:25
  • 1
    @jagstock If you tend to find opportunities among a huge batch of pairs in a uniswap-forked DEX, you need to use some sort of graph search algorithm, which can be quite CPU-intensive. These kinds of problems sometimes can be (or converted to an) "embarrassingly parallelizable" form which literally means you can run them on GPU to get near-instant results. Aug 9 '21 at 4:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.