LLM - freeze_llm mixes sender and subject account
kacperzuk-neti opened this issue · comments
There's no docs for freeze_llm, so it's hard to be sure, but it seems like there's a major bug in freeze_llm. It takes an account argument, which specifies which account should have LLM frozen. In the code however, it uses sender to check LLM balance. If sender has some frozen LLM already, it will increase it. If not, then sender won't have any LLM freezed, instead the account from call args will have LLM frozen.
In any case, it's the sender LLM balance that will be reduced.
What's the purpose of freeze_llm call? Is this for some regulatory stuff? Maybe it's an old thing related to freezing LLM when voting and can now be removed?
If this is a regulatory stuff to be used to lock LLM of someone misbehaving or something, following changes should be made:
- origin is only used to confirm that call was made by someone approved (Root? Council? Referendum result?)
- all LLM balances and locked amounts is modified for
accountfrom call args pallet-assetstransfer is invoked withaccountas origin
Also, it seems like there's no way to unfreeze frozen LLM. Which suggests that freeze_llm is some left-over that can be removed?
Yes, we very likely will not freeze llm, HOWEVER depending on delegation requirements it might be needed
So given that it's unknown whether we'll need it or not and that current implementation is broken, I'll go ahead and create a PR that removes it. We'll readd it properly if needed.
PR ready.