CoW Protocol started out with the promise of 1 price per token per block. This worked reasonably well when all orders had their fees signed upfront. However, with the introduction of limit orders which could be open for a very long time it was important to allow solvers to compute a dynamic fee based on network conditions of the settlement time and settlement route.
This was achieved by adding "adjusted" prices to the price vector for each order with a dynamic fee. So now the price vector no longer contains 1 price per token but theoretically any number of prices for the same token.
What's even weirder is that if all orders have dynamic fees there is really no need to even include the originally 1 canonical price for the traded tokens since it wouldn't be used by any order anyway.
Currently we still include the canonical price in the vector but more for accounting purposes as this is not strictly necessary to execute the settlement on-chain.
All these details seem like code smells since we shoehorned in a feature that the original contract was not designed for.
Acceptance criteria
Determine if it's possible to have a more natural implementation of dynamic fees since at the moment it looks like those should be the only ones going forward.
Problem
CoW Protocol started out with the promise of 1 price per token per block. This worked reasonably well when all orders had their fees signed upfront. However, with the introduction of limit orders which could be open for a very long time it was important to allow solvers to compute a dynamic fee based on network conditions of the settlement time and settlement route.
This was achieved by adding "adjusted" prices to the price vector for each order with a dynamic fee. So now the price vector no longer contains 1 price per token but theoretically any number of prices for the same token. What's even weirder is that if all orders have dynamic fees there is really no need to even include the originally 1 canonical price for the traded tokens since it wouldn't be used by any order anyway. Currently we still include the canonical price in the vector but more for accounting purposes as this is not strictly necessary to execute the settlement on-chain.
All these details seem like code smells since we shoehorned in a feature that the original contract was not designed for.
Acceptance criteria
Determine if it's possible to have a more natural implementation of dynamic fees since at the moment it looks like those should be the only ones going forward.
Research track
protocol-design