Vac Sustainability and Business Workshop

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.

Background

Rationale

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.

Workshop format

Overall the event has been quite intense but a big success.

This event wouldn’t have been possible without the amazing work by @fryorcraken, @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:

  1. 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

  2. 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

  3. 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

  4. 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.

Summary

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.

1) Org sustainability

On sustainability in general

There are two vital things for us to focus on right now:

  1. Waku protocol incentivization, including protocol fees
  2. 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.

On the possibility of becoming a DAO

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.

On grants and other models

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.

Outreach strategy

We should have a Vac outreach strategy. This includes things such as:

  1. Platforms and projects we want to integrate with
  2. Community conferences we want to attend and speak at
  3. University/Research contributor collaborations
  4. Possibly other funders, as well as idea for how to use existing shared resource to ensure Vac contributors can focus on protocol development
  5. How we aim to engage with operators and developers

2) Protocol incentivization

Incentivization

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.

On tokens

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.

Services

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.

Credentials

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.

Reputation

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.

Interaction points

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.

Pools

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.

Fragmentation

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.

Protocol fees

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.

Other incentive mechanisms

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.

Discovery

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.

On RLN and staking

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.

3) Mental models

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.

Actors

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.

Metrics

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:

  1. 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.

  2. Alternative “cash flow” metric through e.g. Gitcoin fundings.

  3. Other incentive metrics likely to become relevant as research matures, e.g. RLN registrations and protocol fees.

  4. 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.

Accessibility

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.

Platforms

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.

Multi-chain

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.

Gordian knot

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:

  1. Zero cost entry should be thought about more (operators without crypto)
  2. Allow platforms to choose to subsidize usage for their users
  3. Subscriptions and credentials can be used for less frequent payments
Niche

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

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).

Operators

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.

Specs

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.

Censorship

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

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.

Roadmap

A very rough high-level roadmap for Waku network incentives looks as follows:

  1. RLN for spam protection

  2. 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.

  1. Protocol fee abstraction

Possibly in parallel with above.

  1. Governance

Q1 goals (draft)

Focused only on business/sustainable oriented goals.

Incentivized Waku protocols

  • 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

Sustainable org

  • 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
3 Likes