Fiat exchange rate: if only there were price-oracles that published timestamped+signed fx rates

Current practice:

In the case of Electrum Wallet, the client can opt-in display and use fiat amounts (converted from BTC), in addition to BTC, in the History list or when sending/receiving money. There is a fiat option in the Preferences, where the user can select a currency (such as USD, EUR, ...), and select an exchange rate provider (such as CoinGecko, BitStamp, BitFinex, Kraken, ...). The client then connects to the HTTP(s) API of the selected fx rate provider to fetch the spot exchange rate.

What I would like instead:

Imagine if Coinbase/Kraken/Binance/etc, some kind of semi-trusted entity, periodically published the USD/BTC and EUR/BTC exchange rates. Consider e.g. ((spot_fx_rate, fiat_ccy, timestamp), oracle_pubkey, signature) tuples, where the signature commits to the (spot_fx_rate, fiat_ccy, timestamp) tuple using oracle_pubkey.
(e.g. spot_fx_rate is 58000, fiat_ccy is "EUR" and timestamp is a unix ts such as 1784763235)

The electrum server could fetch such tuples from different price oracles, and serve them over the electrum protocol to wallet software (clients). Then clients would not have to connect to the price oracles directly.

This would be a win/win/win:

• good for clients
  • keeps same trust assumptions
  • they already connect to electrum servers anyway
  • now they would not have to also connect to separate fx rate providers
    • one fewer entity the client "leaks" their IP_address--bitcoin_usage association to
  • with current approach (client directly connects to oracle), the oracle can selectively lie about the price to certain clients based on IP or timing, without risk of cryptographic fraud proofs (https is not good for that)
  • could even take the median of all spot price rates, and use that
    • currently e.g. the Electrum Wallet does not do this as it would mean connecting to many different http endpoints hosted by different entities, however if the electrum server served data from multiple price oracles, it would be trivial to do
• good for fx rate providers as this lessens their server load
  • instead of having 100k clients connect to them via HTTP, now only 500 electrum servers would connect to them and they act as load-balancer proxies free of charge
• well ok, maybe not a win for electrum servers, as this is a bit more work for them to do. :D Worth it though.

Note we have to differentiate spot prices and historical prices.
When sending/receiving money, the spot price is needed. Whereas in a History list for details of a historical tx, the historical exchange rate is needed.

Serving spot exchange rates inherently needs trust. Nasty attacks...
But maybe serving historical rates does not really need trust? In any case, the historical use case is not that important anyway.

Here I am mainly thinking about the spot price. It would already be a huge win if the client could get that from electrum servers without having to trust the electrum server. (Though if there were price oracles that signed and published historical prices, servers could proxy those rates as well.)

Do such price oracles exist currently? Ideally they would have to be openly accessible, not behind a paid API, so electrum servers can practically get the data.

Start by reviewing the existing Electrum client-server JSON-RPC protocol and how clients currently obtain spot and historical fiat rates from HTTP providers. Define whether signed oracle tuples can be represented and served through the protocol, with separate handling for spot versus historical prices. Done means the protocol requirements and trust assumptions are clearly specified.