FLX Emission Boosties

General Discussion
1

Summary

Update the off-chain scripts used to calculate FLX rewards for different farms to boost rewards for those who also staked in the FLX/ETH pool that protects RAI. This would align farmers with long term FLX holders as well as with the protocol. This mechanism would also offer an extra perk to those who stake FLX/ETH LP tokens.

Abstract

The veCRV mechanism is extremely popular within DeFi due to the fact that it aligns CRV farmers with long term CRV holders as well as with the protocol itself. The vested escrowed mechanism was successfuly adopted by other projects such as FRAX and others like Ribbon Finance, Balancer and mStable are moving their tokenomics in the same direction.

This proposal lays out a potential path to simulate veCRV mechanics for FLX/ETH Uniswap v2 LP stakers. Namely, those who stake FLX/ETH LP tokens would start to accrue a boost for the amount of FLX they farm in various other protocols.

Practical Example

Let’s assume there are three people who participate in various FLX incentivized protocols: Alice, Bob and Charlie. Right now, none of them are staking in the FLX/ETH LP pool, so each one of them has a reward_boost of 1.0x.

Alice and Bob decide to stake in the FLX/ETH LP pool because they know that the longer they stay staked, the more their reward_boost will grow. Bob stakes in the pool 4 months after Alice starts to stake.

Alice’s and Bob’s reward_boost can go from 1.0x to, let’s say, 2.5x as they remain staked in the FLX/ETH pool (without requesting that they unstake). The reward_boost reaches 2.5x if they stay staked for 5 months in a row. Past the initial 5 months, the reward_boost will remain at 2.5x until one of them decides to request an unstake, at which point the reward_boost resets to 1.0x.

Let’s say Alice stays staked for 5 months and Bob only stays for 1 month, after which he requests to unstake from the pool. The following is a quick overview of how much FLX Alice, Bob and Charlie would get from a specific FLX incentivized protocol.

Incentive Distribution before Staking

Screenshot 2021-12-14 143044

Incentive Distribution after Staking

Screenshot 2021-12-14 143728

As you can see, given that Alice has the largest boost out of all participants, she receives more FLX than before for the exact same initial distribution (200 FLX for Alice, 350 FLX for Bob, 150 FLX for Charlie). Bob had his cut of the rewards diminished because he did not stay staked as long as Alice. Charlie also has his share diminished because he did not stake at all.

Note that in this scenario, Bob can be a whale and receive the most FLX before introducing the reward_boost mechanism but a smaller stakeholder such as Alice gets an edge because she is long term aligned with the RAI protocol.

Potential Complications

As mentioned in this and this post, the Money God League proposed by Reflexer a while ago is starting to shape up. Other teams who are friendly forking RAI agreed to offer the Reflexer community a stake in their projects.

These (un)governance tokens would be distributed via several smart contracts where FLX, FLX/ETH LP and RAI LP token holders can stake. These smart contracts are not the same as the one used to stake FLX/ETH LP tokens and protect the RAI protocol. This means that FLX stakers would have to choose between boosting their FLX rewards and getting skin in the game in RAI friendly forks.

Remarks

Note that the mechanics described here are not yet polished, hence why I’d like to hear what others think!

6 Likes
2

100% here for it. I’d also advocate for FLX Boosties calculations to be backdated to the start of the FLX/ETH staking program.

3 Likes
3

Problem with backdating is bias, would rather announce a start date from which everyone starts to increase their reward_boost.

But open to hear more people about this topic!

3 Likes
4

Fully agree it’s biased. I would argue it’s not a bad strategy to retroactively reward users for contributing to behaviors that the protocol wants to incentivize. That said, I wouldn’t be mad about accruing boost after an announced date.

4 Likes
5

I personally love it as well. I do think the behavior is aligned so maybe a retro “reward” (isn’t even a distribution) as @ceresbzns proposes makes sense.

My other comments would be that the amount of boost should be tied to the amount of FLX - for example staking 1 FLX/ETH should not boost receipt of 100 FLX.

Lastly, I think I mentioned this before, but I think the Money God League should distribute to stakers in the current contracts. This would achieve multiple goals:

  1. Concentrate rewards, increase APY
  2. Concentrate staking in contract that is useful (protects system)
  3. Not introduce tech / smart contract risks to FLX from external teams. I think a lot of us are quite comfortable with Reflexer team and audits

An external additional staking contract dilutes reward and increases risk to stakers - not sure why. Lyra shows how the reward of external protocol (Lyra) can be distributed to SNX stakers in original contracts (Synthetix). They just distribute linearly to people that stake in the original contract.

Maybe I am missing something though, why do we prefer that Money God league splinter rewards and staking?

3 Likes
6

For a couple of reasons, one of them being taxes, no one should touch these tokens that go out to the Reflexer community.

The process should be automated and immutable. I am not against bundling all rewards for a single staking contract but from what I understand here, Lyra is doing it manually and there’s no smart contract to do it autonomously.

Also, agree with taking both time and size of position into account for the reward_boost

1 Like
7

I see the point on not moving them through Reflexer and the issue on scripts.

However is there a way to just read on chain what a user has accrued for FLX/ETH stake in terms of FLX rewards? Since FLX accrued is visible on the staking app I am assuming smart contract could read same variables too. And the FLX/ETH rewards are immutable on chain rather than scripted.

Then the new protocol could just distribute the same ratio fraction for the FLX reward accrued delta (plus claims) on the original FLX/ETH pool between various time periods such as from last league token claim (or league token program start) to present? What do you think?

1 Like
8

Not really possible imo because this other contract would need to be notified when someone enters or leaves the pool in order to correctly distribute pro-rata.

There’s no possibility to call this other contract with the staking pool because it would require changing the current staking pool code and redeploying which introduces risk for both stakers and the protocol.

1 Like
9

I agree @stone we need to align FLX farmers with long-term holders.

I don’t understand why FLX stakers would have to choose between boosting their FLX rewards and getting skin in the game in RAI-friendly forks? Would it make sense to build a time-weighted FLX/ETH LP pool that gives boosters and voting power?

similar to the Time-weighted voting. Vote-locked tokens in VotingEscrow in Curve

10

Problems I see:

  • Slashing is incompatible with veCRV style boosting from what I know, can’t recompute weights for all stakers when they get slashed, assumes a loop through all stakers
  • Switching from the current pool to the new one introduces risk for something that already works as it is
11

Since we have a 21-day thawing period, then why not have the other contract distribute on a weekly basis to current FLX stakers that aren’t thawing? (Weekly snapshot style)

(It doesn’t even need to distribute, just receive more token and update claim recordkeep on chain. I guess there is some dependence on a bot calling that contract weekly or with some periodicity to acquire league distribution from dripper and update the claim amounts for current FLX stakers).

You can’t really game it if it takes 3 weeks frozen to game a week’s league distribution. SNX has done ok with weekly distribution that is even a lot more gameable.

Would that work?

12

But how does the contract do the snapshot if it doesn’t know who is in the pool and who exits? It doesn’t have a hook in the staking pool to receive these events.

13

I see yeah always off chain hmmm. And there’s probably reasons for which you don’t want them go to a multisig where Reflexer can run an off chain monthly script together with the other monthly reward scripts.

Well at least the boost plus ability to stake RAI LP (uni, curve) might be quite interesting as a combo too!

1 Like
14

The idea is great. I don’t however like the fact that I must chose between boosting my FLX rewards and getting skin in the game in RAI friendly forks.

I don’t love the time+size of position because then whales get most rewards and not the little guy that might be interesting in the protocol at a later stage. But there are formulas and workarounds to address this.

15

veCRV is also time × size, if we don’t add size accounts that stake tiny amounts can rig the distribution.

And yes it’s not ideal to pick between boost and friendly forks although don’t see an easy fix atm.

16

I love these tokenomics! It will show who’s really committed long term.

1 Like
17

Follow up with (hopefully) correct math this time and details on how all the boost calculation would work.

Boost Eligibility

To make things simple and to better align stakers long term with the protocol, if someone requests an unstake during a particular month, their multiplier for that month will be 1, no matter if they stay staked for most of the month. They have to wait until a distribution snapshot is finalized and then start the unstaking process.

Also, to make things even simpler, we can take a snapshot of each staker’s reward_boost at the end of the month instead of linearly applying it over the month as it increases. This further aligns people to stay staked for at least one full month without requesting an unstake.

Collecting Data

At the end of each distribution, we need to determine:

  • The amount of FLX/ETH liquidity in USD that someone was staking 7 days after the last monthly snapshot
  • The age of someone’s stake

If someone has been staking for more than 6 months (180 days), their stake duration will default to 180 days (the max stake we take into consideration). This can be determined by checking staking pool events. If someone has requested an unstake since the last monthly snapshot, their reward_boost for the current snapshot will be 1.

Also, in order to determine the weight of someone’s stake size, we use the USD value of their FLX/ETH position 7 days after a new monthly campaign starts. Why 7 days? It’s enough time, after a new monthly distribution, during which stakers can decide to increase their staking positions and before their stake size is recorded for the next reward boost calculation.

Let’s say a snapshot is done on 15th of December at 12:50 PM UTC. Stakers have time until 22nd of December at 12:50 PM UTC to stake more LP tokens and increase their position size. The stake sizes used for the whole month will be recorded on 22nd of December at 12:50 PM UTC. If someone increases their size after 22nd of December at 12:50 PM UTC and before the next snapshot, that increase in size will only reflect in the next monthly campaign.

Determining the Reward Boost

First, we determine the reward boost for the time spent staking. Assume we have 3 participants, Anna, Bob and Charlie. Also, assume that the max boost for the staking time is 2.5x. Anna has been staking for 6 months, Bob for 2 months and Charlie has not staked at all.

Name Time Staked Boost
Anna 6 months 2.5
Bob 2 months 1.5
Charlie N/A 1

As for the amount of liquidity staked, let’s assume the following distribution:

Name Dollar Amount Staked
Anna $1M
Bob $2M
Charlie 0

Notice that Anna has 33.33% (0.3333x) of the staking pool and Bob has about 66.67% (0.6667x). For each staker, we determine their stake size weight by doing 1 + percentage_staking_pool / 100. So the weights will be as follows:

Name Dollar Amount Staked Boost
Anna $1M 1.333
Bob $2M 1.667
Charlie N/A 1

Finally, we multiply the reward boosts from each stake’s age with the reward boost calculated for each stake size in USD. We get the following results:

Name Total Boost
Anna 3.33325
Bob 2.4999
Charlie 1

Applying the Boost to Monthly Rewards

Assume that this is the monthly reward distribution without applying reward boosts:

Name Base FLX Rewards Boost
Anna 200 FLX 1
Bob 350 FLX 1
Charlie 200 FLX 1

Taking into account the total boost calculated in the last step, the adjusted rewards would look like this:

Name Boosted FLX Rewards Boost
Anna 365.85 FLX 3.33325
Bob 274.38 FLX 2.4999
Charlie 109.77 FLX 1

Basically, we sum up all boosts, then determine what percentage of the summed up boost is allocated to each staker and then that same percentage is used to determine how much FLX is given to each staker out of total FLX distributed in a campaign.

Practical example to determine Anna’s reward:

  1. Sum up all FLX rewards: 200 + 200 + 350 = 750 FLX
  2. Sum up all boosts: 3.33325 + 2.4999 + 1 = 6.83315
  3. Determine Anna’s percentage out of the summed up boost: 3.33325 * 100 / 6.83315 = 48.78%
  4. Use the percentage to calculate the FLX reward allocated to Anna out of the total FLX rewards: 0.4878 * 750 = 365.85 FLX
18

Whoa this really advantages stake whales. I just think we could use a corresponding size for the boost, for example if you have 50FLX+ “x” ETH staked (the LP token), then only the first 50 FLX of a monthly distribution would be boosted or something like that. The math above is confused and essentially skews much higher than the 3.5x max potentially, I think if you had Anna have 2/3 of the pool her multiplier would have been off the charts while Charlie actually gets a -50% (this will also get a lot of complaints from new stakers).

19

We can play with max boost values then e.g instead of 2.5x use 2, 50FLX+ “x” ETH staked shifts as the two assets’ prices move around and I also think it can be gamed.

In this example Anna is not as big a staker as Bob and manages to outweigh him.

20

I agree it is important that the model can’t be gamed. Boost is a complex issue. Badger DAO for example has iterated their boost model twice already, and they are already discussing a third iteration with the community, now to include time as well. The first two iterations have had some issues that some of us did foresee (for example, disincentivizing new deposits or even incentivizing you to withdraw funds to get a better boost). Even the latest vault they launched had a portion not subject to the boost, so that little investors would still get an attractive yield, therefore recognizing the flaws in the current boost model, while they get finish discussions on the new one (currently paused due to more pressing issues as you might be aware).

I know there is no comparison on the boost they are doing, and what we are doing here at Reflexer. I am just mentioning it as an example of why it is important to get things right, with the incentives aligned for all stakeholders, try to foresee different possibilities and behavioral tendencies of the users.

1 Like