TAP-26A - Expansion of Vendor Finance Partnership

yettywapp

With only a single audit depositing 5mm is seriously not appropriate no matter what other proposal or currently ongoing. For example, look at the Morpho TAP, they have the most audits, tons of TVL, and are considered extremely secure - even there we proposed a 500k deployment.

Besides that, I want to make sure that: This is not the stance of the DAO, it's my personal opinion.

Also, meanwhile, cooler loans is undergoing a second audit to further strengthen the contract.

My recommendation stays: To decrease deployment to 500k and increase if there is sufficient demand to a maximum of 1mm to keep the treasury exposure at a conservative 0.5% of the treasury.

abipup Lend Ratio is computed at the time the pool is deployed. So say OHM is $11 on the day the treasury decides to create the pool. In that case at a 90% LTV the lend ratio will be set to 9.9. That value is going to be constant for the duration of the loan.

Just reading through other proposal and had some big concerns. As mentioned already, 5M for one of our own is debatable enough, but 5M for a smaller protocol that outside of our partnership has almost no TVL, one audit and no proper bug bounty program (report a bug on website is a joke and not best practice!) is way too risky. Also, 3.3%! why not just put it in a T-Bill protocol and earn 5+%?!? 3.3% at high LTVs is a bad deal! At the very least, I agree with yeildOhmie above that should be shrank down by an order of magnitude to 500k. Last thing, I don’t think Vendor will be able to scale (admittedly I also think this might be a problem a bit with cooler loans, but Zeus is an OG here and had the idea first!). If we have to do long drawn out debates and votes every time we adjust the LTV or APR a bit, that seems like a nightmare...

I'm personally for this on the condition that we are able to review the contracts and audits.

There's about $10M in borrowed capital against OHM being charged high interest rate; providing alternatives such as this is key. Having this available on Arbitrum aligns with the goal of driving adoption of OHM on L2s.

I also hear the concerns about the size of deployment, and deployment into V1 doesn't mean much if V2 is a major upgrade (security guarantees are not carried over). Is there something to review of how V2 is different?

unbanksy33 We are more than happy to do a code walkthrough with OlympusDAO dev team and provide any source code/audit report. The major difference of V2 is addition of strategies and the ability to deploy different types of pools (that is a factory difference and does not really matter on a pool level). If the DAO wants to be as conservative as possible in regards to security, strategies can be disabled for your pool as they are optional. In that case changes are minimal. Once again we are more than happy to walk you guys over the code at any moment.

unbanksy33 I understand and value your perspective regarding the necessity of borrowing solutions for OHM. However, when contemplating the allocation of $5 million into a newly released v2, which currently only possesses $250k in TVL and lacks extensive testing, it becomes essential to evaluate the potential risks and rewards. It is also crucial to bear in mind that even seemingly minor alterations of the smart contract can significantly impact its security and might also open up new attack vectors.

To mitigate the associated risks and adopt a more cautious approach, I suggest that our investment be contingent upon Vendor achieving specific milestones. For example, we could initiate our deployment with $100k, already representing a 40% of their total v2 TVL. Subsequently, as Vendor v2 attains predetermined thresholds, such as reaching $1 million TVL (excluding our investment), we can gradually increase our commitment.

By adopting this approach, we can effectively monitor the development and stability of the v2 platform while minimizing our exposure during its initial stages. Implementing milestones linked to Vendor's performance enables us to establish a measured and responsible investment strategy.

It is disconcerting to see that the Vendor has not taken previously raised concerns seriously, but rather is trying to rush this proposal through without appropriately addressing any of the highlighted issues. As already discussed in https://forum.olympusdao.finance/d/3337-tap-26-expansion-of-vendor-finance-partnership/20, the proposal has several significant deficiencies and weaknesses, including serious security concerns raised by their auditor. These issues are only exacerbated by the odd way this was promoted and shilled within the Olympus community, with an attempt to win favor with an insider to persuade the community into allowing the Vendor to receive a substantial investment. This would be terribly misaligned, with Olympus taking on all the risk while the Vendor takes none (very different to our in-house Cooler proposal). They're also looking to subsidize borrowing volume with a very aggressive LTV (again where the Vendor wouldn't take any risk) at a comparatively low interest rate. To summarize, there are several major deficiencies that make supporting such a proposal irresponsible:

• Centralization risk: Vendor's auditor has raised serious concerns around the centralization risk of their v2. As per the audit report (page 24), the Vendor team can pause repayment functions, effectively forcing borrowers into loan default. The audit report states: “In the given contract setup, the owners of the LendingPool implementation have very strong control of the activities in the pool [...] In the current audited code, there is no possibility to remediate this situation after a pause." (Audit report from Zellic, page 24). Vendor attempted to dismiss this issue by asserting that they wouldn’t have any incentive to act maliciously, which is a dismissive and insufficient response to such a serious concern. To highlight the absurdity of their argument, let's take Vendor's argument to its extreme. If we accept that a system is secure simply because the admins say they won't act maliciously, we invalidate the very essence of DeFi and might as well just trust them with our whole treasury.
• No clear bug bounty program: The Vendor's lack of a properly structured bug bounty program is worrisome. A clear, transparent, and incentivizing bug bounty program is a cornerstone of robust security practices in the crypto space. The absence of such a program raises doubts about the Vendor's commitment to ensuring their platform's security.
• Misleading Information: There are serious concerns about the accuracy and transparency of the information provided by Vendor regarding the TVL in their v2. We should expect precise information from a project requesting a $5m deposit. However, Vendor has repeatedly offered misleading details, suggesting that their v2 smart contracts are reliable because they have previously held $1.8m of user funds. They intentionally or unintentionally failed to specify that the $1.8m TVL figure pertains to their v1 and not v2, into which they are requesting us to deposit.
• Unreasonable Deposit Request: Vendor requested a $5m contribution from Olympus. For perspective, Vendor's all-time high TVL was around $200K. Therefore, the proposed Olympus contribution would amount to 25 times their current TVL, which appears excessively disproportionate. This behavior implies that Vendor's main interest might be exploiting the Olympus treasury by hastily advancing the proposal without adequately addressing all the significant concerns raised. The fact they dare ask for $5m again, despite previously expressed concerns, suggests indifference towards community apprehensions and a desire to take advantage of the Olympus treasury. This view is further reinforced by their demand for the Olympus treasury to lend at an aggressive LTV ratio, essentially shifting the risk onto us while subsidizing Vendor's borrowing volume.
• Insider Relationship: Vendor has maintained close relationships with an Olympus insider to promote and shill the Vendor partnership within the Olympus community. This relationship seems to involve an enticement from Vendor, using the prospect of a retrospective airdrop as bait. The Olympus insider appears complicit, actively pushing Vendor's proposal, thus luring the community towards potential support.

In conclusion, this proposal from Vendor is not only riddled with severe deficiencies but also fraught with dubious practices that cast serious doubts about its legitimacy and prudence. Centralization risks, lack of clear security practices, misleading information, an excessive deposit request, and suspicious insider relationships cumulatively paint a worrying picture. These factors indicate a severe imbalance of risk and reward, leaning heavily towards Olympus bearing the potential fallout. The seemingly dismissive attitude towards addressing these substantial concerns further exacerbates the situation.

0xcrypto The deployment schedule is both time and demand reliant, not just time based.

Reason for this is so that:
1. Capital is only deployed when certain demand levels are proven.
2. Capital is only deployed when contracts have seen more usage from a security perspective.

These were concerns from the community/DAO that are satisfied via the proposed scheduled deployment. I also do not remember a time when a proposal was contingent on third-party milestones and so why is that necessary now?

I'm afraid I am also going to have to call into question the validity of your account due to when it was created (12 days ago), which was 4 days after TAP-26 was posted. Along with the fact that you've also only exclusively commented on Vendor related proposals in an overly critical manner.

0xcrypto I don't run out of arguments, you just choose to ignore them. This is also the first time I've ever responded to you and the only other person I've questioned regarding their legitimacy is citizen_wayne. Both of you who almost only exclusively comment on Vendor related forum posts, created your accounts within the last 3 weeks and have no presence anywhere else outside of this forum?

As for my intention, it is to expand OHM utility on Arbitrum as I personally operate very heavily on that network and believe Vendor is a good platform to do this on due to my past experiences with using their product. Many other OHM holders will be in the same camp as to wanting more OHM utility on Arbitrum as well as it tying in closely with the DAOs work regarding cross-chain OHM.