Context
Olympus has deployed a modified version of the GovernorBravo system (originally by Compound) to use for onchain governance (OCG). Up to date information about the system can be found on the Olympus documentation site.
As a safeguard against potential issues and following best practices used by other DAOs, Olympus’ GovernorBravo is upgradable using a proxy pattern. This allows, among other things, OCG proposals to upgrade the Governor logic itself to patch certain types of issues with the contract.
In line with the activation of the GovernorBravo system executed by OIP-166, Olympus commissioned another audit of the code from yAudit. No major issues were found and the proposal proceeded with activation. However, there were some minor issues that were deemed appropriate to address in a follow-on proposal. We are now here.
Audit Results
yAudit’s full report from their audit of the OCG system can be found here.
No critical or high severity issues were found, and none of the issues put any funds at risk. There were 3 medium severity issues and 4 low severity issues according to their rating system.
To directly quote their final remarks in the report:
“OlympusDAO has selected a solid and battle-tested option to implement its on-chain governance system. The review has identified some issues within edge cases for the functionalities added by the client, which can lead to an inability to execute proposals when the system enters the emergency state or allow an attacker to brick a proposal’s execution under rare conditions.
Additionally, the review has identified a theoretical attack vector by which an attacker can inflate or deflate a proposal’s quorum requirements: at the time of the report’s writing, the largest relative manipulation possible was around 1% of the non-manipulated amount.
Overall, the system lies on solid foundations that have proven reliable for normal state operations. In the case of emergency state operations, additional care and testing should be applied to verify that the system processes proposals correctly, both when their entire lifecycle occurs with the system in emergency state and when the system switches state during it.“
Remediations
After receiving the audit results, Olympus devs reviewed the results with yAudit and developed a remediation plan. We either remediated or there are existing mitigations in place for all of the issues raised..
The issues that were fixed are M3, L2, L3, L4, and I5.
M1 is not fixed because the likelihood is very low and the impact is minimal (would simply need to resubmit the proposal). Additionally, it would require a change to the storage layout which we wish to avoid.
M2 is not truly fixable without deploying a new gOHM token, which would be a significant undertaking and has many downstream effects within the Olympus system as a whole. The impact of the issue is constrained to the amount of OHM that is flash-loanable (less than 1% of supply). We also have the option to mitigate this issue entirely by enabling a staking warm-up (but with UX costs for users) if needed in the future.
L1 is more of an inconvenience than a true issue in that overpaying for an execution that requires native ETH can result in the executor overpaying. This can be resolved by refunding the executor at a later time.
The remediated GovernorBravoDelegate contract (which is the implementation contract the proxy GovernorBravoDelegator references for its logic) can be found in this Pull Request on the olympus-v3 repository. It has been deployed and verified at this address on mainnet: 0xdE3F82D378c3b4E3F3f848b8DF501914b3317E96.
In order for the updated contract logic to take effect, an OCG proposal must be passed to set this address as the new implementation contract. This is done by calling the _setImplementation(address) function on the GovernorBravoDelegator contract (which is the canonical Governor address used for OCG).
