Oighty

If it wasn't clear by posting here, the purpose of the forum post is to get a temp check before moving to an OCG proposal.

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).

Affected users should be reimbursed because while the contracts were not part of the core system, they were supported on the Olympus frontend and appeared to be so from a user perspective.

Olympus is working towards launching RBS 2.0 which fully automates the real-time on-chain valuation of treasury assets as one of the final steps towards full decentralization (the other being on-chain governance).

A requirement for any treasury asset going forward is to have a reliable on-chain oracle that can be used to get a secure price value for any asset in the treasury (and preferable more than one oracle for redundancy). The oracles that will be initially supported are Chainlink and UniswapV3 TWAPs (where the full range liquidity is large enough to protect against manipulation, see https://www.euler.finance/blog/oracle-attack-simulator for more info).

Given that, does StakeUp have plans to provide an oracle of this caliber at launch? If not, then it's not feasible for Olympus to own it.

Others have discussed the risk/reward of this allocation above. I won't belabor it, but agree that this type of "venture" allocation doesn't seem to make sense. In today's context of Cooler loans, individual holders can choose to borrow a conservative backing asset (DAI) against their OHM and reallocate elsewhere if they see fit. It doesn't need to be done within the protocol treasury.

As one of the developers of the new system and having thought about this a bit, I believe this is a good idea for both Olympus and the OP team moving forward. Here are the points that most resonate with me:

1. The new system is essentially a permissionless OTC market creator. At its core, it enables anyone to create a market to exchange one asset for another without requiring external liquidity. When viewed from this lens, there are a number of different products that can be built on top of it, not just the "Olympus-style" Bonds as we know them (I call these Repeating Dutch Auctions or Continuous Dutch Auctions - CDA was previously used by Paradigm to refer to a different mechanism so may be less clear). Examples include a dutch auction NFT mint, token launches, collateralized bonds, etc. However, a number of these products are not related to Olympus' core mission of creating a decentralized reserve currency; therefore, it doesn't make sense for Olympus to use cycles/pay to develop these kinds of solutions.

2. As its own protocol, the Bond system would be similar to a "hyperstructure" with very low or zero fees at the platform level and allow front-end operators to charge referral fees to markets that they route traffic to, similar to Liquity. A neutral protocol that provides infrastructure for this type of financial primitive will allow tokenized payouts to concentrate in the same asset for equal products. A different way of saying this is that allowing anyone to build off the protocol with no fees removes the risk of forks/vampire attacks and providing network effects for tokenized payouts like more liquidity. Similar to UniswapV2, the permissionless nature of the system makes it a potential target for forking. Instantiating the system as a neutral protocol with no/low protocol level fees removes two motivating factors to fork it and focuses on network growth. The current 3.3% fee model is not likely to be competitive in the future. Other offerings that achieve similar outcomes to OP have come out since that structure was put in place, e.g. Porter Finance and Solv Protocol, and others are being built, e.g. Concave Finance. Therefore, past/existing revenue streams from OP should not be taken as a given for Olympus. Significant work will need to be put into continued innovations on front-end applications (as one in the larger ecosystem), business development, and differentiated services (such as white glove operations and marketing) for partners to continue justifying that type of fee in the market. This will likely require more investment in the near-term than revenues generated by the current service given market conditions (not including development of new products). A separate Bond Protocol allows the team to raise funding to support these efforts instead of Olympus paying for them.

3. The protocol has been developed with Olympus' requirements in mind. All of the types of bonds that Olympus issues (reserve, inverse, and OHM-OHM bonds as well as both fixed-term and fixed-expiration vesting) can be handled by the system. Additionally, the "callback" functionality of the Bond system would allow Olympus to update custom payout handling logic as needed without changes to the core protocol. Since Olympus operates its own interface for bonds and the protocol will not charge Olympus a fee at the infrastructure level, Olympus would not be charged to use the system. Essentially, Olympus doesn't have any operational disadvantage by spinning off the system and has ownership in the new protocol to benefit from the up-side of growth in existing or new market offerings.