Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

driver should be less conservative when computing available balances #3270

Open
MartinquaXD opened this issue Feb 6, 2025 · 0 comments
Open
Labels
bug Something isn't working track:maintenance maintenance track

Comments

@MartinquaXD
Copy link
Contributor

Problem

The driver has built-in logic to prioritize and pre-filter some of the orders. For example if a user has 3 open orders for the same sell tokens but only funds for 2 we discard the worst priced order (according to native prices).
This is further complicated with partially fillable orders. If for example the third order was partially fillable the driver would tell the solver that only a portion of the order would be fillable with the user's funds instead of dropping it completely.
Also if an order has a pre-interaction it makes sense to compute the available balance after executing the pre-interaction (in case the pre-interaction unlocks more funds).

Impact

All of this logic is relatively complex and currently overly conservative. For example if the same user has multiple orders open for the same sell token but with different pre-interactions the driver can't really be sure how much funds would actually be available for each order.
This can lead to cases where an order with a pre-interaction would unlock a lot of funds gets filled a tiny amount based on the users balance without taking the pre-interaction into account.

This very conservative logic was implemented to avoid solvers trying to solve multiple orders and then running into reverts because not enough funds for both orders are available. However, this is a pretty rare thing and most solvers are single order solvers which later merge together solutions anyway. In this scenario it would be preferable to very rarely run the risk of wasting some time on solving incompatible orders than filling orders with pre-interactions suboptimally.

To reproduce

Create 2 orders (same user, same sell_token):

  1. limit order without any pre-interactions
  2. market order with pre-interaction that unlocks more sell_tokens (sell_token.balanceOf(user) needs to be way smaller than the order's total amount)

Expected behaviour

The system should be able to settle the second order completely given that the pre-interaction unlocks all the necessary funds.

@MartinquaXD MartinquaXD added bug Something isn't working track:maintenance maintenance track labels Feb 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working track:maintenance maintenance track
Projects
None yet
Development

No branches or pull requests

1 participant