Logos Labs / Focus on Onboarding

Logos Innovation Labs Winter/Spring 23/24

Over the past few months, I have explored various directions, attempting to crystallize ideas, methods, identify problems, and contemplate the best way to make our team’s output as valuable as possible for the continuation of our Cypherpunk ideals and optimize the chances of success for the Logos Network State.

Imagining and visualizing where we want to end up as a network state is the easy part. Finding a pathway towards it is what I find incredibly challenging. Numerous problems need solving, and we are dependent on infrastructure that is not yet in place, using tools and systems from a worldview that is not ours.

Personally, the challenge is to create stability in these three pillars: identifying the problem, envisioning a conceptual framework for solutions, and applying the right methodology to increase the chances of actually solving the problem.

Without focus, all these three pillars can become unstable. For instance, not having a clear priority in which problems to tackle first impacts the team’s efficiency. Changing conceptual frameworks or methodology mid-journey takes our brains a lot of time and energy to adapt, energy that is not spent solving the actual problems.

“People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully. I’m actually as proud of the things we haven’t done as the things I have done. Innovation is saying no to 1,000 things.” — Steve Jobs

My proposal for our team’s focus is to go all-in on one problem, with one concept, one method.

The Problem

In 2023, the main problem to get people onboard to P2P technology remains the same as it ever was: the decentralized computation resources are distributed, leading to the leech vs. seeder problem. There is no gatekeeper, no judge, nobody to ensure the network or resources are not being spammed or plundered by users who have no stake in guarding the distribution of resources.

To use tools like EVMs, or messaging networks with spam protection, or a decentralized storage network, you need to have a token, an NFT, or some other kind of proof that you actually have the right to use the tool.

Waku, for instance, will soon introduce their DDOS protection in the form of zk membership, which needs a transaction on-chain. We know this concept from Kurate: to be part of a group of users, you have to be added to a semaphore group in order to prevent freeriders.

Codex will eventually also need a token, for users to pay for storage, similar to the postage stamps concept in Swarm.

In order to get these tokens, or NFT or any proof, a user first has to reach out to the community, expressing their wish to join the network and start using it. But how can the user reach out and express this when they have no right or token to do so?

This onboarding problem has existed for a long time, and many solutions have been proposed. Most of them are, of course, centralized services and companies. Even in the current Status app, there are links to centralized companies selling tokens for fiat, making your onboarding to crypto a KYC process, intruding on the privacy most users are seeking to avoid in joining these networks.

I think this is the big problem we need to solve without compromising on the Cypherpunk principles the Logos Network State wants to progress. This means users can onboard privately and in a secure way.

In the Status white paper, written almost 7 years ago, this exact problem was described. Their solution is called “Teller”, a decentralized service that would enable a marketplace for exchanging fiat to crypto. This was based on the premise that with Whisper, you don’t need a token to signal/message the network because Whisper existed as a side service on the Ethereum nodes, just like SMS was in the early days of mobile phone networks.

In the new version of Status, focused on communities, paying for a Waku and storer node is handed off to the community owner, who will be able to run their own hardware or purchase resources with third party providers. For group and DM chat, Status will subsidize the resources and spam protection. This is a conscious strategy to “kick the can down the road”.

In Swarm City, the idea was to onboard people through human interaction, having grassroots activists curate Swarm City in their real-life city and onboard people by having them come to meetups.

In both cases, the legal system and regulations make it illegal, or at least have a chilling effect on people’s motivation to help others get into crypto, or join a network state.

The challenge is finding a way for users to privately signal they want to join the network and are looking for someone to help them out; a sybil resistant anonymous network of trusted users.

Concept: The Social Contract

When I feel uncertain about which direction to take in the Logos Innovation Lab, I go back to our elders’ writings. The Cypherpunk’s Manifesto is written on a wall in my home, so I never have to go far to be inspired. Recently, I re-read the last 4 paragraphs as if they were milestones for Logos Network State, and to my delight, we already achieved a lot of what is being proposed there.

With the advent of ZK-proofs and ZKEVMs, we reached a moment where we can start to think of the “anonymous transactions systems” Eric writes about.

But it was the next paragraph that stood out to me as it hints towards a solution for the onboarding problem:

“For privacy to be widespread, it must be part of a social contract. People must come together and deploy these systems for the common good. Privacy only extends so far as the cooperation of one’s fellows in society.” — Eric Hughes Cypherpunk’s Manifesto

To showcase Waku Objects, we made our version of a simple chat app called “Waku Play”. Onboarding to it is simple: just send an invite link, and the other party can join the conversation.

With the introduction of DDOS protection on Waku, this invite flow needs redesign, for onboarding people to a chat app where they can signal their wish to join a network is no longer possible without zk membership. For this, gas is needed.

Inspired by the Cypherpunk Manifesto, I would like to propose seeking a solution in creating the “social contract” Eric talks about. This could be realized as a trust-network of users.

Simply put; we grow a grassroots network from people we already know and trust, by inviting them to our network, showing them our tools, and handing them the tokens necessary to participate in the network.

This onboarding flow would consist of creating zk proofs (attestations), gifting or exchanging the tokens a new user needs to get started, adding them to semaphore groups so they can anonymously signal their needs and vouch or attest the data points needed for them to (co)operate in permissioned groups and communities.

The belief that underlies this approach is that each user’s existence in the network is an added value to the overall value of the network, meaning “I am willing to invest in this new user because I think in the long run more users mean more value for me too”.

With Waku Objects, we are introducing a framework to distribute mini-apps over chat. With these objects, people are able to privately do transactions, exchange goods and services. Imagining a Teller-like mini-app to exchange fiat to crypto is easy when considering things like zk-rollups and private group chats, with onboarded users who have all the tools and resources they need to operate in the network. Then it is merely a matter of having a liquidity pool where users can create and send spending proofs to each other, preserving their privacy.


I would like to use the remainder of this development cycle (ending March 2024) to focus on this onboarding flow and validation of new users through attestations, thus creating the possibility of having new users signal their needs through an anonymous group chat.

The Cypherpunks are actively engaged in making the networks safer for privacy. Let us proceed together apace.

I’m open to feedback as always and hope you agree with me that focus is saying no to all these other brilliant and attractive ideas we have.

Lucille Bellepleure


Great points, the introduction of DoS protection and forced on-chain interaction to send messages on the Waku network, and later incentized store services, creates a friction point of the user.

Friction is expected: the point is to protect the network from a DoS attack. If there is no friction then an attacker could just create many identities to flood the network, the same way that someone proceeeding with a DDoS attack secures many IPs to do the attack.

Because of the properties of censorship we want, the identity of a Waku user needs to be on a decentralized, censorship resistant system itself: an EVM blockchain.

The fact that we use zeroknowledge semaphores is because we also want privacy, but that in itself does not create much friction.

It is then a question of alleviating the friction as much as possible for developers and their users.

I created RLN Design Patterns - Practical Development and UX Best Practices · Issue #102 · waku-org/pm · GitHub to summarize the various design patterns I can think of. I actually did not think of the one you mentioned here so I added it as (E). We are pushing Waku in the hands of developers at upcoming hackathons, hackers house, etc. It will be very interesting to see how they think about this problem and want to deal with it and hopefull new patterns will emerge.
Our role in the Waku team will be to support and document these patterns as best as we can.

There are straightforward scenarios. If you use Waku in a Wallet, you already need crypto to use the wallet, so spending some gas for RLN isn’t really a show stopper.

It is much different when you are using an app primarily to communicate. In the recent years, I have seen pattern such as Warpcast and Lenster emerging, where the project developers subsidize the onchain (polygon) fees for the user to register (farcater) or even use the (lens) protocol.

These are good practices to get inspired from. We also need to note that Waku R&D is still in progress. We have plans to incentivize node operators to run nodes. Because we do not want to end up in a federated-like network where only project run Waku nodes for their own users.
We also have more work to do on RLN:

As the underlying protocol changes, the best practices may change with it.

We are very aware that Dev Ex and final UX and important criteria to build a successful protocol. Which is why we are ramping up dev rel activities and getting Waku in the hands of developers. This will continue to be a priority for 2024.

1 Like

I had this post openned for ages and finally got to reading it:) Great write up! Completely agree that adoption in p2p networks (especially where multiple different kinds are combined like Waku + on-chain membership) is not a simple topic not only for newcomers, but also power users.

I really like the idea of attestations - sounds kinda like key signing parties which used to be popular at free software / open source events:)

PLease do share the progress, would love to follow along!