I want to start this article by clarifying that I want web3¹, as commonly proposed, to succeed. The ideals that the web3 movement often espouses - transparency of web service logic, privacy and personal control of user data, anti-monopoly - are ones with which I resonate². Unfortunately, there are several common questions that current projects seem unable to answer, leaving me skeptical that they will succeed.

(Aside: I started writing this post before the current calamitous freefall of cryptocurrencies, which may render unnecessary many of the criticisms below as the shaky projects will have been abandoned. Still - I’ve started, so I’ll finish)

I’m writing this post primarily to articulate the questions for myself, to state them clearly and to test them for coherence, watertightness, and importance. Secondarily, I hope this will serve as a reference for discussion - instead of having to re-state a question or criticism afresh, I can link to a description here. I flatter myself to think that web3 proponents might be able to use this post as a checklist to ensure that their project doesn’t have any obvious flaws³.

Most of these questions assume that the project aims to reach some critical mass of size. This is a particularly reasonable assumption for projects that have a social component (there’s no point posting on a social network if your friends aren’t there!), but also applies to general economic considerations.

Many thanks to my proof-readers Éamon and George, who identified a common theme of these questions - “How are you planning on solving the non-technical sides of the problem (i.e. those that are primarily economic or socio-political)?”

Questions

Soft Questions

These are questions that are not deal-breakers, but that can highlight a potential point of friction or concern in the project.

User complexity

How complex will it be for a user to understand and run the components necessary for the system? This presents a barrier to entry - if only geeks, nerds, and enthusiasts are able to use your system, then it’s unlikely to hit critical mass.

This is a soft question because it can be addressed with UI/UX improvements, by “hiding” the complexity under user-friendly components. Most internet users couldn’t tell you how TLS/SSL certificates work, for instance, and yet they benefit from them every day.

Fork-resiliency

How resilient will this system be to chain-forks; large-scale consolidated actions in which chain participants agree to ignore/rewrite a chunk of history?

This is categorized as a soft question, despite the potential large impact ("if the chain can be forked at any time, then there is no guarantee that my assets/ownership/stake are durable and reliable"), because a project owner could argue that this situation is no worse than the current web2 situation - InsertLargeServiceProviderHere co. can arbitrarily decide that you are not welcome on their platform, and unilaterally take whatever actions they wish by seizing your digital assets or ejecting you from their system. Personally, I believe we’re not yet at a state where the stability of large blockchains is more trustworthy to me than than the reputational damage to TwitAmaGooPpleBookSoft of such arbitrary bootings - but it probably won’t be long before they’re comparable.

Abuse-resiliency

How resilient will the system be to hacks, phishing, fraud, bugs, etc.? If a transaction occurs on the system that can be proven to have been unintentional or malicious, can it be reversed?

This is a thorny question - the “code is law”⁴ attitude I perceive in many web3-thusiasts seems to imply a rugged individualist “if you get scammed, you deserve it - that’s the price you pay for the benefits of unregulated liberty”. Perhaps this is why basically any web3 or crypto story ends with a rugpull, a major hack, or some combination of the two.

Note that this is a dual to the question above. Abuse-resiliency is, by definition, the ability to revert transactions that are determined to be “bad” - that is, rewriting history. In order to do so, the project must give up a commonly-touted benefit - the lack of a central dictatorial authority who can compel action or override preferences. A quorum of users who can initiate a fork always form such a central authority, but it could(?) be possible for a system to be built such that an operation could be compelled by a trusted super-user without requiring a full fork ("I, user abc, hereby authorize user def to take control of my account in the following situations and with the following constraints: …"). Each system(’s steering commitee) would have to decide for itself whether the abuse-protection of such an override is worth the loss of liberty it implies. Hence, this is a soft question - some users might want a rugged, wild-west, “do what thou wilt be the whole of the law” environment, while others might want some protection from scams.

Data Ownership

“You own your data” is a common refrain of web3 systems. However, this is a fuzzy statement that could cover a multitude of claims, given the uncertainty about the key terms “own” and “data”:

• Does “Ownership” mean:
  • that you have final say in the usage, sale, and distribution of the data? If so - how can you prove that the service isn’t selling your data, or that 3rd-parties to whom you provide access are not saving-and-selling-on that data.
  • that you will always share in any profit derived from usage/sale of your data?
  • that you will always be able to extract the data about you from the system? This is one of the more reasonable and justifiable claims (though…how would you prove that the data is complete? How could a user prove that data is missing without knowing what that apparently-missing data is?) - though, frankly, for countries that have GDPR or an equivalent, this isn’t actually much of a novelty (see “Why do you need a blockchain/decentralization for this? Does portability/scarcity even make sense?”).
• Is “your data”:
  • Just the data that you provide to the system - your preferences/settings, your posts, your connections (follows/friends/circles), your structures (playlists) - or also…
  • …the data that is generated as an output of your usage of the service - your Data Exhaust? This encompasses simple things like “play counts of songs”, or complex inferred data like “customer genre tastes derived from play counts” or “customer marketing segment derived from click-through rates”.

I think that a lot of web3 systems do a (possibly-intentionally?) terrible job of clarifying this ambiguity. Users think that they’re being promised a beautful utopia where your data never gets sold or used for marketing and you can profit from your usage of the system just as much as the service itself does, where in fact the promise is the minimal coverage of “you can always extract from the system whatever you put into it (but not anything we calculate from you) - and forget about any profit-sharing”

Hard Questions

These are questions that, I believe, are fatal to a web3 system if they cannot be answered satisfactorily.

Why would a service implement this?

Most web3 proposals make the experience significantly better for users. This is usually at the cost of some lost-advantage for the service provider - less information, less monopoly power, and so on. A particularly egregious example (often used in the context of NFTs in music⁵ or gaming⁶) is the case where a user buys content on service A, and then expects to be able to consume that content on service B via ownership expressed via an NFT or similar. Assuming that the service isn’t profiting from the customer’s use of the service (see “Data Ownership”), why would service B permit this?

This question can be split into two sub-questions:

Why would an existing service integrate with this?

Most existing web services benefit from an economic moat - there is friction in moving away from the service, since a customer has built up an identity (preferences, posts, connections) on the service that cannot be exported. This conveys an economic advantage - the service can extract more profit-per-customer because the friction forces a customer to endure a level of service that would otherwise cause them to stop using the service, or switch to a competitor. This is a situation that many web3 projects aim to counteract; to increase competition (and thus, quality of service) by reducing the friction of moving an account to a different provider.

However, we must ask why any existing provider would willingly integrate with a system that destroys an economic advantage that they have built up. They would only do so when there is a net economic advantage to the integration (a large one, because this integration with an outside system would presumably be more complex than working with their own systems, and would provide value to a competitor) - and that, presumably, would only happen when the user-base of the low-friction system is large enough to represent a significant asset. A web3 system that needs to integrate with existing providers in order to succeed is therefore stuck in a chicken-and-egg situation - it cannot reach critical mass until existing providers integrate with it, but existing providers will not do so until it has grown sufficiently large.

Why would a new service implement this?

Consider, instead, a system that is “starting from scratch” - not attempting to integrate with existing providers, but providing value in-and-of-itself. Still, here; given that there is an economic advantage to “building moats”, why would a new system choose to give up that advantage?

(One very reasonable response here is “because we plan to set the expectation in this product-space that web3-openness is table-stakes, so that users will reject non-open competitors; and users will be so impressed by our differentiated features that they choose to keep using our service rather than moving to another open competitor”. If so - that’s great! I am not saying that these questions are fundamental flaws in web3 per se. Rather, they are questions that a project must be able to answer in order to appear feasible. If you have good answers - good for you, I look forward to seeing your success!)

Why would a user migrate to this/stay with this?

A service cannot survive without customers. Customers evaluate a service on two parameters; quality and price⁷. In order to convince a customer to move from an existing service to this new one, the combination of quality-at-price must not only match the existing service, it must exceed it by enough to overcome the friction associated with migrating.

One point on which Web3 services pride themselves is that their systems are open, decentralized, and privacy-respecting. These are admirable properties! But they have associated problems:

• If the service isn’t selling customer data or serving ads, then the customer is not the product - this makes it pretty likely that the service will not be available for free (this is further supported by many blockchain-based systems that require a payment-per-interaction - a rude surprise for customers who are accustomed to internet interactions being free!). Migrating from a free service to a paid one requires an extraordinary surplus of quality.
• Frankly, most customers don’t seem to care much about privacy: witness the fact that many continue to use Web2.0 Social Media despite the repeated revelations about privacy abuses. From this, we can conclude that “this service respects your privacy” is not a particularly compelling feature for the average customer⁸ - it’s a nice-to-have, but the service will need to provide a slew of other compelling features to overcome the migration-friction and the price-increase-from-free.

So - you need features in order to attract customers, and you need a lot of features to attract customers from a free service to a paid one. But the situation is even worse than that for nascent web3 services:

• in order to build those features, you need money
• to get money, you need either paying customers (but you don’t have them yet) or investors
• those investors will expect a return on their investment

This is not a problem that’s unique to web3-based services, by any stretch! “Launch fast with a compelling offering, acquire a critical base of customers, then pivot to profitability” is a tried-and-true Silicon Valley strategy. However, it may be a little more difficult to sustain when two key pillars of your offering are:

• privacy - which precludes you from two key sources of income that don’t come out of your customers’ wallets; personalized ads, and selling customer data.
• low-friction of migration between services - so, you cannot rely on economic moats; your service will live or die on whether its features are better than a competitor’s.

At the risk of repeating myself - this is not a fatal gotcha! There are certainly imaginable ways that a web3 service could navigate these requirements, by building features that attract and retain customers while achieving profitability. But this certainly seems like a harder product problem in a space where you cannot profit indirectly from customers, and where the friction of moving to a competitor is low.

Why would real-world authorities respect this?

Some projects aim to represent real-world ownership or entitlement as digital resources, with the promise that transacting on (validating, transferring) those ownerships will be faster, smoother, and cheaper (see “Code Is Law”⁴). That’s all very well - but, what will you do when you need to enforce that ownership in the real world?

Take the case of homeownership. In part, the value of a traditional home title document is that it is backed by the authoritarian power of the establishment; that, if someone is squatting in your home, you can have confidence that Men With Guns will come and back you up in your claim that they should stop doing so. If your aim is to build a new system of determining ownership, you have one of two choices:

• Reject the authority of the existing establishment and declare your system to be the Truth. Enjoy attempting to explain that to the aforementioned Men With Guns.
• Attempt to convince the establishment that they should respect your system as an alternative/supplementary source of ownership truth. This then reduces to a “Why would an existing service integrate with this?” question - why would the existing bureaucracy a) put in the work, and b) give up their profit margin (or government grants, or whatever), by adopting your system?

Again, potential satisfying answers to this question exist, including buying-out the existing bureaucracy or offering them a cut of the profits. This is not a global-gotcha, it’s just an awkward question that often goes unanswered.

How do you enforce that the system represents reality?

Many systems attempt to represent real-world entitlements in a digital form. For instance, some NFT systems represent ownership of a real-world piece of media or art⁹. In such systems, it’s important that the representation is accurate and reliable; if it cannot be trusted, then it is not a valuable system.

This problem is particularly important at the point of creation of a digital resource. For a resource with a chain-of-custody that can be confirmed in some trustworthy source (potentially, but not necessarily, a blockchain), you can be sure of “where it came from, and who transferred it, when”, and thus hopefully confirm that those transfers correspond with transfers of the real-world entitlement (though, see the next paragraph) - but this only inductively proves “if the resource originally represented the entitlement, then the resource now represents the entitlement”. It’s missing the crucial base case - “did the resource represent the entitlement at the time that the resource was created?”. Without this proof, you end up in the absurd situation where anyone can mint an NFT “proving” ownership of (say) the Brooklyn Bridge.

Note that this question is related both to “Why would real-world authorities respect this?” (existing authorities will be unlikely to respect a system that is unreliable) and to “Abuse-resiliency” (abuses to the system will most likely be intended to transfer ownership away from their “rightful” owner, thus making the system an inaccurate reflection of reality)

Why do you need a blockchain/decentralization for this? Does portability/scarcity even make sense?

Don’t get me wrong - blockchains are fascinating data structures, with many interesting and potentially-useful properties. But they’re also overkill if you don’t need or benefit-from those properties. Similarly, the ability to represent ownership on a distributed ledger in a system-agnostic way is very cool - but, if your use-cases only ever include transferring ownership within systems owned by your own company, you have just introduce a ton of complexity to achieve an outcome that is indistinguishable from “a row in a traditional database”.

Conclusion

To repeat - my articulation of these questions does not mean that I think that web3 is doomed, nor that I inherently oppose it. I resonate with many of the ideals professed by many web3 projects, and I really hope that projects exist that can answer these questions and provide value to users while avoiding significant environmental impact. This article is a framework for evaluating common flaws in proposals, not a comprehensive takedown of all of web3.

• web3