FLIP78- Delegator Staking Minimum

[joshuahannan]

Proposes adding a minumum stake for delegators to receive rewards

[AlexHentschel]

Thanks, I like this. A few thoughts on possible degrees of freedom we could use:

• I think Jordan has a really good point:

  • How do we deal with the fact that the threshold might change and avoid confusion?

  • We have a similar situation if you delegated to a node that drops out of the network. In this case, we simply just return the delegated tokens.

    I think we could do the same with the delegated tokens below the threshold: return them and do not accept any new delegations below the threshold.

• I think 100 Flow is comparatively large threshold. What if it was 10Flow? Below that amount, we just don't accept any delegation. And you get rewards immediately.

I think this would have 2 benefits with nice synergies:

• We remove data from the system smart contract.
  • If I understand correctly, in your approach, we would primarily reduce the number of events for small delegations below the threshold. Nevertheless, the computational cost of storage cost remains, as we have to maintain the data and probably iterate over it.
• We make additional UX changes optional: delegations below the threshold will fail. Otherwise, we would need a very clear warning (on all the platforms that allow delegation).

[joshuahannan]

These are good points. I think that is enough of an argument to change the proposal to just have a minimum to stake anything, not to just receive rewards.

[bluesign]

I think 50 is too low, makes like 0.08-0.09 FLOW reward approx per epoch. Also delegated tokens are the biggest problem of flow economy. Last time I checked account with over 1 FLOW or more non staked balance was very very low percentage.

Putting something like, 250-500 FLOW minimum and requiring staking amount to be multiple of 250 or 500, can improve economy a lot. ( if I have 400 FLOW, and limit is 250; I can either go buy 100 FLOW or I can spend 150 FLOW ( or at least have unstaked flow, if I see some nice NFT ) )

[joshuahannan]

@bluesign The minimum was chosen more for security and performance reasons than economic reasons. Like we say in the FLIP, we still want the minimum to be accessible for regular users so they can feel like they can easily contribute to the network and be rewarded for it. I also would be a little uncomfortable having the delegator minimum be greater than the access node minimum. Can you elaborate a bit more on why you think it should be that high? We're definitely open to changing it in the proposal if there is a consensus

[bluesign]

@joshuahannan yeah I understand the motivation, but this is also an opportunity to fix delegation I think.

My though process is a bit like this: ( all in back of napkin style, approx numbers )

• we have 2 parts of the system; staking node + staking via delegation for rewards
• currently staking node is practically not possible ( in the short term at least )
• there is no slashing ( in the short term at least )
• delegation has 92% of the rewards (
• total staked is like 700M , probably like 50-55% of total supply, inflation is like 5%, RoR should be like 9-10%
• if we target 1 FLOW reward per epoch, 52 FLOW rewards per year => 500 FLOW staked with 10%

Considering worse case scenario, flow price stays same at around 1$, still nothing can beat FLOW staking RoR, this causes:

• it is risk free, very good RoR
• no defi can compete with that ( not sure how increment.fi is doing, but I don't think very good )
• no new defi will come

if we put let's say 500 FLOW limit, there will be contracts on FLOW that allow pooling etc; most wallets already have support to allow staking on their nodes.

we still want the minimum to be accessible for regular users so they can feel like they can easily contribute to the network

I totally agree that this is good mechanic, ( I mean we use this on mobile games as daily rewards, to make user to come daily ( here is weekly ) and get something for free ) but here contribute to the network part feels similar to saying: "you go deposit your money to bank and feel like you can easily contribute to stability of the economy."

[redallica]

@joshuahannan I do agree with @bluesign. The amount of delegation is one of the biggest challenges for Flow protocol economics. Any action to reduce the delegated amount and put back the staked Flow in circulation in the network would be a great initiative. With a 9% - 10% APR for delegation, it is a killer for any initiative (DeFi, NFTs, everything) in the network.

Maybe @KshitijChaudhary666 has a view on this one as he is also working on proposals to reduce the inflation rate of the Flow network, which is imo the biggest issue of the Flow protocol economics.

I would recommend taking this into consideration while fixing the Delegator Staking minimum.

[KshitijChaudhary666]

Here’s what I think. Having a minimum stake (M) for delegation could have two opposite economic effects, depending on how delegators perceive Flow RoR against other networks or even securities -

CASE-1. Those with stakes <M no longer want to participate, decide to unstake and liquidate. If this is the case, there are two effects - (1A) total stake in the economy reduces, thus the reward share of individual entity increases (ceteris paribus) and we can match today’s rewards with lesser tokens issued each epoch, great. But -> (1B) liquidation could lead to supply spike potentially affecting Flow value if there are no immediate use-cases to absorb the excess tokens. This problem is similar to what we face when we discuss reducing the minimum staking requirements for nodes, which would help reduce inflation but could create a big token surplus problem provided we don't have enough investing/spending opportunities

CASE-2. Those with stakes <M could increase their stake to reach M. If this happens, the total stake in-fact grows, having an adverse effect on inflation

To have this change impact inflation, we want to be sure that first, case-1 overpowers case-2, and second, the impact of liquidation of unstaked tokens (1B) is minimal. Imo, larger the M we set, the higher the probability of case-1 (and 1A) overpowering Case-2, but also creates a larger 1B problem. A mix of the two cases seems most practical, achieved with a non-trivial but fairly small M. While many minority stakers might stop participating, some believers would increase their stake to the new minimum requirement. Maybe a distribution chart of delegated stakes can help understand how much the total stake could reduce, and the max tokens that could go in circulation at various 'M's (M= 50, M=100, M=500, etc.), but don’t think we can build a conclusive judgment here on how inflation would be affected.

That said, I agree that high-yet-risk-free-RoR for delegators is a key problem, and we should aim to solve it via economic incentives instead of minimum caps - for eg an increase in delegation cut (take-rate) that operators receive, along with effective slashing conditions affecting all parties (incl delegators) would ensure the delegators no longer receive risk-free pie. This can also incentivize operators, and either increase their APY with the same inflation, or maintain their APY with a reduced inflation. I'm working on this as one of the recommendations re inflation. Meanwhile, a small minimum delegation requirement would address other non-economic but crucial parameters (security/ performance) like @joshuahannan mentioned.

[bluesign]

@KshitijChaudhary666 I would normally not agree, but I just take a look into the numbers, delegators are not a big problem as I imagined.

Case 1 is totally ignorable, numbers are really weird. Even if we setup 500 FLOW limit, get rid of 78% of the delegators, it is just 0.38% ( 0.0038 ) of total delegated. ( would not make a dent in the price )

Case 2 would work perfectly and flow price would for sure increase, but I don't feel good suggesting it with this distribution.

I think what @joshuahannan suggested is pretty good for now.

[joshuahannan]

I created an issue in the flow-core-contracts repo and I'm going to get started on it soon so we can have an implementation to show for the FLIP