Integrate oracle pallet and add price feed

[dutterbutter]

In order to exchange assets for PINT, the value of those assets as well as PINT’s NAV needs to be computed. To achieve this a price-feed service is required.

[mattsse]

After looking into the PINT price feed and the chainlink-feed-pallet there are some open questions: @ansermino @willemolding

Who would pay for the incentives to submit prices?

Should the oracle fees be paid via the PINT treasury?

In what unit is the nav of each asset measured, what's the base currency?

Should this be DOT or PINT?

Example: Requesting "What's the price of Asset X?" from the price feed requires a unit or rather an asset pair: "What's the price of Asset X in DOT" so the asset pair is (Asset X / DOT).

To my current understanding, the base currency cannot be PINT directly because the number of PINTs in circulation is based on NAV_total:
NAV = NAV0 + … + NAVn/ Total Supply PINT

So the total number of PINT depends on the NAV of each Asset? This begs the question how is the NAV of an asset determined?

However, because PINT has a value, we can express the NAV of an asset in PINT.
In the end, it all probably boils down to "How much DOT is a PINT?" or rather the asset pair (PINT / DOT)

Also, since the rewards from the staked assets of the PINT index will be exchanged via an AMM for PINT we probably know the price Asset X / PINT, but a portion of the returns will be burned, right?

[willemolding]

I wonder if instead of having a separate set of incentivized price providers, that submitting price information should be the responsibility of the council/committee. They are already essentially able to manipulate the NAV of PINT by submitting new SAFTs so it doesn't add any additional trust assumptions to have them also submitting the price of liquid assets. They are intrinsically incentivized to have the PINT assets accurately reflect reality.

[mattsse]

I also think a separate incentive structure is not really necessary if only the council/committee submits new values.
However, if we want to allow oracles external to council/committee (e.g. chainlink nodes) to submit new entries, they should probably be rewarded for doing so.
The way the chainlink pallet basically works is a user creates a new feed and deposits a payment for future submissions and unlocks a set of oracles (accounts) that then can submit new values and receive a reward for doing so.

[ansermino]

I wrote this and forgot to post, so forgive me if its a bit outdated:

The price of the underlying assets in the index must be up to date when a user redeems their PINT for those underlying assets. Manual updates would leave a lot of room for price variation which could potentially be gamed. Although the council can update the NAV of SAFTs, this is the exception not the rule.

Perhaps we should rethink the flow of events a bit. A user redeeming their assets still has to wait for the unbonding process to occur. Thus, it's not unreasonable to delay the initiation for a small amount of time, or perhaps batch these together in some fashion to reduce the number of oracle queries and prevent this itself from being exploited (perhaps by a data provider?).

We should also consider the implications of callbacks in Chainlink, so new data from the oracle can automatically adjust the index's NAV. In this case we would need to consider what happens if the data becomes stale and react accordingly by pausing redemptions.

[mattsse]

For the time being an updated version of substrate v3 lives here mattsse/chainlink-polkadot

There is also a draft for the callback implementation in the feed pallet: smartcontractkit/chainlink-polkadot#51