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
I have seen for a bunch of "slow to solve" orders that they were quoted by a Gnosis solvers (e.g. 1Inch) which later on didn't attempt to settle them thus making them expire or take a long time to settle.
Details
Single order solvers sort orders in the auction instance by "likelihood" of being executed based on the external price vector that is part of the auction file. They then try to settle as many orders as possible based off that list until time runs out or the upstream API starts rate limiting them
It is a known fact that the external price vector tends to be inaccurate. Yet the orderbook is quite large, which may lead to bad prioritisation.
In particular, if a solver just quoted an order a couple of seconds earlier it should prioritise re-solving for that oder as it's likely going to be solvable given the same route that was obtained in the quote.
Acceptance criteria
Attach information about the winning quoter on each order
Inside the single order solver, keep sorting orders by likelihood but also put orders that were quoted in the last couple of minutes by the current solver ahead of the queue, as they are likely going to execute.
The text was updated successfully, but these errors were encountered:
In the first auction that the order was valid (9177561) no solutions were proposed so it could have easily been settled. The 1Inch solver never tried to match this order.
Just to make sure I didn't miss anything. This requirement implies adding a creation timestamp column to the quotes table, and the same timestamp should be reflected in the order_quotes table(to avoid adding quote_id and SQL joins), correct?
Background
I have seen for a bunch of "slow to solve" orders that they were quoted by a Gnosis solvers (e.g. 1Inch) which later on didn't attempt to settle them thus making them expire or take a long time to settle.
Details
Single order solvers sort orders in the auction instance by "likelihood" of being executed based on the external price vector that is part of the auction file. They then try to settle as many orders as possible based off that list until time runs out or the upstream API starts rate limiting them
It is a known fact that the external price vector tends to be inaccurate. Yet the orderbook is quite large, which may lead to bad prioritisation.
In particular, if a solver just quoted an order a couple of seconds earlier it should prioritise re-solving for that oder as it's likely going to be solvable given the same route that was obtained in the quote.
Acceptance criteria
The text was updated successfully, but these errors were encountered: