Price oracle contract

[maurolacy]

Instead of simple-price-feed, implement a proper price oracle contract that gets its info from a DEX such as Osmosis. This may require querying of price information over IBC.

Support multiple crypto currencies / crypto currencies pairs, both from a local (Consumer side) DEX, or from a remote (Consumer side / other) DEX, over IBC.

Use TWAP or similar to get a stable price estimation for a crypto currency pair.

[JakeHartnell]

Going to have a couple of these. IMO an easy one to start with would be band-price-feeder , I would:

• Make a new folder dedicated to price-feeders: contracts/consumer/price-feeders/
• Move simple-price-feeder in there
• Base a new band-price-feeder contract off the example contract in cw-band but conforming to the standard interface as demonstrated in simple-price-feeder: https://github.com/bandprotocol/cw-band

[JakeHartnell]

What are some other price-feeders we might want?

Off the top of my head:

• Osmosis Twap: https://docs.osmosis.zone/osmosis-core/modules/twap/
• Astroport Twap: https://docs.astroport.fi/docs/develop/smart-contracts/oracle
• Ojo: https://github.com/ojo-network/contracts/tree/main/cosmwasm

Maybe a generic ICQ (which version?) or Polytone one?

[maurolacy]

We can start working on this soon. Let's discuss offline.

[maurolacy]

Some comments / guidance from Osmosis on how to implement a price Oracle using the Osmosis DEX:

So for on chain queries, we want to query via Stargate Query

https://github.com/zodiac-protocol/tokenfactorytest/blob/c4044443ef83528be613e5b6fccd16f57542ea7d/contracts/tokenfactory_hooks/src/contract.rs#L189

Path here is the query path, and msg is the binary-ized protobuf query message.

We basically rely on cosmwasm’s querier to dispatch the query to osmosis, and receive results.

[uint]

So for on chain queries, we want to query via Stargate Query

This looks less boilerplatey, I'll give it a try.

[uint]

I've been poking at this and the scaffold I have so far is a "price feed provider" contract (deployed on Osmosis) and "price feed consumer". Provider has an admin that can add/remove subscriptions (IBC connections). Provider will require some sort of endblock capability to periodically send all subscribers updates - is that something we can do? If not, I can probably adjust.

[uint]

Current design I have:

osmosis-price-provider

To be deployed on Osmosis. The contract has an admin set at instantiation. The contract is capable of handling multiple IBC connections.

After a successful IBC handshake, the admin can bind the IBC connection to a denom through a local exec msg. Once a channel is bound, it's an active subscription. Every epoch every active subscription is sent (fire-and-forget) an IBC message with the current twap for their particular trading pair.

For triggering the periodic updates, I'm hoping we can figure this out via the epochs native module on Osmosis, but if I understand Osmosis docs properly, we'd need some help from them. I'm not 100% sure this is appropriate since I imagine we'd want the twap to be updated quite often.

remote-price-feed

To be deployed on consumer chains. The contract doesn't have an admin. It can handle a single IBC connection to the osmosis-price-provider (or another provider with the same API?).

It works pretty much like simple-price-feed, but instead of manually updating the exchange rate, it receives updates over IBC.

Along with the exchange rate, the contract stores a timestamp of when the update was received. If for some reason the exchange rate is outdated (configurable threshold), querying for the price returns an error.

[maurolacy]

Just seen this, sorry for not commenting / reviewing earlier.

Some comments:

• Handling multiple IBC connections on the Price provider is fine. I see now that this is to support multiple consumer contracts querying the Osmosis DEX for pricing info through the contract. I would still support a token pair there, not just a denom. Because a Consumer could want pricing info against another token besides Osmosis. Imagine a (future) Juno consumer chain that is secured by CosmosHub, and queries the Osmosis contract for the JUNO/ATOM price.
• I would put the query loop on the Price consumer contract. That simplifies the Osmosis contract, and allows for multiple, configurable querying frequencies per Consumer. This would require sudo / end blocker privileges on each Consumer, but that's something a Consumer is already doing for the virtual-staking contract. So, more of the same setup in a sense.