ERC-20 tokens as membership deposit for RLN contract

[kgrgpg]

The currently used RLN membership contract as implemented in https://github.com/kgrgpg/rln/blob/main/contracts/Rln.sol , accepts the payment in ETH for register function. This acts as the stake of the member in the RLN group that gets slashed when the member misbehaves like spamming the peer to peer network.

There have been request to support ERC-20 tokens as membership deposit for the contract. But detailed discussion and implementation over the said functionality has not taken place and this issue will address it.

The implementation of ERC-20 token can take place in multiple ways. Some of them are listed as follows and require different technical implementations in Solidity smart contracts:

1. Accept an existing ERC-20 token (like SNT, etc.) as the ONLY membership deposit for the RLN contract.
2. Accept Wrapped ETH i.e. WETH as the ONLY membership deposit for the RLN contract.
3. Accept an existing ERC-20 token and WETH (so 1. and 2. as above combined) as the ONLY membership deposit. The value of the membership deposit is pre defined while initialising the contract.
4. Mint a new ERC-20 token (maybe called WAKUTOKEN) with FIXED SUPPLY that can be bought in the free market. This token will be the ONLY token accepted as the membership deposit.
5. Mint a new ERC-20 token (maybe called WAKUTOKEN) with DYNAMIC SUPPLY. This token is minted by depositing an existing valuable token like ETH in a bonded contract. This token will be the ONLY token accepted as the membership deposit.
6. Accept multiple ERC-20 token that are pre-selected during initialisation of contract. The membership deposit value is chosen in a base currency, like USDC or ETH. All accepted tokens must be equal to this value of deposit that is verified by ORACLES.
7. Dynamically add new ERC-20 tokens, if possible, to the list of accepted tokens. The membership deposit value is chosen in a base currency, like USDC or ETH. All accepted tokens must be equal to this value of deposit that is verified by ORACLES.

The complexity of the implementation goes higher as we move down the above list. We need to discuss the most valid ones and move towards them.

[kgrgpg]

Requesting feedback from @staheri14 @fryorcraken @oskarth

[richard-ramos]

Maybe it's too early for discussing technical implementations, but if a new token is created (in options 4 and 5), consider adding support to https://eips.ethereum.org/EIPS/eip-2612 so it's not necessary to do an approve transaction as a step previous to depositing the tokens.

For option 1, if SNT is the token to use, maybe a helper function function receiveApproval(address _from, uint256 _amount, address _token, bytes memory _data) public { could be added to allow using approveAndCall from https://eips.ethereum.org/EIPS/eip-1363, and this way also avoid having to do 2 separate transactions.

[fryorcraken]

Is there a difference in the respective contract API between an ERC-20 token and WETH?
I am not sure to understand why WETH is a case set apart

I would not scope the minting of token in this work. I think it makes sense to only scope

Accept an existing ERC-20 token (like SNT, etc.) as the ONLY membership deposit for the RLN contract.

Other use cases may raise in the future (several ERC-20, ERC-20 token + Eth with discount on token, etc) but they can left out of scope at this stage.

[oskarth]

I would not scope the minting of token in this work. I think it makes sense to only scope

Accept an existing ERC-20 token (like SNT, etc.) as the ONLY membership deposit for the RLN contract.

Agree.

To me, ERC20 should basically be a parameter when you deploy the contract. So the contract itself is agnostic to ERC20 address, and deployment of it is a separate concern.

It might make sense to have two contracts. One using only ETH, and the other being parametric ERC20. Then depending on what platforms/networks want, they can deploy a specific instance of some ERC20 token.

The decision to point an implementation to a specific contract instance is then a separate discussion, so you can imagine that in the future people using the Status protocol would instruct nwaku to use the SNT ERC20 address, but a different platform could conceptually deploy their own thing and point nwaku to that.

[oskarth]

(in options 4 and 5), consider adding support to https://eips.ethereum.org/EIPS/eip-2612 so it's not necessary to do an approve transaction as a step previous to depositing the tokens.

For option 1, if SNT is the token to use, maybe a helper function function receiveApproval(address _from, uint256 _amount, address _token, bytes memory _data) public { could be added to allow using approveAndCall from https://eips.ethereum.org/EIPS/eip-1363, and this way also avoid having to do 2 separate transactions.

These are great points and I agree! Big difference for usability. Just to check:

1. Would this work for any ERC20 token? Or does EIP-1363 support have to be added to the actual "ERC20" token contract and not just in the RLN contract?

2. If the token contract needs native support for it, could this easily be detected and tokens that support EIP-1363 can use one-step approveAndCall, with older versions requiring approve and call as two steps?

[oskarth]

This issue is also in the wrong repo, it should either be in the RLN repo (which should live under vacp2p GH org) or the research repo

[kgrgpg]

Moving this issue under the correct organisation and repo. Refer to vacp2p/rln-contract#1 and continue all future discussions there.