Badger ibBTC

Quantstamp5 Aug 2021Files named in the report

Quantstamp reviewed BadgerDAO (Badger ibBTC) on 5 Aug 2021: 13 findings, 0 critical; 2 marked fixed, 10 acknowledged, 1 open.

No open critical findings

Open the report Open BadgerDAO’s security record

Report hosted on certificate.quantstamp.com.

Trustblock does not review code.

Findings13

Statuses are the security firm’s own, from its report.

Severity	Open	Acknowledged	Fixed
Critical	0	0	0
High	0	1	0
Medium	1	3	1
Low	0	6	1

MediumPeaks may be duplicated and cause `totalSystemAssets` to miscountFixed

Peaks are added to the `Core` contract by `whitelistPeak`, which first validates for whether `peaks[peak] == PeakState.Extinct` L155, before adding it to `peakAddresses` , setting the status at `peaks[peak]` to `PeakState.Active` and firing an event. The status of peaks can be adjusted at `setPeakStatus`, which allows for any arbitrary state to be set as long as the current status is not `PeakState.Extinct`. This means that it is possible to have whitelisted a peak, then set its status to `PeakState.Extinct` after, then whitelist the same peak again, ad infinitum. Given that the peak address is not removed from `peakAddresses` when the peak is set to `PeakState.Extinct`, nor does it perform an existence check when adding it, this means that duplicates can happen. This means that `totalSystemAssets`, which relies on iterating through all `peakAddresses`, will count the duplicates and produce a miscounted value.

LowPotential precision loss in divisionFixed

In the `_btcTobyvWBTC` method, a division of `1e20` is performed before the next division of `byvWBTC.pricePerShare`. This is probably done for the purpose of reducing the decimals to an intended `8`. However, given that the useful work is done in `byvWBTC.pricePerShare`, it would make more sense for the purpose of information preservation to perform that first, before `1e20`