logos-messaging/specs
1
0
Fork 0
mirror of https://github.com/logos-messaging/specs.git synced 2026-01-08 00:53:10 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update rln-contract.md

Browse Source
This commit is contained in:
Jimmy Debe 2025-05-06 05:43:11 -04:00 committed by GitHub
parent 1c02083263
commit 63c2fb7106
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 4 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
standards/core/rln-contract.md
View File

@ -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. Each membership MUST have exactly one holder.
The holder role MUST be assigned at membership registration time to the sender The holder role MUST be assigned at membership registration time to the sender
(`msg.sender` in Solidity semantics) of the registration transaction. (`msg.sender` in Solidity semantics) of the registration transaction.
The sender of the registration SHOULD have RLN `identity_commitment` generated. The sender of the registration SHOULD have an RLN `identity_commitment` created.
For more information see [32/RLN-V1](https://github.com/vacp2p/rfc-index/blob/main/vac/32/rln-v1.md). 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`, 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`. 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 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, When authorizing membership-related requests,
the contract MUST distinguish between the holder and non-holders, the contract MUST distinguish between the holder and non-holders,
and MAY also implement additional criteria. and MAY also implement additional criteria.