Decide how to manage "payments" when GNOT will be locked

[moul]

Currently, we have some contracts, such as r/demo/users, that are requesting payments for actions (https://gno.land/r/demo/users/users.gno).

However, we will lock GNOT tokens at launch (#2980), so we need to find an alternative.

Here are some options:

1. Use gas
2. Use another native std.Coin, but not GNOT
3. Use a grc20, which could be a future token
4. Disable these features until we enable token transfers

[thehowl]

I'm tempted to say 4: Disable these features until we enable token transfers. The reason is that I don't think we should officially have and support 'gnot' future tokens, because if they're used by the core team they're likely to have as much validity as unlocking gnot directly.

I am thinking that maybe we can support an alternative token, depending on the realm, to perform the "payment". This token can be awarded with a faucet depending on the project, or be airdropped similarly to GNOT to mimick the real token distribution. Then we can have a way to permanently switch it, in the realms, to using gnot instead; but use the "playground" token for the meantime.

[moul]

I'm also trying to avoid 3.

I'm considering a "reputation" GRC20 (or non-transferable) token that will have its own earning mechanism, such as contributions. We might not expect the token to serve as a payment method, but rather as a way to unlock features when you have "enough" reputation.

[moul]

Right now, we have identified two main patterns:

Preventing abuses and DDoS attacks by requiring specific actions to be whitelisted by a DAO, or by expecting more contracts to implement an invite system.

• Implementing a "target whitelist" in the GNOT lock module, enabling payments but only for whitelisted realms.

We expect to use these two patterns to reduce spam while still allowing people to create fully permissionless systems.

We can close this issue as we have a solution. However, please feel free to open a new one to suggest additional ideas.