Thanks @KemarTiti and the Pyth team for the proposal !
From the technical side, we think it is a good moment to give some extra context to the community about the rationale of the fallback oracle and our position on it.
The fallback oracle is a mechanism introduced with Aave v1, not really used since then, but kept in order to enable any potential integration of a mechanism to cover an edge case of the primary oracle.
Its logic is the following: if at any point a primary price feed (Chainlink) would return 0 or a negative value for an asset, the AaveOracle smart contract would try to call the address configured as fallback oracle to retrieve an alternative price.
This scenario is a really edge case, because once there is a price on-chain on the primary oracle, for it to become 0 or negative, there should be a malicious update.
Later on in the lifetime of Aave v1, and with v2 and v3, it was realized the scenario is almost not possible, as it implies not trusting the security of the primary oracle; which would disqualify it for Aave to start with. Thus, the fallback was first not really active (v2) and completely disabled later on (v3).
As we commented with the Pyth team, from BGD we don’t really see much value in the fallback oracle as it is, given its “legacy” nature, but if it doesn’t create any extra burden to the community (e.g. additional cost), we don’t have a strong stand against enable it.
As always, it is up to the Aave community to decide.