Create Vesting Account Message

[alexanderbez]

Summary

Currently, the only way to define and utilize vesting accounts is through genesis. Now that the hub has launched, there is essentially no longer a way to create new vesting accounts.

Proposal

• Create a new message and corresponding handler:

type MsgCreateVestingAccount struct {
	FromAddress sdk.AccAddress `json:"from_address"`
	ToAddress   sdk.AccAddress `json:"to_address"`
	Amount      sdk.Coins      `json:"amount"`
	EndTime     int64          `json:"end_time"`
        Delayed     bool           `json:"delayed"`
}

The handler for this would not differ much from a traditional MsgSend except that it would modify the newly created account to now include the new vesting fields.

Also, I decided to omit start_time and allow that to be inferred from the block time (ie. it starts vesting immediately).

/cc @cwgoes @zmanian

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[zmanian]

I don't think we should omit start time.

[zmanian]

I think this is mostly going to be useful in contexts other than the Hub

[fedekunze]

Nice proposal, it might also make sense to move vesting accs to a new module as per our discussion last week with @rigelrozanski

[rigelrozanski]

Yeah I'd say this makes sense to happen as a part of the refactor which removes vesting from auth. But also, like it seems like there is no use for this? Why would anybody want to create a vesting account from unlocked tokens? It seems like what we actually want is more generalizable send capabilities aka smart contracts.

So I'd actually propose we hold off on this one in favour of some kind of more generalizable scheme.
Thoughts?

[alexanderbez]

@zmanian I think we can remove Delayed in favor of StartTime, but my main concern is what if accounts spend coins that are meant to be vesting prior to StartTime. Will this account behave safely once StartTime has passed? I need to further analyze this.

---

@rigelrozanski, @fedekunze

I'm not necessarily against moving the vesting account implementation out of x/auth, but I want to understand the primary rationale behind such a move. I know IRIS forked the SDK and modified x/auth by removing vesting, but I don't necessarily understand why? You're not forced to use vesting accounts -- ie. you can use accounts as normal.

[cwgoes]

Generally my question here is around whether vesting "accounts" are really the right model or whether we ought to switch to vesting "coins" and deprecate the current vesting account system (although retain the same logic for determining which coins are spent in what order). Right now, each account can only have one kind of vesting (and one start time / end time), which is rather restrictive.

[alexanderbez]

That would be a full paradigm shift @cwgoes but this approach would allow greater flexibility. Namely, as the number of tokens expands in the hub, this would be the ideal approach.