Rewards-withdrawal locking up

[aggre]

Currently, staking and holder rewards can be withdrawn at any time. There should be a lock-up to prevent the dumping of DEV.

In my opinion, there should be a 21-day lock-up for staking rewards and a 14-day lock-up for holder rewards.

I would prefer these to be set dynamically by Policy, not fixed.

the Property owner will turn the biggest enemy with greed.Also I have a suggestion on rewards...Rewards by Stakers should not be withdrawn before 21 days and Property owners before 14 days (quotes)
The staker should be allowed to re-stake his tokens if he unlocks immediately.That should be allowed in my opinion as he is trusting the project more and is being loyal (quotes)

Options of the logic

I think there are a few options for the lock-up. I don't have an idea of which option is appropriate. Please give me your opinion.

1. Withdrawal application - Always send an apply transaction before withdrawing rewards. Once applied for, it will be ready to be withdrawn after a lock-up (21 or 14 days). This is simple, easy to develop, and robust logic.
2. Expiration of a period - Rewards distributed, it will be available for withdrawal at any time after the lock-up expires. This is a somewhat involved logic that needs to be well thought out, given the changes in the various balances.

[defi-er]

I highly disagree with this and would be inclined not to use Dev Protocol if this was the case. This issue must be looked at from a First Principles perspective. Therefore, the question we must ask ourselves is why users "dump"? Users dump for the following reasons according to some friends I asked:

1. Take advantage of trading Dev token
2. Better APY opportunities somewhere else
3. Don't support open asset creators' project anymore
4. Open asset creator isn't performing anymore

These issues that cause dumping can be solved with the following steps:

1. Create an interest baring token. Interest bearing tokens (aTokens for short) are minted when you stake and burned when redeemed. The aTokens are pegged 1:1 to the value of the underlying Dev tokens that are staked in the Dev protocol. aTokens can be freely stored, transferred, and traded. While the underlying asset is staked in a property pool, aTokens accrue interest in real time, directly in your wallet!
2. Hire a business developer to start onboarding Github projects
3. Better UI/UX for both users and OSS developers
4. Penalize unauthenticated property owners

Lock-up periods will only achieve the following:

1. Decrease the number of users willing to use Dev Protocol because of the opportunity costs
2. It won't prevent dumping but only delay it
3. Give more predictability to the open asset creator on what their funding schedule is

If lock-up periods are implemented then I would advise for the following:

1. Make them optional for the user
2. Have different lock-up schedules (30,90,120,365 days)
3. Earn extra APY if you lock up longer

However, the above advice would increase the difficulty of using Dev Protocol for both parties. Again this upgrade should take priority at a more mature stage. Let's keep it casual then move towards a move structured system. The best solution is to focus on the issues that cause dumping while not preventing and delaying dumping.

[aggre]

I close this as we are not currently actively considering bringing lockup-dependent value into the protocol.