feat: Calculate executed protocol fees in postprocessing

[sunce86]

Problem

on_settlement_event_updater runs for each settlement and calculates some data to be stored in database. Here, for each limit order, we should fetch fee policy and quote from database and calculate the executed protocol fees. Then, those fees need to be stored into order_execution.

[fleupold]

I'm not sure about this. What's the disadvantage of simply storing one value for fee (the difference between the executed exchange rate for this order and the exchange rate according to uniform clearing prices)?

E.g. let's USDC/USDT trades 1:1 according to the clearing prices. But the user sold 100 USDC for 90 USDT (according to the settlement transaction).

This would mean the user paid 10 USDC in total fees.

[sunce86]

What's the disadvantage of simply storing one value for fee (the difference between the executed exchange rate for this order and the exchange rate according to uniform clearing prices

Can't do it that way because, in the driver, we:

1. start from UCP
2. adjust UCP for surplus fees -> exchange rate 1
3. Adjust exchange 1 for protocol fees -> exchange rate 2

and onchain, we only see UCP and exchange rate 2. So we need to know the exact policy to reconstruct how much of the fees are surplus fees and how much are protocol fees.

[fleupold]

My point is why even differentiate between the two (at least on a database level). The user paid 10 USDC in fee, why do we want to differentiate between the surplus fee and the protocol fee (maybe there is an obvious reason, but I'd just like to challenge this assumption)

The protocol fee will in any case have to be computed from the order itself since some solvers may not charge it from the order in an on-chain observable way. Let's stick to the example above (and assume the user placed a limit order expecting 80 USDT outcome):

• Solver A uses our driver provided logic to charge fees. Thus they report a clearing price of 1 and an order specific price of 0.9 (adjusting $5 of network fee and $5 for protocol fee)
• Solver B uses their own driver. They report a clearing price of 0.9 and no order specific price

In both cases the protocol will request $5 - 50% of the difference of 80USDT and 90USDT - from the solver as a protocol fee at the end of the week. This is assuming the solver computed fee CIP passes and solvers with heavy private market making arms implement their own driver.

How should the database records for both executions look like?

[sunce86]

why do we want to differentiate between the surplus fee and the protocol fee

Probably for accounting reasons. (edit: aaand we use the surplus_fee/network_fee for solver rewards)

Solver B uses their own driver. They report a clearing price of 0.9 and no order specific price

Need to adjust the example, so:

• Solver A uses our driver provided logic to charge fees. Thus they report a clearing price of 1 and an order specific price of 0.875 (adjusting $5 of network fee and $7.5 for protocol fee)
• Solver B uses their own driver. They report a clearing price of 0.875 and no order specific price

For second, based on the fact that we take 50% as protocol fee, we would see that the $87.5 - $80= $7.5 is 50% of the protocol fee, meaning the solver provided a solution for price of $95. The protocol fee would be $7.5 and the network fee would be unknown (0) - or calculated as gas cost from settlement?. In this case, this fee would also be irrelevant since we won't pay them back to solvers.

[fleupold]

For second, based on the fact that we take 50% as protocol fee, we would see that the $87.5 - $80= $7.5 is 50% of the protocol fee

I'd call this a 100% surplus fee (we observe $7.5 surplus on chain and thus request $7.5 from the solver) but that's just a question of reference (it's 50% of the counterfactual execution assuming the solver behaved rational) and the two are interchangeable with different values (although we should probably align on a common term @olgafetisova)

and the network fee would be unknown (0) - or calculated as gas cost from settlement?

Gas from settlement may not work in case there was more than 1 order (hard to attribute the cost). That's why I'm saying we should make sure we understand what we want to do with those values, if we cannot rely on observing them in the first place. In the example above what values do we want to store?

1. Surplus fee (the difference between UCP and per order clearing price)
2. Protocol fee (any claims the protocol will make against the solver for settling this batch)
3. Network fee (surplus fee - protocol fee)

[sunce86]

and the two are interchangeable with different values

We as a protocol define the order of how the fees should be taken (first surplus, then protocol fees in order as listed, and reverse when observing the onchain settlement). Although we don't have the CIP for this.

1. Surplus fee (the difference between UCP and per order clearing price)
2. Protocol fee (any claims the protocol will make against the solver for settling this batch)
3. Network fee (surplus fee - protocol fee)

So initially I wanted to store 2 and 3 since those values are meant to be directly used for something. Also Surplus fee is zero for the example where solvers run their own driver so why saving it.

[fleupold]

We as a protocol define the order of how the fees should be taken (first surplus, then protocol fees)

Surplus fee is not a requirement though (a solver can settle a batch with two orders without any visible surplus fee and still be profitable because they priced their cost into the exchange rate). In this case (solver B example), how would the table be populated? Would network fee be negative (given that surplus fee is 0 and protocol fee is $7.5 based on the observed price improvement)?

[harisang]

Had a quick read, and will revisit again.

A first comment, as I don't think we have consensus within the solver team.

Solver B uses their own driver. They report a clearing price of 0.9 and no order specific price

Personally, I would like solvers to report the UCP and the per order clearing prices. Although not necessary I guess, I do see the value of getting essentially a price feed from solvers. E.g., say gas is high and a user for some reason is selling 100 USDC for DAI. Then it might be the case that 50 USDC is the gas. Having a solver just report p(DAI) = 1 and p(USDC)=0.5 is of course fine for the execution onchain, but it conceals information. One could look at the gas cost, but in a batch things become less clear. So what do these prices mean; do we have a depeg, do we have huge protocol fees, do we have high gas costs or any combo of these?

For this reason, I would propose that solvers must provide a UCP.

Regarding the discussion about how refined must be the distinction between different kinds of fees in the database, I will think about it and get back to you.

One thing to note (although i guess this is unrelated to the database) is that we would like to rank solutions before taking the protocol fee. I.e., in your example above, if the surplus the user receives is $7.5 and another $7.5 was the protocol fee, then the "rank by surplus" objective should assign a value of $15 to that solution; the rationale being that solvers try to maximize the size of the pie and should not care / treat differently orders with or without protocol fee.

[sunce86]

Closed as not needed. Decided to just provide the input for calculating the protocol fees.