4848

Relwyn · Nov 24, 2023

RFC Purpose:

The goal of this RFC is to submit one potential vision on how Olympus may grow to the next phase of its existence: Scale and Adoption.

As the system now feels operationally complete (Cooler Loans being a final vertical, allowing scaling access to extrinsic value, but with with OCG vs. Optimistic Multisig remaining), I wanted to put forth some structured ideas around the future to promote discussion and action. I plan on entering capital into the governance system that ultimately gets deployed, such that I can propose discrete, actionable scopes of work to see these ideas realized. That said, I wanted to organize and share my thoughts for constructive criticism and peer review.

Scope:

This RFC is intended to be broad and serve as both a temperature check to community as a whole, as well as a starting point to identify if there is requisite, aligned power to reach quorum in the OCG system to implement the proposed vision effectively. OCG, as written, has specific requirements to move from a dormant state into an active one. One requirement is enough capital in the system to even propose and I commit to taking that on. The other is that enough voting power enters the system, votes and is willing to take on illiquidity following to pass things. As such, I think gaining effective commitment and alignment to the vision will help minimize the probability of surprises. Planning is low cost and I want to be respectful to those voters since their capital and their time is important.

At a high level, the document (Outlined in a Medium Article below) speaks to the following:

Acceptance that, in the future, a centralized DAO will not exist as an axis of power but, if successful, ongoing building over the top of the protocol will happen for the foreseeable future.
Empowering community to act as owners and stakeholders in the protocol and thus enabling them to use its function, at a grass roots level and in permissionless way, to build valuable structures over the top of it.
Create better, low friction means for social coordination and collaboration.
Defining specific key verticals where effort should be directed and lay out a plan for how community can participate in those, rather than being a product of them.
Re-invigorate the culture so that new people entering the system can find a community worth actively engaging with vs. remembering the community and culture that used to be.
Having fun.

The full RFC is memorialized and can be found here: Olympus - A Vision Forward

Timeline:

I intend to leave this RFC open through the end of the year, largely because the actionable components will be realized through (And thus are blocked by) OCG. That said, I was eager to socialize the broad ideas, establish who was supportive and who wanted to go in different direction. I think this helps define what the playing field looks like for FY24. As OCG gets realized and deployed, more targeted efforts will be submitted with discrete Scopes of Work and asks to the community.

In the meantime, I will create a thread on the Community Server surrounding this topic so that there can be real-time discussions in Discord as well as asynchronous discussions here on the forum. Will also coordinate some Twitter Spaces so that the reach can be expanded more broadly and outside of the echo chamber that Discord can create.

Conclusion:

I'm looking forward to discussions around these ideas. Please share your own, constructively criticize gaps and together, we can mold the future.

Ooga,

-Rel

0xFelix · Nov 9, 2023

RFC Purpose

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.

Summary

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.

Why?

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.

How?

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.

Incentive structure

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.

Alternative solutions

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.