# Reliance On Fetching Oracle Functionality

{% hint style="info" %}
[**Book an audit with Zokyo**](https://www.zokyo.io/)
{% endhint %}

## [Unable to transfer WrappedIbbtc if Oracle goes down](https://github.com/code-423n4/2021-10-badgerdao-findings/issues/20)

#### Impact

Within the `WrappedIbbtc` contract, users will encounter an inability to execute transfers if `oracle.pricePerShare()` (found on Line 124) reverts. This issue arises because `balanceToShares()`—a function integral to both `transfer` and `transferFrom` methods—incorporates a call to `pricePerShare()`. This dependency means that any failure in `pricePerShare()` would incapacitate the `transfer` and `transferFrom` functionalities.

It's crucial to highlight that there is an inconsistency in behavior with `WrappedIbbtcEth`, which does not directly rely on `oracle.pricePerShare()` for transfers. Instead, `WrappedIbbtcEth` utilizes a cached value stored in a local variable `pricePerShare`. This cached value isn't continuously updated but rather refreshed only through calls to the `updatePricePerShare()` function.

#### Recommended Mitigation Steps

To rectify this inconsistency and potential transfer issue, careful review and modification of the contracts are necessary. Depending on the intended behavior specified in your design, you will need to adjust one of the contracts:

* If the design requires real-time price per share for transfers, consider updating `WrappedIbbtcEth` to mirror the behavior of `WrappedIbbtc`.
* Conversely, if the design allows for the use of cached values, you should adjust `WrappedIbbtc` to use a locally stored variable for `pricePerShare` similar to the approach in `WrappedIbbtcEth`.

Through these changes, you can ensure consistent and expected behaviors across the contracts, enhancing the reliability and functionality of the transfer processes in both contracts.

## [Should a Chainlink aggregator become stuck in a stale state then TwapOracle will become irrecoverably broken](https://github.com/code-423n4/2021-11-vader-findings/issues/16)

### Impact

Inability to call `consult` on the TwapOracle and so calculate the exchange rate between USDV and VADER.

### Proof of Concept

Should any of the Chainlink aggregators used by the TwapOracle becomes stuck in such a state that the check on L143-146 of `TwapOracle.sol` consistently fails (through a botched upgrade, etc.) then the `consult` function will always revert.

<https://github.com/code-423n4/2021-11-vader/blob/3a43059e33d549f03b021d6b417b7eeba66cf62e/contracts/twap/TwapOracle.sol#L143-L146>

There is no method to update the address of the aggregator to use so the `TwapOracle` will be irrecoverable.

### Recommended Mitigation Steps

Allow governance to update the aggregator for a pair (ideally with a timelock.)

<br>