TBD Financial Model

Web5 is a technology stack built on three primitives:

1. Decentralized Identifiers (DIDs) - self-generated, self-owned identifiers anchored in ION (Bitcoin Layer 2); no centralized authority; resistant to interdiction; universally discoverable.
2. Verifiable Credentials (VCs) - cryptographically signed data claims issued to a DID, stored in an identity wallet, and selectively presented to verifying parties (PFIs, banks, apps).
3. Decentralized Web Nodes (DWNs) - personal data storage + async messaging nodes; eventually-consistent, optionally encrypted, semantically typed, universally addressable; replicated across devices and clouds.

Together these components form the Decentralized Web Platform (DWP) on top of which Decentralized Web Apps (DWAs) are built - analogous to Progressive Web Apps (PWAs) but with a local DWN SDK replacing centralized app servers.

Key use-cases shown: decentralized finance (tbDEX exchange protocol), music playlist portability across apps, unified travel reservation data, bank credential verification.

Not explicitly named. Implied competitive framing:

• vs. Web2: current model traps users in company-controlled data silos
• vs. Web3 / crypto: Web5 is positioned as the alternative (Web2 + Web3 = Web5 formula) - avoids "special utility tokens or subjective consensus"; uses Bitcoin ION for DID anchoring, not a proprietary token

Moat: open standard (DID, DWN are W3C emerging standards); Bitcoin-anchored identity (ION); being built by Block / TBD with existing developer ecosystem credibility.

• Archetype + why: This deck does not present an operating company with disclosed revenue, customers, or financials. TBD is a Block subsidiary building open-source infrastructure. The appropriate model is a developer-ecosystem / platform adoption forecast paired with a downstream protocol revenue model (transaction fee / spread on tbDEX exchange volume). If the purpose is an internal business case or investment memo for Block, a 3-statement operating model for TBD as a cost center → revenue center transition is most appropriate.

• Forecast horizon & granularity: 5 years (Year 1–5), annual; quarterly for Year 1–2 once operational metrics are defined.

• Key drivers & assumptions:
• Developer adoption (DWA builders): start at ~500 active developers in Year 1, grow at 150% YoY as platform matures; rationale: early open-source protocol plays (Stripe, Twilio) saw similar curves
• DWN node deployments (proxy for end-user adoption): 10 DWNs per active developer on average in Year 1
• tbDEX monthly transaction volume ($): launch in Year 2; pilot PFIs = 3–5; ramp to $50M GMV/month by end of Year 3; rationale: stablecoin/remittance adjacent, conservative vs. Stellar/Ripple comps
• Protocol take rate on tbDEX: 5–10 bps (0.05–0.10%); rationale: thin spread to compete with SWIFT alternatives
• R&D / headcount spend: primary cost driver; assume 50 engineers at average $200K fully-loaded in Year 1, scaling to 150 by Year 3
• No deck data exists for any of the above; all are model assumptions

• Scenarios (Base / Bull / Bear - which variables flex):
• Bull: tbDEX gains 10+ PFI partners by Year 2; GMV ramps to $200M/month by Year 3; developer ecosystem hits 5,000 active builders
• Base: 3–5 PFI partners by Year 3; $50M GMV/month; 1,500 active builders
• Bear: Protocol adoption stalls; no meaningful PFI uptake by Year 3; TBD remains a pure cost center for Block

• Required sheets / outputs:

1. Assumptions - all drivers in one place with vs tags
2. Developer Adoption Model - cohort-based growth of DWA builders and DWN deployments
3. tbDEX Revenue Model - GMV bridge, take rate, protocol revenue
4. P&L - operating expenses (headcount, infrastructure, developer relations), EBITDA
5. Cash Flow - burn rate and path to breakeven (relevant if modeling as standalone unit)
6. Dashboard - KPIs: active developers, DWN nodes, tbDEX GMV, protocol revenue, burn