TBD Pitch Deck: Slide-by-Slide Breakdown

The Vision: Moving Beyond Web3

TBD’s deck is a departure from the standard startup narrative. In 2022, while the industry was focused on Web3, TBD (an arm of Block, formerly Square) introduced "Web5." The deck is a technical manifesto that prioritizes architectural standards over commercial metrics. It presents a world where the user is the center of the data universe, rather than a product of centralized silos.

Slide 1: Title Slide

The deck opens with a retro-computing aesthetic, featuring a pixelated font and a browser-window frame. The title is "Web5: The Decentralized Web Platform." The subtitle defines it as "A new evolution of the Web that enables decentralized apps and protocols." The branding is minimal, with the "tbd" logo in the top right corner.

Slide 2: Evolving the Web

This slide sets up the problem and the desired future state. Under "Today," it shows users pointing toward a centralized web icon, noting that people do not own their data or identity and are held "captive in app silos." Under "The Web We Want," the diagram flips: personal communications, financial interactions, and apps all point toward the individual. It introduces the concept that apps built for Web5 store their data "with you." It also mentions "tbDEX" as an example of a new class of decentralized protocols.

Slide 3: The Web5 Equation

This slide provides the conceptual framework: [Web 2] + [Web 3] = [Web 5]. It defines the Decentralized Web Platform (DWP) as the toolset that enables developers to write Decentralized Web Apps (DWAs). The core components mentioned are Decentralized Identifiers (DIDs) and Decentralized Web Nodes (DWNs). The primary value proposition is "returning ownership and control over identity and data to individuals."

Slide 4: The Pillars of Web5

TBD breaks the platform down into three functional pillars: Decentralized Identifiers (self-owned identifiers for authentication), Verifiable Credentials (data formats for cryptographic claims), and Decentralized Web Nodes (data storage and message relay nodes). This slide serves as the technical table of contents for the middle section of the deck.

Slide 5: Decentralized Identifiers (DIDs)

This slide goes deeper into DIDs. It uses a "Bob and Alice" example to show how identifiers are self-generated and self-owned. Key technical claims include: no centralized providers, no special utility tokens, and resistance to interdiction. It emphasizes that IDs can be made "universally discoverable" without a trusted authority.

Slide 6: Verifiable Credentials (VC)

Slide 6 illustrates a workflow for identity verification. It shows "Acme Bank" issuing a Verifiable Credential to "Alice’s Wallet." Alice can then present "Bank Account Proof" to a "PFI Verifier" (Participating Financial Institution). The diagram shows the "ION" network as the underlying layer for anchoring DIDs and public keys. This is the first slide that hints at a practical financial use case.

Slide 7: Decentralized Web Nodes (DWNs)

This slide defines DWNs as an emerging standard for data storage. It lists six features: Universally Addressable, Replicated (masterless and eventually consistent), Secure (encrypted with DID keys), Semantic Discovery, Async Message Threads, and Support for any identity type. The summary box describes DWNs as the foundation for building decentralized apps and protocols.

Slide 8: The Anatomy of an Identity Wallet

Using a smartphone mockup, this slide identifies the five core functions of a Web5 wallet: Data Management (managing DWN data), Credential Functions (signing and verifying), DID Functions (create/update/recover), DID Auth (managing authorizations), and Context Management (enforcing which DIDs are used with which apps).

Slide 9: Web5 Network Topology

This is a complex architectural diagram showing how Alice and Bob interact. It involves local DWNs (on their devices) and remote DWNs (in the cloud). The process involves a "DID Resolver" to find endpoints. The text explains that this combination replaces "one-off protocols" (like specific encrypted messaging apps) with universal standards for data exchange.

Slide 10: Visualizing Web5 and the DWP Stack

A pyramid diagram shows the hierarchy of the technology. At the base are Decentralized Identifiers, followed by Decentralized Web Nodes, then the DWA Model. These three layers constitute the "DWP" (Decentralized Web Platform). At the top of the pyramid are the "DWAs" (Decentralized Web Apps), with tbDEX listed as the primary example.

Slide 11: What are PWAs?

This slide takes a step back to explain Progressive Web Apps (PWAs). It lists ten attributes, such as "Work Offline," "App-Like," and "Installable." This serves as a bridge to explain how TBD’s new model improves upon existing web standards.

Slide 12: From PWAs to DWAs

This is a critical comparison slide. A standard PWA connects a Web App to a Service Worker, a Local Cache, and a Centralized App Server . A DWA (Decentralized Web App) replaces that centralized server with a "DWN SDK" and a Decentralized Web Node . This visualizes the core technical shift TBD is proposing: removing the app-specific backend.

Slide 13: Acme Bank? Is this legit?

This slide addresses the issue of trust in a decentralized system. It shows a two-step process: 1) Alice resolves the Bank’s DID, and 2) Alice fetches credentials from the Bank’s DWeb Node. It includes a code snippet: navigator.did.request({ schema: "banking.org/charter" }) . The goal is to show how anyone can independently verify the identity of an organization.

Slide 14: tbDEX Message Threads

This slide focuses on tbDEX, TBD's decentralized exchange protocol. It shows Alice’s app sending "Ask" messages to various PFIs (Participating Financial Institutions), which respond with "Bid" messages. The text describes tbDEX as a "DWN-based threaded messaging and data exchange protocol layer."

Slide 15: Music to my ears

The deck moves into consumer use cases. This slide shows how a user could have a single music playlist stored in their DWN. One app ("Groove") writes to the playlist, and another app ("TIDAL") reads from it. The takeaway is: "It’s not fun to regurgitate your playlists over and over again for different music apps, so let’s stop doing that."

Slide 16: Hotel me your travel plans

A second use case focuses on travel. Alice grants a hotel, airline, and car rental provider the ability to add "Reservation" objects to her DWN. A separate "Travel App" can then request access to all those objects to create a unified itinerary. It highlights the current "unworkable mess" of data strewn across hundreds of apps.

Slide 17: Conclusion

The final slide repeats the definition of Web5 over a meme-inspired image of two astronauts looking at Earth (the "Always have been" meme). The text reinforces that Web5 returns ownership and control to individuals. One astronaut asks, "We're building an app platform?" and the other responds, "Always have been."

What TBD Does Well

The deck is exceptionally clear about its technical architecture . By breaking the platform down into three pillars (DIDs, VCs, DWNs) and providing a stack visualization (Slide 10), it makes a complex concept digestible for a technical audience. The use of comparative diagrams (Slide 12) is a masterclass in explaining "the new way" vs. "the old way." By showing exactly which component is replaced (the Centralized App Server), TBD removes the ambiguity often found in decentralized project pitches.

Furthermore, the use cases (Slides 15 and 16) are grounded in everyday frustrations—re-creating music playlists and managing travel itineraries. This helps bridge the gap between abstract protocol layers and actual user value.

What is Missing from the TBD Deck

As a fundraising document, this deck is incomplete by traditional standards. It lacks:

A Business Model: There is no mention of how TBD or Block intends to capture value from this platform. · Market Analysis: There are no figures on the size of the identity market or the DeFi space. · Competition: The deck ignores other decentralized identity solutions or Web3 protocols that might compete for developer mindshare. · Team: While the catalogue facts state this is a Square/Block business arm, the deck itself does not list the leadership or engineering talent behind the project. · The Ask: There is no slide detailing how much capital is being raised or how it will be deployed.

These omissions suggest that the deck’s purpose was not to raise venture capital in the traditional sense, but rather to serve as a developer recruitment and ecosystem alignment tool .

What Founders Can Copy

Founders building complex infrastructure or protocols should study TBD’s visual hierarchy . The deck uses a consistent color palette (yellow, cyan, and purple on black) and clear iconography to represent different actors in the system. The step-by-step flow diagrams (Slides 6, 9, 13, and 14) are excellent for explaining how data moves through a multi-party system.

Another takeaway is the "Equation" slide (Slide 3). Reducing a company’s entire philosophy to a simple mathematical expression (Web2 + Web3 = Web5) is a powerful way to make a brand name feel like an inevitable logical conclusion. Finally, the use of code snippets (Slides 13-16) is a subtle but effective way to signal to developers that the product is real and the implementation is straightforward.

Final Thoughts

TBD’s Web5 deck is a technical manifesto masquerading as a pitch deck. It succeeds in defining a new category and providing a roadmap for its construction. However, its total avoidance of commercial reality makes it a poor template for a typical startup seeking investment. It is a "vision deck" in its purest form, designed to inspire a movement rather than close a round.