round opps strandard deviation report #248
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
reports opps standard deviation for each round against avg of x number of previous rounds
addresses #247
Solution
Tackling reporting on drops in execution (found opps irrespective of whether they got actually cleared by bot successfully or got frontrun or tx failed or ...).
keeping track of counts of opps across x number of previous rounds (x latest rounds), by each passing round a new count is returned, we can check the new number against the standard deviation of previous rounds, subtracting the 2 values will give us the difference from the norm of x previous rounds, so any value below 0 means it has hit the lower bounds of stdvs and then on hyperdx can setup an alert to go off, also can apply how many levels below 0 to deviate before alert goes off, like if we deviate more than 1, 2, 3, ... levels below the stdvs, then alert should go off.
This will hint to the anomaly that occured for the current round, many reasons can cause this, such as orders got removed, market moved rapidly and some orders cant correctly adapt and may need redeployments, orders' vaults got emptied, rpcs are ratelimiting, etc etc.
Next configuraion can come into play in hyperdx to set an occurance number for the anomalies count across y span of time. Meaning, maybe 1 anomaly 1 time, isnt really something that concerning as it can be as a result of examples above such as orders got removed, but if that happens more than once across let's say an hour, it can indicate to something other than expected reasons.
These are configurable per bot per chain on hyperdx, and each can have their own set of thresholds.
Good part about this approach is that, it will not stay fixed on a value and continue alerting forever, but rather it is always adapting to latest x number of rounds that bot reports about, as number of orders change and each order quote/vaults/clearing situation changes over time so does the stdvs, making it a more dynamic and flexible approach to check for bot's possible execution drops and anomalies.
Checks
By submitting this for review, I'm confirming I've done the following: