• General
  • RFC: Expansion of Vendor Finance Partnership

Great write-up, very interested in this.

I actually would like to see an asymmetric deployment to L2 to help spark more activity there (both for LPs and users). Depending on others' comments, I would be most supportive of simply $5M to Arbitrum or a variation of 1:4 etc.

The value here makes sense to me as it would rival Vesta Finance current cap & utilization. Effectively doubling the opportunity on L2.

Excited to see what the community thinks.

Very much in favor of this proposal. Agreed with @Don_G_Lover on favoring greater deployment on arbitrum. Otherwise this is a great proposal in terms of every single parameter (interest rate, capacity requested, LTV etc.) that Cooler proposal can actually learn from.

Absolutely agree with doing both Cooler and this at the same time, as it minimizes overall risk.

I'm all for this. Tbh I would like to see 5m mainnet and 5m arb as it will make for easier refinancing of debt out of other protocols into this.

In favor of a deployment to Arbitrum. Terms should probably match those of Cooler if it is utilized on Ethereum.

    nicnombre I agree with both points. It's probably best if an "all-up" proposal is made for these deployments. In that I'd expect to see:

    1. A total "Lending Market budget" (i.e. 33M seems to be a favourable idea amongst the community) and how it will be allocated across Cooler, Vendor and future platforms. For example:
      - 15M total pool(s) on Ethereum Mainnet
      - 5M total pool(s) on Arbitrum
      - 13M reserved for expansion to meet demand on current and future networks and platforms

    2. Loan Terms for all deployments

      Joel33 I like this. Back to the originator of this post it feels as though the 9.5 borrow amount should go up as LB goes up and wall parameters increase as well. At least there should be some way to revisit this as those things appreciate.

        Shpadoinkal Unfortunately the lend ratio of the pool is set on deployment and cannot change. The TVL available to borrowers changes as the price of the assets change, but the lend ratio remains constant for the duration of the pool. However if this is an issue for everyone, multiple pools could be deployed over time at different lend ratios to emulate the effect of the lend ratio increasing as liquid backing increases.

        The proposed 9.5 lend ratio felt like the safest option for both the DAO as a lender and ohmies as borrowers. With the RBS lower wall being at 9.61 DAI, the chances of borrowing being disabled due to a large price dump are greatly reduced. This also allows the DAO to deploy a single pool and "set-and-forget", which would eliminate the need for monitoring or maintaining the pool

        @nicnombre I am also in favor of deployment to Arbitrum. The costs for both borrowers and lenders would be significantly cheaper, and this would drive further integration and utilization of OHM on Arbitrum

          lorem Wondering if as part of this the bottom wall moves up to LB to be in line with the cooler proposal

            Shpadoinkal Also I would personally prefer to see GOHM as it would enable us to participate in governance. Once of the issues with current lending facilities is no governance abilities for holders.

              Shpadoinkal I'd be interested to hear what others feel about this. For us (at Vendor) both tokens gOHM and OHM work, but it was my understanding that gOHM is to be replaced with OHM over time. I suppose the decision between the two tokens depends on how long the transition from gOHM to OHM will take as well as the length of the pool

              Shpadoinkal That would go against the entire cross-chain strategy and the efforts put into the native OHM deployment on Arbitrum. It would also increase the tail risks of the gOHM cross-chain synthetic asset - i.e. more funds sitting in a bridge contract not controlled by the protocol. Today, already more >$22m of funds are sitting in this contract and if this proposal were to pass with gOHM as a collateral asset that situation would only get worse (and the risks would only increase).

                Shpadoinkal at the moment, we do not have this ability. We could investigate if that can be done though. Is there a good person who would be able to explain how this works in detali?

                  Thanks Lorem - couple of questions:

                  Are there code differences between v1 and v2 other than "Vendor Strategies"?

                  Is the v2 audited?

                  How long has v2 been deployed for?

                  Are the fees charged upfront? Is the 0.3% per term, per a year, or something else?

                  Thanks

                    Mark11

                    1. Numerous code differences exist between v1 and v2, primarily aimed at improving future scalability of the protocol while preserving core functionalities.
                    2. V2 is audited. You can find the report in the v2 contracts repo here.
                    3. V2 contracts have been deployed for ~1 month on Arbitrum.
                    4. Fees are upfront. The protocol fee is charged on a per borrow basis.

                    Ex:
                    Borrower borrows 1000 USDC w/ 5% term rate & 0.3% protocol fee. Borrower receives 1000 - 5% - 0.3% = 947 USDC. 3 USDC (0.3% proto fee) is sent to protocol. 50 USDC (5% term rate) remains in pool for lender. It's worth noting however, that the total amount a borrower wishes to borrow and inputs into the UI is the actual amount of USDC they will receive. The amount of collateral required to back that loan will be adjusted accordingly.

                    Shpadoinkal The naked asset should be fairly easy to add. However, both OHM and gOHM on Arbitrum don't have a build in delegate function as far as I know, and so I'm not sure how feasible it is to include assets in lending markets. It would really only be a temporary thing though (for Cooler as well) because OCG is likely to completely change the voting set-up and I'm not sure to what extent all these assets can be accounted for if everything is done fully on-chain.

                      Lemme see the whole 'Vendor Strategies' thing is presented as something new and exciting. But does it really offer anything groundbreaking to Olympus? And let's not forget where all this comes from. Vendor's system is simply a rehash of the defunct Ruler V2 contracts. Sure, reusing old contracts might be quick and convenient, but is it truly innovative? It's pretty hard not to compare it with the bespoke solutions like Cooler that were built from the ground up, specifically for Olympus.

                      They're quick to trumpet a 99% utilization rate of their V1 pool, but seem to conveniently gloss over the hefty fees that accompanied it. Now they're offering a simplified fee structure with V2, but is that enough to put treasury funds at risk to boost TVL of an unproven protocol?

                      Their call for diversifying our involvement across multiple platforms sounds good on paper. But in practice, it might just end up creating more opportunities for third parties to profit at Olympus's expense. Is that really a gamble we want to take?

                      And then there's the proposal to establish a $5M pool on V2, and the choice to use OHM instead of gOHM for collateral. On the surface, it might seem reasonable, but a deeper look suggests it's a strategy that's more beneficial to Vendor than Olympus.

                      So, yeah, while Vendor's proposal might seem impressive at first glance, we need to unwrap the package and look at what's really inside. It's essential we dissect these proposals to ensure we're making the best decisions for our community. Just food for thought.

                        0xTaiga Coolers are borrower-specific contracts with a delegate() function that allows the owner to point their governance power toward a designated address. Hope this helps.