Apply fee on top of rather than subtracted from swap fee

[danrobinson]

Component

General design optimization (improving efficiency, cleanliness, or developer experience)

Describe the suggested feature and problem it solves.

Right now, the protocol fee is specified as a denominator of a fraction that is multiplied by the swap fee to determine the protocol fee, with the resulting protocol fee subtracted from the swap fee before the latter is applied. This seems weird for a few reasons.

• Specifying a denominator is just weirdly imprecise and inconsistent with how fees are measured everywhere else.
• Charging as a fraction of swap fees means that the imposed protocol fee would be higher on pools that charge higher fees even for the same asset pair, which doesn’t feel right when you think about it.
• It could allow some hooks to evade protocol fees by charging swap fee in a different way (such as using the deltas in #482).
• It seems less natural for a change to result in liquidity providers receiving a lower fee on a particular swap than they would expect; rather than resulting in swappers paying a higher fee than they expect, given that liquidity providers and hooks would usually be considered “slower” than swappers. (This argument arguably also applies to how protocol fee worked in v2 and v3, but seems stronger in v4 due to hooks.)

Describe the desired implementation.

Have protocolFee specified in pips (hundredth of a basis point), like swap fee, with some cap. During a swap, have it applied on top of the existing swap fee (so it is effectively paid by swappers), rather than taking away from the swap fee earned by LPs.

Since 2^16 pips would be 6.5%, which is much higher than where you’d want to set the cap, you shouldn’t have to change the size or type of the variable.

Describe alternatives.

We could have the protocol fee be subtracted from the fees earned by LPs, rather than added on top and paid by swappers. This raises the question of what would happen if protocol fee is higher than swap fee.

Additional context.

No response

[codyborn]

Throwing out another idea for protocol fee design.

Percentage of BASEFEE

With EIP-1559, the protocol can access the BASEFEE on Ethereum and L2s. The fee could be a governable percentage of the transaction fee that users are paying and different on each chain.

Benefits

• Transaction fee is independent of pool fees (handles the custom accounting problem)
• Can collect fees in ETH instead of random tokens (easier treasury management)
• Although denominated in ETH, is independent of the price of ETH
• Correlated with the fee that we know the user is already willing to pay (gas fee)

Downsides

• Fee doesn't scale with trade size so the protocol may be passing up potential revenue