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
This order was filled sub-optimally in 2 partial fills.
It contains a pre-hook that claims rewards to provide the full sell token balance to the owner. The driver already computes the available balances for an order based on the outcome of the pre-hooks (if there are any). But in this case the balance simulation didn't show that the owner would get all the necessary sell tokens from the hook so it reported the available balance to be whatever the owner currently has without the hook.
A solver picked up this order and executed it. In the actual settlement the hook got executed and unlocked the remaining sell tokens which led to another partial fill that then fulfilled the order completely.
When simulating the hook on its own it exceeds its gas limit and therefor reverts. This explains why no balance change happens in the simulation. However, in the actual settlement the balance change happened.
When comparing the hook simulation with the onchain settlement simulation it became apparent that executing the hook as part of the actual settlement was a lot cheaper.
The reason seems to be that the storage loads are a lot cheaper in the real settlement. That is likely caused by the fact that we use access lists for the real solution but not during the balance simulation.
Impact
The driver fails to compute an order's accurate available balance when hooks unlocking sell tokens set a tight gas limit.
Expected behaviour
The simulation for computing the available balance should be as close to the real settlement as possible to avoid these differences.
The easy fix is to just use access lists for during the balance simulation, too.
The text was updated successfully, but these errors were encountered:
Problem
This order was filled sub-optimally in 2 partial fills.
It contains a pre-hook that claims rewards to provide the full sell token balance to the owner. The driver already computes the available balances for an order based on the outcome of the pre-hooks (if there are any). But in this case the balance simulation didn't show that the owner would get all the necessary sell tokens from the hook so it reported the available balance to be whatever the owner currently has without the hook.
A solver picked up this order and executed it. In the actual settlement the hook got executed and unlocked the remaining sell tokens which led to another partial fill that then fulfilled the order completely.
When simulating the hook on its own it exceeds its gas limit and therefor reverts. This explains why no balance change happens in the simulation. However, in the actual settlement the balance change happened.
When comparing the hook simulation with the onchain settlement simulation it became apparent that executing the hook as part of the actual settlement was a lot cheaper.
The reason seems to be that the storage loads are a lot cheaper in the real settlement. That is likely caused by the fact that we use access lists for the real solution but not during the balance simulation.
Impact
The driver fails to compute an order's accurate available balance when hooks unlocking sell tokens set a tight gas limit.
Expected behaviour
The simulation for computing the available balance should be as close to the real settlement as possible to avoid these differences.
The easy fix is to just use access lists for during the balance simulation, too.
The text was updated successfully, but these errors were encountered: