Support Multiple Vesting Schedules in Vesting Pallet

[shawntabrizi]

Right now we have a pretty strict limitation that only one vesting schedule is allowed per user.

This means if you already have a vesting schedule (say from participating early in Polkadot), that you cannot receive any more manifests with a vesting schedule.

You might imagine that the treasury would want to support vesting payouts at some point, and a single user would want to be the target of multiple vesting payouts.

The solution here should be pretty simple. We should allow a user to have a vector in storage with max length MaxVestingSchedules (configurable) to represent the vesting schedules for the user.

A lock is placed on the account with the maximum balance across all vesting schedules. When a user updates their vesting, we go through the schedules and correctly update the lock, removing any completed schedules.

Since there is still some limit to number of vesting schedules, we should add an additional extrinsic which allows a user to "combine" vesting schedules.

This would combine the balance of two vesting schedules, and create one vesting schedule whose lock time is the greatest of the two.

This means that a user can always extend their vesting schedule to consolidate vesting balances, but also free up space to collect more vesting schedules.

[xlc]

FYI our vesting pallet implementation already support this https://github.com/open-web3-stack/open-runtime-module-library/blob/master/vesting/src/lib.rs

[shawntabrizi]

So only root can consolidate a user's vesting schedule?

This implementation does solve more than 1 vesting schedule, but it would be quite easy to lock out a user from getting more vesting schedules by sending them 20 vested transfers. Then we are back to the same problem.

Seems on the right track though.

[xlc]

update_vesting_schedules is to modify existing vesting schedule. e.g. extend it or reduce it.

Our implementation only put one lock. I don't think it is possible to consolidate multiple vesting schedule instances.

but it would be quite easy to lock out a user from getting more vesting schedules by sending them 20 vested transfers

Good point... Maybe I should not allow anyone to call vested_transfer... At least at Acala we don't have this requirement.

[shawntabrizi]

It is not about creating one lock, my suggestion would be the same, but limiting the size of the Vec. Basically, my idea is that you let the user combine two schedules into one by accepting the worst of the two unlocking schedules.

[Rose2161]

I agree with multiple schedules