Permanently Locked accounts + Msg for account creation on-chain

[clevinson]

For Community Staking DAOs we need the ability to have accounts with "permanently locked tokens", as the funds allocated to these DAOs for governance are not intended to be tradable, but only used for onchain gov & voting procedures.

Current implementation strategy using what's already available in the SDK would involve putting these in a vesting account where the lockup period is some arbitrarily large number (e.g. 1000000 years).

A preferred alternative is to add new functionality to regen ledger (or potentially upstream in the Cosmos SDK) where accounts can have some set of tokens that are permanently locked and only used for governance.

For our own use case, this is only needed to be set at genesis.

Related: cosmos/cosmos-sdk#7774

[aaronc]

We should have an issue on cosmos side too. Should I write that up?

[clevinson]

Adding this to the Baikal upgrade milestone.

After a few conversations w/ the Regen Foundation team, they definitely have a desire to be launching multiple CSDAO's over the next several months. I think it's better practice to not have the creation of these too tightly coupled with our upgrade cycle, so I'd like us to add a MsgCreatePermanentLockedAccount & CLI methods and fold that in to the v2.0 release cycle.

[clevinson]

IMO the path forward should be updating our fork of the SDK (which is currently based off of v0.42.0) to be based off the v0.43.0 and add in the corresponding Msg.

We can likely upstream this later to the SDK similar to what @zmanian did here: cosmos/cosmos-sdk#9596

[aaronc]

This will probably delay things significantly no? I really think we need to weigh the pros and cons of each feature along with how it affects the timeline

[clevinson]

I don't see this as significantly affecting timeline. The PR above (regen-network/cosmos-sdk#42) I knocked out pretty quick. If there are changes needed to it, I'm happy to try and get those out fast so not to delay timeline further.

My current sense of this is:

• min impact of timeline (3 days) [1 day implementation, 2 days review / merge, 0 days audit additional time]
• max impact of timeline (2 weeks) [5 days implementation / review, 5 days audit / review]

I shared these range today with @glandua on the DecentralOSS call, and he seemed in favor with this decision as well. If there's still contrary opinions that these estimates are either inaccurate or that they would set us back too far, I'm happy to re-evaluate on the regen ledger product call tomorrow.