12. Assessing Use Cases

What this lecture covers

This lecture gives students a practical framework for evaluating blockchain use cases, aimed directly at their final projects. Building on the "Letter to Jamie Dimon" and a McKinsey survey report, it works through how to assess costs and benefits, why switching costs and interoperability matter to incumbents, and when a permissioned system, a permissionless system, or a traditional database best fits a given problem.

After watching, you should be able to apply a four-part framework (benefit, value capture, competition, and the specific role of append-only logs and consensus) to judge whether a business problem is a good fit for blockchain technology, and explain why permissioned systems trade scalability for a smaller trust set compared to permissionless ones.

Key ideas

• Censorship resistance, two ways: individual censorship (being denied a service or credit) and market-level censorship (barriers to entry that let incumbents dominate a market), both cited from the "Letter to Jamie Dimon" reading.
• Switching and interoperability costs: incumbents evaluating a blockchain solution must weigh it against the cost of connecting to legacy systems and getting existing users to change behavior, which is why targeted, permissioned solutions tend to be more practical than wholesale disruption.
• The four-part use-case framework: what is the pain point and benefit, how do you capture value, what are competitors doing, and specifically why do you need append-only logs, a consensus protocol, and possibly a native token to solve it.
• Permissioned scalability trade-off: permissioned blockchains gain scalability by limiting the number of validating nodes and dropping proof-of-work, but this means trusting that smaller group, which can be checked by periodically hashing the permissioned ledger's state onto a public chain like Bitcoin.
• Immutability is a spectrum, not absolute: the Ethereum DAO fork, where the community reversed a $50 million exploit, shows that even permissionless systems can effectively "amend" history through consensus, raising the question of how immutable "immutable" really is.
• Native tokens for jumpstarting networks: when there is no existing central intermediary and a group faces collective-action problems (getting many parties to adopt a shared system), a token-based incentive can help coordinate adoption in a way legacy incentives cannot.
• Head-on versus greenfield strategies: a blockchain project can either attack an existing centralized intermediary with high economic rents, or build a trustless peer-to-peer network where no strong intermediary currently exists, such as remote agricultural markets with limited banking access.
• Vocabulary looseness: the lecture acknowledges that "blockchain" is used loosely across the readings, and suggests that append-only logs and consensus protocols are the more precise underlying concepts worth focusing on.

Walkthrough

The Letter to Jamie Dimon and censorship resistance (3:07)

The class discusses Adam Ludwin's open letter responding to JPMorgan CEO Jamie Dimon's criticism of Bitcoin. Students debate whether the letter adequately answers "who needs censorship resistance," and Gensler expands the concept into two forms: an individual being denied a service, and a broader market barrier that lets incumbent platforms with strong network effects resist competition.

Switching costs and interoperability (13:15)

Drawing on the McKinsey report and the Geneva Report he co-authored, Gensler explains that incumbent institutions weigh a blockchain solution's cost reduction against the switching costs of connecting it to legacy systems and existing customer relationships. A student's project idea to build a permissioned blockchain for consumer credit reporting becomes a running example of how switching costs and market power shape whether a new entrant can realistically displace an incumbent like Equifax.

Why permissioned systems trade scalability for trust (25:23)

Gensler narrates how the financial industry, attracted to blockchain's potential to cut back-office reconciliation costs, found Bitcoin's roughly seven transactions per second too slow, and responded by dropping proof-of-work and native tokens in favor of a small set of trusted, known nodes. This raises scalability but concentrates trust in that smaller group; the lecture notes that a permissioned ledger's state can still be periodically hashed onto a public chain like Bitcoin for an added integrity check.

How immutable is immutable, and the vocabulary debate (35:44)

A student criticizes an Accenture project for building an "immutable blockchain" that can still be edited, prompting a debate about whether such a backdoor undermines the whole concept. Gensler brings up the 2016 Ethereum DAO hack, where the community used a contentious fork to reverse a roughly $50 million exploit, illustrating that even permissionless blockchains can effectively rewrite history through consensus. The class debates whether "blockchain" is too loose a term, with a suggestion to use "append-only logs and consensus protocols" instead.

The four-part framework for assessing use cases (40:51)

Gensler lays out his framework for evaluating any proposed blockchain use case: identify the pain point and benefit for specific stakeholders, determine how to capture economic value, assess what competitors (including those using traditional databases) are already doing, and pin down exactly why append-only logs, a consensus protocol, and possibly a native token are needed rather than a conventional database. He notes that roughly $30 billion has been raised across initial coin offerings and venture capital in the space, with investors increasingly demanding answers to these questions.

Deciding among traditional databases, private, and public blockchains (1:02:17)

Responding to a student asking for a non-technical way to choose between database types, Gensler suggests asking whether you are moving something of value that needs peer-to-peer participation among multiple parties, whether there are large economic rents you're trying to compete away, and whether you need a native token to overcome collective-action problems in a market with no existing central intermediary, illustrated with the difficulty of getting many hospitals to share one medical-records system.

Before you watch

• Watch the two previous lectures on permissioned systems and blockchain economics, since this lecture builds its use-case framework directly on Catalini's verification and networking cost concepts introduced there.
• Being familiar with the "Letter to Jamie Dimon" reading and the basic story of the 2016 Ethereum DAO hack will help you follow the class discussion.

Check your understanding

1. What are the two forms of censorship resistance the lecture identifies, and how do they differ?
2. Why do permissioned blockchains tend to be more scalable than permissionless ones, and what trade-off does that scalability come with?
3. What four questions make up Gensler's framework for assessing a potential blockchain use case?
4. How does the Ethereum DAO fork complicate the claim that blockchains are fully immutable?
5. According to the lecture, when is a native token likely to be a useful tool, and when is it not necessary?