Abstract

In the last few months at Boundaryless we’ve been helping teams considering and implementing complex products and go to market strategies that in some cases have regarded the adoption of a web3 strategy. The exploration of the potential of a web3 strategy – including for example the release of a protocol complementing a product, the design of a crypto-token to be used for governance or other utilities and other elements – was always framed as functional to either the product model or to the  go to market strategy as a driver of adoption, legitimacy and network effects. At Boundaryless we believe that companies currently facing the market should always consider these new enabling technologies – such as the blockchain – and patterns – such as developing protocol-product systems, the creation of tokens – because they constitute a significant addition to the design and commercialization of a new product.

In this piece we share a bit of a systematic overview of the driver of adopting such approaches, but also a framework for helping teams understand challenges and needs, so that a team building a product strategy involving web3 drivers can fully consider the implications. Teams that are currently considering web3 as a strategy, and are looking for professional help should reach out to us (check the form at the bottom of the piece), and designers interested in the topic should subscribe to our newsletter and social media channels (such as Twitter or Linkedin) as we’ll release soon a set of tools that can complement the existing Boundaryless’ frameworks in platform thinking – and organizational design and development.

Subscribe to our newsletter if you don’t want to miss a thing!

 

In sharing this piece I also want to thank the team at SOUNDIT – which I’ve been working closely with in the last four months or so – and that applied lot’s of the ideas that are described in the piece.

---

Why Building with Web 3

There are a lot of questions on the real benefits of embracing the principles of web3 as an entrepreneur or designer embarking into developing a new venture, especially if we consider the inherent complexities of adopting a pioneering technology of which the design patterns are not still defined and clear: why adopt blockchain and crypto technology? What are the benefits of using tokens and tokenomics to extend your capabilities to design to include programmable governance and tradable rights?

It’s been more than four years since Chris Dixon wrote his seminal “Why Decentralization Mattes” where he pointed out some of the key drivers of embracing such a paradigm shift. Crucially, Dixon explained, decentralization matters as it provides means of eliminating the conflict between incentives that exists between the platform owners and their user base and also between the platform owners and the ecosystem of their product’s complements (for example third parties applications). His now famous graph is more than effective at explaining the problem: platforms kickstart networks and – within time – move from a supporting and enabling posture towards an extractive one, often ending up squeezing as much value as possible from their ecosystems.

Web3 can fix that according to Dixon, by eliminating entirely – or, maybe, better: progressively and sufficiently – the need for a centralized entity that “runs” the network “for” the participants, in favor of a cooperative system where participant themselves can govern and evolve the network in the interest of all stakeholders, and not only the owners.

But what are – in a few words – some of the key enablers that such as web3 stack provides? And why does it make sense to peek into them and see if they may help you design better products or organizations?

 

Four key advantages of building with web3

Four advantages of web3 stand out clearly, that can contribute to creating more valuable, and resilient organizations and business models:

• Enabling users control their data: First, adopting a blockchain stack allows for much deeper data transparency and can help you ensure that users are in control of their data and do not experience a barrier in accessing it. As data is stored on the blockchain (either public or private) participants will always be able to access the data they – and others – produce by interacting with the system.
• Improve trustability towards applications: Second, web3 allows interfaces to be radically open and trustable: app developers can access the underlying data and protocol infrastructure using public smart contracts; the two layers (protocols and apps) are disentangled, and apps can trust protocols more than they could do with centralized platforms. The relationships between third parties and platform owners is indeed notoriously problematic as the former can suddenly change the rules with no accountability. Such a stability that embracing a web3 stack provides, and the resulting increased trust in the interfaces, could make the case for more players to build applications, integrations and extensions, increasing the overall ecosystem value.
• Leveraging Tokenomics: Web3 enablers make it possible to develop complex tokenomics schemas, and token-based economies, plus complex but auditable smart contracts that allow the distribution of the value produced inside the ecosystem to third parties more easily.
• Distribute Governance: Finally, the same tokens can be combined with ancillary tools and processes that can help distribute governance power to users and value creators, allowing the network to be part of the ownership and the governance of itself.

 

Sufficient Decentralization

Cautiously pondering the option to leverage web3 mechanisms, in building a new venture, makes even more sense as – besides the technical hurdles – one has to face the inherent challenges of building something that is “sufficiently decentralized” from a management perspective as Variant’s Marc Boiron recently coined the definition.

In the Boiron’s words, “sufficient” is related to passing the Howey test: a test that is adopted by the US’ SEC (Securities and Exchange Commission) to deem that an asset is either or not an “investment contract”, and thus its sale subject to being SEC regulated, something that would strongly limit the options for capital collection and market placement of such an asset.

According to the Howey test, something classify as an “investment contract” if:

1. it’s an investment of money

2. In a common enterprise

3. with the expectation of profit

4. to be derived from the efforts of others3

Point 4 has historically been the most significant aspect of the Howey test that web3 builders have tried to address to be sure that the distribution of project tokens would not have to be SEC regulated. As Boiron explains:

“Web3 builders […] focus on distributing the efforts of driving profits in a crypto-asset from a centralized company to unaffiliated community members working towards a common goal.”

Furthermore, achieving sufficient decentralization may be not only a means of overcoming regulatory concerns but also a way to generate trust and legitimacy towards the ecosystem of third parties building on top of a shared common layer. If centralized decision-making could be acceptable in the first place, and pockets of autonomy are welcome in managing a web3 venture, ecosystem players expect a common, enabling layer such as a protocol, to be democratically governed.  Although different forms of governance are possible, it’s key that they take into account all stakeholders’ perspectives when an impacting decision – such as a change in fees, standards, or functionality – takes place.

To answer this need, the concept and practice of building DAOs (Decentralized Autonomous Organization) has been widely adopted in the space, either as something to transition the governance to, after an initial phase (as in Walden’s “progressive decentralization” or in Schneider’s “Exit to Community”), or as a way to institutionalize an emergent organization, as – for example – in the experience of Yearn’s Governance 2.0.

The role of protocols, the role of products (applications)

As I’ve been able to explain already in Bootstrapping user-owned Networks with Web3, there’s a typical two-layer architecture when it comes to web 3 initiative: the protocol, on the “bottom”, and the applications (products, platforms…) on “top”.

Protocols are normally responsible for establishing a certain domain model, defining the transactions that are enacted “on-chain” and that go into the transparent transaction history. Applications instead are responsible for the creation of the user experience and usually rely on the protocol to execute the “on-chain” part of the transaction flow. By providing a shared domain model, and a shared “database” protocols essentially are common goods, and have a 1:N relationship with applications: many applications, one shared protocol.

Being based on an open protocol provides legitimacy in an ecosystem: an open protocol is essential to make the four drivers of building on web3 (transparent data access, controllable and open interfaces, distributed value and distributed governance) tangible, but not all protocols are the same.

More specifically, protocol have four essential properties to differentiate them: being permissioned (based on whitelisting) vs permissionless, being token-less vs token-based, being fee-less vs taking a fee / having a sustainability model, being DAO operated vs being operated by a centralized entity:

• Permissioned (based on whitelisting) vs permissionless protocols: Some protocols are open for everyone to build upon and don’t require applications (or, more generally, smart contracts) to be whitelisted. In other cases, your application has to receive a green light to be able to use the protocol.
• Token-less protocols vs Token-based protocols: While some protocols don’t have any specific token (they’re essentially just a bunch of smart contracts) some others are connected with a variety of tokens. Protocol tokens can be of very different types. Protocols that operate their own blockchain are normally based on proof-of-stake architectures that imply validator nodes and currency staking. The staking, that is essential to secure the network, can be done either with existing currencies (normally either layer 1 currencies that have a relatively stable value, or stable coins) or via currencies that are specific to the protocol, and that are valorized through mechanisms such as market makers (e.g. Liquidity pools). Protocols that are instead based on shared security just pay “gas fees” to the layer 1 they choose to build upon. Tokens can also be related to protocols in other ways. The most common and intuitive way is that protocols can feature governance tokens that they distribute to those that create value for the protocol (e.g.: users or applications that use the protocols) to incentivize adoption. These governance tokens are normally connected to governance rights inside a more or less complex institutional architecture normally called DAO (more later).
• Fee-less vs taking a fee / having a sustainability model: While some protocols don’t take any fee (and thus are normally operated by an entity that “pays the bill” – gas fees) most of the protocols develop their own sustainability model, normally based on a take rate on the transaction value. These fees are key as protocols strive to be governed by a trustable and legitimate entity – a DAO – that is supposed to be fair towards all the stakeholders. A self-sustainable protocol can sustain an institution such as a DAO that can operate it impartially, while a protocol that depends on a third party may fall short of independence. Crucially, all these properties can evolve during the lifetime of a protocol: a protocol can start as permissioned, token-less and fee-less, and evolve towards being self-sustainable, and releasing tokens later on in its development, as the founding team embarks into progressive decentralization. In other cases, protocol can stay permissioned, token-less and fee-less: context matters.

Building the applications vs building the protocol: where do you start? It’s been forever that concerns have abounded regarding the risk of building “pointless” web3 initiatives that only stem from the frenzy of creating tokens or using blockchains. Amir Bolous recently wrote an interesting piece (“What I’m frustrated by in crypto”) that contextualizes the issue and provides a good basis to reflect on the overall value-added capabilities of web3 in several contexts. Web3 legend Jesse Walden recently added a piece on thinking about tokens as “products” asking designers to put themselves “in the user’s shoes” and wondering about “what problem does your ownership experience solve?”

At Boundaryless we have been doing product/platform design for a decade now, and thus when helping our customers and adopters we always start with ecosystem identification, investigating problems (and potentials), and analyzing the value chain. I wrote tons of pieces explaining our practice: we explained how we map arenas and ecosystems, how we analyze the value chain by using Wardley Maps and our library of Platform Plays as a way that helps us come up with a platform strategy model. We actually have an entire exploration methodology – well proven through years of adoption – that you can familiarize with by downloading it here (it’s Creative Commons).

---

Join us at the upcoming Platform Design Bootcamp to fully understand how you can: map your ecosystem, understand and transform the value chain, design a product strategy that resonates with it. Join hundreds of teams worldwide that have been going through the same program and delivered succesful strategies as a result.

---

According to such a mindset, we always advise teams to start from the product (or, actually, start from the ecosystem): this means firstly understanding what is the ecosystem the product will serve, what are the key interactions happening in the ecosystem, how’s the value chain, and how that can be transformed. More generally we look into how a product can fit into it as a mix of a product/service bundle (such as a SaaS), one or more marketplaces and potentially an extension strategy that extends the core service bundle (check here to understand the framing)

Once this is done, and, ideally, after a series of validation steps aimed at validating the assumptions embedded in the ecosystem model, the value chain, and the set of suggested value propositions to be built – it is normally possible to extrapolate what we call a “domain model”: the basic object model, the key events, the relationship between them; all of this constitutes the project “ontology”.

Once the ontological layer, the layer of the basic domain model is defined, the team building the product has two options: adopting an existing protocol (if any exists that maps decently with the model) or building a new and dedicated one. Let’s also remind why we want to have (or build) a protocol layer. As outlined in the earlier part of this blog post: a protocol-based initiative, where apps are separated from the protocol (normally covering data, and executing the key transactions on the blockchain) is a means to develop legitimacy and credibility among the end users and the application developers, and gives you a huge potential to be leveraged by adding financial incentives to your design tools, through tokenomics.

In prior analysis we made on this blog, we indicated how a certain “ontological convergence” – the emergence of shared protocols to sustain different application ecosystems – is set to emerge if one looks into the current market dynamics. While web3 paradigms are still nascent, there also is a general perception that web3 is instrumental to building an internet that is more capable to produce fairer and more valuable alternatives to web2. Web3 lends itself to a better balance between competition and cooperation, due to much broader composability and modularity between pieces and layers, ideally resulting in a less frequent need to reinvent the wheel which – everybody would agree – could become a net loss to a healthy ecosystem.

As a result of such dynamics, we may assume that the lower in the value chain, the broader the convergence we can expect. Indeed, lower value chain layers are normally characterized by less added value in specialization, and a slower pace of evolution. The higher you go in the value chain, the more protocol alternatives will probably make sense to build (higher value-add will make the case for niche protocols to emerge).

Below, it’s an example of how protocol stratification could emerge in a content economy: the higher you go in the value chain, the more alternatives.

The options one normally has – as a new service/application developer – when considering an existing blockchain-based protocol or building and bootstrapping a new one – normally in parallel to the launch of the first application – are, in essence, three:

• the adoption of an existing protocol, complementing it with app-level logic when certain aspects of the user experience one wants to build are not covered;
• forking an existing protocol to make it fitter for our specific use cases;
• creating a new protocol from scratch.

Generally, all these options may make sense given the contexts: building or forking a new protocol though has relevant implications on a team’s list of priorities, freedom of choice, and capital needs.

There are conflicting drivers for application developers to accept or encourage an ontological convergence driven by shared protocol adoption. Converging on an existing protocol definitely introduces a set of constraints for an application developer (for example in terms of accepting a certain transaction model), while on the other hand may bring some interesting upsides, mainly related to inheriting protocol generated network effects.

First and foremost upside is probably not having to build the protocol. Building and bootstrapping a protocol is a (damn) hard job and it can drain a substantial amount of effort from a team. Such an option should therefore be considered only by well-funded teams that face a market context where existing protocols are either lacking or very badly managed. Trying to assess if an existing protocol can serve the purpose or trying to influence the development of an existing protocol is an option that may be a radically easier path for teams. I expect the complexity of building a protocol to be a major driver of ontological convergence moving forward in web3. 

Another driver of value of adopting an existing protocol is piggybacking on cross-application, protocol-driven, network effects. For apps based on marketplace-type interactions, or generally featuring supplier-consumer dynamics – for example – a newcomer app could easily (by plugging into the shared protocol) get access to a liquid market because the network effects play out at the protocol level. On the other hand, such a characteristic would make apps less defensible: a user could theoretically easily drop an app in favor of another unless other defensibility mechanisms are pursued at the application level. Such defensibilities may regard particular technological advantages or other lock-in strategies, for example a superior UX or the fact that the app operates well inside a major incumbent platform stack, for example as a plug-in or certified mobile app.

Adopting an existing protocol can also bring token-related network effects: if the protocol is token-based, its user base (that would be inherited by the application) could be very loyal due to the skin-in-the-game that accumulated.

Data network effects could also be interesting: adopting an existing open protocol may indeed mean gaining access to a vast amount of transparently available data (sometimes mediated by data unions), giving the application developer a head start in leveraging analytics.

Furthermore, adopting an existing protocol, especially if the protocol is community trusted, is a powerful ideological signal to the community, portraying the intention of the application developer to somewhat adopt a “standard” signaling a will to support the principles of web3 – such as composability.

 

Implications of building a protocol together with launching a user-facing application/product

Building and bootstrapping a protocol underlying an application is an extremely demanding task. Assuming we’re building a token-based and fee-taking protocol. Simpler options such as fee-less and token-less protocols lack the appeal and capability to become ecosystem-enabling and are mostly to be seen as go-to-market tricks for applications or even experiments. Often such protocols (token-less, fee-less) can end up being “forked” as a result of their lack of legitimacy.

Protocols have an impact on fees: irrespective of building a strategy based on a multi-sided network/marketplace or just a core service/product bundle such as a SaaS solution, fees taken by the applications will have to make some room for the protocol to take a fee for its existence. The dual system app-protocol will have to converge on a take rate that is also more competitive of a typical centralized platform’s take rate. This would normally mean a take rate on a transaction (imagine we’re an app-protocol for the trade of certain services or products) that peaks around 15% max, ideally going lower than 10%, or even more towards 5%. In this fee percentage we’d need to comprise both: the average app fee and the protocol fee, where the protocol should aim at staying around a 5-10% fee max. If the protocol is implemented on a shared security model on an L1 (or L2 scaling solution) also typical gas fees will have to be carved out (likely from the protocol fees).

These constraints on fee structures are due to the fact that one has to see each layer as responsible for a certain contribution to the system, versus the typical situation with a centralized platform that does the whole thing and takes the whole fees.

Considering that take rates in centralized platforms normally range from 10% (rarely) to 30% (sometimes much bigger but for relatively small use cases), one could think that a web3 alternative must squeeze less value out of the transaction.

Assuming a less than 15% take rate as a whole a typical breakdown of fees may be as follows:

Protocol fees will be essential to building a protocol strategy that has a chance of surviving long term. Seeking a protocol design that is sustainable, having its own “business model” (e.g. taking a fee from the transactions it processes and sets into the blockchain) means having the possibility to build an institutional structure that will be responsible, over the long term, to manage the protocol as a Commons for applications to use and rely upon. This normally means building a protocol DAO that is supposed to manage the protocol in a way that is independent of the influence of particular stakeholders. The progression to the launch of the DAO and its evolution towards being truly decentralized, and community managed, is crucial, especially if we plan our protocol to release a “protocol token”.

Indeed, as we anticipated above, tokens could one day be deemed investment contracts, especially if there’s a plan to attach at least part of the revenues generated by the protocol to the token ownership, and distribute them to token holders. In my experience, a typical path would in this case take a team through raising a capital round that is capable of supporting both: the creation of the protocol and the gradual handover towards a community-managed and executed DAO, and the investment in the company that likely builds a first product on top of it (that is often the product from which the original idea was born), and helps bootstrap the protocol.

Such an investment round could be based for example on a combination of:

• a SAFE (Simple Agreement for Future Equity) for investors to access equity of the company building the application and bootstrapping the protocol;
• and a SAFT (Simple Agreement for Future Tokens) for investors to access soon to release tokens at a favorable price.

SAFE is becoming more than an industry standard for investing in startup equity. SAFT and more generally Primary Issuance Events that entail the pre-minting of a certain token supply to be distributed to investors, community rewards for protocol usage, DAO treasury and grants, is – by the way – not the only option. At least, token pre-minting could be used in combination with more dynamics methods such as Primary Automated Market Makers (PAMMs) and Secondary Automated Market Makers (SAMMs) – the former being like the Commons Stack Augmented Bonding Curve, the latter being like Uniswap’s liquidity pools.

 

The Role of Tokens

The last ingredient to this new recipe of building ventures in an interoperable, modular and composable web, are the tokens.

There’s been a lot of fuss around tokens – their speculative, almost Ponzi-scheme-invoking nature – but tokens should be considered just a tremendously powerful way to create digital and programmable rights and assets, that can lead to much more cooperative layers in digital value chains. Of course, tokens also represent shared ownership in such layers, and can occasionally – once sufficient decentralization has been achieved – provide access to protocol revenues.

As tokens are launched, normally teams aim at token appreciation as a dual mean: first, an appreciating token is a signal that the underlying system is stable, growing and appealing, and secondly, an appreciating token is always also good news for the protocol builders and early adopters that likely have invested in the token (or received it as pay) in the early stage of a venture.

Protocol tokens are also normally used as means for allowing participation in governance: various mechanisms ranging from one-token-one-vote mechanisms, sometimes powered by delegation schemas, to more complex and democracy-preserving schemas such as quadratic voting are often adopted.

When launching a protocol, it’s suggested to distribute protocol tokens in a way that it rewards usage, both from end users and application developers as this could generate a positive incentive for adoption – especially in the first stages (when distribution can also be more generous). Such a mechanism, combined with a – rather typical – mechanism for the management of protocol improvements such as that of Protocol Improvement Proposals (see for example EIPs in Ethereum) can lead to empowering application developers to act as protocol innovation drivers.

Applications can catch innovations in user experience – thanks to their proximity with users – and push them gradually into the protocol adoption, to make it possible for the new behaviors to be codified in the protocol, and linked to the release of more protocol-tokens. In a few words, new types of transactions that application developers have developed to resonate with emergent user needs, can be “standardized” in the protocol progressively.

Application developers are likely the fastest at identifying certain new behaviors: these new elements of the experience shall be first integrated and developed by the niche applications; then the app would initiate a Protocol Innovation Proposals to integrate the new transaction in the protocol, pending the vote of token holders. After a positive vote, often subject to a quorum, the protocol DAO would be responsible for extending the protocol’s smart contracts and, possibly, the newly specified transactions would qualify for token releases for both the users involved and the application developer (rewarding usage). This is for example the approach we’re integrating into SOUNDIT.

The importance of such a progressive integration (in the protocol) process will be essential: as a pioneer in ecosystem thinking and legend of strategic thinking such as Simon Wardley explained multiple times, “ecosystems are future sensing engines“. In centralized platforms, platform owners often “mine” the data emerging from the ecosystem as third-party apps use APIs. Suddenly platforms create “official” and “platform-provided” versions of such experiences – that are extremely competitive in price – making it hard for the third parties to stay competitive. This is an expression of a typical ILC (Innovate Leverage Commoditize) process, a “red-queen” effect in platform-powered ecosystems: small players such as third party developers find themselves with the need to always run to build the next generation of apps, not only for the competition of other app developers but – often – for how the platform continuously commoditizes their value proposition.

Such an approach – with apps initiated PIPs – would bring the benefits of ILC without the impacts of a centralized platform continuously squeezing out a third-party business.

 

Token Value accrual besides governance

Other value drivers exist for tokens to accrue market value besides governance. First and likely the most important one is token utility – the mechanisms through which a protocol token can give access to specific benefits such as discounts, privileges such as the possibility to trade or access specific services, and more. Mechanisms for Token utility are clearly very much context dependent. Over the long term a protocol token can be accepted – at least partially – as a means of payment for protocol fees, in this way helping the protocol avoid the depletion of the fraction of the protocol treasury made of native protocol tokens.

Furthermore, applications could start to accept protocol tokens for app fees payment – at least partially – as applications may be eager to acquire protocol tokens for governance, giving them the ability to influence the protocol evolution. Apps could accept protocol tokens for standard applications fees but also for ancillary services – which are normally less related to their core business model – for example for granting access to learning content, for advertising services (imagine an application providing a marketplace interface offering improved positioning for certain sellers in exchange for protocol tokens) and much more.

Protocol tokens can also be linked to programs that distribute part of the protocol revenues to token holders. This pattern is probably the most promising, it mirrors owning equity and accessing dividends for a traditional venture, but – to be applied – requires achieving so-called sufficient decentralization. Lacking the decentralization and handover of the protocol management to a really decentralized DAO, governed by the community, the token would indeed fall into Howey test and be characterized as an investment contract, thus deeming strong constraints on its distribution. This pattern is – in any case – typically implied as a long term outcome that many of the web3 investors believe invested teams have the potential to activate over the long term – as decentralization is achieved. This could be a dangerous condition though because – by definition – a sufficiently decentralized initiative would rely on the decisions of the user base, more than the founding team, and may have different views on the use of revenues that is not token holders’ payback. Access to such paybacks may also be connected with certain forms of token staking, preventing tokens to be sold on the market, thus generating a scarcity that would drive token price value up.

Another pattern to increase token value could be any form of liquidity mining where, in the presence of token demand and liquidity pools, one could be rewarded by providing tokens on such pools. Occasionally, protocols can also use their own treasury intentionally adding different forms of incentives for token buyers, such as with protocol owned liquidity and liquidity bootstrapping pools (mainly around the first phases of launch of the protocol token).

As a further driver of token value, some protocols are also increasingly implementing token buyback mechanisms where a specific smart contract design makes the protocol itself go and buyback tokens from the market, often in a way that is proportional to the protocol GMV. Such a buyback may also be followed by mechanisms of slashing/burning. While the latter may be an attractive perspective to make the protocol token more sound, this is also a dangerous path, potentially leading to treasury depletion, so it needs to be used with care.

 

Conclusions: implications for businesses and designers

Anyone approaching the design of a venture these days can’t underestimate the potential of the adoption of web3 patterns, and shall be interested in exploring how building or choosing to comply with protocols and cooperate with DAOs could complement a product strategy. Shared protocols will be essential to building product strategies in software development, SaaS, marketplaces and more and besides the traditional driver of growth and success, designers will have to think about legitimacy as the market turns towards more efficiency, and more cooperation especially with respect to the lower, enabling, layers of the value chain.

Teams currently considering web3 as a strategy, and looking for professional help should reach out to us for help. If you’re generally interested in the topic, please subscribe to our newsletter and social media channels (such as Twitter or Linkedin) as we’ll soon release new sets of tools that can complement the existing Boundaryless’ frameworks in platform thinking – and organizational design and development and help you navigate this complextity.

---

Do you want to learn how to frame your product to resonate with your Ecosystem? Learn how to design platform strategies with us at the Platform Design Bootcamp coming up in October

Join us at the upcoming Platform Design Bootcamp: