Proposal to integrate Yearn and have the DAO earn revenue via its partner program

I’m ready to VOTE! 1f60d

Hello, another Yearn contributor dropping in to say we would love for this to happen. I think DAO to DAO collaborations are great ways we can work together and align our ecosystems.

  • I originally allocated money for project management and UI/UX for a couple of different reasons:

    I think now is the time to experiment with outside work stream proposals to see what makes the most sense. I was planning on using this as sort of a test to see what this looks like and break down costs in a detailed way for the project management piece to see if its accurate. I think this adds value to the community in the long term to get a good idea of costs on a project.

  • In the proposal, I have that the work streams approve the work before payments are made, which aligns with Willy’s suggestion, so I think payment could go through that as well.
  • If this work is done on off hours by engineering, I think there needs to be allocation for other team members that will very likely be working off hours as well.
  • Hi, I think this is a lovely idea. I think helping the treasury is a great space to be looking at projects from. I do have some questions.

    What is the projected ROI timeline for this project? If the goal is to add liquidity to the treasury. I am unsure of the returns of these types of projects, so I just am looking to learn and ask questions I haven’t seen asked yet. So I apologize if this is a dumb question.

    Why just a jump over the original post of costs in the latest proposal? The initial post said 100k fox tokens, the proposal says $120k worth of fox, which is a drastically larger amount. I am relatively new and am not sure about the costs of these types of projects, but it just seems like a large jump. From about $68.6k to now $120k.

    Thanks for any answers/conversation continued from this.

    Hi ! Thanks for the great questions.

    I’m still working on the ROI piece, but to answer your second question about cost: I spoke to some of the centralized team to see how many engineers it would take and how long it would take to complete this work. Based on those answers (5 engineers and 4 weeks) I came up with the cost estimate. I also made the request in USD worth of FOX because it gave a better expectation of how someone working on the project would be compensated, and ideally motivate them to participate in it. Let me know if you have more questions about this!

    Thanks so much for the response. When you figure out the ROI piece, I’d love to see the data and what you come back with. 1f642

    • I think now is the time to experiment with outside work stream proposals to see what makes the most sense. I was planning on using this as sort of a test to see what this looks like and break down costs in a detailed way for the project management piece to see if its accurate. I think this adds value to the community in the long term to get a good idea of costs on a project.

    I hear you, but I think the Osmosis proposal will satisfy that experiment, and think that this next proposal would be a great opportunity to experiment with a feature going through the product workstream. My only recommendation here would be to remove the Product/UX portion of the budget and instead reward product contributors via the workstream budget proposal that should be made later this week.

    In other words, because we’re already planning to make a proposal to fund the full-time product contributors that will likely be working on this, I don’t see the need to request a separate budget to reward those same contributors.

    Just my 2 cents. Appreciate the context you added and willing to support whatever path forward you think is best.

    I agree with Willy on this, it would make the most sense in my opinion to have this UX & design portion flow through the workstream.

    I think this clearly has strong support and is pretty ready to move forward to boardroom ideation whenever you feel it’s ready 1f642 !

    The integrations will offer fox interface users options to provide liquidity and earn interest on their holdings. The only question I have is what should the expectation of a user be upon completion of all the milestones.

    There are many types of valuts that yearn has. Anyone that uses any number of DeFi applications will have some familiarity with the amount of options these protocol to protocol integrations provide (strategies).

    Right now the only Fox pool I know of is a Fox/Eth UniswapV2 pool. Other protocols allow their users to provide liquidity to that pool and mine the liquidity through their user interfaces. Is the yearn integration based upon this pool (Fox/Eth Univ2) where the DAO (or corporate Shapeshift) launched with a user interface to provide liquidity, or is this a yearn integration that allows Fox application users the ability to provide liquidity to additional yearn vaults for Fox rewards? If so, how many vaults will Fox application users be able to provide liquidity to?

    I think the plan is to give users access to all Yearn vaults. Currently this does not include any FOX-related strategies, but if Yearn were to add one then we would of course support it as well.

    To the user, the experience would be seeing all of the available strategies and the corresponding deposit token and APY. The user could select a strategy, deposit the necessary token, and begin earning yield in the deposit token. ShapeShift DAO can also consider incentivizing users with additional FOX rewards, which I would personally support as like says, this could make ShapeShift the best interface for using Yearn.

    Thank you for the clarification. What would be the difference between providing liquidity to the Fox/Eth pool and a yearn vault as it relates to the Fox rewards. The more liquidity that the Fox/Eth trading pair attracts the better. As of this writing the total liquidity is sitting at approx. 21M. Many tokens, especially the less volatile stable coins, liquidity reaches the 100s of millions.

    I would hope the yearn DAO support providing liquidity to the Fox/Eth pool for said Fox reward, has that been part of the DAO to DAO discussion?

    Weighing in from engineering here.

    I think this a great concrete proposal to drive revenue to the DAO.

    My focus would be on optimizing where users with the largest wallets can connect. Serious defi users only user browser based dapps with hardware wallets or MetaMask.

    Logically this will be the new open source version of the platform that will support all popular hardware and software wallets that the existing defi community use.

    I would not support this proposal, and would be vehemently against, adding support to the existing web and mobile platforms, due to the direct and immediate time and cost to add this to legacy code, the cost to support this revenue generation (AWS and engineering time), limited wallet support, and the fact it’s moving in the wrong direction (towards centralization).

    I’m fully in support of this proposal in the new, web based, open source version of ShapeShift, which supports all major hardware wallets, with the highest TVL or AIO (internal ShapeShift metric - Assets In Orbit, i.e. the total value of assets in wallets connected to our platform).

    More TVL in Yearn → more affiliate revenues → more DAO revenue.

    The Yearn Vaults would be a different option for users to deposit different assets. Currently, there is not a FOX Yearn vault and as said the FOX rewards would be used to incentivize users to use ShapeShift to deposit into Yearn vaults/select their strategy. The value in this is that it brings revenue to the DAO. The DAO can earn up to 50% of the fee Yearn charges, but it depends on the TVL ShapeShift DAO provides to the vaults. So, if users deposit more through ShapeShift, it creates more revenue for the DAO.

    There are/have been conversations about extending FOX rewards for the current LP pool (in discord). To me, these are two different options for users. Users can deposit into the FOX/ETH liquidity pool and use Yearn as another way to earn on other assets.

    appreciate you weighing in on this and understand where you are coming from regarding an engineering perspective and the drive towards the best resource allocation amid open source and decentralization efforts, but I respectfully disagree in this case. I want to see the integration in as many places as possible if there is funding to support the work getting done and today the vast majority of ShapeShift users are on mobile and the current web platform.

    Leaving aside the point that the new open source platform (which we of course all strongly support and want to see the yearn integration in as well) is not out yet and will likely not reach feature parity with the current platform for some undetermined amount of time (probably measured in months not weeks), If we leave out where the majority of current ShapeShift users are right now we are operating against the current network effects of ShapeShift which I think would be a big mistake.

    Yearn integration into the mobile app is critical IMO and one of ShapeShift’s differentiation points right now from others apps. We don’t have a plan to replace the mobile app right now contemplated yet and it’s where the majority of user owned wallets are + offers the best user experience today when using ShapeShift.

    I think we are much better off finding a way to do work that can offer further functionality in both the new web app and the current web app + mobile apps simultaneously as much as possible, such as by integrating unchained work into current platform so we don’t have to duplicate work (an idea Adam was saying we could explore to get the best benefits of adding new chains in the short term), rather than just abandoning our network effects right now during this critical period of time where they matter so much to keep the community on a path of growth.

    I don’t see any harm in having broken out bounties for different parts of the work in the proposal (open source app, current web app, and mobile apps) and if no engineers step up to claim the bounties for something like current web or mobile then, so be it at that point, it won’t get done, but I think the incentive should be there and it would benefit the community to do so and have more options to spread this critical functionality to more users, and importantly drive more ShapeShift DAO revenue sooner.

    Ultimately any bounties placed on this would need to be engaged by interested engineers working on their own time to complete, I don’t think we should be mandating they should not work on also adding this functionality to the current apps if they are voluntarily willing to do so to pickup additional bounty incentives, I think the benefits to the community would be more than worth it to fund and have that work completed.

    I am on the other side of this, if this proposal only incentivized adding this to the yet to be released, and not at feature parity, open source web app - and did not include bounties for current apps, I would be quite reticent to vote for it as I would not feel like we would be looking out for where the users currently are and thus not looking out for the ShapeShift DAO community’s best interest at this time.

    +1, well said .

    Once we have a better idea of what the LOE would be to add this to the current web app, I agree it’s worth considering only prioritizing this functionality in the new web app, and pointing users from current shapeshift web and mobile to the new web app to utilize Yearn. If we support wallet connect on both the mobile and new web app, ShapeShift mobile users wouldn’t be left out.

    I also think it will help inform this decision once we have a better understanding around how soon the new version will be useful/stable enough to point users there. If we think we’re ~1 month out, I’d be strongly in favor of only prioritizing it in the new web app. If we think we’re ~12 months out (please god no) then I’d be strongly in favor of prioritizing this in old axiom web and mobile. I imagine the answer is somewhere in between, and curious what you think about this

    I do agree with some of ’s thinking above that much of this depends on how far out feature parity is for the new open source app (and I am personally skeptical that will be any sooner than 2-3 months if not like 6-12+ months but would love to be wrong on that).

    But even then I don’t think we should just ignore and not work on the mobile app where the vast majority of the users are, I still think that is worth the time and effort to provide a great UX, but granted if we got wallet connect functionality in the app and things could be supported that way I might start to shift my perspective.


    The level of effort to integrate this into the new open source version would be an order of magnitude less than into the existing codebase. It also means the we can lean on the community for maintenance, bug fixes, and improvements.

    It also opens us up to users that actually have serious funds associated with wallets. We need to be focusing users with 6, 7, 8 figure portfolio wallets.

    This is probably a higher level discussion outside the scope of this specific proposal in regarding the strategic goals of the ShapeShift DAO and the role of the existing platform and mobile app.

    To quickly summarize my position from a financial perspective - I view the current centralized platform as a massive cost center and antithetical to decentralization. Running the infra, and the labor to maintain and work on it is essentially the cost of goods sold - we need to offset that before we see a net profit. The sooner we can move away from it the better from a cash flow perspective, and a community engagement perspective - currently only centralized foxes (or newly onboarded centralized foxes, if that will be a thing?) can work on it, limiting our talent pool and stunting community developer engagement.

    The cost of running the new open source version is dramatically lower from an opex perspective, and the revenue derived from allowing wallets with serious balances to connect and use affiliate services will dwarf the value of wallets in mobile or that are currently able to connect to the platform.

    Totally understand and agree with those points - and agree this is probably getting a bit off the topic of this particular thread.

    I don’t have a good view today on what it takes to get the open source web app to feature parity with the current one and what our plan is regarding the mobile apps and how to maintain those moving forward (I think they add great value and I would be against just not having apps in the store in the short term, but for something like a web app wrapped in a native wrapper and deployed in the stores).

    If we get a better idea of the timelines of some of these things then I think there could be a better higher level strategic plan of how long these other apps should be maintained and when we should be moving 100% of the efforts to the new open source efforts. With the info I have today I can not endorse such a plan to not keep adding features and supporting the current apps where our users are. With more info, discussion, and understanding I am of course more open to changing my perspective on this, but with the info I have today still prefer to see a bounty to get this yearn integration multiple places.

    I do think there is a lot of uncertainty and/or lack of clarity in regards to timing of the opened sourced version of this. I think it will be really valuable to get alignment on the timeline for the open sourced version for this proposal and other ones. My goal is to get a better understanding of this by the end of this week.

    I do think that if it is months before users can use the open sourced version, this needs to be added to the current platform and mobile. However, if that is not the case, then I think we can explore the possibility of pushing users to the new version through the old version and incentivize users to start using the new version.