VIP-6: Voltage Finance Lending Network

Summary

Ola Finance proposes to build and deploy a lending network in partnership with Voltage Finance. Ola will build and maintain the technical aspects of the lending network while providing ongoing risk advisory support. As the owner of the customized, branded lending network, Voltage has the power to list tokens, adjust parameters, and request additional features.

The Voltage lending network will not only provide lending/borrowing capabilities for the token ecosystem of Fuse Network (ie. VOLT, FUSE, etc.) but also serve as a source of revenue for Voltage Finance. As borrowers pay interest, a percentage of that interest will be removed into a reserve fund which will be split between Ola and Voltage. The percentage of borrower-paid interest getting removed (ie. the “Reserve Factor”) is one of many parameters determined by Voltage.

Background

Ola Finance is a technology provider that offers lending-as-a-service to its partners. Ola enables projects to own their own white-labeled lending network while receiving ongoing technical upkeep, risk management advisory, and custom product development support. Each lending network is highly customizable, allowing the owner to select which tokens are supported and tune a variety of related parameters.

Voltage Finance is the DeFi hub native to the Fuse blockchain. They offer a powerful suite of DeFi tools including trading, yield farming, and staking. The native token of the platform, VOLT, serves as a governance token which gives the community the final say on major decisions that affect how everyone interacts with the protocol. Community proposals can be posted on forum.voltage.finance for discussion before being brought to a vote (pending significant traction) on https://snapshot.org/#/voltagefinance.eth.

Security

The Voltage lending network, built on top of Ola’s platform, will include a number of safety mechanisms and risk management features. First and foremost, a recent upgrade introduced two important corrections to Compound’s original codebase thereby enabling support for ERC-677 and ERC-777 tokens. These two corrections are:

  1. Global Re-Entrancy Locks:

The original locks implemented in Compound’s codebase prevented re-entrancy within a single Money Market (MM), but not across multiple MMs. The Global Re-entrancy Locks prevent this kind of cross-market re-entrancy.

  1. Corrected Checks-Effect-Interaction Pattern

When calling borrow and redeem functions, this correction makes it so that we first register the “effect” (ie. the loan taken or collateral withdrawn) before completing the “interaction” (ie. sending the tokens to the user). This fixes the original Compound code which has this logic reversed.

These changes were reviewed as part of our most recent audit. The audit, conducted jointly between the Solidifed and Oak Security teams, was the second audit that Ola Finance has undergone. Both audit reports can be viewed here.

As an additional measure of accountability, Ola Finance has created a public Token Report to confirm that the token standard and transfer logic for all tokens (across all Lending Networks) has been thoroughly reviewed for possible re-entrancy vulnerabilities. This Token Report is consistently updated and can be reviewed here.

While risk prevention mechanisms are the golden standard, Ola also offers a number of unique, hard-stop parameters which significantly limit potential damage to the lending network:

  1. Active Collateral Cap (ACC)

The ACC represents the maximum value of a particular asset that can be used as collateral across all users, at any given time. The ACC has multiple benefits, such as limiting fraudulent borrowing power (eg. price manipulation attack) or the amount of an asset seizable through liquidation.

  1. Borrow Limit

The Borrow Limit caps the total amount of an asset that can be borrowed across all users, at any given time. This cap can prevent a potential exploiter from borrowing all of the funds from a particular market.

Outside of Ola’s immediate architecture, a couple service integrations will offer additional protection for users. First, Ola is in the process of getting listed on InsurAce, a leading insurance provider in the DeFi space. This will allow users to purchase optional coverage over their funds, further protecting them against various risks. Second, Ola is completing its bug bounty listing on Immunefi. This program will offer a payout to white-hat hackers who securely report any contract vulnerabilities and aid in the revision of Ola’s smart contracts. As with all lending networks deployed on Ola, the list of utilized smart contracts will be made publicly visible in Ola’s gitbook.

Conclusion

Ola provides Voltage Finance the infrastructure to easily bring lending and borrowing capabilities to the Fuse blockchain. The variety of security measures - both preventive and reactive - can be flexibly adjusted, helping the safety of the lending network without compromising its scalability.

Polling Period

The polling process begins now and will end in one week, at 14:00 UTC on 10/07/2022. After this, a Snapshot vote will be put up.

  • Deploy a Voltage Finance Lending Network
  • Do nothing

0 voters

2 Likes

Thanks for reading the proposal! I would love to hear your thoughts and feedback, and I’ll be answering questions in this thread all week.

1 Like

Thanks for the proposal. Personally I would not advice Voltage to have this construction, as there is a shared responsibility. We should learn from the past and not leave any room for confusion.

Common practice in risk management is to make the party responsible that is able to influence/ accommodate the risk best. In this situation that clearly is Ola. They are most on top of the latest news on vulnerabilities in lending and also can use their experience/ expertise from other networks to benefit the protocol most.

I would suggest:

  • Ola to run and own the lending network;

  • Voltage to only suggest parameters/ tokens, which will always strictly have to be approved by Ola;

  • Voltage to receive a fee (as proposed) for integrating the Ola lending protocol in their interface and therefor promoting the usage of the protocol.

Any other model will result in unclarity about where responsibilities lie.

Personally I will not be voting for this proposal, but only a proposal where Ola is owner and takes final responsability.

On another note, referring to discussions in the past, I am wondering:

  • Who will provide rewards for lending and how?
  • Who will do liquidations and take profit of those?
3 Likes

Thank you for contributing your thoughts to the discussion and supporting them with suggested action. To first answer your questions:

  • The incentive mechanism is highly flexible and distributes rewards according to the discretion of the owner. This includes which tokens are distributed, the distribution rate, and the length of the distribution program. That said, a reward program is optional and not a requirement to deploy a lending network.

  • Liquidations are available to be completed by any public liquidator, as this helps ensure the health of the network; naturally, the liquidation incentive would then go to whichever entity completes the liquidation. In addition to public liquidations, Ola runs its own advanced liquidator bot to ensure liquidations are completed.

Unfortunately, I don’t believe it’s feasible for Ola to own the Lending Network due to its structure as a B2B technology provider. We hope to bring lending/borrowing capabilities to Fuse to support the diverse token ecosystem and seek the right partner to build for to accomplish this.

That said, Ola’s experience/expertise will still be offered through ongoing support. Allowing Ola to focus on technological development and research is, in my opinion, the way to most benefit the protocol.

1 Like

So, what difference does it make if the lending network is owned by Voltage or owned by Ola?
Assuming there is no rewards program and Voltage shows it on the UI, will there be a difference?

1 Like

So what does it actually mean to own your own lending network?

The Owner of the lending network has the decision-making power to tweak parameters, add support for new tokens, accept logic upgrades and other feature implementations to the network, and admit various other changes. In addition, the Owner benefits from earning revenue generated from the lending network.

When we talk about a Voltage Finance lending network, we mean a network that generates revenues for Voltage Finance and allows lending/borrowing functionality for a variety of their ecosystem tokens.

While Ola’s focus is on building and developing lending infrastructure technology, another project could in theory launch a lending network that supports the token ecosystem of Fuse and Voltage. Since Voltage would not be the owner, they would have no share of the revenue or say over the risk profile (ie. which tokens are used as collateral to borrow VOLT, how much can be borrowed at once, etc.). Being the owner of your lending network gives you this freedom.

I hope that helps add some clarity!

2 Likes

What’s the fee % for Ola and Voltage?

From the post it suggested Voltage get to decide the reserve fund parameter. Is this the fee and if so, there must be min/max limits on this?

For voltage - let’s use a % of this fee to buy back and burn Volt, the remaining % to buy volt and reward stalkers.

1 Like

Yep you’re right - the “Reserve Factor” is the fee % for Ola and Voltage. It’s defined as the % of borrower-paid interest that goes to Ola and Voltage instead of going to the lenders.

There is a minimum set at 5%, but no technical maximum. The average reserve factor across other LeNs is about 20%

2 Likes

Thanks, what was the avg $ daily fee for Ola/Fuse from the previous Fuse/Voltage LeN?

1 Like

The big difference is that Voltage (as the explicit owner) would be responsible for potential new vulnerabilities in the Ola protocol. I think we should learn from the past and consider that as not being an option?

If Voltage would still consider it as an option; are the returns so high that it is worth the risk of another vulnerability? I cannot believe they are… If I’m right on that assumption and if Ola would not be prepared to take ownership (as they state above), why not consider another lending network?

Again; I think the party responsible for building and maintaining the code should be owner, because ownership comes with responsability for vulnerabilities/ hacks. If Voltage needs to be on top of the code (because why would you risk taking responsability for code you don’t know?) and stay updated on latest ins and outs on lending vulnerabilities, it makes no sense to use a 2nd party protocol, but it would be more sensible to build the code in house.

3 Likes

Looking at a snapshot taken from February 2022, it looks like it was generating an annual revenue of $55,078 or $150 per day

2 Likes

Thanks for the proposal!

Someone in the Fuse Unofficial Telegram group suggested partnerting up with Lossless.
During the recent Harmony/Horizon Bridge exploit, Lossless team managed to save 78M $AAG tokens (valued at ~$800k during the time of the exploit).

Would something like this be an option for Ola?

Regarding some questions that have been asked before, i think one of the main concerns is responsibility in case of another exploit. Is it possible to put in simple words who would be more responsible in case of a negative event, Voltage or Ola?

Also, props to the Ola team for going for another audit. The idea to run a bug bounty program on Immunefi, as well as the idea to get listed on InsurAce is a great move towards assuring the community the team is actively working on improving security mechanisms.

1 Like

Thanks for starting this thread! I appreciate the visibility

I’d like to know more about the Active Collateral Cap. I’m concerned the cap could result in users not being able to earn interest on their deposits if it is used up, or that a malicious user could hold the “ability to borrow” hostage by consuming all of the collateral cap. Have these angles been addressed? Will the ACC change over time to match market conditions? If so, will it change automatically or will a privileged role control it?

I’d like to see a formal plan to monitor related codebases and forks. For example, a process setup to look for pushes to any github repos which have also forked compound, or are similar to Ola finance (for example, AAVE or Rari’s Fuse). This way, issues which may affect Ola can be detected early and Ola can leverage the efforts of other open-source devs

Have you considered on-chain monitoring? For example, running a monitor on protocol balances and investigating any significant changes within a certain period of time? It would also be helpful to see a plan for properly shutting down the protocol and removing user funds in the event of an unforseen vulnerability.

Finally, i super appreciate creating an ImmuneFi bounty program. In my opinion, Ola should be completely open-sourced. Security only comes from having lots of eyes on the code, not the reverse.

I support the buyback of VOLT if this is intended to be part of the Voltage Finance Ecosystem

I don’t think having a “responsible party” in case of losses is necessary. This is DeFi after all. The great interest rates and potential gainz from DeFi come from taking a risk… deal with it :stuck_out_tongue: Still, Ola should make this abundantly clear in their UX, with a message to the effect of “Don’t put funds you can’t afford to lose in the protocol”

4 Likes

I don’t understand how Ola is not ashamed about proposing again their lending network and their perpetual fees after how they made the big re-entrency hack happen and how they reacted so poorly.
I would not understand if Fuse accepts again to take this risk of ownership. This vote doesn’t make any sense to me.
Go continue your spooky lending on Fantom and don’t make Fuse users lose again their funds.

2 Likes

+1

they ain’t compensate users yet with their usdc promise and want to be back now :thinking:.

i get fuse needs a lending network but can’t we find something better?

and the annual revenue figure’s just 1/6 of what fuse put to compensate users

Please don’t trust this vote as long as the possible answers are not clear.
It’s completely oriented by Ola so voting for deploying a lending protocol on Fuse doesn’t mean voting for Ola deployment.
No need for a Snapshot vote when your vote proposal is so disoriented.

1 Like

Looking into additional partnerships to help enhance security is always an option. This is why we have completed an Immunefi bug bounty (officially launching on July 19th) and are in talks with insurance platforms as well.

As for your other question - there is no simple way to say who would be responsible, as an exploit can occur in so many different ways, from improperly tuned parameters to smart contract vulnerabilities. Therefore that question is not so black or white.

2 Likes

The ACC is a very powerful parameter that is meant to reinforce the safety of the network and can not be “used maliciously”. First, it does not limit a user from earning interest on their deposits. EVen if the ACC has been reached for a particular asset, more can be supplied and will still be lent out to earn interest. That additional supply simply cannot be activated as collateral and borrowed against.

In addition, the cap is dynamically adjusted to market conditions so it can always be raised and allow for more borrowing (the converse is true too). There is little incentive for a malicious actor to hold this ability to borrow “hostage” anyhow so this is not viewed as a risk. The ability to adjust the ACC is done so by the owner of the lending network.

Ola has also developed an on-chain price monitoring system that add another layer of safety to the lending network. One way that we use it is to determine when reported prices on the Lending Network deviate by a certain amount from its actual price as represented on sites such as CoinGecko. This, in conjunction with the ability to pause borrowing/minting across money markets, is a useful tool in preventing/mitigating exploit impact.

Thank you so much for your thoughtful comments as they were a constructive addition to this proposal. Let me know if there are additional points to be addressed.

1 Like

Agreed.
We all expect transparency and regular checking of the security status.
With the new audit, bug bounty program and deal with InsurAce, i think it’s fair to say the lending platform will be in a safe spot.

True, it really isn’t a black/white question.

1 Like

We need a way to borrow against existing yield farms i have already deposited VLP tokens to. Would be cool to borrow against those vlp tokens just like how stock investors can borrow against stock shares in companies they own.