Summary

Following the earlier RFC, this OIP supports the creation of a system of decentralized Olympus front-ends, hosted and managed by third parties. With the ongoing decentralization efforts (e.g., OCG, open development) there is one remaining residual centralized element in the proposed structure that could be a risk factor, the Olympus website/front-end itself. This OIP advocates for the adoption of a modified version of Liquity’s decentralized front-end system, in order for Olympus to become fully decentralized on a smart contract level, on a front-end level, and on a development level.

Background

There are a several reasons why the model of decentralized front-ends is desirable and indeed justified given the current state of the protocol:

• Following OCG and without a group of core contributors the current hosting set-up will likely need to be discontinued or changed as well. Since the majority of users connect to the contracts through the official website an alternative solution needs to be developed.
• Recently announced legislation such as MiCA in Europe seems to make a distinction between DeFi that is actually decentralized and "DINO" protocols. In this context, decentralization seems to refer to 1) permissionless contracts, 2) not a single entity controlling or managing the development of or core services to the protocol, and 3) multiple front-ends through which a user can interact with the contracts. While legislation of this type is still novel, it is worth considering the future implications and ways of remaining compliant - whether that is by moving to a fully decentralized system or through a different set-up.
• With the creation of Cooler Loans there is now an economically viable way of adopting the Liquity model for the protocol - something that used to be the main blocking point for adopting decentralized front-ends and attracting third parties.

Proposed set-up

At a high level, this proposal argues for a Liquity-like model that separates the main Olympus website from the front-ends that interact with smart contracts. The former would become an information hub for the protocol hosting landing pages, dashboards, (technical) docs as well as the forum, while the latter would be hosted by third parties that are incentivized through protocol revenue streams. More specifically:

1) Main Olympus website

The current Olympus DAO website would be converted into an information portal (landing pages, dashboard, docs, forum, et cetera) and would list and link to third party, independently hosted front-ends for all smart contract interactions.

This list of front-ends is a curated selection. The criteria to be included in this list should focus on ensuring all contract interactions are possible (staking, cooler loans, OCG, bridging, RBS) and that the team hosting the front-end seems trustworthy (some level of DD needed).

At the same time, a system of automated (continuous/regular) checks would need to be adopted to ensure that these front-ends link to the correct contracts to prevent malicious actors from stealing user funds. There is a potential solution in place for a system like this.

One thing to note here is that this system will inevitably place an additional burden on users and the community in vetting and promoting certain front-ends. While some due diligence can be done and while automated checks should prevent obvious attacks, in the end users will be responsible for selecting which front-ends to use to interact with the smart contracts.

The hosting of the new Olympus website (without any smart contract interactions), the curation of the list, and the ongoing automated tests of front-ends should be managed with a small, ongoing maintenance budget that will need to be adopted post OCG deployment.

2) Decentralized front-ends

Independently hosted front-ends that allow for smart contract interactions will be incentivized with two protocol revenue streams:

Referral fee on the bond contracts

If a user purchases a bond through a certain front-end, that front-end would receive a small kickback. This feature is already built into the current Bond Protocol contracts but hasn’t been used so far. Note that wall swaps don’t have this fee, since it’s a different set of contracts.

Cooler Loan fees

Either

1. a portion of the interest paid by Cooler Loan borrowers at 0.5% p.a., equivalent to 0.167% per loan term; or
2. a portion of the liquidation incentives arising from Cooler Loan defaults. In the current set-up, a user borrows at 95% LTV and when a default happens the remaining 5% is used for an auction to liquidate the user’s position and subsequently burn the remainder of the collateral. With this proposal, the LTV% would stay the same but rather than allocating 5% for the liquidation auction only 4.84135% would be used for that. The remainder, 0.15865%, would be forwarded to the front-end from which the loan originated.
   This way the incentives for the front-end operator are completely aligned in each scenario: per loan term they either receive 0.167% of the borrowed amount in DAI in case the user repays/extends their loan, or 0.15865% (0.167% * 95% LTV) of the collateral amount in gOHM.

A second core component of the system would be the kickback rate that operators set for their front-end. Rather than allocating the full amount of paid interest or part of the liquidation incentives to FE operators, the kickback rate allows them to compete on total costs and incentivizes operators to lower costs over time as the total number of front-ends increases.

This kickback rate determines the amount of interest/liquidation incentives that are kept by the operator vs. forwarded to the protocol treasury and/or burned. For example, a kickback rate of 25% would indicate that 75% of the 0.167% interest payment/0.15865% of the liquidation incentive is kept by the front-end operator and the rest sent to the treasury or burned.

The kickback rate can range from 0% (the full amount is kept by the FE operator) to 80% (20% is kept by the FE operator). One lesson from Liquity’s experience is that there is a race to the bottom in terms of fees and so a minimum earnings level should be created through this mechanism. This ensures that multiple operators will be able host a front-end for the long-term, improving censorship resistance.

For reference, most operators for Liquity have a kickback rate of >99%. However, one key difference between Liquity’s model and the above is that the user is directly impacted by the kickback rate when interacting with Liquity’s contracts, whereas for Olympus a higher kickback rate would benefit the treasury and all holders. So the incentive to lower fees over time might be less pronounced than what Liquity experienced.

Fee distribution

In today’s situation, without any active bond markets, the total, maximum amount of yearly earnings that could be distributed to front-end operators would be:

1. Bond referral/kickback fee: $0
2. Either Cooler Loan interest or Cooler Loan liquidation incentives: $420,000 $84m * 0.5% interest = $420,000 p.a.^

These incentives should be more than enough to attract multiple front-end operators as well as to incentivize them to increase the kickback rate to >0%, reducing the overall cost of the decentralized set-up.

Implementation

Upon governance approval, this OIP should be implemented post OCG deployment. This will ensure that all of the key elements of an Olympus decentralized front-end (RBS, Cooler Loans, Bridging, Staking, and Voting) are live and that front-end operators don’t have to update their set-up to include OCG at a later stage.

In terms of changes to existing contracts, this OIP will require a redeployment of the Cooler clearinghouse contracts to include referral fees to front-end operators as well as the kickback rate mechanism.

Finally, a front-end SDK should be created that contains all the necessary information and elements to create a new Olympus front-end. This way, the barriers of entry are lowered and FE operators should be able to easily use this package to deploy new instances of the front-end.

We encourage interested parties that want to host a decentralized front-end to reach out and get in touch to discuss the possibilities and get feedback on these ideas.