Skip to content
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

Open
deelawn opened this issue Mar 25, 2024 · 3 comments
Open

Accounts should be locked and unlockable #1837

deelawn opened this issue Mar 25, 2024 · 3 comments

Comments

@deelawn
Copy link
Contributor

deelawn commented Mar 25, 2024

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-L98

Another 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.

@deelawn deelawn self-assigned this Mar 25, 2024
@moul
Copy link
Member

moul commented Mar 25, 2024

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 std.Event (#575) triggered by r/sys/acctlock.


For the three types of locking, consider the following:

  • To use a global flag controlled by r/sys/config (Creating a r/sys/config realm for runtime configuration #1856) or r/sys/acctlock to block gnot transfers universally.
  • Use DAO logic to unfreeze special accounts (escrows, etc) in r/sys/acctlock.
  • Allow standard users to self-unlock by signing terms of service without DAO intervention in r/sys/acctlock.

@jaekwon
Copy link
Contributor

jaekwon commented Aug 15, 2024

std.Event

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.

@moul
Copy link
Member

moul commented Oct 15, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Triage
Development

No branches or pull requests

6 participants