Add multiple price feeds option

[harisang]

This PR adds the option to use multiple price feeds as follows:

• at most 4 price feeds are considered, and the approx_percentile(0.5) the method for computing the median that is presented in this article is used to compute a price based on these price feeds. This replaces what has been now only the dune price.

In case all price feeds return null, we continue to use the fallbacks that have been used up till now

[fhenneke]

The changes generally make sense for testing other price feeds.

One issue is that the query is a bit too complicated for me now. (Maybe already was too complicated before.) Since it is essential to the accounting, it has to easy to understand what the query does.

For example, the handling of missing values seems a bit indirect: first, some price feeds are combined and an approximate median is computed. If that is missing, yet another price feed is used. So there seem to be different tiers of price feeds as well. But that is not made explicit anywhere. And only the Dune price feed is used for some things (intrinsic prices, native token prices) that other price feeds could theoretically also be used for.

[fhenneke]

This name does not help me understand what this table means. You can just select from a union in the next table. If it is a conceptually important table to you, the name should be changed.

[fhenneke]

Please add some comments on what those tables mean, or on the meaning of some tables in the context of the full query.

[fhenneke]

Why was this change required? Before, the entries in the prices table were always distinct from entries in the native_token_prices table since the token address was different. Does this still hold?

If not, there might be additional issues due to a token having multiple prices at the same time, leading to duplicate entries when joining.

[harisang]

Tbh i didn't think too much about it and it just looked more correct to me (in the sense that if you provide a prices table where native tokens are included, then you should not use the corresponding native_token_prices entries). In the current state, i don't think it can ever happen that the two table have common entries so i will switch back to union all

This dude cannot be trusted!

[fhenneke]

Is there a way to test this query?

[github-actions]

Are you sure you want to use the legacy prices.usd table? Consider using prices.minute (https://docs.dune.com/data-catalog/curated/prices/overview)

---

Caused by:

• cowprotocol/accounting/price_feed/raw_price_feed_query_4252674.sql
• cowprotocol/accounting/slippage/slippage_prices_4064601.sql

[harisang]

For the median part of the code, i added this "test"
https://dune.com/queries/4646457

[fhenneke]

Do you have a test query on dune for some of the final queries, e.g. raw slippage from query 4059683?

I still do not quite get what the final design would be and what the intermediate testing would look
like. Do we just run every query twice and compare? Or have one more query which calls slippage with different price feed parameters? Will we remove the price feed parameter at some point? How does it help with fixing prices?

[harisang]

So, i forked basically all queries that this PR changes as follows:

• slippage_4070065 -> https://dune.com/queries/4668024
• slippage_prices -> https://dune.com/queries/4646513
• raw_slippage -> https://dune.com/queries/4646519
• unusual_slippage -> https://dune.com/queries/4671700

There are some minor changes in some queries so that their output is more interesting for testing purposes

[harisang]

I still do not quite get what the final design would be and what the intermediate testing would look
like. Do we just run every query twice and compare? Or have one more query which calls slippage with different price feed parameters? Will we remove the price feed parameter at some point? How does it help with fixing prices?

My goal would be to eventually use the "new price feed". What this will be is not clear yet. Currently it is the median of some price feeds; we could add more price feeds or take some other function of the existing ones, or average out over longer periods of time, etc etc. But the goal is to replace the Dune price feed eventually.

The problem itself is a bit underspecified, that's why i don't have a clear answer to "how does it help with fixing prices".

A concrete first goal for me would be to kill outliers, i.e., not have to manually exclude txs from the accounting because slippage is extremely off.

[fhenneke]

I checked the raw slippage per transaction query and there seems to be a significant difference between the old and new query with the dune price feed (e.g. for transaction 0x89aae16f7b5650fb4f4cc59fe1bb63d6c622a205a4ac8b344db748e800ce7a47 or 0x8f941c8512d281efee3e76f5d388a76af40990812478c5840b3dda538c3f3d9e). And the differences between the two price feeds in the new query seems small (but thta would kind of be expected).
old:

new with dune price feed:

new with median price feed:

Do you know where those differences are coming from?

[fhenneke]

I think the issue is with using prices per unit instead of prices per atom. E.g. for token 0x9de1c3d446237ab9baff74127eb4f303802a2683, the Dune table does not contain a price nor does it contain information on decimals. The original reworked slippage accounting intentionally used prices per atom which could still be computed from exchange rates. The rework in this PR moves to prices per unit, which depends on having information on decimals. The corresponding contribution to slippage is thus ignored.