Utilize rETH2 in DAO treasury to Generate Yield - SWIP

Proposals
1

Hello StakeWise DAO,

It looks like we had a lot of great traction in this forum post for utilizing the idle rETH2 in the treasury.

Proposal

We will take 50% (75.5 rETH2) of the current rETH2 balance (151 rETH2) in the treasury (balance snapshot as of 2022-Feb-13) and swap it for sETH2 using the rETH2/sETH2 pool. We will then create an LP position in the rETH2/sETH2 in such a way that it will minimize the SWISE rewards the pool would receive, but at the same time provide the whole sETH2 stack to traders.

The idea of how to create the LP pool in such a way was wonderfully proposed and explained by @dreth:

This range would basically make SWISE rewards a whole lot smaller and would effectively provide the entire 63.5 sETH2 portion taken from the pool at the disposal of traders. The position is ~13-14 ticks to the left and one tick to the right, 0.98807-1.002. This uses the maximum amount of sETH2 possible, while providing very little rETH2 to the pool.
.
I’m not sure how much this would reduce SWISE APR exactly, but I know it’s significant because I pooled like this on the sETH2/ETH pool for a while to avoid loss of principal (since I staked early) and to maximize staking rewards even if SWISE rewards were lower.
.
Using this position though, the DAO would feel the change in proportions of rETH2 and sETH2 as other liquidity providers whenever a trade happens, but would retain the maximum possible amount of sETH2.

Specifications

Special thanks to @tsudmi for helping construct this idea. Since he explained it best, I will just quote him on how this proposal will be executed:

It’s a bit hard to write a specification for it as the transactions have slippage settings and in case the price between rETH2/sETH2 will change, the transactions will become invalid. Also, currently, rETH2 is accumulated to the team’s multisig, we need to change that as well later.
.
I suggest we create a snapshot vote without transactions. If the vote passes, the team’s multisig will convert 50% of rETH2 to sETH2, create LP position and transfer LP NFT to the DAO address. That will be the easiest to execute technically.

Do you want this proposal to pass?

  • Yay
  • Nay
0 voters
2 Likes
2

I support this proposal !

3 Likes
3

I support this proposal! :slight_smile: You have my vote!

1 Like
4

Sorry if these are all noob questions, but what is the actual goal here?

  1. The stated goal here is to generate yield. Who/what gets the yield? Is this creating a new farming instrument? Is this trying to increase the size of the Treasury?

  2. This is taking money from the Treasury. Why is there a treasury, and how does this affect the goal of the treasury? Does it add risk to the Treasury?

  3. Does this affect the yields on the existing farming pools? The ETH-sETH2 pool yields are already pretty low.

2 Likes
5

I’m not the original proposer but I could help answer some of these:

Sorry if these are all noob questions

Never apologize for asking questions man! Questions are a good thing!

Who/what gets the yield?

The DAO treasury!

This is taking money from the Treasury.

Not exactly!, it’s compounding acquired rewards in the DAO treasury, but they will remain in the treasury, only now they will be generating yield.

In a way this is giving more money to the treasury over time.

Does it add risk to the Treasury?

No! (from what I understand, correct me if I’m wrong @kiriyha/@tsudmi) Holding rETH2 is riskier than holding sETH2, given that in a slashing event rewards are taken as penalty before principal is.

Does this affect the yields on the existing farming pools?

Extremely minimally, the goal of pooling one-sided is to take advantage of the fact that a significant factor in StakeWise pools’ SWISE rewards is the tightness of the liquidity position, if the position is very wide, then the rewards the position earns are extremely low. I did this test myself with the ETH/sETH2 pool at some point. Therefore a significantly wide position would have a basically negligible effect on the rewards given to those pooling in a tight range.

The ETH-sETH2 pool yields are already pretty low.

This does not affect the ETH/sETH2 pool! This affects the rETH2/sETH2 pool, but it does so in such a way (given the tightness of the liquidity position) that it won’t dilute rewards almost at all, and by that I mean likely significantly lower than 0.001%

Regarding the proposal, this has my support as well, I think it’s a fantastic proposal.

wonderfully proposed and explained

damn :flushed: thank u

2 Likes
6

@blakevh I can help answer the purpose of this proposal :slight_smile:

We can grow the funds in the treasury and figure out what to do with them later. I spoke to Dimi and he mentioned he will think about a way to include the distribution of the rETH2 that is earned from the sETH2 that will be purchased with this proposal, which can help increase the yield of SWISE holders (the same can be done with the other 50% if we so choose to use it that way). Could also think of the treasury as an emergency fund.

I am sure we can also utilize the rETH2 (and sETH2 if we would like to) to fund future SWAT proposals, investments, etc. (in addition to to paying in SWISE as well).

The options are endless, but in the meantime let’s earn an extra 3.6 rETH2/year. This is easily enough to get some extra SWAT tasks done/paid for, for example.

3 Likes
7

I support this proposal, thanks for the work on it !

3 Likes
8

This is something that I think we need to discuss. In my opinion the treasury should be the first to cover slashing penalties. Regardless of what it holds.

I also think this is a pretty good reason to keep a nice little stash in the treasury in the first place (instead of distributing it to Swise holders for instance).

1 Like
9

Given that a slashing event would affect the entire pool, the mitigation that holding more rETH2 in the treasury would provide is minimal to negligible. I think instead of focusing on this way of mitigating risk, some form of slashing insurance should be established. This is AFAIK something the team has as a top priority in this quarter.

3 Likes
10

I meant that all the holdings of the treasury would be used first, so both rETH2 and sETH2, before anyone else gets slashed.

It would be a good thing to generate yield with the treasury funds as it increases the amount of funds available to compensate in the case of a slashing event.

3 Likes
11

Really great initiative. We should consider doing this transaction via Rook DAO’s platform. It will remove any gas/slippage concerns and would reward the DAO with any potential MEV that could be extracted from the trade. It would also be a nice way to utilise the platform of a partner DAO.

I do not see any need to change the snapshot for this. If passed, the multisig should have the discretion to use Rook should they see fit. Happy to hear any opinions on this though

2 Likes
12

Great idea @pnut . I am not too familiar with this platform, so will need to read up more. Is there an estimate on the MEV potential from this transaction?

1 Like
13

I don’t think there will be much slippage with this trade, there is about 5978 sETH2 in the pool (and 2245 rETH2), significantly more than the size of the proposed trade, and 90% of it in a very narrow band (1.001 to 1.002). Which makes potential MEV minimal. Assuming the pool stays as it is.

While I am not a MEV expert in any way, from the little I know MEV seems to be extracted by sandwiching the transaction between two miner generated transactions. They’d need to sell rETH2 before ours, and then buy it back after, basically selling at the higher price and buying back at the lower price after our transaction lowered the price.

This would need to earn back their pool fees of 0.05% twice, but the slippage is nowhere near enough to justify that I think.
Secondly they’d need to flashloan the rETH2 to sell, because a miner most likely won’t have those tokens (unlike ETH), but where can you flashloan rETH2? Nowhere that’s where.

I hope my analysis is correct, maybe someone with more knowledge could either confirm or correct me?