• General
  • Towards a Fully Autonomous Olympus

Summary

As a result of the successful passing of TAP-28, the DAO proposes accelerating the automation of Olympus, as well as making necessary adjustments to the 2023 projects and current operations, in order to facilitate the successful launch of Cooler Loans, as well as to further decentralize and automate protocol operations.

Motivation

As stated in the Cooler Loans RFC and related proposals, a key motivating factor for the implementation of Cooler Loans is to optimize for the protection of network value and privatize the risk and reward associated with asset deployment activities. This strategic decision is prompted by the recognition of external macroeconomic forces beyond the community’s control, reinforcing the need to proactively safeguard against potential risks.

While Cooler Loans will effectively simplify and de-risk the treasury to a degree, there is still a need to mitigate or minimize the operational, regulatory, and smart contract risks associated with the protocol. It is the DAO’s opinion that given Cooler and the above stated goals, the best path forward is full protocol automation and autonomy, coupled with the implementation of on-chain governance, allowing anyone to propose code upgrades and build on top of Olympus. We believe that since the protocol is already on this path of minimizing treasury risk, only by doing the same for all associated risks will we put OHM in the best position to achieve its vision of becoming a reserve currency.

With this proposal, the DAO aims to lay out the vision and present a 6-month path to achieve above-mentioned protocol automation and autonomy. It also aims to align existing projects and products with this vision and the realities of what is feasible and advantageous in a post-Cooler world, as well as provide clarity to the broader community and partners. 

The Same Vision on a Different Timeline

Since its inception, the vision for OHM has been that of a decentralized, automated and fully autonomous reserve currency. The job of the DAO (community and contributors) has always been to build out the necessary infrastructure to make this a reality. Over the past nearly two and a half years, we’ve all been doing exactly that, constantly developing the codebase, ecosystem, and protocol mechanics.

With the successful passing of the Cooler Loans proposal, we’ve made an important step towards automating the protocol, by automating the treasury, a historically very manual and cumbersome process. Now, we think that it’s a good time to use this momentum and push for full protocol automation and autonomy within the next 6 months.

By the end of January 2024, the goal is for the protocol to require little to no human intervention to function properly. With the introduction of on-chain governance, anyone will be able to propose code upgrades, assemble their own dev team and even request a bounty if needed to build something out. There will not be a need for a persistent working DAO, which greatly simplifies protocol operations and reduces costs, as well as risks. This would require more broader community engagement than today, but we believe that by simplifying and de-risking the protocol, as well as removing the working DAO, we empower the community to get excited about OHM again and take matters into their own hands.

Parthenon - OlympusDAO’s On-Chain Governance

Parthenon, our on-chain governance system, will have its own proposal detailing the mechanics and asking for permission to launch, but the DAO would like to give a brief overview here, so the community knows what to expect. The implementation details here are still subject to change.

Transitioning from current OIP/Snapshot/Multisig execution flow to a custom on-chain governance system is paramount for the post-Cooler world. Current governance flows are sub-optimal and heavily rely on human intervention to carry out proposals with a passing vote. In an on-chain governed environment this responsibility, and liability, is removed in favor of voting on completed code that is execution ready. 

While there will always be a human element surrounding gathering awareness to gain consensus, the actual submission of a proposal, ability to vote on a proposal, and execution of said proposal, should be automated through a cohesive and secure system.

Currently available “off the shelf” governance systems would require customization and have been found to add risk to the system as opposed to the proposed system that is specifically tailored to Default Framework. 

Parthenon is a governance system built with risk-minimization features specifically to be Cooler-compatible. In particular, upon launch, governance is in a “dormant state”: governance functions, such as proposal submissions and voting, are effectively turned off. In order to activate the governance system, a certain threshold of total supply needs to be deposited into the voting contract. 

This feature is important when migrating to on-chain governance when considering the recent “negligence attacks” in Tornado Cash and others’ governance. In a post-Cooler world, it’s possible that a significant portion of the protocol’s economic interest may not be proactively monitoring the governance system for malicious proposals. As such, it’s important that the on-chain governance system should only function when there is enough signaled interest to participate.  

In addition, Cooler Loans interest and defaults revenue would be directed to this voting contract. We believe this mechanic introduces an incentive for holding OHM as an effective counter balance to Cooler Loans. By aligning Cooler income with network security, the protocol creates tradeoffs that more accurately signal community engagement and interest in ongoing protocol development.

We understand that Parthenon presents a big change to how the protocol is governed and it is important for the community to recognize the added responsibility they take on. As such, we will prepare two additional documents to specify the upcoming proposed governance changes: an article overviewing on-chain governance systems as a whole, and documentation specifying the mechanisms of our proposed OCG system for Olympus. 

The Six-Month Plan

The timelines here will not necessarily be accurate as tasks may be moved up and down the priority list, but the deadline of January 31st should be met for the project as a whole. 

July

  • Cooler Loans development and testing

  • OCA audit, round 1

August

  • Treasury consolidation

  • Liquidity migration to Uniswap v3

  • Staking rate set to 0%

  • Cooler Loans audit & launch

  • OCA development

  • RBS upgrade development

September

  • QA & Testing of RBS Upgrades

  • QA & Testing of OCA

  • Landing page updates

October

  • OCA and RBS audit

  • QA & Testing Parthenon (OCG)

November

  • Cross-chain bridge upgrade

  • OCA launch

  • RBS upgrades launch

  • QA & Testing Parthenon (OCG)

December

  • QA & Testing Parthenon (OCG)

January

  • Parthenon (OCG) Launch

We also propose that the Six-Month Plan be counted as the final pillar project for the DAO and be allocated 45% of the bonus pool for timely completion, as described in the compensation framework. As evident by the plan above, it actually consists of multiple projects, so the restriction of one project not exceeding 33% still holds.

2023 Projects List & Current Project Impacts

Below is a list of projects the DAO has been working on. Some of them are impacted by the Cooler Loan vote passing, and the DAO deems them to be incompatible with the system post-Cooler launch. However, this does not mean these projects could not be re-launched by the community in an on-chain governance world, if circumstances change. One possible reason to re-launch some of the initiatives could be a premium developing and thus emissions being freed up. The following projects are categorized as Compatible, Incompatible, or Rescoped.

Compatible

Cross-chain (Mint & Burn) - Cross-chain involves a bridge using LayerZero to allow canonical OHM to be minted and burned across chains, enables cross-chain OHM, and access to L2 markets. Due to the changes to OCA scope, minor changes to the cross-chain bridge may be necessary to develop. Also, due to the fact that the bridges currently use an emergency multisig, for emergency pausing, this might change the project’s compatibility, pending further analysis. Ideally, we would not require multisigs for the protocol to function in the post-Cooler world.

On-chain Governance - Explained in the above section.

Incompatible

Emissions Framework & Automated Emissions Controller - The advent of cooler loans has effectively addressed the need for an Emissions Framework and Automated Emissions Controller, as the available emissions supply is drastically reduced. As a result, the sources of emissions become simplified, which diminishes the original purpose of these frameworks and controllers. In this post-cooler world, the focus will shift away from current emissions sources, leading to a discontinuation of work on the Emissions projects.

OHM Bonds - In the context of a simplified Cooler vision, the inclusion of OHM bonds introduces complexity and associated risks. Additionally, the reduced availability of emissions limits the capacity for bonds. The decision to stop this project aims to maintain a coherent and efficient strategy within the cooler loans framework and allow for a focused implementation of initiatives that are better suited to the current circumstances and objectives.

Boosted Liquidity Engine / Liquidity AMO -  BLV allows the Olympus treasury to mint OHM (single-sided) directly into liquidity pair vaults against select, high quality assets. The counter-asset is provided by partners directly or from individual holders with partner incentives. The goal of BLV is to generate deep liquidity for OHM across many liquidity pairs in order to establish it as an effective medium of exchange. This is not feasible post-Cooler Loans for a few reasons:

  • Not enough fiscal space: If all of the treasury working capital (assuming $10m) is allocated as backing for BLV (ideally it should be less), then there would be a maximum of $10m in deposits into boosted liquidity vaults. Given that deposits are at $2.3m currently, there isn’t a lot of room for expansion.

  • Risk to backing: if there is a de-peg or considerable impermanent loss in a BLV, leading to more OHM entering circulation, future cooler loans will have a reduced capacity (treasury value same and OHM supply up = lower liquid backing / backed OHM)

  • OpEx: continued rollout requires engineering work (implementations for more partners, integrations with more liquidity providers) and BD (convincing partners to use BLV), which counters the motivation to achieve full autonomy.

We therefore propose to stop onboarding new partners, leave capacity as is while Cooler is launching, and to re-evaluate as a community when OHM achieves a sufficient premium over backing.

Lending AMO  - The Lending AMO is the first foray of Olympus into DeFi credit markets, with the aim for OHM to not just be a good collateral asset but to become a good borrowable asset as well. More specifically, the project aims to test minting OHM directly into lending markets. This is not feasible post-Cooler Loans, for similar reasons to BLV:

  • Not enough fiscal space for general lending markets (i.e. not credit account style markets): this similarly requires backing from the treasury, which is not available

  • Risk to backing: if a lending market is hacked, OHM can enter circulation and affect the capacity of Cooler Loans

For these reasons we propose that the current Lending AMO contracts be deactivated and that no more new OHM is minted into lending markets. As capacity in lending markets decreases, the treasury will be able to take out existing deposits until the protocol-supplied capacity is zero. 

Rescoped

Treasury Management - Per TAP-28, the Treasury team is working to set a discrete loan value as a result of the passing vote. Thereafter, the scope of the Treasury team’s activities will be significantly reduced. 

On-chain Accounting - As noted in other project sections, the voted-on Cooler configuration makes some products that Olympus has built incompatible with the future protocol state. OCA was designed to support some of these products, such as CDP, lending, and emissions controller with various on-chain calculations. Since these are no longer feasible, the scope of OCA can be decreased to simply what is required for the existing products to run in a more automated fashion, specifically: 

  1. Deploying a generalized PRICE system, allowing the use of multiple oracle providers and simplifying codebase.

  2. Automating RBS management by using PRICE module and SPPLY module to calculate liquid backing per backed OHM.

RBS 2.0 - The implementation of Range Bound Stability (RBS) v2 will be canceled as the previously planned system is not compatible with the approved Cooler parameters, and therefore is not as effective or necessary as initially intended. Instead, efforts will be refocused on automation of the current RBS system, adding asymmetric spreads and expansion of the cushion spread logic to two independent parameters: upper and lower cushions. Automating the system increases reliability and decentralization; no more “humans in the loop” will be needed to actively maintain the system. Separating the cushion spread parameter into two, one for upper and one for lower cushion, allows us to maintain the current target price logic while adhering to the lower cushion requirements of Cooler Loans. Specific changes that should be made:

  1. Integrate On-chain Accounting modules (see above) to automate 

  2. Operator updates

  3. Asymmetric spreads created, with lower cushion value at 2.5% and upper cushion value at 10%

Staking

Per OIP-133 the community voted in favor of setting the staking rate to zero after the implementation of Lending, Leverage, LP farming, and OHM Bonds. Since these products are impacted by Cooler, we propose that the staking rate be set to 0%, as staking is a source of emissions which are undesirable in the post-Cooler world.

No migration would be needed as gOHM simply lives on with no utility besides being Cooler Loans collateral.

Liquidity

We propose to migrate $5m of liquidity from Balancer to Uniswap v3 on mainnet, deployed in a full range. The remaining liquidity in Balancer will be withdrawn and split into reserves. We also propose to migrate the Arbitrum OHM-USDC and gOHM-WETH POL positions to Uniswap v3 on Arbitrum, deployed in a full range. Uniswap routing has proven to be far superior for OHM, so we expect to see higher utilization of the protocol liquidity on that platform. Furthermore, POL on Uniswap v3 guarantees an on-chain price oracle via the v3 TWAP functionality. This adds oracle optionality and allows for integration with protocols that don't use Chainlink.

Conclusion

The DAO is excited about these changes to the protocol, as this is a culmination of all the work done so far and something all of us have been building towards since the start. We will allow for plenty of time for discussion before moving this to an OIP and Snapshot vote, as the vision for Olympus has to be shared by both the contributors of the DAO and the broader community. 

Thanks for posting this. Let's give plenty of time to get feedback on this RFC before moving forward. Lots of topics to discuss here!

Excellent write-up. If this passes, those deposited in Cooler will not have voting rights. should we then launch Cooler with OHM since voting is the only reason gOHM as collateral was needed? gOHM has historically been a major source of confusion for many and making it obsolete would work to simplify the protocol for new entrants and make routing easier for whatever is built on top of Cooler.

    notSHAFT Yes, we think that would be the cleanest solution, but will have to confirm with nic. The Cooler Loan depositors wouldn't have gov rights in the OCG world, so it wouldn't make sense in the time until OCG launch either. I'll include this implementation detail here as soon as we hash it out with nic.

      GL! Proposal looks solid imo.

      There was some discussion about this on the DAO Work Server and I wanted to add to the scope of the RFC, if possible.

      Currently, there is quite a bit of OHM supply that exists in discrete contracts that have been deployed by our deployer contracts.

      Examples include, the Inverse Bond Contract (Pre RBS), etc.

      Today, we have to account for and extract all this OHM in the supply calculations since it is out of circulation. For the OCA part of this RFC, this adds additional labor and complexity that we'd like to eliminate if possible.

      Ask: Community approval to pull all out of circulation OHM from the discrete contracts they are held in to the Treasury Multisig. This OHM will continue to be unbacked and out of circulation but it moves the supply to a single, discrete place. We would also ask community permissions to programmatically burn this OHM at some point in the future. This would have no material effect on LB since the math already excludes it but it does grant us authority to execute code and burn the supply.

      Context: We've been given legal guidance that the programmatic burning of supply (Like RBS does) is legally allowed. Ad-hoc burning where a discrete individual performs an action that burns supply is to be avoided. There's important legal nuance to this.

      Suggest this ask gets included in the OIP.

      Thanks for the detailed write up.

      No qualms here, quite excited to see the OCG documentation.

      shadow while I disagree with anyone using cooler losing all of their voting rights I do like the mechanism of voting being incentivized. Unfortunately I'm unsure how to balance all or nothing but it doesn't feel great to have a product that we want people to ultimately use but the byproduct of that is not being able to be active in governance. With this said given all existing lending markets are basically using gohm it could get pretty messy to get rid of gohm until a full transition to OHM occured. Unless I'm missing something.

        Shpadoinkal We can never get rid of gOHM. Users will always be able to unwrap for the underlying OHM; no liquidity is needed.

        The proposed design builds a simple and autonomous Olympus protocol. We shouldn't sacrifice that so that people can have their cake and eat it too. With that said there is no reason for gOHM to be a collateral option for Cooler.

        Write a Reply...