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

abipup Looking at the votes for this temperature check, do you think we can proceed to the snapshot?

    The proposal contains several questionable points:

    Firstly, Vendor's claims regarding their TVL are misleading. They've cited an ATH of $1.8m but upon closer inspection this applies to their v1, not the v2 that's the focus of this proposal. In reality, the v2 TVL is significantly lower, around $200K. So taking into account the actual numbers rather than the ones being used to sugarcoat things and downplay our risks, if we were to deposit $5m into their v2, our contribution would make up over 96% of their TVL, or +2500% of their current TVL.

    Secondly, considering the substantial investment they're demanding from Olympus—where we have significant capital at risk and they bear no risk whatsoever—it's unclear whether they've put in enough effort to ensure funds are safe. So far, they've conducted only one audit, while Cooler is already initiating a second one. Additionally, their claim of offering bug bounty requests seems unfounded as no official or formal bug bounty program seems to even exist.

    Their attempt to capitalize on an inflated TVL and a fictitious bug bounty program in their proposal introduces a host of uncertainties. It would be their responsibility to take these points more seriously.

      citizen_wayne If the proposal was not for v2 but for v1 instead, would you be in favor, since it has been more battle-tested? Taking into account 0 fees? Also, at what capital allocation would you feel comfortable, $500k was borrowed very fast…

      That is hypothetical of course, just trying to gage your thoughts on Vendor overall.

      Also, Vendor v1 was audited by a Olympus Incubator preferred auditor!

      Cooler has not even been seen nor tested, has 0 TVL! Both our v1 and v2 are in the wild. You seem to be over the moon about cooler passing? So, I am confused 😐

      citizen_wayne In regards to the first point, I don't recall ever claiming that v2 had 1.8m in TVL and apologize if there was any confusion, but the point is: we have managed large amounts of TVL without the presence of Olympus. Additionally, both the v1 and v2 contracts share similar logic - as v2 is largely a more robust version of v1. Considering that both v1 and v2 are audited I can not agree that we downplay anything here. We have also previously received bug reports, which fortunately did not survive any POC test. Had they confirmed any bugs however, we would have been happy to payout. Furthermore, v1 of the protocol is still supported, which the Olympus community is more than welcome to push towards if that makes them more comfortable. So far however, no one has leaned in that direction.

      Secondly

      citizen_wayne considering the substantial investment they're demanding from Olympus

      Vendor is not demanding anything. We have submitted two temperature check proposals for consideration by the community. The community/DAO has then had the opportunity to engage in discussions and collectively determine if the terms in the proposals should move forward. This can be seen through a temperature check vote (found within both proposals). If there is predominantly positive support then a finalized snapshot proposal assembled by the DAO is released, where Ohmies can exercise their governance power by voting on the snapshot. Thanks for your concern

      0xTaiga We need to decide parameters on the following:

      • Lend Ratio
      • Due date
      • Term rate type
      • Term rate
      • Strategy

      Can Vendor team provide some guidance on these terms?

        I think it's ok to move the first two votes outlined here to snapshot, they're the most important ones.

        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:

          1. Deposit $5M on both Ethereum and Arbitrum
          2. Deposit $5M on Arbitrum
          3. Don't deposit into Vendor Finance

          Also, option (1) is still $5m combined, correct?

            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.

              abipup You can actually type them in manually on UI as well🙂

              (https://ibb.co/ph1BvcR)

              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.

              0xTaiga hi taiga, could you please point me towards your bug bounty program? thanks

                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.

                  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.

                    0xcrypto I actually posted two responses and one that addresses the bug bounty is not approved conveniently. I would wait for a full response to be published. Audit report does not indicate the risk of a rugpull. Vendor team has no and never had way to pull funds out of the protocol.

                      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!

                        abipup Good point! We will do that and post an updated version. Thanks for checking in.