Oracle
While Vendor does not require oracles to operate, it is certainly nice to have as it gives the lenders additional protection and peace of mind.
Why do we need an oracle?
Since the mint ratio of the pool is fixed, a situation where pool is lending more value than accepts as collateral is possible.
Example: Alice creates a pool with lend ratio of 1000 USDC per 1 WETH when ETH price was 1500$. Imagine that in 2 weeks ETH price drops to 900$. Alice will still lend 1000$ worth of USDC while only taking $900 as collateral. This will result in pool being drained, since once can use borrowed funds to buy more wETH and borrow again until the pool is empty.
Data Sources
We primarily rely on the Chainlink data feeds as they are least likely to be manipulated.
Data Returned
In order to get the price of the supported token the caller need to use the function called:
This function will return the USD price for the _base token in 8 decimals. One thing to keep in mind while using this function is that it will return a signed value. That is because if the token price can not be retrieved (if feed is not available, or oracle is stale) then function will return -1
Special Tokens
Not all tokens have a chainlink oracle, in that case we can add custom logic into the function called
For example in case of gOHM we are able to query the index from the gOHM contract and then multiply it by the price of OHM we get from Chainlink. This function should also return -1 if the price was no computed in this function.
Non Upgradable
Once the price feed for the token is set, it can not be updated or changed. Special tokens price computations can not be changed either because contracts are also not upgradable. The only way to change the feed is to deploy a new oracle. That will only affect the pools deployed after that point though. This way lenders can rest assured that there is no trust involved for the Vendor team.
What happens if there is no price for a token?
This could happen if the token does not have a chainlink oracle for example. In that case pool should be deployed with a a very high maxLTV value equal to the max value of uint48. That would essentially disable the oracle check. In that case if the LTV grows too high, lender will need to pause borrowing manually.