This is definitely a valid point. However, I see some issues if we want to incorporate this into the mechanism. Let’s think about sell quotes, where there is a sell amount and solvers are requested to compute the expected buy amount:
- To assess volume, most likely you need a price of the sell token with respect to ETH. This is exactly what the requests of the second type compute (the “buy 1 ETH” requests). Which means that we cannot really compute the reward only based on the quote itself, but we would need some “external” information in order to evaluate the reward; not necessarily bad, but also not the cleanest solution either.
- I am worried whether in the case that we decide to evaluate the volume and increase the reward for larger volume quotes by using these “buy 1 ETH” quotes to convert the sell token to ETH, that the estimators would then try to inflate the price of the sell token so as to make the quote look like it is selling a larger volume. Not sure how valid of a concern this is, but I think this could happen.
In general, I agree with you that the mechanism feels a bit too static, and in a way, the whole effort resembles the solver competition rewards, and it could happen that price estimation evolves in a similar way to solver competition, with gradually more fine-grained rewards that take into account the complexity of the order/quote in question. On the other hand, there is already enough complexity to the protocol, and since it is not clear how soon we will have multiple external solvers competing in price estimation, and how stable these estimators will be, I am in favor of pushing something simple forward to get things started, and depending on solvers’ engagement and the potential problems that will show up, we should monitor and revisit the mechanism soon.
Still, I would like to hear some other comments on this as well. If there is some consensus that the reward should somehow depend on the volume (e.g., by doing some linear interporation between a min and a max reward that is based on the volume on the order, as @tomatosoup suggests), then we could make this part of the proposal.