Proposal to further incentivise the Uniswap RLY/ETH liquidity pool

Following on from @Grand’s proposal to help boost the liquidity of the Uniswap RLY/ETH 50/50 by using some of the Rally treasury, we can also try to attract more liquidity providers to this pool by increasing it’s incentives.

We currently have 6 pools, each receiving an equal share of 38 RLY per block - ie. 6.33 RLY (17%) each per block:

BAL RLY/USDC 90–10
BAL RLY/USDC 10–90
BAL RLY/ETH 90–10
BAL RLY/ETH 10–90
UNI RLY/ETH
YDV curve.fi/3pool

A couple of possible proposals:

  1. Increase the UNI RLY/ETH allocation and decrease the remaining 5 pool allocations to maintain a total 38 RLY per block. This keeps from increasing the RLY emission rate, but may be a contentious vote. It’s quite possible that liquidity pool providers for the remaining 5 pools would mostly vote against a decrease of their rewards.

  2. Increase the UNI RLY/ETH allocation, decrease the remaining 5 pool allocations and increase the RLY per block to maintain the 6.33 RLY per block for the remaining 5 pool allocations. This is a less contentious proposal, but would increases RLY inflation.

Any further thoughts, suggestions? If the community is supportive of an increase, there is also the question of how much to increase the allocation by. Perhaps we could setup the proposal with a selection of values and implement the most popular or an average.

1 Like

Thanks for writing this up cryptolytica, I’ve also been thinking about the best way to move forward on this topic after the discussion in Discord.

I think that it may be too early to increase the RLY emissions. Doing so could cause some unnecessary volatility when we are hoping to show liquidity providers more stability.

I would propose we go with your option 1, and specifically make it so that the Uniswap pool emits roughly the same % as it’s volume, 35%, with the rest of the pools getting the remaining 65% split evenly. Summary is this:

  • Uniswap ETH/RLY - 35%
  • Balancer RLY/ETH 10/90 - 13%
  • Balancer RLY/USDC 10/90 - 13%
  • Balancer RLY/ETH 90/10 - 13%
  • Balancer RLY/USDC 90/10 - 13%
  • y3Crv Pool - 13%

Love the post. I know it may be slightly more contentious, but agree that 1) would be the better route for what @smalldogg outlined. We should get trading volume data to make sure we’re moving it to the right level

Good call out @KevinChou. I think cryptolytica originally called out a temporary period for this change of 30 days, so we could give that a try to get that data and adjust at the end of the period if needed.

Do you know if the 35% figure was a snapshot or an average over the previous week or so?
I’m for option 1, but I would love to see the current data points on liquidity and volume levels for each pool to accompany an argument towards a # this large for the reallocation. Pushing through such a large change to existing incentives might simply move large positions out of balancer and into uniswap. Also a bit shady on the heels of introducing the 3pool and touting the LM incentives. From a governance perspective, introducing a new proposal so soon that undercuts the last one might undermine trust to some extent.

I think a slightly smaller rebalance might not see such strong headwinds from the y3crv providers, but we can have it all by offering several choices as @cryptolytica suggested. Instead of choices for additional allocation, it would be for new split.
Option 1: @smalldogg proposal.
Option 2: Uniswap @30%
Option 3: Uniswap @25%
Option 4: No change

Also, I’d be down to bake in a 30 day reappraisal period to rebalance based on the 30 day average volume and liquidity levels.

Agree Grand. Would love more opinions on this before we move forward with it, as I think it’s a pretty big change to the current distribution. I think having multiple options that you mentioned on the Snapshot proposal would be the best path forward. I’d recommend having the 30 day reappraisal period as a separate proposal.

Got some data from Uniswap and Balancer. Last 7 days average, the UNI pool gets 32% of the volume but only has 14% of the liquidity.

Pool Avg. Vol Avg. Vol % Avg. Liq Avg. Liq %
UNI 37986 32% 128752 14%
10/90 ETH 33489 29% 256889 27%
10/90 USDC 30257 26% 316559 34%
90/10 ETH 10147 9% 121533 13%
90/10 USDC 5383 5% 116876 12%

I just manually entered the figures from the uniswap.info and balancer pool info web pages into a spreadsheet for the calculations, and it’s late here, so there might be some data entry errors, but that looks about right compared to today’s latest figures (uni has 35% of volume and 18% of liquidity).

2 Likes

Nice work! Due Diligence! I think it’s super strong to have this reference for your proposal. Given the prospect of further impermanent loss for the LPs across the higher proportion RLY pools, I see a strong argument here for greater incentives to counter that in the Uni pool for starters with your proposal.

Nice work @cryptolytica I believe there was another post in Discord that tied the number to 35% a few days ago, so pretty consistent data.

I think the most disconcerting issue is the volume-to-liquidity ratio. IF liquidity was proportionate on Balancer, the transaction volume would suggest 32-35% rewards to Uniswap relative to Balancer.

But since liquidity is actually 6.3x (Balancer 256,889+316,559+121,533+116,876) / (Uniswap 128,752) compared to 2.1x transaction volume (Balancer 33,489+30,257+10,147+5,383) / (Uniswap 37,986), there’s actually an even larger dislocation than looking at just transaction volumes alone.

I do think @Grand and @flynnjamm have good points about not oversteering so quickly relative to the recent changes in YDV and LMs, but the data does seem to support the higher end of the range in adjustments of Uniswap rewards.

1 Like

Have you all looked at Bancor V2, which is supposed to fix IL? I am participating in the YFI vaults but afraid to LP due to possible impermanent loss on Uniswap.

But maybe I’m poking the wrong end of the bear here, if the issue is that ppl WANT to use Uniswap to buy & can’t be convinced to use something else. Would it be reasonable to try Bancor V2 and publicly encourage buyers to use those pools before upping the compensation for IL on Uniswap via RLY tokens? Just an idea.

Bancor v2 is a great idea, and I think would have been a particularly strong solution early on to protect LPs. As it happened some arbitrageurs captured a lot of value at their expense. Likely still some volatility ahead through the full bridge implementation in mid-November.

The Uniswap rewards proposal went through and is active. I believe the Rally team is holding a call this coming Friday (more details on discord) to discuss a number of things including LP pools and rewards. Certainly further room to optimize the LP incentives, and I’d encourage you to bring this up as a possible solution.

I could definitely see how consolidating liquidity between 2 deeper pools vs. the current 5 would be beneficial to the RLY community and price stability and would love to hear thoughts on this from the team and RLY holders. It would also allow us to develop a system that periodically rebalances rewards emissions based on liquidity and transaction volume so we don’t have to revisit it with proposals so frequently, and so that whales wouldn’t get an outsize say on increasing rewards to their LP position. As it was, nearly 70% votes in favor of the proposal came from a single holder.

Wow re: 70% of votes coming from single holder(!). Really encourage you all to look into quadratic voting mechanisms, and weighing Creator votes much heavier than everyone else – if the network is to be in the hands of Creators (as it should be, and I say this as someone who is mining $RLY in the pools, not a Creator).

I worry that a handful of whales is taking advantage of these opportunities at the expense of Creators who are actually adding value to $RLY and strongly encourage proposals that would mitigate this, and/or help Creators themselves earn more control of the network.

Rally did implement quadratic voting for Snapshot votes. https://snapshot.page/#/rally

Re: Snapshot voting – gotcha, but I only see that Rally is using Snapshot’s contract-call strategy, which involves checking another smart contract for vote weights, but the contract address is not specified anywhere?

What contract is called, and what is the strategy that is implemented there? Sorry, i looked all thru snapshot and this forum and couldn’t find any specifics.