Permanently Locked Vesting Accounts

[clevinson]

Summary

Add support for vesting accounts that can hold permanently locked tokens, for usage in governance voting and staking, but which cannot be traded or moved to different accounts.

Problem Definition

In Regen Network, we have a % of tokens at genesis that are to be allocated to a set of Community Staking DAOs. These organizations must have tokens allocated to them (controlled via a group account), which can be used for governance voting, but which are not tradable or liquid.

We have a corresponding issue on Regen Ledger (regen-network/regen-ledger#188), but it is our hope that this feature would be welcome by other projects besides Regen Network, which is why we are proposing this as a feature for the Cosmos SDK.

Proposal

Add a new type of vesting account LockedVestingAccount or PermanentVestingAccount, where all of the tokens held by this account never become spendable. These accounts should be able to be set in genesis, as well as through an MsgCreateVestingAccount msg in the case where the relevant account owners are not necessarily known at genesis time.

---

For Admin Use

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

[alexanderbez]

Why you can certainly do this explicitly through a new PermanentVestingAccount type, you could also just use the existing DiscreteVestingAccount type with an EndTime that is so far into the future (i.e. max time possible), it's practically permanently locked.

[aaronc]

I think the argument for a new permanent account is 1) greater clarity and 2) we could more easily separate potentially liquid supply from totally non liquid supply for exchanges, etc.

[alexanderbez]

Makes sense, I just wanted to point it out ;-)

[clevinson]

@alexanderbez Yes, an obscenely large EndTime with DiscreteVestingAccount is what we had originally planned on doing, but as it seemed a bit more like a hack, we thought it'd be worth discussing adding as an explicit feature. Also for the reason @aaronc mentioned around more easily querying liquid supply.

[hxrts]

The NFT/metadata working group has a proposal for the NFT standard itself including a notion of transfer capabilities as well.

https://github.com/interNFT/nft-rfc/blob/ac6838bdd90a2e1e56ef75b1c4dfa97c0f7b01db/nft-rfc-005.md#titleproperty-pattern

https://github.com/interNFT/nft-rfc/blob/ac6838bdd90a2e1e56ef75b1c4dfa97c0f7b01db/nft-rfc-004.md#technical-specification

[hxrts]

I'm starting to wonder whether we should have "vesting accounts" at all, or if any account should be able to put coins into a "covenant" that defines conditional distribution of funds. UX patterns would need some research (non-transferrable shares may be one such pattern), but a few standard methods may suffice + maybe an optional method to call cosmwasm for advanced logic.

[aaronc]

Vesting accounts should definitely go away. It will just take some design work. See #8528