Implementation of Long-term (5y & 10y) lock-in of staking DFI in exchange for higher staking returns (DFIP 2106-01)

[uzyn]

Implementation of DFIP 2106-01: Long-term (5y & 10y) lock-in of staking DFI in exchange for higher staking returns

DeFiCh/dfips#39

Overview

Locking up of DFI liquidity benefits the ecosystem. Users should be rewarded and encouraged to lock up liquidity for long period of time.

Cake introduces Freezer program for DFI staking on their site and it has been widely popular. We have seen some users locking their funds for as long as 10 years.

Requests have been made by community users to have a similar feature like Cake's freezer for "on-chain" freezing. For DeFiChain and DFI, it would be beneficial to both DFI holders and stakers if DFI can be staked with a long lock-up period in exchange for a higher masternode reward with a higher block finding probability.

Proposal

Two long term locks possibilities:

1. Lock up collateral for 10 years in exchange for 2x (double) the block finding probability compared to a non-locking masternode.
2. Lock up collateral for 5 years in exchange for 1.5x the block finding probability compared to a non-locking masternode.

This proposal is only concerning staking rewards, other long-term staking masternode will not carry extra weights on other masternode functions such as voting.

Mechanism

1. Block finding probability is increased by shortening the period used for coinage accumulation. Normally coinage increases every 6 hours, lockup of 10 years would increase coinage every 3 hours and lockup of 5 years would increase coinage every 4.5 hours.
2. This does not alter the coinage cap for individual nodes. Maximum coinage for longer lockups is still capped the same with the regular max coinage, i.e. 56.
3. Due to possibility of changing block time, collateral can be unlocked when average block time of the past 1008 * 2 blocks are larger than the period of lock up. This ensures that neither delays in block findings or potential change in block time in the future would affect the unlocking period.

[defichain-bot]

@uzyn: Thanks for opening an issue, it is currently awaiting triage.

The triage/accepted label can be added by foundation members by writing /triage accepted in a comment.

Details

I am a bot created to help the DeFiCh developers manage community feedback and contributions. You can check out my manifest file to understand my behavior and what I can do. If you want to use this for your project, you can check out the DeFiCh/oss-governance-bot repository.

[uzyn]

/triage accepted

[RomanShumkov]

Thinking out loud:

1. Would be great to have a solution in case private key to locked collateral gets compromised, e.g. relocating locked collateral to another address, maintaining the lock (not sure how). At the same time I understand that it could require unreasonable amount of efforts/risks associated with implementing this capability in which case it could be considered for later.
2. Same as previous point, but with regard to operator key which does not control collateral directly, but bad actors could trigger double-sign penalty if operator key is compromised. Maybe it's already possible and will be possible for locked collateral out of the box, but mentioning it here just to be safe :)
3. It's mentioned in white paper that in case of double-sign masternodes are disqualified from further staking immediately. I'm wondering how is it supposed to work with locked collateral?

Sorry if I'm bringing up obvious topics which are already discussed and aligned within core dev team :)

[Stonygan]

Same oppinion of point 2. Im I think its important für locked collaterals that the Owner can change the reward address and setup a new Operatoraddress for his locked collateral.
Especially important for hosted operators, where the stakers associate their owner address with a "foreign" operator address.

[Bushstar]

The double sign penalty system is no longer present in DeFichain since the 1.7.11 release, this may or may not be introduced in a subsequent release. This system was disabled by default and has never actually been used, no masternode has the status BANNED. The majority of masternodes have updated to 1.7.11 so if a masternode was banned now on a previous release it would end up on a minority chain.

@RomanShumkov this should resolve points 2 and 3.

[uzyn]

Implemented with #562