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

[SomberNight]

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.

[SomberNight]

Looks like Coinbase had introduced a "price oracle" in 2020-04, as part of their "Coinbase Pro API" - so I guess not openly available.

In any case they then killed it in 2025-01:

We have deprecated the Coinbase Price Oracle API.

[SomberNight]

Given that most major exchanges already serve the exchange rate over HTTPS (as already used and described in "Current practice"), @Emzy pointed to me to the TLSNotary project.
AFAIU, using that, the electrum server ("Prover") and electrum client ("Verifier") could do MPC while the electrum server interactively connects to the HTTPS endpoint. Then the electrum server could prove to the client what price they received from the exchange.
While intellectually interesting, I think this is not practical in our use case. Taking on the extra dependency is not worth it. Also, it would be much nicer for everyone involved if the electrum servers could just serve and reuse the same data across clients, instead of having to interactively query the price data every time for each client.