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.