Ola Finance
Global Governance
Governance Over Platform-Level Changes
Note: At this time, we only talk about the scope of Ola's global governance and not how proposals are made, voted on, etc.
Global governance decisions go into effect in the Registry contract. The registry is responsible for providing LeNs with global data (eg. asset prices) and with their own state-transition functions. That is, to execute a request, a LeN must query the registry for its own logic (we clarify this point in the following subsection). The scope of Ola’s global governance is the information stored in the Registry contract - any information in the Registry contract and only such information is subject to global governance decisions.‌

Contract Implementations and Logic Upgrades

Money markets are split into 2 parts: the "proxy" and the "implementation". The proxy stores the MM's state, such as the oToken balance and borrowed amount of each account, as well as parameters like the Collateral Factor, Liquidation Factor, etc. The implementation, on the other hand, obtains the logic and rules that the MM adheres to (ie. what conditions must be met for an account to take a loan, withdraw collateral, etc.)
It's important to note that Ola's architecture places the implementation for each MM in the registry. Thus, when a proxy MM is requested by a user to perform a task, it must first query the Registry for its own implementation; that is used as a set of rules to determine if it can complete the task.
This approach enables seamless upgrades to the rules of all LeNs in one action by simply changing the reference to the implementation in the registry. After the change, a LeN that queries the registry for its current logic would be directed to the new set of rules. To be more precise, Ola’s governance does not force LeNs to upgrade their logic whenever a new implementation contract is added to the Registry. Rather, Ola adopted an opt-in approach, where LeN creators need to actively accept upgrades in order for them to take effect in their LeN.

Price Oracle Selection

Reliable and accurate price feeds are a core part of the Ola platform. As there are a plethora of oracle solutions with relative strengths and weaknesses, Ola determined that different assets would benefit from different oracles. Therefore, Ola's oracles comply with the following design choices:
  1. 1.
    Across all lending networks on a particular blockchain, a token should have the same price at all times (ie. assuming LeN1 and LeN2 are both built on BSC, WETH price on LeN1 should always equal WETH price on LeN2).
  2. 2.
    It would be up to Ola’s global governance to determine which oracle provider is used for each asset. That is, the Ola protocol would integrate with as many oracle solutions as possible and then governance would make the decision as to which oracle is the best fit, per asset. For example, reporting prices from Coinbase (as was done in Compound in the past) might be the chosen oracle for ETH, but not for DAI (see the DAI liquidation events in Compound in November 2020), for which Chainlink’s oracle might be used.
When a LeN needs a price for a specific token, it queries the registry for the contract that may return the price for that token. It then queries that contract for the price and uses it within its internal calculations.
Ola’s global governance can change the address that the registry holds for each token's price feed contract. We shall also note that assets for which the registry holds the zero address are not accepted in Ola LeNs. Thus, the first step for a token to be eligible in lending networks is to have a price oracle in Ola's registry.

Whitelisted Interest Rate Models

‌Interest rate models are an interesting area for innovation in the decentralized lending space. We can think of multiple designs that would be interesting to experiment with. That being said, there are many interest rate models that don’t make sense whatsoever, and that should be denied by the platform.
To accommodate this tension, we decided that a LeN creator would have the freedom to select among a rich set of interest rate models already whitelisted, and if their idea for an interest rate model doesn’t already exist, they can whitelist it by passing a governance decision.
Copy link
On this page
Contract Implementations and Logic Upgrades
Price Oracle Selection
Whitelisted Interest Rate Models