What does Chris Dixon think about Web3

Chris Dixon is a general partner at Andreessen Horowitz and founder and leader of a16z crypto, the firm's crypto investment practice. His case for Web3 is not mainly that a token price will rise. It is that blockchains can give internet services rules and ownership structures that are not controlled by one company. He develops that case in his 2024 book, Read Write Own: Building the Next Era of the Internet.

This is an advocate's framework. Dixon invests through a16z crypto, so his writing and public arguments should be read with that interest disclosed. That does not make the technical points false. It does mean that readers should distinguish a description of a blockchain's capabilities from a prediction that a particular network, token, or company will succeed.

Background and investment role

Andreessen Horowitz says in Dixon's profile that he joined the firm in 2012, founded a16z crypto, and leads it. The profile says the practice invests through four dedicated funds with more than $7 billion under management. Fund sizes and portfolios change, so that figure is the firm's stated figure rather than an independent measure of performance.

Before a16z, Dixon co-founded SiteAdvisor and Hunch. The same firm profile says McAfee acquired SiteAdvisor in 2006 and eBay acquired Hunch in 2011. SiteAdvisor warned users about security threats; Hunch made recommendations. Those businesses were conventional web companies, but they inform Dixon's later focus on how platforms attract users and how a controlling company can change the rules under developers.

His official book site says he made early investments in Coinbase and Oculus after joining a16z, and that he founded a16z crypto in 2018. It also says he holds BA and MA degrees in philosophy from Columbia and an MBA from Harvard. These are biographical claims from his publisher-facing site. The more useful point for understanding his Web3 writing is that he has worked as both a startup founder and an investor in companies that depend on network effects.

Read, write, own

Dixon's shorthand divides the consumer internet into three periods. In his account, early Web1 was organized around open protocols such as the web and email. Users mostly consumed pages. Web2 brought user-generated content and social networks, but the largest services were operated by companies that owned the servers, identity systems, and distribution rules. Web3, he argues, adds ownership through blockchains and tokens.

The phrase "read write own" is a thesis, not a standard historical classification. The book introduction says that blockchains can create new kinds of digital property and networks. The important mechanism is a cryptographic key. A user can control a token, sign a transaction, and interact with a smart contract without an application's operator being the sole custodian of the asset.

Ownership needs precision. Holding a token is ownership under the rules of the relevant blockchain and contract. It does not automatically grant copyright, governance power, access to a service, or legal ownership of an associated brand. An NFT can point to media stored elsewhere. A governance token can have voting rights only if a contract or organization recognizes them. The terms of an NFT collection, a protocol's code, and applicable law determine what a holder actually has.

Dixon uses this difference to argue that the internet has shifted from open protocols toward platforms. Email is his standard example of an open protocol: many providers can interoperate because they implement shared specifications. A social-media account is different. A platform can alter ranking, access, monetization, or API terms. A blockchain can offer public state and a common settlement layer, but applications still make product choices. A wallet, node provider, bridge, exchange, or front end may be operated by a company and may become a new point of control.

Strong and weak technologies

In his 2019 essay "Strong and Weak Technologies", Dixon calls a technology weak when its rules can be changed by one organization. He calls it strong when it is based on open standards, can be implemented by many parties, and has durable rules. He uses the web and email as strong examples and commercial APIs as weak examples.

The point is about developer risk. A developer who builds on a company API may benefit from quick distribution, payment tools, or moderation. The company can also change the terms, charge for access, or remove the integration. An open protocol can reduce dependency on a single operator, provided there are usable implementations and a real community maintaining the standard.

Blockchains have some strong-technology features. Public code and replicated state can let independent developers inspect balances and interact with contracts. A user can often choose among compatible wallets or interfaces. But "strong" is not a guarantee. Protocol governance can change rules. Validator or mining concentration can affect control. Many users rely on centralized exchanges and hosted infrastructure. Smart-contract upgrades, admin keys, and token voting can give a small group substantial power. The useful question is not whether a project uses a blockchain. It is which parties can change the rules, how changes are authorized, and whether users can realistically leave.

The decentralization lifecycle

Dixon's 2018 essay "Why Decentralization Matters" describes a recurring pattern. New networks often begin centralized because one team can build a product quickly. If a network becomes valuable, the team may face pressure from users, business partners, or governments. Decentralizing can make the network more credible to developers because no single operator can easily change access or take the economic upside.

This account is sometimes simplified into a claim that a token makes a service decentralized. It does not. Decentralization has several dimensions: who runs infrastructure, who writes or upgrades code, who holds governance power, who supplies liquidity, who controls the user interface, and who can block transactions. A project can distribute a token while retaining a multisignature upgrade key or a dominant hosted front end.

The lifecycle also has trade-offs. Centralized teams can respond quickly to bugs and offer coherent support. Distributed governance can make changes slower and can favor large holders or well-organized voters. A protocol may be difficult to stop, but that does not make it safe, legal in every jurisdiction, or useful for ordinary users. Dixon's argument identifies a reason some builders may prefer credible neutrality. It does not remove the costs of building and governing public infrastructure.

Tokens as ownership and incentives

Dixon describes tokens as a way to align people who use, build, and maintain a network. In a traditional platform, shareholders may own the company while users contribute content or data without a transferable stake. In a token network, early participants may receive or buy units that can be used for fees, staking, governance, or access, depending on the design.

That structure can finance software before conventional revenue. It can also create an incentive to promote adoption. Neither outcome is automatic. Token allocation may give insiders a large share. Trading can dominate use. Regulatory treatment varies by jurisdiction and facts. Tokens that are sold as investments can raise securities-law questions, while an asset that purports to confer governance may still have little practical influence if participation is low.

The difference between a network token and equity matters. Equity normally carries a legally defined relationship to a corporation, including whatever rights its class provides. A token's rights come from code, contracts, and organizational promises. Some protocols have no company issuing the token. Readers should not assume that a token holder has a claim on revenue, profits, intellectual property, or a company's assets unless the relevant documents expressly say so.

Computing cycles and new applications

Dixon often places blockchains in a longer sequence of computing platforms. His "Blockspace" essay compares blockchains to earlier shifts that created new application categories. The analogy does not mean that every blockchain use case is novel or that adoption will follow the same timetable. It is a way of explaining why an underlying technical platform may matter before its best consumer applications are obvious.

This framing is most useful when it leads to a specific question: what can a blockchain do that a database plus contract cannot? Possible answers include permissionless transfer of a natively digital asset, shared settlement among parties that do not trust one operator, or composable contracts that other software can call. If a product relies only on a database operated by one company, calling it Web3 adds little explanatory value.

It is also important to include the costs. Public blockchains can be slower or more expensive than centralized databases. Transactions are hard to reverse. Users must protect keys or trust a custodian. Public transaction data can create privacy risks. Bridges and smart contracts have been frequent security targets. A design that removes one intermediary may add technical and operational burdens elsewhere.

A practical reading of Dixon

Dixon's writing is useful for understanding the pro-Web3 case for open, user-controlled infrastructure. His concepts point readers toward concrete checks: Can someone else implement the protocol? Can a developer build without permission? What exactly does a token entitle its holder to do? Which entity has upgrade power? Can the service work if its company disappears?

The answers should be taken from code, governance documents, terms, and operational reality, not from a token label. Dixon's argument is strongest as a test for concentration of control. It is weaker when treated as a forecast that every application needs a token or that protocol ownership will distribute value fairly. Web3 changes the available technical and economic tools. It does not settle the design, governance, legal, or security questions that follow.