EPIC: Separate x/auth and vesting

[aaronc]

Summary

As we know, x/auth is overloaded. It's primary functionality should be account authentication. But it contains much more.

Problem Definition

Recently we had a problem with x/auth migration where vesting account were vanished: #10591

Related:

• Docs: clarify vesting terminology as time lock escrow + distinguish between common legal vesting terminology #10662

Proposal

Move vesting account feature from x/auth to x/vesting and enable more feature development in a new module.

[alexanderbez]

So what are the concrete action items you had in mind @aaronc? We have a series of SDK issues that relate to vesting and I think we should create a checklist in this main issue that references them, treating this issue as an epic.

For starters, should we start by copying all vesting types to their own Go module?

[aaronc]

A stand-alone go module is nice but maybe premature since we don't have the new app wiring ready yet.

The two main things that would be nice to see IMHO are pulling it out of auth and allowing multiple locks per account. I.e. it should be possible to send a new bunch of vesting tokens to any existing account. The challenge is figuring out how to do this in a way that doesn't allow spam. There's been some prior design work. @AmauryM do you have meeting notes from when we last looked into this?

[bretheren]

A stand-alone go module is nice but maybe premature since we don't have the new app wiring ready yet.

The two main things that would be nice to see IMHO are pulling it out of auth and allowing multiple locks per account. I.e. it should be possible to send a new bunch of vesting tokens to any existing account. The challenge is figuring out how to do this in a way that doesn't allow spam. There's been some prior design work. @AmauryM do you have meeting notes from when we last looked into this?

Yeah, this would be awesome. Is there any plan to work on vesting to make it possible to send different vesting tokens to any existing account?

[tac0turtle]

close in favour of #18782