feat: Forward protocol fee to driver when solving

[sunce86]

Problem

For each auction, a driver needs to know if a protocol fee should be taken, for which orders, and which fee parameters to use.

Additionally, a new database table should be created where the protocol fee parameters should be stored for each auction. This is to have the option to retrieve the parameters in postprocessing for each settlement and calculate the required protocol fee and check if the driver behaved honestly.

Suggested solution

I suggest to have an enum that will define types of protocol fees. Each type would contain it's own specific fee parameters. Right now, we would have only one: QuoteDeviationForLimitOrders. In the future we might add FixedFeeForLimitOrders, VolumeBasedFeeForAllOrders, FixedFeeForTWAPOrders etc.

There are two assumptions to consider when defining how to forward the fee to the driver:

1. The protocol fee is consistent during an auction -> For each auction, different fee can be set.
2. The protocol fee for an auction is the same for all orders of the same type. For example, for limit orders, quote deviation fee with the same parameters will be applied for all limit orders.. There is no need to define different protocol fee per individual order.

Enum type QuoteDeviationForLimitOrders will have parameters:

1. surplus_cut in percentage
2. volume_cap in percentage
3. value_cap in ETH? (not sure about this one, but auction sent to driver should have a price for each token, so the driver should be able to calculate the equivalent amount of sell/buy token for value_cap).

Acceptance criteria

• For each auction, protocol fee is defined and sent to the driver. The driver receives them successfully.
• For each auction, protocol fee is saved to the database.

[fleupold]

This is to have the option to retrieve the parameters in postprocessing for each settlement and calculate the required protocol fee and check if the driver behaved honestly.

Why is this necessary? Shouldn't we be able to compute the fee per auction in hindsight simply by using the quoted amounts we find in the database (and our fee policy). We will then "invoice" solvers that fee amount regardless of what driver implementation they are using. The default driver will make sure that sufficient fee amount is captured in the form of positive slippage. But I don't think the autopilot needs to store the fee amount per auction.

I suggest to have an enum that will define types of protocol fees.

Would it be more flexible to define the fee field per order? This way we can also return it as part of the /orders endpoint so the frontend can compute it.

[sunce86]

fee policy

But we need to know this right? And the policy can change between auctions, for example, if we at some point want to try out some different fee parameters and restart the autopilot. So, basically, I meant to say this:

a new database table should be created where the protocol fee parameters should be stored for each auction

[sunce86]

Would it be more flexible to define the fee field per order? This way we can also return it as part of the /orders endpoint so the frontend can compute it.

Here, I think you are referring to the protocol fee as a final result (when the auction is done and settlement is mined etc).
What I referred to was how to send the fee parameters from the autopilot to the driver and save this data for later. Initially I thought of not attaching fee parameters to each individual order but I might reconsider depending on the implementation

[fleupold]

Right, as long as we store the auction somewhere, we can later on recover the fee parameters. I want to avoid keeping another table with duplicate records of the actual fee that was captured in an auction if this can be determined from the input.

[MartinquaXD]

BTW I think Nick left an implementation idea for this feature here. Just pointing it out in case we want to draw some inspiration from it.

[sunce86]

Closed with #2098