Most orders are processed in batches, but some orders are processed sequentially for additional features like multi-hop swap. Since sequential matching happens after batch matching, it has no effect on batch matching and will require higher fees than normal, so it should only be used when absolutely necessary.
Unlike batch matching, sequential matching makes it easier for users to predict in advance how much they will receive from a swap. This isn't just about increased predictability of transaction outcomes, it also means that it's easier to bundle multiple actions involving swaps and process them all at once. To illustrate, consider a scenario where a liquidity provider possesses only one token and intends to swap a portion of it before providing liquidity within a desired price range. By considering only the state of the pool and their own order, without taking into account other users' orders, it becomes feasible to calculate how their order will impact the pool's price and determine the percentage of each token that should be offered within their desired price range based on the adjusted price.
This enhanced modularity of the swap function allows for the composition of multiple actions as a combination of different functions, which can then be processed together within a module. This capability streamlines the execution of multi transactions and contributes to a more efficient and flexible trading experience.
It might be difficult to completely prevent MEVs during the sequential match phase, so in the future, we may decide to open up slots to users who want MEVs, charge a large fee, and return the revenue to ecosystem participants.
Concept of sequential matching