From 4c09596d9c0e31a7d22c78c22426184f161c6f56 Mon Sep 17 00:00:00 2001 From: Jimmy Debe <91767824+jimstir@users.noreply.github.com> Date: Thu, 17 Apr 2025 11:38:19 -0400 Subject: [PATCH 1/9] Update rln-contract.md --- standards/core/rln-contract.md | 49 ++++++++++++++++------------------ 1 file changed, 23 insertions(+), 26 deletions(-) diff --git a/standards/core/rln-contract.md b/standards/core/rln-contract.md index 4815e9e..ac2569d 100644 --- a/standards/core/rln-contract.md +++ b/standards/core/rln-contract.md @@ -9,21 +9,11 @@ contributors: ## Abstract -This document describes membership management within the RLN smart contract, specifically addressing: +This document describes membership management within the Rate-Limiting Nullifer (RLN) smart contract, specifically addressing: - membership-related contract functionality; - suggested parameter values for the initial mainnet deployment; - contract governance and upgradability. -Currently, this document focuses solely on membership-related functionality. -It might later evolve into a comprehensive contract specification. - -As of August 2024, RLN is deployed only on Sepolia testnet ([source code](https://github.com/waku-org/waku-rlnv2-contract/blob/main/src/WakuRlnV2.sol)). -This document aims to outline the path to its mainnet deployment. - -## Syntax - -The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt). - ## Background Rate-Limiting Nullifier (RLN) is a Zero-Knowledge (ZK) based gadget used for privacy-preserving rate limiting in Waku. @@ -33,27 +23,33 @@ Users interact with the contract to manage their memberships and obtain the necessary data for proof generation and verification. Message transmission is handled by Waku RLN Relay nodes. -The sender of a message MUST prove its validity according to RLN requirements. -RLN Relay nodes MUST NOT relay invalid messages. -For the full specification of RLN Relay, see See [17/WAKU2-RLN-RELAY](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/17/rln-relay.md). +The sender of a message must prove its validity according to RLN requirements. +RLN Relay nodes must not relay invalid messages. +For the full specification of RLN Relay, see [17/WAKU2-RLN-RELAY](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/17/rln-relay.md). + +Currently, this document focuses solely on membership-related functionality. +It might later evolve into a comprehensive contract specification. +As of August 2024, RLN is deployed only on Sepolia testnet ([source code](https://github.com/waku-org/waku-rlnv2-contract/blob/main/src/WakuRlnV2.sol)). +This document aims to outline the path to its mainnet deployment. ## Contract overview -Let us define membership-related functionalities (hereinafter, functionalities) as follows: +The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt). + +The contract MUST provide the following membership-related functionalities (hereinafter, functionalities): - register a membership; - extend a membership; - erase a membership; - withdraw a deposit. -The contract MUST provide the functionalities. - A membership _holder_ is a role that grants special privileges in the context of membership management. Each membership MUST have exactly one holder. -The holder role MUST be assigned at membership registration time to the sender (`msg.sender` in Solidity semantics) of the registration transaction. +The holder role MUST be assigned at membership registration time to the sender +(`msg.sender` in Solidity semantics) of the registration transaction. When authorizing membership-related requests, the contract MUST distinguish between the holder and non-holders, and MAY also use additional criteria. -The holder MAY be a different entity from the one that controls the secret associated with the respective RLN commitment. +The holder MAY be a different entity from the one that controls the secret associated with the respective RLN commitment******. The contract MUST support transactions sent directly from externally-owned accounts (EOA). The contract MAY support transactions sent via a chain of contract calls, @@ -116,7 +112,7 @@ Different line types denote the types of state transitions: | Thin (`--`) | Transaction | MAY be initiable by any user. | | Dotted (`-.-`) | Time progression | MAY be applied lazily. | -Transaction-triggered state transitions MUST be applied immediately. +Transaction-triggered state transitions MUST be applied immediately based on the blockchain tranaction time********. When handling a membership-specific transaction, the contract MUST: - check whether the state of the involved membership is up-to-date; @@ -133,13 +129,12 @@ Memberships MUST be included in the membership set according to the following ta | _ErasedAwaitsWithdrawal_ | No | | _Erased_ | No | -Memberships MUST NOT be transferable. +Memberships MUST NOT be transferable to a different Ethereum address******. A user MAY use one Ethereum address to manage multiple memberships. A user MAY use one Waku node[^1] to manage multiple memberships. [^1]: No Waku implementation supports managing multiple memberships from one node (as of August 2024). - ## Contract functionalities Availability of functionalities[^2] MUST be as follows: @@ -157,20 +152,22 @@ Availability of functionalities[^2] MUST be as follows: Membership registration is subject to the following requirements: - The holder MUST specify the requested rate limit `r` of a new membership at registration time[^3]. - Registration MUST fail if `r < r_{min}` or `r > r_{max}`. -- The holder MUST lock up a deposit to register a membership. +- The holder MUST lock up a deposit to register a membership********. - The size of the deposit MUST depend on the specified rate limit. - In case of a successful registration: - the new membership MUST become _Active_; - the new membership MUST have an active state duration `A > 0` and a grace period duration `G >= 0`; - the current total rate limit MUST be incremented by the rate limit of the new membership. + #### Reusing the rate limit of _Expired_ memberships -Let us define the following rate limits: +Below are define the following rate limits:******** + - `R_{active}` is the total rate limit of all _Active_ memberships; - `R_{grace_period}` is the total rate limit of all _GracePeriod_ memberships; - `R_{expired}` is the total rate limit of all _Expired_ memberships. -Let us define the free rate limit that is available without reusing the rate limit of _Expired_ memberships as follows: +Below define the free rate limit that is available without reusing the rate limit of _Expired_ memberships as follows:***** ``` R_{free} = R_{max} - R_{active} - R_{grace_period} - R_{expired} @@ -223,7 +220,7 @@ The contract MAY restrict extensions for memberships created before the latest p The _Owner_ MUST be able to pause any of the functionalities (see definition above). At some point, the _Owner_ SHOULD renounce their privileges, -and the contract MUST become immutable. +and the contract becomes immutable. If further upgrades are necessary, a new contract SHOULD be deployed, and the membership set SHOULD be migrated. From f292c86a34b2cd4ab34356b36539318a9f73a3a0 Mon Sep 17 00:00:00 2001 From: Jimmy Debe <91767824+jimstir@users.noreply.github.com> Date: Thu, 1 May 2025 09:41:29 -0400 Subject: [PATCH 2/9] Update rln-contract.md --- standards/core/rln-contract.md | 37 ++++++++++++++++++++++------------ 1 file changed, 24 insertions(+), 13 deletions(-) diff --git a/standards/core/rln-contract.md b/standards/core/rln-contract.md index ac2569d..f4eb248 100644 --- a/standards/core/rln-contract.md +++ b/standards/core/rln-contract.md @@ -46,10 +46,15 @@ A membership _holder_ is a role that grants special privileges in the context of Each membership MUST have exactly one holder. The holder role MUST be assigned at membership registration time to the sender (`msg.sender` in Solidity semantics) of the registration transaction. +The sender of the registration SHOULD have RLN `identity_commitment` generated. +For more information see [32/RLN-V1](https://github.com/vacp2p/rfc-index/blob/main/vac/32/rln-v1.md). + +Membership registration MAY be initiated by a different entity from the one that controls the RLN `identity_secret`, +which is associated with the respective RLN `identity_commitment`. +Therefore, the holder MAY be assigned to an blockchain address that does not control the `identity_secret`. When authorizing membership-related requests, the contract MUST distinguish between the holder and non-holders, -and MAY also use additional criteria. -The holder MAY be a different entity from the one that controls the secret associated with the respective RLN commitment******. +and MAY also implement additional criteria. The contract MUST support transactions sent directly from externally-owned accounts (EOA). The contract MAY support transactions sent via a chain of contract calls, @@ -112,7 +117,7 @@ Different line types denote the types of state transitions: | Thin (`--`) | Transaction | MAY be initiable by any user. | | Dotted (`-.-`) | Time progression | MAY be applied lazily. | -Transaction-triggered state transitions MUST be applied immediately based on the blockchain tranaction time********. +Transaction-triggered state transitions MUST be applied immediately based on the blockchain tranaction time. When handling a membership-specific transaction, the contract MUST: - check whether the state of the involved membership is up-to-date; @@ -129,8 +134,8 @@ Memberships MUST be included in the membership set according to the following ta | _ErasedAwaitsWithdrawal_ | No | | _Erased_ | No | -Memberships MUST NOT be transferable to a different Ethereum address******. -A user MAY use one Ethereum address to manage multiple memberships. +The holder assigned blockchian address MUST NOT be transferable to a different blockchain address. +A user MAY use one blockchain address to manage multiple memberships. A user MAY use one Waku node[^1] to manage multiple memberships. [^1]: No Waku implementation supports managing multiple memberships from one node (as of August 2024). @@ -145,23 +150,29 @@ Availability of functionalities[^2] MUST be as follows: | Erase the membership | No | Yes (holder only) | Yes | No | No | | Withdraw the deposit | No | No | No | Yes (holder only) | No | -[^2]: Sending a message is not present in this table because it is part of the RLN Relay protocol and not the contract. For completeness, we note that the membership holder MUST be able to send a message if their membership is _Active_, in _GracePeriod_, or _Expired_. Sending messages with _Expired_ memberships is allowed, because the inclusion (Merkle) proof that the holder provides to RLN Relay only proves that the membership belongs to the membership set, and not that membership's state. +[^2] Note: Sending a message is not present in this table because it is part of the RLN Relay protocol and not the contract. +For completeness, we note that the membership holder MUST be able to send a message if their membership is _Active_, +in _GracePeriod_, or _Expired_. +Sending messages with _Expired_ memberships is allowed, +because the inclusion (Merkle) proof that the holder provides to RLN Relay only proves that the membership belongs to the membership set, and not that membership's state. ### Register a membership Membership registration is subject to the following requirements: - The holder MUST specify the requested rate limit `r` of a new membership at registration time[^3]. - Registration MUST fail if `r < r_{min}` or `r > r_{max}`. -- The holder MUST lock up a deposit to register a membership********. -- The size of the deposit MUST depend on the specified rate limit. +- The holder MUST make an tranasction to the contract, +locking the deposit to register a membership. +- The amount of the deposit MUST depend on the specified rate limit. - In case of a successful registration: - the new membership MUST become _Active_; - - the new membership MUST have an active state duration `A > 0` and a grace period duration `G >= 0`; + - the new membership MUST have an active state duration `A > 0` and + a grace period duration `G >= 0`; - the current total rate limit MUST be incremented by the rate limit of the new membership. #### Reusing the rate limit of _Expired_ memberships -Below are define the following rate limits:******** +Below define the following rate limits:******** - `R_{active}` is the total rate limit of all _Active_ memberships; - `R_{grace_period}` is the total rate limit of all _GracePeriod_ memberships; @@ -175,20 +186,20 @@ R_{free} = R_{max} - R_{active} - R_{grace_period} - R_{expired} Membership registration is additionally subject to the following requirements: - If `r <= R_{free}`, the new membership MUST be registered (assuming all other necessary conditions hold). - - The new membership MAY erase one or multiple _Expired_ memberships and reuse their rate limit. + - The new membership MAY erase one or multiple _Expired_ memberships and reuse their rate limit.*** - If `r > R_{free}`: - if `r > R_{free} + R_{expired}`, registration MUST fail; - if `r <= R_{free} + R_{expired}`, the new membership SHOULD be registered by reusing some _Expired_ memberships. - The sender of the registration transaction MAY specify a list of _Expired_ memberships to be erased and their rate limit reused. - If any of the memberships in the list are not _Expired_, the registration MUST fail. - - If the list is not provided, the contract MAY use any criteria to select _Expired_ memberships to reuse (see Implementation Suggestions). + - If the list is not provided, the contract MAY use any criteria to select _Expired_ memberships to reuse (see [Implementation Suggestions](#ImplementationSuggestions)). - If the list is not provided, the registration MAY fail even if the membership set contains _Expired_ membership that, if erased, would free up sufficient rate limit. - If a new membership A erases an _Expired_ membership B to reuse its rate limit: - membership B MUST become _ErasedAwaitsWithdrawal_; - the current total rate limit MUST be decremented by the rate limit of membership B; - the contract MUST take all necessary steps to ensure that the holder of membership B can withdraw their deposit later. -[^3]: A user-facing application SHOULD suggest default rate limits to the holder (see Implementation Suggestions). +[^3]: A user-facing application SHOULD suggest default rate limits to the holder (see [Implementation Suggestions](#ImplementationSuggestions)). ### Extend a membership From 1c020832631db2b859f369a97de02978d36ddae2 Mon Sep 17 00:00:00 2001 From: Jimmy Debe <91767824+jimstir@users.noreply.github.com> Date: Thu, 1 May 2025 10:04:37 -0400 Subject: [PATCH 3/9] Update rln-contract.md --- standards/core/rln-contract.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/standards/core/rln-contract.md b/standards/core/rln-contract.md index f4eb248..6b42de6 100644 --- a/standards/core/rln-contract.md +++ b/standards/core/rln-contract.md @@ -172,34 +172,35 @@ locking the deposit to register a membership. #### Reusing the rate limit of _Expired_ memberships -Below define the following rate limits:******** +The rate limits are defined as follows: - `R_{active}` is the total rate limit of all _Active_ memberships; - `R_{grace_period}` is the total rate limit of all _GracePeriod_ memberships; - `R_{expired}` is the total rate limit of all _Expired_ memberships. -Below define the free rate limit that is available without reusing the rate limit of _Expired_ memberships as follows:***** +The free rate limit that is available without reusing the rate limit of _Expired_ memberships is defined as follows: ``` R_{free} = R_{max} - R_{active} - R_{grace_period} - R_{expired} ``` Membership registration is additionally subject to the following requirements: + - If `r <= R_{free}`, the new membership MUST be registered (assuming all other necessary conditions hold). - - The new membership MAY erase one or multiple _Expired_ memberships and reuse their rate limit.*** + - The new membership MAY erase one or multiple _Expired_ memberships and reuse their rate limit. - If `r > R_{free}`: - if `r > R_{free} + R_{expired}`, registration MUST fail; - if `r <= R_{free} + R_{expired}`, the new membership SHOULD be registered by reusing some _Expired_ memberships. - The sender of the registration transaction MAY specify a list of _Expired_ memberships to be erased and their rate limit reused. - If any of the memberships in the list are not _Expired_, the registration MUST fail. - - If the list is not provided, the contract MAY use any criteria to select _Expired_ memberships to reuse (see [Implementation Suggestions](#ImplementationSuggestions)). + - If the list is not provided, the contract MAY use any criteria to select _Expired_ memberships to reuse (see [Implementation Suggestions](#implementation-suggestions)). - If the list is not provided, the registration MAY fail even if the membership set contains _Expired_ membership that, if erased, would free up sufficient rate limit. - If a new membership A erases an _Expired_ membership B to reuse its rate limit: - membership B MUST become _ErasedAwaitsWithdrawal_; - the current total rate limit MUST be decremented by the rate limit of membership B; - the contract MUST take all necessary steps to ensure that the holder of membership B can withdraw their deposit later. -[^3]: A user-facing application SHOULD suggest default rate limits to the holder (see [Implementation Suggestions](#ImplementationSuggestions)). +[^3]: A user-facing application SHOULD suggest default rate limits to the holder (see [Implementation Suggestions](#implementation-suggestions)). ### Extend a membership From 63c2fb71069a30ad5825de46408f10719cdfab26 Mon Sep 17 00:00:00 2001 From: Jimmy Debe <91767824+jimstir@users.noreply.github.com> Date: Tue, 6 May 2025 05:43:11 -0400 Subject: [PATCH 4/9] Update rln-contract.md --- standards/core/rln-contract.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/standards/core/rln-contract.md b/standards/core/rln-contract.md index 6b42de6..f7f150e 100644 --- a/standards/core/rln-contract.md +++ b/standards/core/rln-contract.md @@ -46,12 +46,14 @@ A membership _holder_ is a role that grants special privileges in the context of Each membership MUST have exactly one holder. The holder role MUST be assigned at membership registration time to the sender (`msg.sender` in Solidity semantics) of the registration transaction. -The sender of the registration SHOULD have RLN `identity_commitment` generated. -For more information see [32/RLN-V1](https://github.com/vacp2p/rfc-index/blob/main/vac/32/rln-v1.md). +The sender of the registration SHOULD have an RLN `identity_commitment` created. +For more information on `identity_commitment` creation, +see [32/RLN-V1](https://github.com/vacp2p/rfc-index/blob/main/vac/32/rln-v1.md). Membership registration MAY be initiated by a different entity from the one that controls the RLN `identity_secret`, which is associated with the respective RLN `identity_commitment`. Therefore, the holder MAY be assigned to an blockchain address that does not control the `identity_secret`. +The contract SHOULD verify that the `identity_commitment` is valid. When authorizing membership-related requests, the contract MUST distinguish between the holder and non-holders, and MAY also implement additional criteria. From 8c2eb13a3ce1aa1cc8a0e239d90b2e465b162d5a Mon Sep 17 00:00:00 2001 From: Sergei Tikhomirov Date: Wed, 14 May 2025 12:09:06 +0200 Subject: [PATCH 5/9] minor edits --- standards/core/rln-contract.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/standards/core/rln-contract.md b/standards/core/rln-contract.md index f7f150e..697dc81 100644 --- a/standards/core/rln-contract.md +++ b/standards/core/rln-contract.md @@ -52,7 +52,7 @@ see [32/RLN-V1](https://github.com/vacp2p/rfc-index/blob/main/vac/32/rln-v1.md). Membership registration MAY be initiated by a different entity from the one that controls the RLN `identity_secret`, which is associated with the respective RLN `identity_commitment`. -Therefore, the holder MAY be assigned to an blockchain address that does not control the `identity_secret`. +Therefore, the holder role MAY be assigned to a blockchain address that does not control the `identity_secret`. The contract SHOULD verify that the `identity_commitment` is valid. When authorizing membership-related requests, the contract MUST distinguish between the holder and non-holders, @@ -136,7 +136,7 @@ Memberships MUST be included in the membership set according to the following ta | _ErasedAwaitsWithdrawal_ | No | | _Erased_ | No | -The holder assigned blockchian address MUST NOT be transferable to a different blockchain address. +The holder role MUST NOT be transferable to a different blockchain address. A user MAY use one blockchain address to manage multiple memberships. A user MAY use one Waku node[^1] to manage multiple memberships. @@ -163,8 +163,7 @@ because the inclusion (Merkle) proof that the holder provides to RLN Relay only Membership registration is subject to the following requirements: - The holder MUST specify the requested rate limit `r` of a new membership at registration time[^3]. - Registration MUST fail if `r < r_{min}` or `r > r_{max}`. -- The holder MUST make an tranasction to the contract, -locking the deposit to register a membership. +- To register a membership, the holder MUST make a tranasction that locks up a deposit in the contract. - The amount of the deposit MUST depend on the specified rate limit. - In case of a successful registration: - the new membership MUST become _Active_; @@ -239,7 +238,7 @@ If further upgrades are necessary, a new contract SHOULD be deployed, and the membership set SHOULD be migrated. -## Implementation Suggestions +## [Implementation Suggestions](#implementation-suggestions) ### Membership Set Implementation From b29961df5c08c7d99a2374cbc7da5b8fdbe67f21 Mon Sep 17 00:00:00 2001 From: Sergei Tikhomirov Date: Wed, 14 May 2025 14:15:28 +0200 Subject: [PATCH 6/9] fix typo --- standards/core/rln-contract.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/standards/core/rln-contract.md b/standards/core/rln-contract.md index 697dc81..0aeb7c4 100644 --- a/standards/core/rln-contract.md +++ b/standards/core/rln-contract.md @@ -119,7 +119,7 @@ Different line types denote the types of state transitions: | Thin (`--`) | Transaction | MAY be initiable by any user. | | Dotted (`-.-`) | Time progression | MAY be applied lazily. | -Transaction-triggered state transitions MUST be applied immediately based on the blockchain tranaction time. +Transaction-triggered state transitions MUST be applied immediately based on the blockchain transaction time. When handling a membership-specific transaction, the contract MUST: - check whether the state of the involved membership is up-to-date; From 8056725a9625e520b5414f4ccb1403d5c1d316b2 Mon Sep 17 00:00:00 2001 From: Jimmy Debe <91767824+jimstir@users.noreply.github.com> Date: Wed, 21 May 2025 08:18:55 -0400 Subject: [PATCH 7/9] Update rln-contract.md --- standards/core/rln-contract.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/standards/core/rln-contract.md b/standards/core/rln-contract.md index 0aeb7c4..2e0301a 100644 --- a/standards/core/rln-contract.md +++ b/standards/core/rln-contract.md @@ -52,7 +52,7 @@ see [32/RLN-V1](https://github.com/vacp2p/rfc-index/blob/main/vac/32/rln-v1.md). Membership registration MAY be initiated by a different entity from the one that controls the RLN `identity_secret`, which is associated with the respective RLN `identity_commitment`. -Therefore, the holder role MAY be assigned to a blockchain address that does not control the `identity_secret`. +Therefore, the holder role MAY be assigned to a blockchain address that is not derived from the `identity_secret`. The contract SHOULD verify that the `identity_commitment` is valid. When authorizing membership-related requests, the contract MUST distinguish between the holder and non-holders, @@ -119,7 +119,7 @@ Different line types denote the types of state transitions: | Thin (`--`) | Transaction | MAY be initiable by any user. | | Dotted (`-.-`) | Time progression | MAY be applied lazily. | -Transaction-triggered state transitions MUST be applied immediately based on the blockchain transaction time. +Transaction-triggered state transitions MUST be applied immediately. When handling a membership-specific transaction, the contract MUST: - check whether the state of the involved membership is up-to-date; From f5f1a8296ec6770470def90bbbcc7f9a35821a42 Mon Sep 17 00:00:00 2001 From: Sergei Tikhomirov Date: Thu, 22 May 2025 12:40:41 +0200 Subject: [PATCH 8/9] minor edit, add reference --- standards/core/rln-contract.md | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/standards/core/rln-contract.md b/standards/core/rln-contract.md index 2e0301a..1410022 100644 --- a/standards/core/rln-contract.md +++ b/standards/core/rln-contract.md @@ -23,8 +23,7 @@ Users interact with the contract to manage their memberships and obtain the necessary data for proof generation and verification. Message transmission is handled by Waku RLN Relay nodes. -The sender of a message must prove its validity according to RLN requirements. -RLN Relay nodes must not relay invalid messages. +RLN Relay nodes verify the validity of messages according to RLN requirements and do not relay invalid messages. For the full specification of RLN Relay, see [17/WAKU2-RLN-RELAY](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/17/rln-relay.md). Currently, this document focuses solely on membership-related functionality. @@ -383,8 +382,4 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public - [Rate-Limiting Nullifier](https://rate-limiting-nullifier.github.io/rln-docs/) - [11/WAKU2-RELAY](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/11/relay.md) - [17/WAKU2-RLN-RELAY](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/17/rln-relay.md) - - - - - +- [32/RLN-V1](https://github.com/vacp2p/rfc-index/blob/main/vac/32/rln-v1.md) From dbfef374d2f0117def275c556a0d6d517bc303c9 Mon Sep 17 00:00:00 2001 From: Jimmy Debe <91767824+jimstir@users.noreply.github.com> Date: Wed, 28 May 2025 17:05:21 -0400 Subject: [PATCH 9/9] Update rln-contract.md --- standards/core/rln-contract.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/standards/core/rln-contract.md b/standards/core/rln-contract.md index 1410022..5cc65cc 100644 --- a/standards/core/rln-contract.md +++ b/standards/core/rln-contract.md @@ -53,6 +53,8 @@ Membership registration MAY be initiated by a different entity from the one that which is associated with the respective RLN `identity_commitment`. Therefore, the holder role MAY be assigned to a blockchain address that is not derived from the `identity_secret`. The contract SHOULD verify that the `identity_commitment` is valid. +If the `identity_commitment` is not checked or validated, +the contract MAY be exploited using malicious or malformed inputs. When authorizing membership-related requests, the contract MUST distinguish between the holder and non-holders, and MAY also implement additional criteria.