[Epic] 4.2: Protocol Fee Implementation

[olgafetisova]

Epic label: E:...
Planned start date: 08/12/2023
Due date:

Summary

This current task requires configuring drivers (or solvers - TBD) for the successful fee implementation. The quote must pass the decision whether the fee is applicable for the current order or not, then, the fixed parameters will be applied for the fee calculation after the order is executed. Finally, we need to decide how we collect the payment from the solvers (weekly with the payouts, in COW or other).

Iteration 1:

• The fee is applicable for out-of-market Limit orders and Twap orders.
• For Limit orders, the fee is based on charging 50% of the surplus (max 6% of the total volume or $1000)
• For TWAP orders, the fee is based on charging 50% of the positive quote deviation (max 6% of the total volume or $1000)

Additional requirements:

• signal solvers if they need to adjust their quote
• make sure the solution is suitable for the future fixed fee approach - the widget will require a fixed fee setup; hence, we might need to adjust this current delivery.

Acceptance Criteria

• Allow the product team to experiment with different fee mechanisms (surplus vs volume fee, etc)
• Allow the marketing team to create “campaigns” allowing for additional or reduced fee for certain user and orders
• Allow the BD team to work with integrations to charge an extra fee (or subsidize flow)

Tasks

Breakdown of the work

• For Limit Orders: Adjust the per-order clearing prices to incorporate the required surplus fee or positive quote deviation (e.g. if user expected 100 DAI but the solver was able to generate 110 DAI, we need to change prices so that the user receives 105 DAI and the remaining 5 DAI stays in the settlement contract)
• Offer an endpoint to differentiate between transaction fees (gas substitute) and protocol fees (quote deviation) in the explorer
• Adjust Gnosis Solver Solution
• Communicate with our current solvers about the changes they need to apply
• Store fee information for analytics purposes.

[sunce86]

Why solvers (I mean matching engines or solvers in colocation terminology) need to be signaled to adjust their quotes or to be notified in any way about this change?

AFAIU, all needed changed are done in the driver, where we adjust the clearing prices for limit orders so that not only surplus fee, but some additional protocol fee stays in the settlement contract.

[sunce86]

The fee is applicable for out-of-market Limit orders and Twap orders.

Is it for all TWAP orders (in-market and out-of-market price)? If so, how do I differentiate between regular in-market limit order and in-market TWAP order, since AFAIS, there is nothing that marks limit order and says that is originated from TWAP module?

[sunce86]

After the grooming with solver team, the first issue (adjusting the clearing prices for service/protocol fee) would look like this:

1. The user is selling 1 ETH for 4000$, where the current market price is 2000$.
2. The solver engine sends the "raw" solution to the driver, with clearing prices that give 4013$, while also requiring 3$ as surplus_fee.
3. Driver first adjusts the clearing prices to take into account the surplus_fee, meaning new clearing prices give 4010$.
4. Driver than takes protocol_fee_factor = 50% of the difference between the 4010$ and limit price (or quote if higher than limit price) and adjusts clearing prices so that they give 4005$.

If we observe the settlement onchain from the autopilot, while also having the original quote and protocol_fee_factor, by going in reverse we should be able to reconstruct the values for protocol fee and surplus fee.

[olgafetisova]

Is it for all TWAP orders (in-market and out-of-market price)? If so, how do I differentiate between regular in-market limit order and in-market TWAP orders, since AFAIS, there is nothing that marks limit order and says that is originated from TWAP module?

Since we are introducing 0 fee model, technically speaking, all in-market orders will be limit orders, right? So we just need to be able to distinguish between Limit in-market and out-of-market orders and TWAP orders in general. Twap orders have a flag.

After the grooming with solver team, the first issue (adjusting the clearing prices for service/protocol fee) would look like this:

1. The user is selling 1 ETH for 4000$, where the current market price is 2000$.
2. The solver engine sends the "raw" solution to the driver, with clearing prices that give 4013$, while also requiring 3$ as surplus_fee.
3. Driver first adjusts the clearing prices to take into account the surplus_fee, meaning new clearing prices give 4010$.
4. Driver than takes protocol_fee_factor = 50% of the difference between the 4010$ and limit price (or quote if higher than limit price) and adjusts clearing prices so that they give 4005$.

Would in this case, the extra funds (the fee) stay with CoW DAO directly, or will it first go to the solver, and then we have to claim it back?

[sunce86]

Would in this case, the extra funds (the fee) stay with CoW DAO directly, or will it first go to the solver, and then we have to claim it back?

They would stay in the settlement contract which means we would control them.

[fhenneke]

Here are some ideas around the processing of auctions to charge protocol fees from surplus. (You can ignore most stuff at the top of the document.)