Multi-chain/token RLN-Relay

[staheri14]

Problem

A major factor in waku-rln-relay adoption is how membership payment is managed and modeled. Project owners and node operators are interested to know: What is the payment model? is the project tied to a specific token/chain? where do the received funds go?

At this point, there is almost no concrete answer to all these questions. In this milestone, we would like to get hands-on with the implementation of various payment methods and fund management in the rln-relay contract in order to better understand our options, blockers, and unknowns.
Note that in this milestone we are not going to work on the incentivization idea, the game theory behind the fund distribution etc., but rather to develop the necessary components for the payment and fund management according to the most pressing use stories of the waku-rln-relay.

Scope

This milestone encapsulates all the aspects related to the payment model and fund management of the rln-relay membership group contract.

List of issues:

• A raw RFC capturing the basic API for the membership contract 17/Waku-RLN-Relay: Standardizing the interface of rln/rln-relay membership contract  rfc#511
• Capturing fee option in the contract so that a portion of the membership fee goes to a pool of funds as protocol revenue. Incorporating fee option in the rln contract rfc#485
• Pool management potentially through e.g., multi-sig.
• Supporting ERC20 token as the membership payment. ERC-20 tokens as membership deposit for RLN contract  rln-contract#1
• Exploring other payment models and understanding their use cases e.g., a combination of multiple ERC20s and Ether, dynamic support of new tokens. Once decided, further issues shall be created to follow up the implementation and specs updates. The discussion on this has already been kicked off in this issue ERC-20 tokens as membership deposit for RLN contract  rln-contract#1

Risks and uncertainty

NA

Expected timeline: aimed to be done by the end of August 2022.

Acceptance criteria

Once the identified tasks are done, the milestone can be considered complete.

Out of scope

The security of the core rln-relay membership interface e.g., the issue related to the sending of the slashed secret key in plain should be considered out of scope. Will open another milestone for that. The focus of this milestone is only on the payment model.

Notes and links

NA

Future steps

• Contract audit

[staheri14]

cc: @oskarth please let me know your thoughts on this.

[oskarth]

Thanks for capturing these types of issues. I don't think it is at the level of clarity where we can clearly say this is a milestone on its own. Let's first sort out the two most pressing milestones before tackling this.

(The work on contract, fee, erc20 etc should still continue as it is now obviously)