Focus on onboarding: technical feasibility

Focus on Onboarding

This document describes the technical plan and feasibity of the project.


See this document for the rationals behind the project plan: Logos Labs / Focus on Onboarding

To summarize: we realized that no matter what application we aim to build it requires the user to be onboarded to crypto. Products built on crypto usually avoid solving this problem by either subsidizing the users or relying on 3rd party services, often by making compromises on the privacy, decentralization or self-sovereignity of the users.

To us it seems that at the moment we can contribute the most to the Logos ecosystem by solving this problem. There are also other major problems that needs to be solved in order to achieve mainstream adoption, such as having a reliable standardized E2EE chat protocol and a reliable decentralized storage layer, but other teams are already working on those problems so to avoid parallel effort we chose to not focus on those.

Technical description


  • private & anonymous
  • social
  • self-sovereign
  • decentralized


The described solutions relies on several novel privacy focused technologies:

  • Private liquidity pools (PLP): allows users to generate new addresses that are unlinked to their prior transaction history. This can be built either with Semaphore (the whitepaper describes MicroMix as a possible implementation) or by using existing solutions.
  • Semaphore groups for membership (SG): allows an application to check membership and create anonymous signals without revealing the members

Basic flow

The currently imagined flow looks like this:

  • Alice deposits some funds on the liquidity pool
  • Alice tells Bob about Cyphercity (CC), a new app, and Bob is interested in joining
  • Bob opens the app and creates a new Keypair (KP) and from that he also derives an Identity Commitment (IC)
  • Bob shares his IC and pubkey on an existing private channel with Alice (by sending a link or scanning a QR code)
  • Alice creates an ephemeral keypair (EKP) and puts some fund on it from the liquidity pool
  • With the EKP Alice makes transaction to add Bob’s IC to the SG and also blockchain transactions that are necessary (Waku RLN membership, Waku staking etc.)

After this point Bob is a member of the app and can participate and contribute to the community. From that point he may use a CC object to buy more tokens and use the PLP.

Please note that the UX of the flow can be improved and it also leaks PII when sharing the IC and pubkey on an existing channel. We plan to address these issues later, once the basic flow is functional.


Waku and Vac are working together to help standardize protocols, and even have them defined in a transport (ie Waku) agnostic manner. One of the current effort is 70/ETH-SECPM_improvements by ramsesfv · Pull Request #630 · vacp2p/rfc · GitHub cc @kaiserd.

This returns a 404.

Yep. Totally agree. Looking forward to what you come up with.

Here is the new, working link to the semaphore whitepaper (they upgraded the documentation site):

1 Like