I am trying to make an argument here to not separate between protocol fee and gas fees but instead, simply have one (protocol) fee.
Technical argument
Let’s assume it would be our goal to only charge exactly the gas fee - that would cause larger issues
a) how to charge for failed solver attempts
b) very hard to “fairly” split gas costs across different traders in a batch
c) volatile gas prices make it hard at order submission to know the gas price at inclusion time
Incentives
Gas optimization is a complex topic and can include:
a) using gas tokens (deleting order storage in GP)
b) using storage access lists
c) optimizing gas prices/ miner tip
Long term it seems better to let solvers compete here as well and just offer specific solver rewards and let solvers optimize the costs they have.
Communication
a) easier to understand for the user - why bother the user with 2 different fees. A simple statement like: “GP has a protocol fee that covers expenses like solver gas costs”
b) Total amount of fees taken is simply higher. Of course, it is important to be transparent about expenses. From a protocol perspective, these will be solver rewards (and those need to be high enough to cover gas costs)
How to define the fee:
Suggestion: base trade fee = (100k gas * current “1559 base fee”) + (e.g.)2 BIP
Even when just trying to cover gas costs it does make sense to charge a higher fee for larger trades as it makes sense for larger trades to use more gas (more complex executions)-
I think it’s a good proposal! and agree that it is simpler to present just one protocol fee.
The end user should care mainly about the price after fees, and how the fee is structured conceptually is less interesting.
One challenge is that users like to compare prices and fees with other products which currently usually don’t consider gas costs as part of the fees. So it might seem as GP has higher fees / worse price.
Additionally, your suggestion anyway has two components, one to cover the gas cost and one is a percentage fee. If this is the case, then it’s just a question of whether the user want to see this breakdown or not?
I would add to that, there’s a challenge in defining a uniform fee for all trading pairs. The obvious example is like-asset pairs where curve charges 4 basis points and Uniswap 5 BIP.
Even for ETH-USDC the 5 BIP pool is now pretty liquid and might prevent a COW settlement even if it is present as GP is intended to charge 10 BIP?
My assumption is that GP will anyway need to define different percent fee for each pair based on few parameters like the pair’s liquidity and volatility in order to remain competitive vs AMMs. If GP’s spread is higher than the most liquid AMM, it is unlikely to settle COWs on that pair.
Important argument. If the cost of a trade is the relevant metric for users to choose GP, the gas fees could (accidentally or not) be factored in by portals, aggregators, statistic dashboards, etc…
Could we present the user with a “gas component” of the fee? At least an estimate? Same would have to be available in APIs, subgraph, etc…
It’s also harder to compute protocol revenue and advertise it.
Besides those points I agree with Martin and think it would actually improve UX and solver handling.
I think this is a nice intuition which allows us to simplify the gas estimate and make it independent of the concrete “baseline route”. That being said, I think that the way the fee is specified today needs to change going forward. Instead of specifying a fixed fee that the settlement contract charges unconditionally, users should sign a “max fee” (similar to how they sign a max base fee in EIP1559). Solvers should then at execution time only take as much fee as they are entitled to (e.g. using the proposed formula).
This would also allow us to charge a fee as a function of achieved surplus instead of traded volume (and thus only charging in case we created value for the user). This requires a flexible fee taking mechanism given that at signature time we don’t yet know what surplus will be generated.
Even with today’s order format we could achieve this change by “baking” the fee into the limit price (leaving the actual fee field 0) and providing slightly different clearing prices for each trade (effective price = uniform clearing price + fee per trade). While we enforce uniform clearing prices as a “soft” protocol criterion the price vector is currently not verified on chain for uniqueness.
This would come closer to expressing your order as most “bang for the buck” (all fees considered), something that @CryptoOrca has suggested in the past.
I actually think (and suggested to “anxolin” on discord), that cowswap should actually add the real price (nominal price + hidden cost) of some other dexes on the interface. You can’t convice them to show their price in accordance to your system, but you can show their price in a way that is comparable to yours.
What felix mentioned of the “more bang for your buck” is simply the idea that acquiring something has a cost and you want to minimize that.
When you trade what you want is a certain amount of something else. What matters in the end is how much does it cost for you to acquire that. It does not matter if the cost is in the form of gas fees, protocol fees, nominal price etc.
You went into the operation owning X amount of money and left with Y amount of money + whatever you bought. The best place to trade is the one where Y is the closest to X as possible, regardless of how they show price or fees etc.
Agree with @CryptoOrca that the main challenge is communicating it to the user.
I assume we have to communicate in some form the WORST possible price they might get.
The fact that probably they will get a better price is hard to reflect and thus eventually I fear that it will just seem we’re offering worse prices than competitors.