You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a solver repeatedly wins consecutive auctions but fails to settle its solutions on-chain, it can lead to system downtime. To prevent this, the autopilot must have the capability to temporarily exclude such solvers from participating in competitions. This ensures no single solver can disrupt the system's operations.
Suggested solution
Introduce a new domain::competition component to control whether a /solve request should be sent to a solver. This component would handle two responsibilities:
Solver Authorization
Utilize the existing logic eth.contracts().authenticator().is_solver() to verify if a solver is whitelisted.
Settlement Performance Tracking
Implement statistics-based logic to identify solvers that have won the last X auctions but failed to deliver settlements on-chain. This logic would also encompass other criteria for evaluating a solver’s reliability based on settlement success.
All required data is already accessible via the database. For example, given the auction X, we can fetch data from the previous N auctions, including full competition details. Additionally, the settlement::Observer populates a relationship between settlements and auctions. This allows us to confirm whether a settlement exists for a specific auction before its deadline.
The text was updated successfully, but these errors were encountered:
Forcefully enabling this for all solvers feels like it requires a CIP. However, I think it's reasonable to assume that if we offer this as an opt-in safety net for solvers to avoid huge slashing damages most solvers should be interested in that.
Given that this does not address the issue of an actively malicious solver it probably makes sense to make this mandatory via CIP eventually.
And Felix brought up that this should be very simple to communicate to solvers. Or else there might be support questions that need to be addressed. So I suggest that the autopilot should send a notification to the respective driver that it will get timed out due to submission failures. This should be easy enough for solver teams to track on their end how many auctions they won and how many solutions they actually brought on chain.
Problem
When a solver repeatedly wins consecutive auctions but fails to settle its solutions on-chain, it can lead to system downtime. To prevent this, the autopilot must have the capability to temporarily exclude such solvers from participating in competitions. This ensures no single solver can disrupt the system's operations.
Suggested solution
Introduce a new
domain::competition
component to control whether a/solve
request should be sent to a solver. This component would handle two responsibilities:Solver Authorization
Utilize the existing logic
eth.contracts().authenticator().is_solver()
to verify if a solver is whitelisted.Settlement Performance Tracking
Implement statistics-based logic to identify solvers that have won the last X auctions but failed to deliver settlements on-chain. This logic would also encompass other criteria for evaluating a solver’s reliability based on settlement success.
All required data is already accessible via the database. For example, given the auction X, we can fetch data from the previous N auctions, including full competition details. Additionally, the
settlement::Observer
populates a relationship between settlements and auctions. This allows us to confirm whether a settlement exists for a specific auction before its deadline.The text was updated successfully, but these errors were encountered: