178 lines
12 KiB
Org Mode
178 lines
12 KiB
Org Mode
:PROPERTIES:
|
|
:ID: 6d2e3f4a-5b6c-7d8e-9f0a-1b2c3d4e5f6a
|
|
:ID: d28adac8-08a1-40c4-ae43-b5d8d7b1743f
|
|
:ID: 528a0f6c-6fd6-41ed-9d59-237958bdaef2
|
|
:ID: 57f9538a-6270-4302-8d07-d742168419eb
|
|
:CREATED: [2026-05-25 Mon]
|
|
:END:
|
|
#+title: Adoption
|
|
#+filetags: :passepartout:strategy:adoption:growth:
|
|
|
|
This is the canonical adoption and growth document. It replaces the
|
|
earlier separate notes on growth-strategy, effects-flywheel, adoption
|
|
game theory, and the social-first alternative — those are now absorbed
|
|
here.
|
|
|
|
Social and institutional adoption are two separate processes with
|
|
independent dynamics. Each has its own phases, defined by different
|
|
metrics. They run concurrently and reinforce each other, but neither is a
|
|
precondition for the other. Each section below defines its own phases.
|
|
|
|
Phases are distinct from the architecture's development Stages (Stage 0
|
|
= now/Linux-hosted, Stage 1 = social protocol, Stage 2 = verification
|
|
TUI, Stage 3 = Lisp machine, Stage 4 = inference ASIC). The clock for
|
|
both adoptions starts when Stage 2 ships (TUI complete). See
|
|
[[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][Development timeline]] for the Stage breakdown.
|
|
|
|
* Social adoption
|
|
|
|
Social adoption tracks the growth of the social protocol network — users
|
|
on the social graph, instances participating in the protocol. The phases
|
|
are defined by orders of magnitude of users.
|
|
|
|
**Phases and dynamics
|
|
|
|
| Phase | Users | What marks the boundary | Flywheel effect | Growth driver | Revenue | Failure mode |
|
|
|-------+-------+------------------------+-----------------+---------------+---------+--------------|
|
|
| 0 | 0→10K | First organized communities onboarded as full-bundle groups | The bundle is proven for real coordination | Neighboring communities see it working and onboard — organic spread | $20-100K fees | No community finds PMF — the unified bundle is too complex |
|
|
| 1 | 10K→100K | Community refugees and creators arrive; organic spread between neighboring communities | Reputation graph from Phase 0 communities makes migrations stick — users build identity they won't abandon | Platform fees bypassed — economic value accrues on-protocol; creator audiences follow | $1-5M fees + subs | Migrations don't stick — communities leave when crisis passes |
|
|
| 2 | 100K→10M | Contract marketplace reaches critical mass; cross-jurisdiction transactions emerge | Freelancers and cross-border users trust the reputation graph for escrow and arbitration | Marketplace attracts more users; reputation deepens further | $20-100M fees | Contract marketplace stalls — no dispute resolution trust |
|
|
| 3 | 10M→1B | Institution crossover — universities, newsrooms, regulators join the existing network | Institutions join not because they chose to, but because their users are already there | Protocol becomes default identity — traditional barriers to entry become irrelevant | $210-750M | Social graph stalls at niche — never reaches mainstream critical mass |
|
|
|
|
Each phase spans roughly one order of magnitude of users. The phase
|
|
boundary is crossed when the accumulated effects from the previous phase
|
|
generate enough growth driver to reach the next scale — it is a
|
|
consequence of the flywheel, not a timeline that can be accelerated by
|
|
spending more money.
|
|
|
|
**Phase details**
|
|
|
|
**Phase 0 — Organized communities (0 → 10K users):** Onboard HOAs,
|
|
clubs, cooperatives, PTAs — any group that uses 3+ separate tools and
|
|
has a leader who can migrate everyone at once. The group already exists;
|
|
the cold start is solved by group density. Ship all five layers
|
|
(identity, content, payments, contracts, governance) from day one
|
|
because organized communities need all of them.
|
|
|
|
**Phase 1 — Refugees and creators (10K → 100K users):** Monitor
|
|
deplatforming events. When a subreddit of 10K+ users gets banned, offer
|
|
a ready-made community space within 24 hours. Meanwhile ship creator
|
|
tools (LSAT, Lightning subscriptions) for OnlyFans/Patreon refugees.
|
|
This is the highest-ARPU segment — creators earning $50K-500K/yr with
|
|
strong incentive to bypass intermediaries.
|
|
|
|
**Phase 2 — Freelancers and cross-border (100K → 10M users):** The
|
|
reputation graph from Phase 0-1 communities now carries real weight.
|
|
Freelancers and small businesses in weak-rule-of-law jurisdictions use
|
|
the protocol for verifiable contracts and escrow. This is the hardest
|
|
technical build (full SCAL stack, arbitration guilds) but the strongest
|
|
moat — no one else offers verifiable contract enforcement without a
|
|
state.
|
|
|
|
**Phase 3 — Institution crossover (10M → 1B+):** At this scale
|
|
institutions can no longer ignore the network because their users are on
|
|
it. Universities issue verified credentials. Newsrooms publish with
|
|
provenance. Regulators adopt social protocol attestation because it is
|
|
the standard.
|
|
|
|
* Institutional adoption
|
|
|
|
Institutional adoption tracks the penetration of verified computing into
|
|
regulated markets. Its phases are defined by market structure transitions
|
|
— each phase marks a shift in how verification is bought, mandated, or
|
|
priced. User counts are not the metric; the metric is whether
|
|
verification has crossed a structural threshold in a domain.
|
|
|
|
**Phases and dynamics
|
|
|
|
| Phase | What marks the boundary | Flywheel effect | Growth driver | Key metric | Revenue driver | Failure mode |
|
|
|-------+------------------------+-----------------+---------------+------------+----------------+--------------|
|
|
| 0 | First compliance engagement — gate replaces annual audit ($200K-$1M) with subscription ($50K/yr) | Compliance cost drops 10x — the buyer saves | Competitors must match — institutional sales accelerate | First case study | Domain gate packages, verification appliance | First engagement fails to deliver — poisons reference |
|
|
| 1 | Verification API gateway — value decoupled from instance adoption; any LLM user is a customer | AI safety shifts from probabilistic to structural | Any company using LLMs is a customer decoupled from instance adoption | Instances deployed; API gateway users | API gateway subscriptions; gate rule subscriptions | No high-profile AI harm event to drive conversion |
|
|
| 2 | First regulator encodes a rule as a gate — adoption in that domain becomes mandatory | Enforcement becomes automatic, not annual paper<br><br>Accumulated edge cases from all instances | Every regulated entity in that domain must adopt — step function<br><br>Competitive advantage for adopters — those off-network fall behind | Regulated entities onboarded per domain | Mandatory adoption; insurance products | First regulator encode captured by incumbent (backdoored standard) |
|
|
| 3 | Insurance differentiates on verification — unverified code costs more to operate than verified | Unverified code costs 10x to insure<br><br>Network effect: each new parameter makes the store more valuable for everyone | Economic necessity — not preference, not regulation, but cost of doing business<br><br>No institution can be pressured or acquired to remove accumulated knowledge | Certified instances | Certification fees; insurance premiums | ASIC path stalls — verification remains a performance tax |
|
|
| 4 | Installed base is default infrastructure — a decade of attestations cannot be replicated | Installed base moat — cannot replicate a decade of attestations | New entrants cannot compete regardless of funding | Industry standard | Infrastructure rent; marketplace fees | Technology paradigm shift disrupts category |
|
|
|
|
**Phase details**
|
|
|
|
**Phase 0 — Compliance engagements:** The buyer is a compliance officer
|
|
who just failed an audit or sees the cost of the current process
|
|
spiraling. The gate replaces an annual audit ($200K-$1M) with a
|
|
subscription ($50K/yr). First sale funds the team. Each engagement adds
|
|
to the gate rule library.
|
|
|
|
**Phase 1 — API gateway:** The verification API gateway decouples value
|
|
from instance adoption. Any company using LLMs can route calls through
|
|
the gateway and get a proof log — no instance required. This seeds the
|
|
concept of verifiable computation in the market. Institutional sales
|
|
compound as referenceable case studies accumulate.
|
|
|
|
**Phase 2 — Regulator encode:** First regulator encode is the single
|
|
most leveraged event. When a regulator encodes a rule as a gate
|
|
specification, every regulated entity in that domain must adopt. Likely
|
|
candidates: EU AI Act, NIS2, or a forward-leaning national regulator.
|
|
After this, growth in that domain becomes mandatory.
|
|
|
|
**Phase 3+ — Insurance loop:** Actuaries price verified instances lower
|
|
than unverified. The cost of non-verification exceeds the cost of
|
|
adoption. Growth becomes economic necessity.
|
|
|
|
* How the two adoptions interact
|
|
|
|
The social and institutional adoptions run on independent clocks, but
|
|
they reinforce each other at every crossover:
|
|
|
|
- **Revenue funds build:** Institutional compliance sales generate
|
|
revenue from day one, funding the social protocol development before
|
|
the social network has any users.
|
|
- **Network provides distribution:** At scale, institutional verification
|
|
products sell as fulfillment orders to a network that already has
|
|
users — no cold start for each new product.
|
|
- **Users bridge the gap:** Enterprise employees get DIDs from their
|
|
company's PDS and can join social protocol communities with zero
|
|
friction. Social protocol communities naturally need verification for
|
|
contracts and votes.
|
|
- **Edge cases compound:** The institutional regression suite feeds every
|
|
deployed instance. The social protocol's contract volume generates
|
|
real-world edge cases that make the suite more valuable for
|
|
institutional certification.
|
|
- **Identity converges:** Institutional gate attestations and social
|
|
protocol reputation both anchor to the same DID. Over time the
|
|
distinction between "corporate verified identity" and "community
|
|
reputation" blurs — they are the same cryptographic graph.
|
|
|
|
**Correlation not causation:** Institutional Phase 2 (regulator encode)
|
|
tends to occur somewhere in the Social Phase 2-3 range, because a
|
|
regulator needs visible evidence that verifiable computing works in
|
|
practice before encoding a rule. But this is correlation, not causation
|
|
— a forward-leaning regulator could encode early (social Phase 1) or a
|
|
conservative one could hold out until social Phase 4. The social network
|
|
does not cause the regulator to act; it provides the proof of concept
|
|
that lowers the regulator's political risk.
|
|
|
|
**Comparison at a glance:**
|
|
|
|
| Dimension | Institutional | Social |
|
|
|-----------+----------------+-------------|
|
|
| First customer | CISO, compliance buyer | HOA president, club leader, creator |
|
|
| First revenue | $2-12M (year one) | $20-100K (year one) |
|
|
| Time to $10M ARR | 6-18 months | 2-4 years |
|
|
| Startup cost | Low (revenue-funded) | Low (fees fund growth) |
|
|
| Marketing cost | Sales team + compliance | Community + product-led |
|
|
| Key skill | Enterprise sales | Consumer product + platform design |
|
|
| Moat type | Regulatory + insurance | Installed base + attestation history |
|
|
| Moat durability | Good (legal) | Strong (practical) |
|
|
| Entry vectors | One (compliance pain) | Four (publishing, payments, contracts, identity) |
|
|
| Failure mode | Wrong pricing, too early | Any vector stalls — but all four must |
|
|
|
|
See also: [[id:92ccd074-04a0-4e45-a44f-9da24ea20a9b][Impact]] — social, cultural, political, scientific, geopolitical, and technological consequences of broad adoption,
|
|
and [[id:72db9428-d6e4-472d-9693-49335f888e48][Game theory]] — why the dynamics are structural, not just plausible.
|
|
|
|
* References
|
|
|
|
- [[id:8c7b9812-f8d6-4347-8915-ce8e520b7914][Social protocol entry strategy]] — tactical go-to-market for community
|
|
onboarding
|
|
- [[id:ed05cab4-88e9-4e25-b7c9-346fa39c69a0][Revenue]] — detailed revenue streams by phase and stream
|
|
- [[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][Development timeline]] — Phase Zero vs End State lines-of-code estimates
|
|
- [[id:aa6d062e-a520-5d14-8773-00687ed9c689][Moats]] — competitive barriers
|
|
- [[id:827bc546-e887-5b7c-9b65-6392beaf0920][Verification monopoly]] — evaluation harness and certification |