• Proposal
  • TAP-26A - Expansion of Vendor Finance Partnership

yieldohmie

Vendor v1 has been live for almost a year with OHM having already had a pilot program of $500k which was instantly borrowed at max capacity. V2, while new, has been deployed for a little while now with no issues. I understand the concern of it being newer but the changes make things more Capital efficient and more transparent fee structure. We have had an audit as you allude too and have done everything to ensure safety of the contracts including internal testing and peer reviews of the code.

An initial deployment with 500k was already done via v1, proving more capacity is needed for the v2.

It looks like you are in favor of Cooler with a capacity of 69m, yet it has not been launched or tested, so this is confusing to me regarding the reluctancy.

    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.

      I would propose a compromise to scale to $5m deployed over x amount of time. Perhaps a similar schedule as what's on OIP-144?

      This should address concerns of "new code being used" while also still committing to providing meaningful loan liquidity to users.

        abipup Yes I agree, this would be a good compromise. Here are some clarifications regarding the lend ratio and the deployment schedule:

        • Lend Ratio of 90% being calculated at the time of the pools deployment

        • Demand based schedule for the deployment, starting with an initial deposit of $1M and an upper limit of $5M:

          • $1M initial deposit (2x previous pilot deposit)

          • Once $1M is borrowed and 1 month from deployment date has passed, increase to $2.5M

          • Once $2.5M is borrowed and 2 months from deployment date have passed, increase to $5M

        With this in mind we believe that now is a good time to proceed to the snapshot vote.

          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.

            lorem

            The deployment should be contingent on Vendor successfully achieving their milestones to attract their own TVL on v2 outside of Olympus, rather than relying on a fixed deployment based solely on timing. Additionally, considering that only 50% currently support deploying the pool, it might be prudent to reconsider if it's too early to proceed to the Snapshot vote…

              citizen_wayne Only going to comment on your "Insider Relationship" point as I believe it pertains to myself. Sadly you never responded to me when I replied last time on one of your TAP-26 comments…

              citizen_wayne 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.

              This is wrong on all levels:

              • For one, I am no longer a paid contributor at Olympus. Am I still an "insider" and if so, what influence do you possibly think I have as a discord moderator?
              • "Prospect of a retrospective airdrop as bait": This is a baseless accusation with no evidence whatsoever.
              • I haven't spoken in the Olympus discord for over a week now, with this TAP-26A post being posted 3 days ago. Therefore, I wouldn't classify that as actively pushing for the proposal and trying to "lure" the community.

              I am personally in favour of using Vendor because of my personal experience using their platform for my own DeFi needs, not for any other reason(s).

              You are clearly only here on the forum to spread FUD and misinformation about Vendor for some strange and unknown reason. If you really felt this strongly and actually had valid points then I believe you would not hide behind an alt account that was coincidentally created just after the original RFC post from Vendor, similar to a few other accounts that have posted negatively about Vendor.

              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.

                Joel33 Because this appears to be a high risk undertaking (with a new and untested version carrying a substantial centralization risk based on the latest audit), it is important for us to establish milestones based on Vendor's capability to attract TVL from sources other than Olympus.

                When you run out of arguments, it is noticeable that you tend to resort to attacking the integrity of others. This behavior raises serious questions about your real intention. Rather than addressing the actual points being discussed, you choose to undermine the character or integrity of the individuals involved, which is highly questionable and greatly diminishes the credibility of the conversation. Constructive dialogue should be grounded in logical reasoning, evidence, and respectful engagement, avoiding personal attacks.

                  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.

                  • Jem likes this.
                  Write a Reply...