The purpose of this post is to discuss the multisig setup for the RLNv2 contract.
Background
RLN is a core component of Waku that rate-limits resource usage within the network. The central feature of RLN is a set of on-chain smart contracts that manage memberships. Users can purchase memberships, allowing them to send a specified number of messages per unit of time. Message senders prove their membership using zero-knowledge proofs, which preserves their privacy.
In 2024, a new version of the RLN smart contract, called RLNv2, was developed. This version introduces enhanced membership management functionality, as detailed in the specification.
RLNv2 is currently deployed on the Linea Sepolia testnet, which is an Ethereum-based rollup. As of January 2025, RLNv2 has not yet been integrated into nwaku or any other Waku implementation. According to the roadmap (see issue 258), we plan to deploy it on the Linea mainnet.
Owner Privileges in the RLNv2 Contract
The RLNv2 contract currently has an Owner with the following privileges:
In the current implementation (see README):
- Set specific contract parameters, such as the price of one message per epoch and the maximum total rate limit.
Additionally, according to the specification (not yet implemented as of January 2025):
- Pause all membership-related functionalities (e.g., register, extend, erase, withdraw).
Furthermore, to be specified in the future:
- Withdraw and distribute funds from the contract balance.
Problem Statement
This post aims to open a discussion about how control over the contract Owner should be distributed.
According to the specification, the contract should eventually become ownerless. However, this transition may take time. Centralized control over the contract is beneficial during testing and integration, but the contract should not be controlled by a single party upon mainnet deployment.
The primary goal of distributing control over the Owner is to prepare for mainnet deployment while minimizing centralization risks.
The setup should:
- Utilize well-tested software.
- Allow for changes in quorum configuration.
- Enable the replacement of signers in case of key loss.
- Not hinder testing, especially during earlier (testnet) development stages.
- Incorporate best practices from the ongoing management of the Status multisig.
Multisig vs. MPC-based Threshold Signature Schemes (TSS)
Multisig and TSS are two techniques that enable distributed control over a cryptographic entity.
- Multisig: A smart contract is jointly controlled by multiple keys.
- Threshold Signature Scheme (TSS): A cryptographic scheme that allows parties to perform multi-party computation (MPC) to collaboratively sign a message without reconstructing the private key.
The key difference between the two techniques lies in how signers are coordinated.
Multisig
In a multisig setup, a smart contract serves as an on-chain coordinator:
- A smart contract is deployed to implement access control logic.
n
potential signers are assigned.- Any
t
of then
signers independently sign payloads authorizing an action within the contract. - The last signer combines the payloads into a transaction and broadcasts it (and pays the transaction fee).
In our setup, the multisig contract would act as the Owner of the RLNv2 contract. It is possible to designate one contract as the Owner of another (Ownable
) contract.
TSS
In an MPC-based TSS, a coordination protocol operates off-chain. The resulting signature is indistinguishable from one produced by a single key:
- Private key shares are generated and distributed among
n
potential signers. - Any
t
out ofn
signers use a multi-party protocol (MPC) to collaboratively sign a transaction. - The signed transaction is then broadcast.
Unlike multisig, TSS does not require deploying additional contracts on-chain and is network-agnostic, meaning it does not depend on specific smart contract implementations. (However, multisig setups can also be considered network-agnostic if we consider well-tested implementations deployed on EVM-based networks.)
Key Differences
Feature | Multisig | TSS |
---|---|---|
Owner-related logic is on-chain (better transparency, worse privacy) | Yes | No |
Widely used and tested software exists | Yes | Maybe? |
Granular control over Owner’s actions on-chain | Yes | No |
Network-agnostic | Kinda? | Yes |
Defining Our Setup
Choosing a Multisig (or TSS) Implementation
Potential multisig implementations include:
- Safe: Currently the market leader (cf. Q1 2024 Messari report).
- Argent Vault: Primarily focused on Starknet but supports Ethereum “for existing users”.
- Ambre Wallet: Another viable option.
An example of a TSS implementation is Totalsig.
We need to evaluate the security model to make an informed choice. Key considerations include:
- For TSS-based setups, who facilitates coordination? Will we rely on a third-party coordinator?
- For multisig setups, what are the risks if the official frontend becomes unavailable? Can transactions still be prepared locally without assistance from multisig implementation developers?
Choosing a Quorum
In a multisig setup, any t
out of n
keys are required to authorize a transaction, referred to as a quorum (t-of-n).
Common quorum configurations include 2-of-3 and 3-of-5. The value of t
should be strictly less than n
to avoid freezing ownership if a single key is lost.
For our purposes:
- A more permissive quorum (lower
t
) should be used during early development and testing to simplify processes. - A stricter quorum (higher
t
) should be adopted as we approach mainnet deployment.
Considerations for Multisig Parametrization
- Balance development/testing simplicity with minimizing the risk of freezing the contract due to key loss.
- Implement key rotation procedures to replace signers if a key is lost, a person leaves Waku, or other unforeseen circumstances arise.
A written protocol should outline processes such as:
- Signing transactions.
- Verifying the authenticity of data to be signed.
- Key rotation and backup restoration.
Signers must familiarize themselves with this document and adhere to all outlined steps. At least one signer (responsible for broadcasting finalized transactions) must hold native tokens (e.g., ETH on Ethereum mainnet) to pay transaction fees.
Assigning Signers
During the testing phase, most (if not all) signers should be Waku developers and researchers. As we approach mainnet deployment, additional signers from Status, IFT, or independent parties should be included.
Draft Proposal
As a starting point, we propose the following setup:
- Protocol type: Multisig.
- Implementation: Safe.
- Quorum: 2-of-10.
- Signers: To be determined.
Action Items
This post aims to initiate a discussion around the following questions:
- Does the overall reasoning make sense?
- What arguments exist for and against multisig vs. TSS?
- What implementations are worth considering?
- What quorum configurations should be preferred?
- What additional considerations should we account for?
- What other uses can we find for the multisig? (e.g., signing releases)
Feedback and suggestions are welcome!