Asynchronous Websocket Listeners

Hey, Listen!

Up until this point we’ve largely taken an active approach to monitoring the blockchain. We pick some tokens, identify pools with those assets, set up helper objects to monitor and interpret their states, then send transactions whenever we see an opportunity.

This is a fine approach, but it scales poorly because of the underlying need to constantly ask our RPC the question “has anything changed?”

For a simple bot that’s monitoring only a few assets in a few pools, this is no problem. Programming the logic and updating the status is quite simple and intuitive — start a loop, update, re-evaluate, then do it again.

However, what if you’re a profit maxi, and you’d like to monitor several hundred pairs in several hundred pools? Your options start to run out quickly because the synchronous iterative approach (perform the steps in order, over and over) necessarily introduces “lag”. Every time you send a call to the RPC, it takes a round-trip over the Internet with varying degrees of latency. Plus you have to deal with rate limiting at the RPC. Perhaps the RPC only allows 10 requests per second, or sets a monthly cap on the number of requests that you can make.

If you’re trying to monitor the reserves of 50 pools every second, which limit do you hit first? Looping through the pools introduces cumulative latency (you will wait twice the average latency per pool at minimum). If you have a low latency connection but a high number of monitored pools, you have to make a high choice. How many requests do you submit per second, and for which pools? This is a very complicated question to answer, and it’s fragile too. A miscalculation means you hit an API rate limit and get blocked for some time before your rate limit resets.

And the worst part: many of these requests are “wasted”, returning no new results. The sSPELL-SPELL pools are very quiet these days (volume and liquidity are down a lot from the peak in Q4 2021), so checking for updates several times a second is a huge waste! Synchronous communication on the Internet is a zero-sum game. Every time you send traffic out and wait for a reply, you are taking time away from another potentially profitable activity.

So let’s improve our bot code by adding some asynchronicity, freeing ourselves to react quickly to events instead of constantly looking for them.