The goal of this RFC is to introduce the general idea of decentralized front-ends for Olympus and is meant to kick start a discussion and gather feedback. The details of the design need to be spec’d out separately if there is sufficient interest and support in pursuing the model outlined in this document.
This RFC argues for the creation of a system of decentralized Olympus front-ends hosted and managed by third parties. With the ongoing decentralization efforts (OCG, open development instead of contributors) there is one element in the proposed set-up that remains centralized and an attack vector, the Olympus website/front-end itself. By adopting a modified version of Liquity’s decentralized front-end system, Olympus will be able to become fully decentralized on a smart contract level, on a front-end level, and on a development level.
There are a few different reasons why the model of decentralized front-ends make sense in 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 for the protocol to operate in a compliant manner in the future - 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.
At a high level, this proposal argues for a Liquity-like model:
- The current Olympus DAO website would be converted into an information portal (landing pages, dashboard, docs) and would list and link to third party 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 accessing user funds. There is a potential solution in place for a system like this.
The hosting of the new Olympus website (without any SC interactions), the curation of the list, and the ongoing automated tests of front-ends could be managed with a small, ongoing maintenance budget that will need to be adopted post OCG deployment.
Key to any successful adoption of decentralized front-ends is the incentive structure for third parties. For Olympus there could be two sources of revenue for front-end operators:
- A 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.
- A part of the paid interest rate of a Cooler Loan at 0.5% p.a. This is likely to be the majority of incentives for any front-end operator, especially in the current environment where bonds have not been sold in a long time.
Similar to Liquity a kickback function could be created to allow front-end operators to compete on total costs and to incentivize them to lower costs over time.
It could function something like this:
- The interest paid by a user on their Cooler loan (0.5% p.a.) is directed to the front-end operator rather than to the protocol treasury.
- Every front-end operator would set a kickback rate for their front-end, which determines the amount of interest that is forwarded to the treasury vs. kept by them. For example, a kickback rate of 25% would indicate that 75% of the 0.5% interest payment is kept by the front-end operator and the rest sent to the treasury.
- One consideration is setting a maximum kickback rate (e.g. 80% instead of 100%). 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 could be created through this mechanism. This would ensure 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%. One 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.
In today’s situation the total, maximum amount of yearly earnings that could be distributed to front-end operators would be:
- Bond referral/kickback fee: $0
- Cooler Loan interest: $405,000 $81m * 0.5% interest = $405,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 maximum cost of the decentralized set-up.
Instead of adopting a system of decentralized front-ends, a periodic RFQ/RFP process could be launched to select a new party to host the Olympus website (including SC interactions). A practical concern here is that if governance in OCG is not active then no new parties will be able to be selected and/or paid.