Protocol v2.0.0
Protocol v2.0.0 Release Notes
v2.0.0 contains an upgrade handler that properly initializes module accounts as ModuleAccount. This fixes a chain-halting vulnerability if an account managed to be improperly initialized (7a32aa9).
In code paths where a ModuleAccount is expected, an account will be lazily initialized as ModuleAccount. If an account already exists, a type assertion to ModuleAccount is performed, and upon failure the program will panic. This assertion fails if the account has somehow been initialized as a BaseAccount prior to its first usage as a ModuleAccount. For example, if a bank send is performed, an uninitialized destination account will be initialized as a BaseAccount.
Once a module account has been initialized as a BaseAccount, all paths that expect a ModuleAccount will panic. In particular, the x/vest BeginBlocker will panic if the treasury account is a BaseAccount. Thus, it is possible to halt a chain with uninitialized module accounts with two bank sends: Send balance to a treasury account to initialize it as BaseAccount, and then send to its corresponding vest account to initiate vesting.
A few other code paths are also affected by this. For example, querying an incorrectly initialized module account through the x/auth module_account endpoint will error.
Go version
1.21