The last 2-3 weeks Vac has had a business and sustainability workshop. In this post we’ll summarize the purpose how the workshop, how it went, and some takeaways we have.
From the initial workshop proposal:
There are three important problems that we are currently facing.
Vac team: Vac as an R&D team is subsidized by Status and doesn’t currently have a well-formulated business model. This means it isn’t self-sustaining which is bad for long term survival.
Waku protocol: Waku as a protocol isn’t currently incentivized to sustain itself. That is, if “we” (Status/Vac) stops supporting its infrastructure, it wouldn’t exist on its own.
Social: Awareness of this problem space and possible solutions is embryonic, as well as unevenly distributed throughout the team. This makes it harder to make progress to address these challenges and to prioritize work.
Additionally, as Vac interfaces more with other teams and business units, there’s an increased need to have a coherent long-term vision and for us to be on a path towards sustainability.
Overall the event has been quite intense but a big success.
This event wouldn’t have been possible without the amazing work by @froy, @haelius and @sanaz who had to read up on a lot of new things and prepare several talks. Everyone was very active and engaged, taking ownership of the problem as a whole. We’ve massively improved our collective understanding, and have looked at these problems from many angles. Thank you!
The workshop proceeded in three stages each taking about a week each. 1) Initial preparation and organization, 2) individual reading and preparation and finally 3) talks and discussion.
In the first stage, OP collected and organized sessions and topics. The workshop was split into 3 sessions, each with a major theme, plus a final session. Each topic came with specific questions to answer for each session and topic as well as a recommended reading list. Stakeholders were also invited to share links to relevant material. The topics and subtopics were as follows:
Session 1 - Organizational sustainability and Vac as a business unit
Speaker 1 - On DAOs
Speaker 2 - On public goods and grants
Speaker 3 - Brick and mortar and roundabout business models
Speaker 4 - OSS, idealists and volunteers
Session 2 - Cryptoeconomics and protocol case studies
Speaker 1 - Layer 1: Ethereum/ETH and Zcash/ZEC
Speaker 2 - Dapps: ENS, Uniswap, Aave, Sushi
Speaker 3 - Networks: Swarm, Session, Nym, + Torn
Speaker 4 - Regulatory and legal considerations
Session 3 - Waku as a sustainable protocol
Speaker 1 - Services: Service network
Speaker 2 - Economics: A token for your thoughts
Speaker 3 - Target: Networks and chains to deploy to
Speaker 4 - People: Actor analysis
Final session - Summary, conclusion and next steps
Each person then prepared three talks based on their interest, with the goal of maximizing learnings, for example by picking a topic that is new to the person. Because we are remotely distributed team, the initial 3 sessions were split and duplicated across timezones. For each main session there was a 2-3h meeting in EU/AS timezone, EU/NA, and NA/AS timezone. This meant that each participant presented a topic twice, and had the opportunity to talk to all other team members. For the final session, we all met in single meeting that took place across the globe, from 5am to midnight.
For a given session, we split it up into two parts. The first part had individual talks and brief Q&A. The second part was more freeform discussion, where we noted down takeaways, open questions and specific actions to take.
For the final session we summarized main takeaways, discussed some pressing open problems, and wrote down specific action points, including draft Q1 priorities.
We’ve taken a lot of notes, including slides for presentations etc. Because some notes might be sensitive, and we wanted to maximize open discussion, they’ve not been included in this public post. These are available upon request from specific interested parties.
What follows is an attempt to summarize some of the main takeaway from the workshop. It is incomplete, and because of the fractal nature of the topic each point can be expanded on quite a lot.
Some of the thinking might only make sense after having read the Mental models part, so you might have to go back and forth a bit to get a full picture. For example, the actors defined there are used throughout the first two sections.
There are two vital things for us to focus on right now:
- Waku protocol incentivization, including protocol fees
- Metrics for becoming essential, including (i) platform adoption growth and (ii) alternative “revenue” streams
By the second point we mean work related to increasing these metrics, as well as actually measuring them.
These points are elaborated on in sections below.
It might make sense for Vac to eventually become a DAO, but only at a later stage. This would come after (i) core incentive mechanisms are proven to work and (ii) usage as grown significantly, with multiple platforms relying on Waku.
For now, it is best thought as a direction and future goal. This has implications for how we relate to the wider community, prioritize goodwill, credible neutrality, and being a public good.
If we find ourselves doing something that isn’t on this general path that would be a cause for pause.
It also means we want to have clear “activation steps” that correspond with valued behavior, such as engaging with specific smart contracts, which paves the way for future air and wide distribution mechanisms.
We want to focus on building a sustainable protocol and growing our “market share”. This is something that we can clearly communicate with stakeholders, such as funders.
We should setup a Gitcoin grant for Vac and Waku. The goal is to explore alternative funding paths. While we don’t expect this to make a big dent, it’d act as a form of validation that we are doing is useful and valued by the community.
As for the funds, we aim to either (i) leave them there, with the intention of transfering them to a future DAO (or similar governance mechanism), or (ii) use funds to fund public goods.
The initial setup will be with a multisig, with the aim of decentralizing this over time.
Having a stronger focus on principles here is useful for community engagement (e.g. privacy research, public goods). Furthermore, because the community values it the quadratic funding mechanism rewards.
It is an open question to what extent we should explore getting more funders.
While other business models, such as monetizing expertise for integrating with platforms, could be interesting long-term, it isn’t something we are currently focused on.
Grants for specific platforms, chains or research might be interesting but has to be explored further.
We should have a Vac outreach strategy. This includes things such as:
- Platforms and projects we want to integrate with
- Community conferences we want to attend and speak at
- University/Research contributor collaborations
- Possibly other funders, as well as idea for how to use existing shared resource to ensure Vac contributors can focus on protocol development
- How we aim to engage with operators and developers
We want to carefully design incentivization around the behaviors we want. We take an empirical approach and base it on problems we know exists.
We want to avoid introducing roadblocks for platforms and users to use the protocol, for example by requiring a certain token.
We see the role of protocol fees as vital to ensure the sustainability of the Waku protocol.
We want to deliberately constrain the design space further to ensure we get a working solution up and running, then iterate on this.
For simple solutions that we come up with, we want to make sure they are on the path towards where we ultimately want to go. This means we can black box research tasks and treat these separately.
Another reason to keep things simple and robust is that we want to write non-upgradable contracts as much as possible, and rely on the community to deploy these. This maximizes decentralization and likelihood various attacks.
Any token that might be introduced would have to have strong utility and have a unique reason for existing. We currently don’t see any strong need to introduce a new token, except possibly for governance later on.
The choice of which assets/tokens and chains to support impacts (i) operators, and (ii) users via platforms.
Pushing for e.g. SNT might make sense for something like Status Communities, but operators need to accept it.
This is in line with focusing on platform adoption and maximizing accessibility.
Waku nodes provide services that have a specific cost and this should be incentivized in a service network.
The first step is RLN Relay, which is used for private spam protection. It is based on detecting and punishing the sending of multiple messages in a given epoch over the gossip network.
After RLN, the next focus is store protocol, then filter/lightpush protocols. These are all request-reply protocols.
We want to measure more exactly how expensive providing specific services are in order to better price these services.
We also see an opportunity to have non-monetary incentives to provide better privacy with protocols like filter and lightpush. There are likely to exist privacy incentives for the relay protocol as well. This can be both self-interested as well as altruistic (improve privacy for other people).
There are also likely opportunities for discovery protocols to be incentivized with “listing fees” and reputation but this has to be explored further.
We also see guaranteed delivery and proof of service provision as being useful. For example, can a lightpush node prove they have forwarded a message? This may be possible in conjunction with the filter protocol.
We believe credentials and subscription based abstractions play an important role in incentivization. This allows us to decouple payment from service provision, for example for anonymous history requests.
A credential can be acquired and given to a service provider for some service provided. The service provider can then claim funds associated to that credential. In this setup, there’s no economic link between the two parties.
Additionally, double spend attacks of credentials are unlikely to have a severe impact for most Waku protocols and can also be mitigated in several ways.
For example, for store protocol there is no clear economic gain, and amplification attack would be spread out across nodes. It can also be combined with gossiping used credentials which would allow for slashing here.
It is worth exploring if this is the same for all service protocols, and understanding what the worst case scenario is.
Identifying “provably wrong” behavior in many Waku protocols is either difficult to detect or fragile. Instead of using a staking/slashing mechanism for non-provable wrong-doing, we prefer to tie this behavior to a reputation mechanism.
A mental model here is the “decentralized Google review” model. There are ZK based tools that are likely to give us private and non-reputable reputation.
Reputation can be seen as a form of consensus, but it may be open to some attacks. We can use these mechanisms in conjunction with “provably-wrong” mechanisms.
Consensus-based testing of service quality may lead to punishing lazy providers. The difference is customer loss (due to bad reputation) vs financial loss (due to slashing).
There are many enhanced guarantees that can be attacked as separate research problems. For example, a more granular reputation mechanism, identifying adversarial behavior among service nodes, and so on.
There are a few interaction points between protocols that we have to consider.
For RLN Relay, we need to understand how this interacts with other protocols, like lightpush. There are challenges and opportunties here. For example, there’s a potential for zero-entry mesaging here where a platform acquires many accounts and enable users to use lightpush for messaging.
There are likely to be other interaction points.
In general, there should always be a fallback to an altruistic / non incentivized network.
RLN, Reputation and Credentials/Settlement all have a form of “pool” abstraction in a smart contract. This is closely related to the ZK based operations and how the proof and verification works to ensure private computation. We want to explore this “pool” abstraction a bit more.
We want to ensure the design is simple, robust and with minimal dependencies so that it works in case of (i) availability failure (ii) lack of upgradability.
Pools can generally help with increased anonymity.
There may be an opportunity to share the pool for RLN, Reputation and Credentials/Settlement which would allow for a simpler UX.
We want to ensure operations on a pool is limited, to minimize control and upgradability.
More thought can be put into exactly how the distribution should work.
We have to be careful about fragmentation across multiple networks and platforms and try to minimize it.
The upside of using Waku for messaging is that it doesn’t require consensus for everything. The downside is that it might lead to fragmentation.
We have to think carefully about how to deal with e.g. RLN stakes being fragmented across multiple networks.
We want to encourage schelling points, for example shared pubsub topic for increased anonymity set.
We want to allow operators to be modular, for exampel by supporting multiple networks and using a matching engine.
Financial incentives for operators decrease risk of platforms/users only caring about their own platform usage.
Direct protocol revenue acts as a sink which is very useful for sustainability.
The simplest mechanism is to capture this directly as a form of commission / non-refundable fee. See for example ENS, Uniswap protocol fee, Zcash dev fund, etc. This can start off in a simple multisig and later be transferred into a DAO mechanism.
The fee should be used to incentivize security of the network as opposed to some form of direct profit motive, similar to ENS.
It is better to introduce this early than doing it later.
An open question is how having this mechanism impacts relationship and incentive alignment with platforms.
Postage stamps for storing valuable messaging might be worth exploring. There could be a hybrid model in terms of who is paying - sender, receiver or both. We want to make sure we aren’t re-inventing the wheel here with distributed storage.
A user has to be able to find reputable nodes in the network that provide some service. Incentivization is possible here with some form of listing fee and ranking.
Reputation can be used here, along with other common node attributes. We can decouple this listing from supported platforms/networks, so an operator can choose to support multiple platforms and networks.
This probably makes sense after we’ve done basic the basic service incentivization, but before governance. It might be possible to do parts of it in parallel.
RLN is a form of staking mechanism.
We may want to reframe RLN as buying membership to voice yourself in a private and censorship resistant way. This would be similar to how ENS is selling ENS names.
Operators are incentivized to slash spammers to protect the network.
There might be a better name for “RLN messages”.
Open question: What other adversarial behavior exists outside of RLN? For example, online availability. How can this mechanism be made robust?
Staking adds value to a possible token (due to supply/demand), but only if value staked is large. The cost in terms of accessibility can also be quite high.
Throughout discussions, we’ve been able to adopt many shared mental models. These help us orient ourselves correctly when faced with various problems. The following section aims to make some of these more explicit.
We want to be deliberate about creating positive feedback loops for the various actors we have defined, and thinking of each actor’s user story separately. This also means we can think more rigorously about aligning long term incentives among all actors.
The actors that we have are captured in the acronym UPDOC-FC - users, platforms, developers, operators, contributors, funders, and community.
End users use Waku through some platform. Platforms use Waku. Developers builds for platforms. Operators operate the network. Contributors develop the protocol and implementations. Funders fund the contributors and general effort. Community includes all non-tangible interactions, such as conferences, academia, word-of-mouth, good-will, etc.
These roles may be overlapping. For example ideally users are also operators.
For users, we should be mindful of platforms and their different users. We give them tools and options for how to maximize benefits for their users. For example, options around pay-for-use vs platform subsidizing usage.
For platforms, e.g. Status or WalletConnect, we should make sure we understand what each platform values and do our best to provide this. This means being mindful of not confusing platform needs with operator needs, as well as any economic incentive that may exist. Platforms and operators may have diferent incentives that aren’t always aligned.
For developers, accessibility is critical. This means things like ensuring js-waku works well with different code bases. While less prioritized, the same is true for nim-waku in terms of interfaces.
For operators, we want to create a space (e.g. Discord channel) for discussion with an alpha node program. This means we can better understand their needs, for example in terms of economic models.
For contributors, we should make sure there are “good first issues” defined, including “open problems” for research/academia. We should also make sure there is a strong cultural DNA that can be transmitted to new hires.
For funders, especially majority funders, we should make sure they are on board with the general direction and progress towards sustainability. We should be transparent about updates and keep ourselves accountable for milestones we set. We should also clearly communicate any shared resource needs to ensure focus.
For communities, this includes things such as sharing open problems that we are working on with e.g. academia. This enables researchers to actively engage with our work, and opens up the door for collaboration with institution. This is similar to what e.g. Tor, Gnutella, Zcash, and libp2p have done.
We should setup objective metrics to ensure we are on the right path in terms of project growth, ie… become an essential piece of infrastructure and becoming sustainable. Specifically things means things such as:
Platform and developer metrics for adoption.
Here we primarily want to measure the impact of platform integration. The reason to focus on the impact of platform integration is that a single integration can lead to many users using Waku in one go.
Alternative “cash flow” metric through e.g. Gitcoin fundings.
Other incentive metrics likely to become relevant as research matures, e.g. RLN registrations and protocol fees.
Operator metrics are also useful to explore to ensure network is growing and becoming more robust.
One idea for how to measure platform adoption weighed by impact is to use a quadratic utility function based on e.g. number of GH stars or active users.
By pushing for platform adoption, this can also later be turned into possible traditional revenue streams. For example, with grants and monetizing expertise.
Any activation step we introduce for platforms or their users will harm adoption and ease of us.
We can roughly look at it as follows in terms of accessibility: centralized solution → decentralized (js-waku library) → use crypto commodity (ETH) → use specialized token.
There’s an opportunity for platforms to possibly act as proxy for users, for platforms that want this. As a similar example, relayers can be used for fee markets, where a relayer gets some % commission (e.g. see Tornado Cash).
In general, we want to minimize roadblocks everywhere.
We value being adapted by many platforms. This includes embracing what they need.
We want to focus on onboarding platforms, not just users. For example, allowing a specific token to be used that fits their platform, or deploying to a network that platform values.
We want to embrace multi-chain support to make it easier for platforms to adopt Waku.
This is a pragmatic approach, focusing in platform needs, ordered by impact, as this will maximize long-term sustainability.
We want to keep it simple and minimal at first, e.g. focusing on EVM targets with good tooling support.
Outside of specific platform needs, we have a slight bias towards (i) things that work now and have wide usage, as well as (ii) principled approaches, e.g. ZK-EVM based
Additionally, as adoption increases, this leads to possible grants opportunities.
We want to untie the gordian knot of Waku. One the one hand Waku is useful for messaging precisely when you don’t need consensus or a cryptocurrency, but on the other hand crypto incentives are useful for the Waku network.
We want to focus on accessibility, and there are several tools at our disposal. For example:
- Zero cost entry should be thought about more (operators without crypto)
- Allow platforms to choose to subsidize usage for their users
- Subscriptions and credentials can be used for less frequent payments
We should cleary define the niche for various implementations targeting specific actors. This includes understanding the target audience.
For example, optimizing nim-waku for operators (Linux distribution, Docker images, usabiltiy guides, etc).
Regulation is complex and changing, but it appears to be tractable.
We want to focus on (i) decentralization (ii) functionality.
We have a preference for simple contracts that can’t be upgraded to minimize control.
There are some specifics to investigate, such as how protocol fee sinks can work without a set governance mechanism (pre-DAO, a form of chicken-and-egg problem).
We want to target operators separately deliberately, as a different market.
This is more about nim-waku distribution vs js-waku.
Status as a platform (Waku v2 for Status chat) is different from Status being used as operators (nim-waku FTSTORE nodes).
We want to explore using Nimbus as a distribution mechanism for operators.
We want to think about operators and their opportunity cost, what other things can they do?
There are two main incentives (i) as platform and users who want platform to be usable (ii) financial incentives, gaining money. There may also be a smaller subset (iii) altruistic operators who want to improve privacy for others, etc.
We should go over the protocol RFCs and ensure MUST, SHOULD, MAY guarantees are clear w.r.t. economic implications.
Specifically, STORE, RLN, filter, lightpush, and possibly Discovery.
Waku should be designed to be censorship-resistant under reasonably extreme scenarios.
For example, we want to fail-open, and not require access to a specific blockchain (in some scenarios, likely to happen with something like Infura) in order for the Waku network to operate. There should be graceful degradation here to be less vulnerable to censorship attacks.
A useful mental model here is that fuel in the network should work more like a battery or gas, as opposed to being vulnerable to “power outages”.
Principles add value, and we should lean into them more.
We want to adapt the Status principles more formally and act as a stronger guardian of them.
This is also useful for community engagement. For example, in terms of public communication (write-ups) and grants.
A very rough high-level roadmap for Waku network incentives looks as follows:
RLN for spam protection
Minimal subset of reputation, credentials and discovery that would allow for basic service incentivization
Then, these can be extended in separate research tracks. For example: Better reputation, more granular credentials, better listing method, more granular pricing control, better game theory for payment, generalize for lightpush/filter, QoS and detectable faults.
- Protocol fee abstraction
Possibly in parallel with above.
Focused only on business/sustainable oriented goals.
- RLN testnet live, including transaction management (see Nimbus)
- Multi-purpose discovery: capability, reputation, eth address
- Make nim-waku attractive for operators (robustness, usability: settle into niche). Growth metrics. Client comparison.
- Prepare incentivized services base layer (reputation/credentials) with harmonized ZK interface, research tasks and implementation plan
- Setup multisig and grant
- Publishing RLN article
- Onboarding and education: Share vision with 3-6 people; written education (demo paper, Vac principles); ongoing live reading group
- Outreach stategy and re-orient ourselves to actors; platform metrics