Zeus I’m supportive of this approach and would like to see us be aggressive here in terms of roll-out (timing and volume). My thinking;
0xFelix 500k-1m seems reasonable for a testing period. I'm surprised how many ohmies are comfortable with 15m being used immediately without audits or testing.
I strongly believe any amount beyond $500k of protocol funds should be gated by a Sherlock or Codearena review.
The audit competition teams can mobilize quickly & more eyes on something like this would be better.
Given Morpho's current rate (1.8 to 2.02% on various stables) and Fraxlend's high supply rates - I think we should better discuss the rate offered. My quick thought is that the lending rate should be equivalent to the staking rate or within several bps
The roll function is interesting, do loans automatically roll? A smaller pilot period of 30d loans could be interesting so we can see the amount of repayment and then scale accordingly from there - these could be pattern matched to the rate of (previous) inverse bonds.
Churchee Yeah, I'd say that sound much more reasonable. Maybe even $1m to start, then an additional 0.5 after it's been around for a bit. Some form of audit is definitely necessary before I'd consider voting for the proposal in any capacity.
15M is far too much to risk on unproven contracts. When we launched OHM bonds with Bond Protocol we did a much smaller trial and that was just risking OHM, and those contracts were partially developed in-house - much lower risk profile than this. And the safety of a small test was proven there very quickly… I can't see how we should risk more than 500K here. With a peer-reviewed audit process conducted - I'd suggest we get the guys from Bond Protocol to advise and bring their learnings to the table.
Even if you're a god of thunder, I don't agree with deploying 15M into unaudited contracts. That's almost 10% of treasury holdings … let's start with smaller amount and use grants for audits.
glad to see discussion on audits. I didn't comment on this in the proposal because I knew it would come up and thought it would be easier to respond to than get ahead of.
I certainly have nothing against thorough review of code to ensure it is safe and secure -- this is a non-sequitur. I'm glad to see this is a strongly held belief across the board. That said, I have my own issues with audits. Having gone through six of them myself, plus through conversations with other devs, I've found audits to mainly suggest cosmetic changes and (if lucky) gas optimizations. I think there is a fair bit of harnessing of fear and the natural desire for accolades/rubber stamps by auditors to extract tens/hundreds of thousands of dollars out of projects while providing no assurances and often missing any real issues (if they exist). They are no silver bullet, or often any bullet at all: I'll evidence this with the fact that Olympus alone has never seen an exploit on unaudited code, but found issues post-release on two occasions with audited code (though luckily we have a fantastic developer community that caught these early and prevented any damage from occuring).
My belief is it ultimately comes down to the code, and thorough peer review is sufficient in cases where code complexity is low and moving pieces are few (as is the case here). My desire is to prevent the needless expenditure of money and time (which carries a direct monetary cost here from an interest perspective). That said, I am in no way advocating for unsafe or reckless deployment of treasury capital. Loss of funds is always the worst possible case and I do not take risk lightly. FWIW this codebase has gone through 10 months of development, iteration, and refinement to make it (as far as I can tell) absolutely bulletproof. But, of course and always, my word alone should not be sufficient.
The decision ultimately rests with all of you. Personally, I believe peer review and staggered live incentivization is enough; but, if consensus is not with me there, I would advocate for a code4rena competition. That is the best process I have seen to date and does a good job minimizing the issues I see with the audit process as it stands. To that end, I have created additional documentation that you can find here which will walk you through each and every line of code in question. I think this is important to make an informed decision here and, if that decision is to go through a formal audit process, I hope it will help there as well. I'd encourage anyone to look, even if you're not a dev; I think it's pretty easy to follow and you might find it fun!
As always, I appreciate the engagement and concern on behalf of the health of Olympus. It is inspiring and in no way offensive to me.
The $15MM amount is far too large for an unaudited contract.
Another concern I have is just who would be the lender of this? Yes, the program as designed is secured lending, but a more aggressive underwriting than traditional margined loans. The rates in this type of lending should be significantly higher than a traditional margin loan given the risk to the lender. If the collateral loses significant value or goes to zero, the borrower has no incentive to repay. The use case would be short term - overnight lending or for flash loans.
When would interest on the loan be payable? P&I due at maturity is risky for the lender.
in short, I would be open but only to a much smaller amount given both the contract and credit risks.
The council would like to provide feedback on the proposal outlined as requested by our mandate in OIP-91. We are supportive of innovative and new products using OHM, and we agree with Zeus that credit markets are an important focus to highlight OHM's strengths. However, we have a few points that require further attention.
First, the timeline proposed is too ambitious. We recommend taking more time to consider the economic impact of this proposal, assess the treasury allocation, and verify the contract's security. A more realistic timeline would be in the best interests of all parties. We do agree with a staggered timeline which would allow for an in-depth analysis after a first phase to assess if further adjustments or deployment is to be considered.
Second, the treasury should only be deployed into verified and preferably audited contracts. While we recognize that not all audits are equal, we suggest engaging a trusted third party, ideally through a community-sourced platform like Immunify/Code4rena, to audit the contracts. This has proven to be the most effective approach in the past.
Third, we request more clarity on the approval process for loans under this model. An AMA with the community, in addition to a more detailed discussion on this forum, could be beneficial for addressing these questions.
Finally, we would like to explore any potential synergies with other partners in this space, such as the recently posted Vendor proposal.
We would like to note that although Zeus is a current member of the council, this proposal did not originate from the council or the DAO, and all governance procedures will be strictly followed, as with all other proposals.
I think the collective stance re: audit is pretty clear, so I will table this for the time being. I have engaged Sherlock and will circle back when that has gotten underway. Since this is a personal project, and the proposal here is for integration, I will be covering the costs associated.
Appreciate the maturity to listen to the community Zeus
