Let’s speak about the cornerstone of our tokenomics - a liquidity pool for staking rewards, ie a rETH2/ETH liquidity pair. The StakeWise team has an idea to list this pool on Balancer v2. Below is our reasoning on the matter.
Motivation
The appeal of having a reward token is that selling it at a 1:1 exchange rate with ETH allows to compound staking returns. You can consistently sell the rewards and reinvest the proceeds from sale to increase your principal, boosting staking yield by some 10% every year. In order to create a marketplace for staking rewards, an rETH2/ETH liquidity pool is required to exist.
Specification
The liquidity pool and a DEX to list it must meet several criteria:
It must have a potential to farm the DEX’s own governance tokens on top of any StakeWise incentives and trading fees earned by LPs.
It must not cap the price of rETH2/ETH swap at 1.
It must be permissionless.
The choice of these criteria is simple: we want to maximize LPs’ profits from providing capital to the liquidity pool and allow users who don’t participate in the farming of $SWISE via staking of rETH2 to at least partially capture the yield from that incentive mechanism.
The few DEXs that meet both of these criteria are SushiSwap and Balancer (v2). Considering our idea to list sETH2/ETH liquidity pool on Balancer v2 and Balancer’s smart order routing system that makes direct swaps between related pools (ie rETH2/sETH2 swaps) possible, we believe Balancer v2 is a natural choice for listing the rETH2/ETH pair.
Drawbacks
Time. The Balancer team has been preparing to launch v2 in late March/early April that should have been around the corner. However, according to the recent Discord announcement, the devs decided to implement last-minute changes, leading to a few weeks’ delay in conducting the audit and updating the front-end. This means that StakeWise would need to delay the listing of rETH2/ETH pair if it were to choose Balancer v2 as place of liquidity for rewards.
Alternatives
Do not wait for Balancer v2 to launch and list the rETH2/ETH pair on SushiSwap. This still allows direct swaps between rETH2 and sETH2 (using aggregators like 1inch) even though the two tokens are listed on different decentralized exchanges. The potential drawback of this approach is that gas fees for the swap may be higher than if the swap happened on Balancer - we could compare the two costs once Balancer v2 is released and consider migration if necessary.
The team is eagerly waiting for the DAO’s thoughts on this idea.
Perhaps if the Balancer V2 release is being repeatedly bumped later, it would be good to set a deadline: If Balancer v2 is released and fit-for-purpose by such date, we will use it, otherwise we will fall back to SushiSwap.
I think this is preferable to the alternative where we wait indefinitely, leading to ongoing “Sushi v. Balancer” arguments and risking the factionalizing of the community between people who want to liquidate and people who are insistent on the technologically superior solution (and lower gas usage).
This definitely seems to illustrate why Balancer V2 will be the best option for StakeWise once it is up - hard to imagine a more flexible system to build a two-token staking rewards ecosystem around. So I think that the end result has to be there.
Sushiswap seems just fine as an interim choice, but clearly not the most synergistic one long-term. That being said, if setting up rETH pools on sushi is the way we have to go, maybe that also informs whether SnowSwap should be the interim option for sETH2 - even if I think I prefer the idea of trying to work with SnowSwap it probably makes sense to just have the interim options be on the same platform and be as simple as possible before the migration to Balancer V2.
My personal opinion is that postponing the liquidity pools for longer is not an option, especially considering the open-ended release deadline for Balancer v2. At the same time, I really wouldn’t like to fragment liquidity by first going with Sushi and eventually going with Balancer. The solution I’d propose is the following:
Set up a Sushi pool for rETH2/ETH and incentivize it with $SWISE via a series of week-long campaigns that can be rolled over for as long as Balancer v2 is not out.
Once Balancer v2 is out, let the development team create a test pool for rETH2/ETH and measure the gas cost for an rETH2/sETH2 swap internally on Balancer vs 1inch
Decide whether to keep the Balancer v2 pool and start incentivizing liquidity there instead of on Sushi, or make Sushi a permanent place for rETH2/ETH liquidity (i.e. commit to a longer incentive program).
How much onboarding work/auditing is needed to initially set up a current solution such as Sushi? If there is any I think we should start with that, beta test it. Then decide a Go/No-Go Gate condition to start the campaign. I don’t think there will be any fragmentation of the liquidity pools so long as the messaging is concise and active, coupled with a streamlined migration process to a later DEX if desired. So long as the community understands an overwhelming improvement toward a later DEX migration in advance and understands the steps that will be undergone to some degree, I don’t think there will be any sizable backlash.
If we start with SushiSwap, which sounds likely given the uncertainty with Balancer v2 timeline, my take is that a later switch to Balancer v2 is fine but keep in mind the smaller stakers for whom a move of Dex will potentially cause gas fee costs that may not be insignificant to total yield of their strategy. In that light, a couple suggestions:
Give at least 15 days notice before any reward strategy moves from SushiSwap to Balancer.
Consider running the reward strategy in parallel during a 15 day window (on SushiSwap and Balancer) for a 15 day period.
So, timeline might look like this:
Setup pool on SushiSwap as soon as possible
Setup SWISE rewards on SushiSwap pool as soon as possible
When things are ready, give 15 days notice before activation of the new pool/rewards on Balancer v2.
Once Balancer v2 pool is active, run Sushiswap pool in parallel with rewards for 15 days before that shuts off.
Goal here is to make sure adequate notice is given and time for people to plan transactions and take advantage of lower gas fees that come around once or twice a week. (I’m involved in another project where this kind of notice / timing of staking changes was not made and it’s caused unending friction with the user community and, I’m sure, many headaches for the project team). Fully realize that all of what I have suggested above may not be practical (like running rewards programs in parallel) but wanted to offer this as a starting point for consideration.
I don’t believe there is much uncertainty around the Balancer V2 dates. They are likely to be announced soon.
As somebody who has worked with the Balancer team, I would suggest we take ritpub-sipsyl’s suggestion of coming up with some date until which we’re ready for wait for V2.
For a new token, I’d advise against listing on both Sushi/Bal, as you only lose from diluting the total trading volume between protocols. It sounds prudent to establish a homebase in one protocol and stay there.
As mentioned, Balancer seems like a good choice and having the ability to pick the up-and-coming V2 seems like a rare opportunity which would be good to capitalize on.
The alternative is to list on Sushi today and on v2 a month later? How would that impact liquidity of the tokens?
As I’m still learning here, based on what I’m seeing:
SushiSwap or Balancer v2
Not a given that we would have higher gas fees on SushiSwap, but the potential is there. Balancer v2 appears to be the stronger option of the two, it is not a released product. It looks like the community is looking to do direct swaps, and SushiSwap or Balancer v2 would accomplish this.
Time, Quality and Cost are three factors that I look at when it comes to product/project management.
Would the community start to experience profitability with SushiSwap? What is the opportunity cost that we as a community would miss out on if we were to wait until Balancer v2? What is the cost to the developer team to support two listing platforms?
Also consider that we also don’t need to immediately switch to Balancer v2 when it is released. I see that people are open to having to work with one platform and then switch to another. A planned DEX migration with copious amounts of communication would work?
Perhaps SushiSwap is the initial platform. This gives the developer team an opportunity to see what the gas costs really are (vs. a hypothetical projection). As mentioned previously, a migration to a new DEX could then be done (e.g. Balancer v2) using the lessons learned from the initial launch in SushiSwap (which would be of benefit to the developers) to make the plans for Balancer v2 with a planned timeline once it is actually released. This would also enable the developers to test in Balancer v2 using a test pool and compare/contrast with SushiSwap.
Personally, I am ok with waiting since I haven’t figured out what to do with this - but I think there are benefits to using SushiSwap as an initial platform (developer experience, lessons learned, gas price verification) and then use the benefits when launching on Balancer v2, and not necessarily right when it comes out on Day 1, but perhaps X days past Day 1, with the projection estimates based on the learning experiences of launching on SushiSwap.