I think it's ok to move the first two votes outlined here to snapshot, they're the most important ones.
TAP-26 - Expansion of Vendor Finance Partnership
abipup The idea was to follow the terms that would be accepted by the community on the cooler loan votes. Since we do not charge additional fees, we should be able to match them close. The main difference would be an amount: that would be the second vote in this case. In terms of strategy that would depend on whether you guys have bridged USDC or new native Arbitrum USDC.
Thanks for checking in with us, and please let me know if there is anything we can do to help with snapshot vote.
I don't see the need for two votes, just have the terms as laid out in Cooler (if you have no other requests there) and add the following options:
- Deposit $5M on both Ethereum and Arbitrum
- Deposit $5M on Arbitrum
- Don't deposit into Vendor Finance
Also, option (1) is still $5m combined, correct?
- Edited
shadow Yes good point, that's more streamlined. Based on the feedback we've gotten so far and the interest we've seen for Cooler loans on Mainnet, we feel that it may be a conflict of interest for us to also launch on Mainnet. So we've chosen to reduce the vote to two simple options:
- $5 million on Arbitrum
- No deposit into Vendor
This will give access to smaller Olympus token holders and allow them to participate in borrowing/lending on a cheaper chain. It will also allow users to choose which platform fits their needs more
0xTaiga Okay no problem, i was just confused because the Vendor frontend doesn't look like it supports setting up a specific Loan Amount (2850 DAI per gOHM, for example), just 25/50/75%. But if that can be configured in the backend then it's ok with me.
Since Snapshot is having issues today I would like to wait until we get official word from them that it's resolved to post. Idk if making a snapshot now would work after whatever fix they make, for example.
- Edited
abipup You can actually type them in manually on UI as well
I have tried to add an image but it does not render here. You can just simply click on the number in Create Pool widget to type it in manually.
0xcrypto We have always maintained the "Report A bug" section in the top bar menu of our V1 site (which is still there). Additionally, we are currently in the process of migrating it to the V2 UI (it is now live on the menu bar of V2).
Our current treasury constraints require us to exercise caution, so as a result, we work closely with bounty hunters on a case-by-case basis when determining payout amounts. We appreciate every report we receive and thoroughly review each one. We are fully committed to rewarding any legitimate findings that contribute to the security and stability of our platform.
The absence of a structured and professionally managed bug bounty program does not reflect favorably on Vendor's commitment to security. It's disconcerting to think that bounty hunters are expected to devote their time and resources with no predetermined compensation structure in place. The fact that treasury constraints are cited in this context not only seems like a peculiar consideration but also somewhat of a bad excuse. This lack of a formalized approach to vulnerability discovery and remediation becomes even more worrisome when we delve into the audit report.
Regrettably, there's another pressing issue that hasn't been addressed and about which Vendor hasn't been transparent. It turns out that their auditor flagged a high centralization risk within their v2 protocol, which presents a potential rug pull scenario. As per the audit report (page 24), the Vendor team holds the power to pause repayment functions, effectively forcing borrowers into loan default. The quote from the audit report reads:
"In the given contract setup, the owners of the LendingPool implementation have very strong control of the activities in the pool [...] During the time between pausing and unpausing, pools can expire, and the borrower(s) will all default on their loan and lose their collateral as soon as the pool owner gets access to call collect(). In the current audited code, there is no possibility to remediate this situation after a pause." (Audit report from Zellic, page 24)
This revelation puts borrowers in an extremely precarious position, susceptible to the actions of the Vendor team, or any other party, should Vendor fail to secure their wallets properly. Its also conceivable that Vendor could just rugpull and then disappear. Vendor's response, which merely acknowledges this centralization risk while alluding to the use of a multisig, does little to allay concerns. What's more alarming is Vendor’s lack of transparency about this substantial risk. Their disregard for addressing this issue or their choice to belittle it as inconsequential suggests one of two troubling possibilities: either Vendor deliberately avoided transparency on this crucial matter (for whatever reason), or they deem it unnecessary to fix, a sentiment fundamentally opposed to the principles of decentralization. Both possibilities paint a concerning picture of Vendor's approach and commitment to security.
The implications of this scenario are, frankly, alarming. Should we, at Olympus, be expected to place faith in a protocol where Vendor has given itself the authority to halt repayments and trigger loan defaults at their discretion?
Consequently, endorsing this proposal in its current form appears to be highly irresponsible, to say the least. Vendor needs to fix their smart contracts and submit them for another independent audit review before presenting another proposal here. Until such actions are taken, endorsing this proposal seems pretty reckless. And the fact that they haven't been transparent about this issue is deeply concerning. Our community members deserve better than this.
citizen_wayne I believe you may be placing excessive reliance on bug bounties. As an auditor myself, I can assure you that in the majority of cases, individuals are either criminals or they are not. If you were a member of security groups on TG, you would observe that white-hat hackers often attempt to establish indirect contact with the team if direct contact proves unsuccessful. They will go a long way because they believe that is the right thing to do. For individuals who are not criminals, clicking a single button on our home page is actually a straightforward task. In fact, our process is simpler compared to many other platforms like Immunefi, which require a proof of concept right from the start. We thoroughly review all reports we receive. That being said, we genuinely appreciate your feedback and will examine the possibility of establishing a more formal program once our treasury is more firmly established. Regarding the excerpt from the report you have provided, this matter has been discussed with the Zelic team. With all due respect, when protocols are compromised, individuals such as yourself are often the first to express dissatisfaction with the team's perceived lack of vigilance in pausing operations. To address the specific concern raised in the report, repayments and other operations are paused independently. This allows us to enable individuals to repay while keeping the rest of operations paused if needed for further investigation. Furthermore, it is important to note that Vendor V2 does not profit from defaults, so there is no incentive for us to engage in such behavior. The only party that would benefit from defaults is OlympusDAO, as they would receive significant default amounts. There is nothing for us to gain from such actions except damaging our hard-earned reputation and the protocol we have diligently built.
On a separate matter, I am compelled to urge individuals to examine the registration date of the account "citizen_wayne" and review the posts made by this user since then. It is evident that this account was established with the sole purpose of undermining our proposal and exclusively expressing praise for the counter-party. I strongly encourage anyone who comes across this statement to assess the user's posting history and the timing of their contributions, as it becomes apparent that their primary concern lies elsewhere, rather than ensuring the safety of DAO treasury. If that were not the case, this individual would be posing similar questions and concerns regarding the other proposal, which is less battle-tested and established. However, this user appears to show no interest in that regard.
We will not further engage in the conversations with his user, as we see time and time again those are not constructive and our points are simply ignored. Other than that we are always open for constructive criticism and we hope we demonstrated that.
- Edited
thanks for elaborating on the bug bounty, taiga, appreciated. so to summarize: i) neither v1 nor v2 have a proper bug bounty program in place, ii) the existing audit report conducted by zelic indicates a high level of centralization, which increases the risk of a rug pull (even more worrisome considering vendor is not doxed), iii) olympus investing up to $5m would mean that we'd account for >95% of vendor's future TVL and iv) the vendor team itself is not assuming any risk.
curious to hear what the rest of the community thinks about this but imho this doesn't sound like a favorable deal for Ohmies.
Hi 0xTaiga it's cleanest to repost this with the clarified parameters (namely following the Cooler loans params), and vote decision between $5m on Arbi and No deposit
My worry is that this becomes too difficult to track along comments, and simply editing the post makes the unofficial vote invalid.
Thanks!
5 days later
Would the lend ratio go up as price goes up? Or would it be fixed at 9.5?
Shpadoinkal Fixed at 9.5 for the duration of this specific pool. The lend ratio can then be changed on a rollover pool in which other terms such as the loan tenor, interest etc. can also be voted on being changed if desired.
For example, launch with the 6 month pool with the terms laid out in TAP-26A. During those 6 months we can devise a structure on how to quickly and easily vote for any rollover pool term changes should that be desired in order to adapt to the market (i.e. higher lend ratio due to OHM price appreciation).
p.s. Did you mean to comment in the TAP-26A post?
Joel33 not sure but my point is 9.5 is going to look like an unattractive LTV shortly here and we should monitor it leading up to a vote/launch before locking this in. The price OHM has moved as a result of all these discussions.