Unless there is weighting it is not gonna be slightly it’s gonna be 50%
1 Like
2 Likes
Now that I’m thinking about this more, I think it might actually be better to use the LP token from the ren pool on curve.fi (the pool that is roughly 50/50 renBTC/wBTC). The reason I say this is simple– there is very little sBTC currently on defi markets and we would incur slippage if we deposit either renBTC or wBTC into the sBTC pool. Both wBTC and renBTC are far, far more liquid on DEXs like Uniswap, and ultimately we would want to be dumping our CRV for something liquid that will not incur significant slippage (which, in this case would pretty much have to be renBTC or wBTC, even if we were using the sBTC pool).
Additionally, to address those discussing voting gauges on CRV. I spent a while reading through the documentation, and although it is not super clear, I believe the most effective mechanism would be to simply allocate some amount of earned CRV from the renBTC/wBTC pool to this pool (vote-locked for the ren gauge) so that we could therefore collect 2.5x greater CRV payouts on this pool. This part is a bit more complicated, but I would guess the most effective thing would simply be to look at how much voting weights is being thrown at the other, non-CRV pools (especially the sBTC pool) and aim for at least that much, if not more.
3 Likes
None addresses the fact that wBTC is actually custodial. Impressive. I thought that decentralization was the key in the first place, but in the end anyone is willing to sacrifice that for some better ROI
I’m not a fan of wBTC at all, renBTC is simply the best around. If someone else wants to use wBTC however, it’s their choice and I will not stop them.
1 Like
2 Likes
touché
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
1 Like
Just curious– would your solution be to instead have a renBTC-only vault? I think the main issue with that we would either need a completely new farming strategy for renBTC alone, or it would just end up going into one of the pools on Curve– which then means your renBTC basically becomes part wBTC. So I think for now this is likely the best way forward, at least as a first foray into BTC vaults.
This is why to start with we only accept curve LP tokens from curve pool 6 (sBTC) which rewards CRV, SNX, REN and BAL tokens.
People can deposit Ren/w/sBTC to curve. It’s not our concern what they do there as long as they deposit their LP token with us, for now
It becomes wBTC while on Curve, but when you withdraw you can get renBTC as long as there is enough liquidity. The slippage though could change dramatically in the meantime and the withdrawn amount could kill the interest earned.
1 Like
SNX & REN are ending soon right?
2 Likes
I remember having this concern and raised it in curve discord for stables.
They said that you normally get an input bonus on depositing certain tokens so the slippage on withdrawal gets balanced out.
1 Like
To answer your two points– this is partially why I suggested switching to the ren pool instead of the sBTC pool– for renBTC and wBTC, we should be able to buy them on uniswap and send directly to the ren pool and can include a function in the strategy that always sends the one with the lowest balance (so we get a bonus for deposits).
And yes, the SNX/REN/BAL incentives will be ending this upcoming Friday (6 days).
Realistically, I’m a bit worried that once the incentives end, the sBTC pool will not be used much– as sBTC just is not nearly as common as wBTC or renBTC.
To add to what I had previously mentioned as well, perhaps we could state that for first 7 days of the vault being live, the CRV collected will be used for vote locking and gauge weighting? And after the 7 days, the CRV strategy could proceed like normal, and we could revisit and submit another YIP if we believe we haven’t hit enough CRV for the pool to earn enough rewards.
2 Likes
Look at the stable coin vaults. USDC has by far the most AUM despite DAI vault having a higher APY. If no one uses your product it doesn’t matter.
1 Like
Great idea. I would definitely put a good amount of BTC into this vault - I was providing BTC liquidity to Curve until the returns were nerfed by the gauge weight vote. A portion of yVault voting power directed at BTC pools would be very attractive.
1 Like
@dudesahn Yeah, if you look at the volume, most of the swaps is ren<->wbtc. So renCRV might be better, I might even boost that pool with my voting power.
1 Like
Exactly my point. The Curve Wars between Yearn and Compound must have put a lot of BTC stakers off, and we should be the ones to do the right thing and create a win win out of it.
2 Likes
It might be complicated to code, but the best solution is if you can use your votelocked tokens to get a boost for both yCRV and a btc CRV pool.
You can actually get a boost for both at the same time, just more complicated to code the vault.
3 Likes
How? This is really interesting and would like some further detail from you on this.
Hey everyone a few things here,
A) Although there are suggestions to deposit LP tokens (from Curve) vs native wBTC or renBTC I think (and I can be wrong) that we should go with the latter option(wBTC or renBTC). The rationale being that right now we may be married to the proposed Curve strategy but this may not always be the case. We want to remain as flexible as possible in the event that a new (and better) strategy arises for BTC assets(such as staking on Compound, AAVE or elsewhere). We shouldn’t have a vault which needs to be deprecated as a result. As great as the Curve LP token is, it may create “too much” vendor lock-in, so to speak, not allowing a change of strategy as easily as a native wBTC or renBTC vault (Again I can be wrong so I’m open to debate) also introducing further friction for the User Experience.
Conclusion: BTC assets(wBTC or renBTC) favored over Curve LP token deposits.
B) There are discussions here that seem to conflate strategy and vault (I could be wrong). As of right now it is indeed true that the renBTC/wBTC/sBTC gauge on Curve returns the most due to SNX/REN/BAL rewards. This would be a strategy, however this does not necessarily have to be our vault. Nevertheless I do see pros/cons to having sBTC as well as an input in our vault. What we need to also keep in mind is trading volume, as fees will also accrue for not only swaps but a CRV admin fee in the future. At the time of writing the renBTC pool had $3,265,532.25 of volume and sBTC pool $7,382,189.09 daily volume with liquidity utilization(volume/liquidity) being 26.61% for the ren pool and 4.47% for the much larger sBTC pool. Having a greater share of a smaller pool (ren) could grant us greater proportional rewards. To play devil’s advocate, something important to keep in mind is that sBTC will allow for slippage free trades to sETH, and sUSD, since they all share the same debt pool on Synthetix. This means that we could very well see greater trade volume (and therefore fees) in the near future.
Conclusion: Ambivalent (currently exposed myself to sBTC via Curve) but leaning towards renBTC/wBTC deposits as I know the sentiment is slightly against sBTC due to concerns regarding Synthetix amongst BTC maximalists. Additionally being part of the renBTC pool would lead us to have a greater proportional share of crv rewards (someone can correct me if I’m wrong on this). In the future if we decide the sBTC strategy is best we can migrate over and add additional deposits. If not and Curve doesn’t suit us anymore, we can safely yield seek elsewhere. The goal is to remain flexible.
C) Regarding “Conflict of Interest”, @ycho the ultimate goal of the Yearn ecosystem is to increase total AUM (Assets under Management) in a sustainable fashion see: Guiding Principles As for the distribution of CRV gauge weighting, what seems fair is a proportional weight based on total deposits but we can definitely put this up for a vote. I echo @dudesahn’s sentiment here especially this
“To add to what I had previously mentioned as well, perhaps we could state that for first 7 days of the vault being live, the CRV collected will be used for vote locking and gauge weighting? And after the 7 days, the CRV strategy could proceed like normal, and we could revisit and submit another YIP if we believe we haven’t hit enough CRV for the pool to earn enough rewards.”
Conclusion: Proportional Weighting of CRV rewards for BTC pool (vs yCRV) based on Total Deposits. Addendum: Explore @jiecut’s suggestion if possible of using yCRV Pool CRV Tokens to boost BTC rewards which may reduce the need for immediate lockup.
D) For the concerns regarding custodial solutions/ counterparty risk of wBTC aka “centralized” I am also in agreement, however, if that is indeed the case, the same issues exist with yCRV as it consists of a basket which includes Tether(USDT), USDC(https://www.circle.com/en/usdc),and TUSD (https://www.trusttoken.com/trueusd). I am not a fan, but wBTC is supported by most platforms including Maker, AAVE, and Compound. In the case that Curve rewards are no longer viable, wBTC currently grants the most flexibility, although this is not likely to hold forever.
Conclusion: wBTC is not a problem and it should be our deposit.
I am going to mull this all over but I think we should keep the Guiding Principles in mind (sorry to beat a dead horse) as our goal is to maximize AUM. What will do so safely and most flexibly will likely be the solutions that are most supported across the DeFi ecosystem. Also as a complete sidenote, these solutions should be enacted relatively soon as the sooner we begin amassing CRV rewards the sooner we begin to increase our Moat before centralized institutions (like Binance?) begin hijacking rewards. Being agile is critical.
Semi-final thoughts: We should go with what offers us the most flexibility while remaining modular. After thinking this over a bit, we shouldn’t create combined vaults and should instead have three separate vaults(wBTC, sBTC, and renBTC) starting with wBTC which can each share the same strategy to farm Curve initially. wBTC is the most supported BTC version on other DeFi platforms which provides us alternative yield optimization strategies in case something happens to Curve. I’m not a fan of complexity and I’m not sure if introducing too many moving parts is the best idea as it increases the future surface area of failure(bugs, attack vectors etc). https://en.wikipedia.org/wiki/KISS_principle
Maybe @banteg can chime in?
4 Likes