Instant undelegation - restoring continuity

Repository

https://github.com/steemit/steem

Components

• Steem Power undelegation (delegation return) period

Proposal Description

Summary

• Current system
  • SP undelegation takes 5 days.
  • UX discontinuity: After 5 days, a sudden voting value jump occurs, which is prone to be wasted.
• Proposal
  • SP undelegation is done instantly. (This isn't a joke. This can be easily implemented without double spending of voting power. To prevent abusing of too frequent un/delegation, RC requirement can be adjusted.)
  • UX continuity: Right after undelegation, voting value stays the same and keeps recovering continuously.

Technical and Historical Background: Why 5 days?

As you know, voting power (VP) full recovery (0%->100%) takes 5 days. Undelegation removes SP from a delegatee instantly, which should be that way (e.g., easy calculation of end of contract; prevention of delegatee's misuse). However, if undelegation also gives SP back to a delegator instantly, double spending of voting power is possible, i.e., use up all VP before returning and use it again.

This was true before HF20. Technically, VP was actually managed by the variable voting_power in the code. However, after HF20, voting power is actually managed by the variable voting_manabar.current_mana (denoted by voting mana hereafter), which is much more sophisticated one. Currently, VP is just a number for backward compatibility. It's directly derived from voting mana, as explained in my previous Utopian bug-hunting post: voting_power is set to zero for users who haven't voted more than 5 days.

In contrast, voting mana is a very big number proportional to the effective SP. Basically, full voting mana is effective mvests.

 'voting_manabar': {'current_mana': '948778993772',
                    'last_update_time': 1547970732},

My current (more precisely, last updated) voting mana

Implementation Details

Currently, voting mana is already added/subtracted depending on transactions. (e.g., hf20_vote_evaluator()) Thus, changing the voting mana calculation logic isn't difficult nor burden to the system.

Specifically, in the current system, the voting mana of undelegated SP is added in full after 5 days. Instead of doing this, if the undelegated amount is added as zero mana instantly after undelegation, then the mana recovery starts continuously without the chance of double spending of voting power. See the mockups for detailed examples.

Mockups / Examples

Here are mockups of steemd.com. Suppose a user has 10,000 SP but delegated 9,000 SP.

This is the current status before undelegation. Effective SP is 1,000 and will undelegate 9,000 SP.

Current system

Now if the user undelegates 9,000 SP, in the current system, nothing will change immediately. Actually, many newbies complain about this, since they can't even notice the difference at all before/after undelegation. (especially for the undelegation from a big account). Finally, after 5 days, sudden voting power and voting value jumps occur with undelegated SP.

Nothing changes until 5 days, and right after 5 days, sudden voting power and voting value jumps occur.

In particular, the voting power tends to be wasted, i.e., soon reached 100% unless the user set the timer exactly when the undelegation is finished.

Proposed system

Every change occurs immediately after undelegation. Despite the voting power drop, the actual voting value stays the same, i.e., 8% of 10K SP = 80% of 1K SP, and then increases continuously.

In the new system, every change occurs immediately after undelegation. As you can see, a sudden voting power drop may occur (depending on the existing/returning SP ratio), but voting value is actually the same and starts increasing together with voting power.

Most UIs which show voting power also shows voting value (e.g., busy, steempeak). Thus, users will not feel uncomfortable with dropped voting power, since they can easily see the voting value is the same and keep increasing thereafter. In fact, most users understand that voting power itself is meaningless: 100% voting of 1K SP is the same as 10% voting of 10K SP. Actually, this immediate change leads them to recognize that the undelegation is actually well initiated.

Benefits

• Instant undelegation
  5 day return period is too long. After HF20, it is even unnecessary. The instant and continuous undelegation process can be implemented without difficulty and burden on the system. As shown in the mockup, users can see the change immediately after the undelegation, which itself is very helpful.
• UX continuity
  If possible, discontinuity should be avoided, as in our previous experience: HF20 Update: Restoring Continuity. My proposal enables users to have continuous voting value after undelegation. Nobody wants to set an alarm 5 days in advance.
• No voting power waste (advance plan)
  Many users complain that they tend to waste voting power after 5 days of undelegation process, as explained in the mockup. Thus, some experienced users use more voting power than usual before the actual return occurs, which is cumbersome and unnatural. But in the new system, voting power waste is almost unlikely, since they can well adjust for 5 days continuously.

Note: As in the introduction, "instant" is an example. While unnecessarily too frequent un/delegation can be prevented by RC, if you're still too much worried, 1 day (or anything much shorter than 5 days) return period can be implemented similarly.

GitHub Account

https://github.com/economicstudio