RLN-STEALTH-COMMITMENTS

Timeline

• 2026-01-19 — f24e567 — Chore/updates mdbook (#262)
• 2026-01-16 — f01d5b9 — chore: fix links (#260)
• 2026-01-16 — 89f2ea8 — Chore/mdbook updates (#258)
• 2025-12-22 — 0f1855e — Chore/fix headers (#239)
• 2025-12-22 — b1a5783 — Chore/mdbook updates (#237)
• 2025-12-18 — d03e699 — ci: add mdBook configuration (#233)
• 2024-09-13 — 3ab314d — Fix Files for Linting (#94)
• 2024-08-05 — eb25cd0 — chore: replace email addresses (#86)
• 2024-04-15 — 0b0e00f — feat(rln-stealth-commitments): add initial tech writeup (#23)

Abstract

This specification describes the usage of stealth commitments to add prospective users to a network-governed 32/RLN-V1 membership set.

Motivation

When 32/RLN-V1 is enforced in 10/Waku2, all users are required to register to a membership set. The membership set will store user identities allowing the secure interaction within an application. Forcing a user to do an on-chain transaction to join a membership set is an onboarding friction, and some projects may be opposed to this method. To improve the user experience, stealth commitments can be used by a counterparty to register identities on the user's behalf, while maintaining the user's anonymity.

This document specifies a privacy-preserving mechanism, allowing a counterparty to utilize 32/RLN-V1 to register an identityCommitment on-chain. Counterparties will be able to register members to a RLN membership set without exposing the user's private keys.

Background

The 32/RLN-V1 protocol, consists of a smart contract that stores a idenitityCommitment in a membership set. In order for a user to join the membership set, the user is required to make a transaction on the blockchain. A set of public keys is used to compute a stealth commitment for a user, as described in ERC-5564. This specification is an implementation of the ERC-5564 scheme, tailored to the curve that is used in the 32/RLN-V1 protocol.

This can be used in a couple of ways in applications:

1. Applications can add users to the 32/RLN-V1 membership set in a batch.
2. Users of the application can register other users to the 32/RLN-V1 membership set.

This is useful when the prospective user does not have access to funds on the network that 32/RLN-V1 is deployed on.

Wire Format Specification

The two parties, the requester and the receiver, MUST exchange the following information:

message Request {
  // The spending public key of the requester
  bytes spending_public_key = 1;

  // The viewing public key of the requester
  bytes viewing_public_key = 2;
}

Generate Stealth Commitment

The application or user SHOULD generate a stealth_commitment after a request to do so is received. This commitment MAY be inserted into the corresponding application membership set.

Once the membership set is updated, the receiver SHOULD exchange the following as a response to the request:

message Response {
  
  // The used to check if the stealth_commitment belongs to the requester
  bytes view_tag = 2;

  // The stealth commitment for the requester
  bytes stealth_commitment = 3;

  // The ephemeral public key used to generate the commitment
  bytes ephemeral_public_key = 4;

}

The receiver MUST generate an ephemeral_public_key, view_tag and stealth_commitment. This will be used to check the stealth commitment used to register to the membership set, and the user MUST be able to check ownership with their viewing_public_key.

Implementation Suggestions

An implementation of the Stealth Address scheme is available in the erc-5564-bn254 repository, which also includes a test to generate a stealth commitment for a given user.

Security/Privacy Considerations

This specification inherits the security and privacy considerations of the Stealth Address scheme.

Copyright

Copyright and related rights waived via CC0.

References

• 10/Waku2
• 32/RLN-V1
• ERC-5564