feat: Make protocol fee accessible via orderbook API

[fhenneke]

Problem

Fee policies for trades are currently not accessible through our orderbook API. This makes it difficult to check protocol fees and network fees as post processing in the EBBO repo. In particular, we used to check for cost coverage on a per settlement basis. This is currently not possible using the orderbook API alone. Other uses cases might be showing protocol fees in the explorer. And generally, protocol fees are an important part of the protocol now.

Suggested solution

I would like to be able to get information on protocol fees in one of the orderbook queries. The information should be either the total protocol fee for a trade or the protocol fee policy (including parameters). I am not sure what the correct place for that would be. One candidate is the trades endpoint since protocol fees are attached to execution of orders (and not necessarily to orders themselves).

Alternatives considered

There are ways to get information on protocol fees not relying on the orderbook API.

• One can access the database directly. This has the advantage that no backend work is required. It would, however, require database access for all parties running the EBBO script. It would also make the code in the EBBO repo more complex.
• One can query dune to get information on protocol fees. That would suffice for our current requirements in EBBO. But not all parameters for protocol fees are currently synced and the additional dependency on dune would increase code complexity.
• Completely move cost coverage alerts out of the EBBO repo to dune.

[sunce86]

I would prefer to give you fee policies instead of executed protocol fees. The fact is that given the policies and the execution of the settlement it's possible to recalculate the executed protocol fees (which is more in a decentralization spirit). Unfortunately, the decision to define the protocol fee policies and attach them to the order in the autopilot (instead of in the orderbook at order creation time) was mostly pushed by me (the reason being I believed that each autopilot restart with different fee policy config should reflect which policy is attached but it's mostly a product decision and not that strong argument) and I am slowly starting to believe I was wrong with this decision and that we should have defined policies in the orderbook.

(1) Moving this into orderbook is a more involving change. (2) The alternative would be to expand the Order api struct with fee_policies and read them from database, but those are available only once the order is part of some auction and can change up until the order is fulfilled. It also doesn't work well for partially fillable orders so it would have to be referenced for trades (not orders) and represent "executed_fee_policies".

I think I would be for (1) as a long term solution.

[fhenneke]

I think attaching fee policies to an order is indeed the better approach. Since this feature is not blocking any work on the solver team side, implementing the long term solution should be fine.

[fleupold]

We can still attach the fee policies to each executed order leg without defining them on a per order basis in the orderbook, right? If so I'd suggest to do that. Moving the place in which the fee gets determined is a bigger change and might not be worth the effort given other things we could be working on.

[sunce86]

Yes, we can add them to /api/v1/trades. The db query would have to join with settlements table to get auction_id, and then use that auction_id and order_uid to get the policies from fee_policies table.

[github-actions[bot]]

This issue has been marked as stale because it has been inactive a while. Please update this issue or it will be automatically closed.

[fhenneke]

I still think protocol fees should be accessible from the orderbook api. It is not a high priority though. Maybe it will be part of any restructuring of data pipelines.

[alfetopito]

Re-iterating the request to have this data available from the API.

The use case now - apart from the explorer - is for third parties (e.g. Safe) to build their UIs on top of the protocol, and be able to decode the partner fees.

This use case in special doesn't care about protocol revenue (formerly called surplus fee), as those are transparent to the user. What matters is the partner fee, or at a minimum, the network costs associated with the quote that originated the order. That's because, the order contains only the minimum received after slippage and fees (networks costs + partner fees) have been applied, and it's impossible to reverse that and show the user what is the partner fee agreed upon.

[fleupold]

It was briefly discussed yesterday that the backend would provide information about approximate

• protocol fee
• partner fee (if any)

in the sell token (same as network fee). This is to reduce complexity as in theory different fees could be charged in different tokens (protocol fee in CoW, volume fee in buy token for buy orders, network fee in sell token)

[fhenneke]

Could you elaborate on what you mean by "approximate", @fleupold?

Some use cases for the solver team would benefit from having access to exact protocol fees (or even just fee policies) via the orderbook API.

[fleupold]

Could you elaborate on what you mean by "approximate"

Fee converted into the most useful currency (in this case sell token) using approximate price vectors (e.g. clearing prices)

I do think we should provide a way to expose fee policies for each trade so that the solver team can compute exact fees in whatever token is correct (COW, sell token, buy token, ETH).

Would that work?

[alfetopito]

I do think we should provide a way to expose fee policies for each trade so that the solver team can compute exact fees in whatever token is correct (COW, sell token, buy token, ETH).

This is somewhat tangent to the topic in this issue, but @harisang did mention the solver team was working no a PoC for an endpoint exposing exact fees per order. Might need his input to give further context.

[fleupold]

Let's not add another dependency to the frontend (on top of bff and core services API). We should be able to provide the required information from one of the existing two backend services.

[alfetopito]

Let's not add another dependency to the frontend (on top of bff and core services API). We should be able to provide the required information from one of the existing two backend services.

For sure, the data exposed by the backend here would be enough for the frontend needs. I raised it only in regards to Felix H.'s question on the "accuracy", which might be a requirement for the solver team.