Venus - ERC4626Oracle

Some ERC4626 implementations, such as [OpenZeppelin's](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/extensions/ERC4626.sol), may have more than 18 decimals. For example, if the OZ implementation is used on an asset that has 18 decimals and the decimal offset is chosen to be 1, then the ERC4626 token will have 19 decimals. (See [here](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/441dc141ac99622de7e535fa75dfc74af939019c/contracts/token/ERC20/extensions/ERC4626.sol#L99C5-L108C6)). There are assumptions made throughout the codebase that the decimals of tokens are less than or equal to 18. If such an ERC4626 token is to be supported, we recommend carefully reviewing to ensure that it does not cause any potential issues within the protocol.

The `correlatedToken` is assumed to be an ERC4626 vault, and the input `underlyingToken` must be the asset of the vault. However, it is not checked that the asset of the vault is the input `underlyingToken`. If the incorrect `underlyingToken` is chosen, it will result in an incorrect underlying amount returned and thus will result in inaccurate pricing.

The `ERC4626Oracle` contract relies on the security of the underlying ERC-4626 implementation and the behavior of the `convertToAssets()` function. The following specifications should be ensured for every ERC4626 token that is to be supported with this oracle. - It **must** comply with the [ERC-4626](https://eips.ethereum.org/EIPS/eip-4626) specification. - It **should** have been audited and is free from share manipulation vulnerabilities. In particular direct or stealth donation attack vectors should be properly mitigated. - It **should** be non-upgradeable or if it is upgradeable the upgrade authority should be well trusted and carefully monitored. - It **should not** incorporate fees, otherwise, `convertToAssets()` may return an inflated share price as it does not account for the fees charged. - It **should not** incorporate custom logic, such as delayed withdrawals or other constraints that can affect share value. Such mechanisms result in the share value being less than the amount of assets they can be redeemed for due to the delay and available liquidity. Vaults using other custom logic should be considered on a case by case basis to ensure proper integration. - It **should not** include flash loan functionality. If the vault allows flash loans, then during the flash loan the vaults balance will decrease and may manipulate the return value of `convertToAssets()`. - It **should be** highly liquid to ensure negligible slippage when converting shares to assets and vice versa. Otherwise, `convertToAssets()` may be inflated.