Repository navigation
Rewards-withdrawal locking up #2
Description
Activity
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:
- Take advantage of trading Dev token
- Better APY opportunities somewhere else
- Don't support open asset creators' project anymore
- Open asset creator isn't performing anymore
These issues that cause dumping can be solved with the following steps:
- 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!
- Hire a business developer to start onboarding Github projects
- Better UI/UX for both users and OSS developers
- Penalize unauthenticated property owners
Lock-up periods will only achieve the following:
- Decrease the number of users willing to use Dev Protocol because of the opportunity costs
- It won't prevent dumping but only delay it
- 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:
- Make them optional for the user
- Have different lock-up schedules (30,90,120,365 days)
- 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.
Reacted by aggre and Bilgin IbryamI close this as we are not currently actively considering bringing lockup-dependent value into the protocol.
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.
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.