-
Notifications
You must be signed in to change notification settings - Fork 389
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Accounts should be locked and unlockable #1837
Comments
To enhance performance, we should handle locking filters by adding new fields in tm2's user store. The mempool should efficiently filter transactions with minimal lookups. For updating fields and managing logic, we can apply the same approach planned for PoC (r/sys/valset), and the namespace system (r/sys/names). This involves having gnoland listen to specific For the three types of locking, consider the following:
|
instead of an event, which should be avoided for logic whenever possible, we can just have 'std.SetConfig(string,string)' and 'std.GetConfig(string,string)' which can be called from any realm (but initially only r/sys or r/gov), which stores the parameter in an sdk/param keeper, which is copied over from cosmossdk's x/params. |
This is a must-have for when we unlock GNOT transfer globally, but not for the first launch. In the meantime, we can postpone it. However, it may be convenient to develop both solutions—GNOT global lock and per-account locking—simultaneously within the same module. |
This has to do with GNOT distribution. Accounts should be locked by default -- any transactions submitted should fail while in this locked state, with the exception of a new type of transaction that can be submitted to unlock the account. The new type of transaction should be submitted to indicate that the account owner agrees with the terms of a legal waiver authored by us. Alternately, we could have a special realm the account can call to agree to the waiver and unlock the account.
As for the implementation details, we can add a new method of the
keys.Info
type that returns a boolean indicating whether the account has submitted a transaction agreeing to the waiver, then update all interface implementations accordingly. https://github.com/gnolang/gno/blob/master/tm2/pkg/crypto/keys/types.go#L87-L98Another issue will follow that makes some accounts (exchanges, ICF, IBC) unlockable only by passing a governance proposal.
@moul @jaekwon -- please edit or add any details Ii have missed.
The text was updated successfully, but these errors were encountered: