gbrain: sync converted org-mode brain files
This commit is contained in:
Hermes
@@ -37,21 +37,25 @@
|
||||
"10289e64-a4ff-4c34-828f-f3a9c769b73d": "projects/passepartout/social-protocol/requirements-00-readme.org",
|
||||
"efc76898-03f7-57ba-923d-35d65da88bb7": "projects/passepartout/strategy/sufficiency-flip.org",
|
||||
"1d074690-a279-59cb-b91d-e9a22ae104ad": "projects/passepartout/strategy/social-protocol-overview.org",
|
||||
"57f9538a-6270-4302-8d07-d742168419eb": "projects/passepartout/strategy/social-growth-strategy.org",
|
||||
"e4f5a6b7-c8d9-0123-4ef0-123456789012": "projects/passepartout/strategy/phase-4-impact.org",
|
||||
"6d2e3f4a-5b6c-7d8e-9f0a-1b2c3d4e5f6a": "projects/passepartout/strategy/adoption.org",
|
||||
"d3e4f5a6-b7c8-9012-3def-012345678901": "projects/passepartout/strategy/phase-3-impact.org",
|
||||
"72db9428-d6e4-472d-9693-49335f888e48": "projects/passepartout/strategy/game-theory.org",
|
||||
"d84679f1-c0c5-5be4-b19c-6573560640ee": "projects/passepartout/strategy/verified-skill-marketplace.org",
|
||||
"9af13fff-9725-542b-93b1-a555bc74ad72": "projects/passepartout/strategy/lisp-economics.org",
|
||||
"5f55bbe6-d243-5766-8ccf-5c5cc88a6542": "projects/passepartout/strategy/ai-industry-impact.org",
|
||||
"528a0f6c-6fd6-41ed-9d59-237958bdaef2": "projects/passepartout/strategy/effects-growth-flywheel.org",
|
||||
"b1c2d3e4-f5a6-7890-1bcd-ef0123456789": "projects/passepartout/strategy/phase-1-impact.org",
|
||||
"2e390c1d-65f3-5fb3-b898-ac3fc4291ee7": "projects/passepartout/strategy/social-protocol-usernames.org",
|
||||
"5961e469-53a3-5f3c-ab72-3c83ef91963f": "projects/passepartout/strategy/investment-thesis.org",
|
||||
"a0b1c2d3-e4f5-6789-0abc-def012345678": "projects/passepartout/strategy/phase-0-impact.org",
|
||||
"67faf52f-9126-50a7-b87e-2bedc610dac7": "projects/passepartout/strategy/licensing.org",
|
||||
"64708e1f-00e9-4cb7-b44b-ea0b98e5296d": "projects/passepartout/strategy/social-protocol-contracts.org",
|
||||
"9c3d4e5f-6a7b-8c9d-0e1f-2a3b4c5d6e7f": "projects/passepartout/strategy/_index.org",
|
||||
"92ccd074-04a0-4e45-a44f-9da24ea20a9b": "projects/passepartout/strategy/impact.org",
|
||||
"aa6d062e-a520-5d14-8773-00687ed9c689": "projects/passepartout/strategy/moats.org",
|
||||
"29e4dbf3-cf19-589c-8b14-389e8a39d564": "projects/passepartout/strategy/upgrade-lifecycle.org",
|
||||
"8c7b9812-f8d6-4347-8915-ce8e520b7914": "projects/passepartout/strategy/social-protocol-entry-strategy.org",
|
||||
"827bc546-e887-5b7c-9b65-6392beaf0920": "projects/passepartout/strategy/verification-monopoly.org",
|
||||
"d28adac8-08a1-40c4-ae43-b5d8d7b1743f": "projects/passepartout/strategy/enterprise-growth-strategy.org",
|
||||
"c2d3e4f5-a6b7-8901-2cde-f01234567890": "projects/passepartout/strategy/phase-2-impact.org",
|
||||
"ed05cab4-88e9-4e25-b7c9-346fa39c69a0": "projects/passepartout/strategy/revenue.org",
|
||||
"dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70": "projects/passepartout/strategy/time-estimates.org",
|
||||
"84a537b4-4256-50c8-91f5-dd5b4538418f": "projects/passepartout/strategy/verification-appliance.org",
|
||||
|
||||
@@ -45,6 +45,8 @@ The knowledge subsystem maintains two indices over the Org prose:
|
||||
|
||||
The prose is always ground truth. Both indices are derived views that can be rebuilt from scratch. Nothing is lost in the indices that was not already in the Org files.
|
||||
|
||||
The same principle extends beyond prose to structured data. Empirical parameters, validity envelopes, provenance chains, and benchmark results live in Org as property drawers and tables — the same format the user reads and edits. The system maintains a derived representation — the provenance store — optimized for machine queries: filter by confidence interval, find all models valid for a given input class, trace a parameter to its experimental source. Like the two indices, the provenance store is a derived view rebuilt from Org, not a separate system with its own canonical copy. Nothing is lost in the store that was not already in the Org files. And when the system learns something new — a validated parameter, a benchmark result — it writes back to the Org files, keeping the human layer current.
|
||||
|
||||
This is what sovereignty means in technical terms: the user owns the data in a format they can access, and the system operates on the data in the same format they own. The format is stable — Org-mode has been in active development since 2003. There is no schema migration, no database upgrade, no vendor lock-in. Your notes survive the system.
|
||||
|
||||
**The verification subsystem: the gate.**
|
||||
|
||||
@@ -28,6 +28,7 @@ The conventional stack spans every layer:
|
||||
| Application | XSS, SQLi, RCE, dependency chain attacks, supply chain |
|
||||
| User | phishing, social engineering, credential theft |
|
||||
| LLM (if present) | jailbreaks, prompt injection (unbounded space), data leakage in outputs, probabilistic unreliability |
|
||||
| Empirical provenance | No systematic model validity checking. Parameters lack provenance, validity envelopes absent, neural networks treated as black boxes with no distribution match |
|
||||
|
||||
**Key property:** Every layer is independent and untrusted. No layer can vouch
|
||||
for any other. Security is *empirical* — "no bugs found in this release" — not
|
||||
|
||||
@@ -24,6 +24,7 @@ Communication becomes provable - when you choose it to be.*
|
||||
- Pseudonymous Personas for deniable identity
|
||||
- Relays as transient routers (pub/sub model, no long-term storage)
|
||||
- Onion routing between PDSs for metadata masking
|
||||
- **Provenance store seeds:** signed data exchange for empirical parameters. When instances share a validated force field parameter or benchmark result, the message carries the experimental source signature and validation history. The receiving instance stores it with provenance — the first structured empirical data in the knowledge store
|
||||
|
||||
## What is eliminated
|
||||
|
||||
|
||||
@@ -22,6 +22,8 @@ Capability-based authorization. "Root" as an attack target no longer exists.*
|
||||
- Does the action violate any system invariant?
|
||||
- Decision procedure formalized in ACL2, machine-checked
|
||||
- Gate runs as a decision layer on the conventional host (Stage 0 [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][hardware]])
|
||||
- **Provenance store becomes operational infrastructure:** a structured data extension of the Knowledge subsystem storing empirical parameters, validity envelopes, and benchmark results with full provenance chains
|
||||
- **Validity envelope predicates as gate vectors:** the gate checks not only security policy but also scientific validity — is this model valid in this context? Are the parameters within their validated range? Does the input fall within the model's training distribution?
|
||||
|
||||
## What is eliminated
|
||||
|
||||
|
||||
@@ -33,6 +33,10 @@ user interface into one address space:
|
||||
compatibility layer inside CL image → native CL implementations.
|
||||
- **Minibuffer:** universal command surface — edit files, navigate web,
|
||||
run Lisp expressions, invoke agent commands.
|
||||
- **Provenance store becomes native Lisp hash table with persistence.**
|
||||
The symbolic engine queries it directly — no IPC, no file parsing at runtime.
|
||||
Empirical parameters, validity envelopes, and benchmark data live in the same
|
||||
address space as the evaluator and gate
|
||||
|
||||
### Phase B — Cannibalization (3-5 years)
|
||||
|
||||
|
||||
@@ -23,6 +23,7 @@ during generation. No external API, no separate trust domain.*
|
||||
tagged Lisp object pointing to flat binary)
|
||||
- Deterministic inference: same input, same output, same hash — auditable
|
||||
and replayable
|
||||
- **Distribution match check runs at evaluation loop speed:** the gate's validity predicate for neural network models becomes a fast native function — compute distance to training distribution and compare against threshold in the same process, no IPC
|
||||
|
||||
*Two neural components on the same substrate:* Stage 4 hosts the LLM for
|
||||
generative reasoning and action proposals. The LeCun-type world model (sensory
|
||||
|
||||
@@ -1,8 +1,42 @@
|
||||
:PROPERTIES:
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: 9c3d4e5f-6a7b-8c9d-0e1f-2a3b4c5d6e7f
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:END:
|
||||
#+title: Strategy
|
||||
#+filetags: :index:
|
||||
|
||||
Business strategy, competitive analysis, compliance landscape, and market positioning for the verified infrastructure category.
|
||||
Business strategy, competitive analysis, compliance landscape, and market positioning.
|
||||
|
||||
- [[id:6d2e3f4a-5b6c-7d8e-9f0a-1b2c3d4e5f6a][Adoption]] — the unified adoption and growth document. Two separate adoptions (social and institutional), each with own phases, flywheel, and dynamics
|
||||
- [[id:92ccd074-04a0-4e45-a44f-9da24ea20a9b][Impact]] — overview of social, cultural, political, economic, scientific, and geopolitical consequences
|
||||
- [[id:a0b1c2d3-e4f5-6789-0abc-def012345678][Phase 0]] — 10-10² users. First compliance savings, first communities, nothing breaks.
|
||||
- [[id:b1c2d3e4-f5a6-7890-1bcd-ef0123456789][Phase 1]] — 10²-10⁴ users. Refugees, creators, first unbundling signals.
|
||||
- [[id:c2d3e4f5-a6b7-8901-2cde-f01234567890][Phase 2]] — 10⁴-10⁶ users. Insurance wedge, contract marketplace, mutual pools.
|
||||
- [[id:d3e4f5a6-b7c8-9012-3def-012345678901][Phase 3]] — 10⁶-10⁸ users. Cybersecurity/ad collapse, institution crossover, financial disruption.
|
||||
- [[id:e4f5a6b7-c8d9-0123-4ef0-123456789012][Phase 4]] — 10⁸-10⁹ users. Two-tier equilibrium, full financial transformation.
|
||||
- [[id:72db9428-d6e4-472d-9693-49335f888e48][Game Theory]] — strategic analysis, Nash equilibria, and failure modes
|
||||
- [[id:ed05cab4-88e9-4e25-b7c9-346fa39c69a0][Revenue]] — detailed revenue streams by phase, subsystem, and first-mover window
|
||||
- [[id:aa6d062e-a520-5d14-8773-00687ed9c689][Moats]] — competitive barriers and infrastructure lock-in
|
||||
- [[id:827bc546-e887-5b7c-9b65-6392beaf0920][Evaluation Harness]] — collective regression suite as certification monopoly
|
||||
- [[id:67faf52f-9126-50a7-b87e-2bedc610dac7][Licensing and Patents]] — AGPL strategy and patent approach
|
||||
- [[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][Development Timeline]] — Phase Zero vs End State estimates
|
||||
- [[id:efc76898-03f7-57ba-923d-35d65da88bb7][Sufficiency Flip]] — per-domain autonomy from LLM dependency
|
||||
- [[id:8c7b9812-f8d6-4347-8915-ce8e520b7914][Social Protocol Entry Strategy]] — tactical go-to-market for community onboarding
|
||||
- [[id:64708e1f-00e9-4cb7-b44b-ea0b98e5296d][Smart Contracts and Contract Marketplace]] — SCAL, escrow, arbitration
|
||||
- [[id:c3b6b7a6-8d9e-4f5a-b6c7-d8e9f0a1b2c3][Compute Marketplace]] — verified compute exchange
|
||||
- [[id:1a2b38df-20ba-58ca-ba55-a072be67bd0d][Personal Data Store]] — PDS hosting service
|
||||
- [[id:2e390c1d-65f3-5fb3-b898-ac3fc4291ee7][Premium Username Registry]] — namespace economics
|
||||
- [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Verification Appliance]] — hardware appliance
|
||||
- [[id:0b5a8a74-cfd6-542d-bc88-4eb3cd8626f9][Lisp Economics]] — zero marginal cost argument
|
||||
- [[id:5f55bbe6-d243-5766-8ccf-5c5cc88a6542][AI Industry Impact]] — effect on GPU demand and AI market
|
||||
- [[id:ef1d6a2b-3c4d-5e6f-7a8b-9c0d1e2f3a4b][Upgrade Lifecycle]] — distribution and migration
|
||||
- [[id:3b4c5d6e-7f8a-9b0c-1d2e-3f4a5b6c7d8e][Outbound Sales Strategy]] — legal and compliance sales framework
|
||||
- [[id:45ea493b-94ad-5885-aa65-0c846e5c3c1d][Verified Skill Marketplace]] — certified skill marketplace
|
||||
- [[id:1bc22b89-d3eb-4f6d-bcfc-2b0c19c8ed8f][Competitive Analysis]] — competitor landscape
|
||||
- [[id:5a6b7c8d-9e0f-1a2b-3c4d-5e6f7a8b9c0d][AI Agent Landscape]] — scoping of AI coding agents
|
||||
- [[id:e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c][Compliance Index]] — all regulated frameworks by region and priority
|
||||
- [[id:c34940cc-090e-57c4-8020-e78b1d32b96c][Domain Gate Packages]] — gate rule encoding for compliance domains
|
||||
- [[id:84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f][Compliance Framework Mapping]] — mapping gate architecture to each regulation
|
||||
|
||||
See the [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Architecture]] page for how the subsystems compose, and the
|
||||
[[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][Development Timeline]] for when each component ships.
|
||||
|
||||
178
projects/passepartout/strategy/adoption.org
Normal file
178
projects/passepartout/strategy/adoption.org
Normal file
@@ -0,0 +1,178 @@
|
||||
: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
|
||||
@@ -2,7 +2,7 @@
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: 5f55bbe6-d243-5766-8ccf-5c5cc88a6542
|
||||
:END:
|
||||
#+title: Impact on the AI and GPU Industry
|
||||
#+title: AI Industry Impact
|
||||
#+filetags: :passepartout:economics:industry:ai:gpu:nvidia:
|
||||
|
||||
If a symbolic-bootstrapping architecture becomes popular, the industry structure shifts fundamentally:
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: 0d4e5f6a-7b8c-9d0e-1f2a-3b4c5d6e7f8a
|
||||
:END:
|
||||
#+title: Passepartout — Competitive Analysis
|
||||
#+title: Competitive Analysis
|
||||
#+filetags: :index:
|
||||
|
||||
Competitive analysis of AI coding agents, verification platforms, and the broader infrastructure landscape.
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
:ID: competitive-landscape-agora
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: Passepartout Social Protocol Competitive Landscape
|
||||
#+title: Social Protocol Competitive Landscape
|
||||
#+filetags: :passepartout:social-protocol:competitive:strategy:landscape:
|
||||
|
||||
The social protocol is a decentralized social operating system that replaces the entire centralized internet platform stack: every function that currently runs on Facebook, Twitter, Instagram, YouTube, TikTok, Reddit, Medium, Substack, OnlyFans, Pornhub, WhatsApp, Signal, Telegram, Discord, LinkedIn, eBay, Etsy, GitHub, DocuSign, Stripe, and Google/Apple ID — all through one unified identity, one data model (the Note), one communication protocol (DIDComm), one payment rail (Lightning), and one contract layer (SCAL).
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:UPDATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: Compliance Framework Mapping — Global Regulated Industries
|
||||
#+title: Compliance Framework Mapping
|
||||
#+filetags: :passepartout:triad:compliance:global:index:
|
||||
|
||||
This file has been split into atomic framework notes under [[id:1c4c91ec-c465-44ab-bd91-4c3b45909ddb][compliance/]].
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:UPDATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: Compliance Framework Index — Global Regulated Industries
|
||||
#+title: Compliance Index
|
||||
#+filetags: :passepartout:triad:compliance:global:index:hub:
|
||||
|
||||
The [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]] and domain gate package [[id:ed05cab4-88e9-4e25-b7c9-346fa39c69a0][revenue streams]] depend on
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
:ID: c34940cc-090e-57c4-8020-e78b1d32b96c
|
||||
:ID: 45ea493b-94ad-5885-aa65-0c846e5c3c1d
|
||||
:END:
|
||||
#+title: Domain Gate Packages — Encoding and Products
|
||||
#+title: Domain Gate Packages
|
||||
#+filetags: :passepartout:revenue:gate-rules:compliance:subscription:encoding:llm:translation:
|
||||
|
||||
* Encoding — How Rules Are Translated from Codified Domains
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: 3c6b0449-a8fb-5b89-b82a-34efb21ef5b5
|
||||
:END:
|
||||
#+title: Social Protocol Compute Marketplace
|
||||
#+title: Compute Marketplace
|
||||
#+filetags: :passepartout:social-protocol:revenue:compute:marketplace:
|
||||
|
||||
[[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] instances offer their symbolic engine capacity (ACL2 cycles, Screamer constraint solving, VivaceGraph queries) to other agents on the [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][social protocol]] network.
|
||||
|
||||
@@ -1,95 +0,0 @@
|
||||
:PROPERTIES:
|
||||
:ID: 528a0f6c-6fd6-41ed-9d59-237958bdaef2
|
||||
:ID: effects-growth-flywheel
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: Effects–Growth Flywheel — How Adoption and Consequences Amplify Each Other
|
||||
#+filetags: :passepartout:strategy:growth:effects:flywheel:
|
||||
|
||||
The [[id:b9fa4b7b-bc61-4d7f-918d-ff687b80f2ba][effects page]] and the [[id:d28adac8-08a1-40c4-ae43-b5d8d7b1743f][growth page]] treated two sides of the same process as separate timelines. They are not sequential — effects do not wait for adoption to finish, and adoption does not happen before effects begin. They are interleaved at every scale. Each effect is a growth driver; each growth milestone unlocks new effects.
|
||||
|
||||
The key insight: /every systemic effect is a growth engine for the next phase/. There is no phase where effects passively happen while adoption independently proceeds.
|
||||
|
||||
* The Flywheel, Not the Pipeline
|
||||
|
||||
The old model (sequential, linear):
|
||||
|
||||
Growth Phase 0 → Effects Phase 0 → Growth Phase 1 → Effects Phase 1 → ...
|
||||
|
||||
The real model (interleaved, amplifying):
|
||||
|
||||
Enterprise sale → compliance cost drops → more enterprises buy → compliance industry margin erodes → price drops further → small businesses afford gate rules → regulator notices → regulation-as-code → enterprises /must/ buy → ...
|
||||
|
||||
At every scale, the effect /is/ the growth mechanism. There is no waiting for effects to "arrive" after adoption reaches a threshold. The first enterprise that saves $500K on an audit has already triggered the compliance erosion effect — at scale 10⁶, that same effect is a structural industry shift, but it is the same mechanism operating at different magnitudes.
|
||||
|
||||
* Effect–Growth Map at Each Scale
|
||||
|
||||
** Phase 0 (0 → 10² instances, weeks–months)
|
||||
|
||||
| Instance count | Effect that starts | Growth driver generated |
|
||||
|---------------+-------------------+------------------------|
|
||||
| 1–10 | /Scientific reproducibility:/ the first verified paper | Universities buy [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] for their compute clusters |
|
||||
| 1–10 | /Compliance erosion:/ first enterprise replaces audit with gate rule | Competitors must match the cost savings — enterprise sales accelerate |
|
||||
| 10–50 | /Verification API gateway:/ first company runs LLM calls through Passepartout | /Any/ company using LLMs is a customer, not just triad adopters. This effect starts at 10 instances but can scale to millions of API users before growth Phase 1 |
|
||||
|
||||
Key observation: the verified API gateway decouples the effect from triad adoption. A company using the gateway never installs Passepartout — they send API calls to a proxy and get back a proof log. The gateway is an /effect/ that drives /economic growth/ (revenue) without requiring /ecosystem growth/ (instances).
|
||||
|
||||
** Phase 1 (10² → 10⁴ instances, months–years)
|
||||
|
||||
| Instance count | Effect that starts | Growth driver generated |
|
||||
|-------+-------------------+------------------------|
|
||||
| 100–500 | /Regulation as code:/ first regulator encodes a rule as a gate | All regulated entities under that regulator must adopt Passepartout — step function in demand |
|
||||
| 500–2K | /AI safety shift:/ gate rule verification becomes expected in enterprise AI procurement | Every company buying AI services requires a proof log — API gateway demand explodes |
|
||||
| 2K–10K | /Proof library compounding:/ the [[id:a5d59d12-b23e-58d6-a81b-9b8b06556949][collective regression suite]] has enough edge cases to be qualitatively better than any solo library | Competitive advantage for adopters — those not on the network fall behind on verification coverage |
|
||||
|
||||
Key observation: regulation-as-code creates a /step function/ in demand. Before the regulator acts, growth is organic enterprise sales. After, it is mandatory compliance. The timing of the first regulatory encode is the single most leveraged event in the flywheel.
|
||||
|
||||
** Phase 2 (10⁴ → 10⁶ instances, years)
|
||||
|
||||
| Instance count | Effect that starts | Growth driver generated |
|
||||
|-------+-------------------+------------------------|
|
||||
| 10K–50K | /Computational trust:/ PDS model makes surveillance advertising visibly obsolete | Consumer demand for PDS — "why does my bank still own my data?" |
|
||||
| 50K–200K | /Verification cachet:/ /I verify/ becomes a resume signal | Developer adoption accelerates — not from enterprise mandate but from peer pressure and cultural norm |
|
||||
| 200K–1M | /Attestation marketplace:/ verifiable reputation has enough data to be reliable | Insurance products become viable — insurers price unverified code higher |
|
||||
|
||||
Key observation: the shift from enterprise adoption to consumer adoption is cultural, not technical. The technology works at 10K instances. But consumers don't adopt because the tech works — they adopt because the /alternative is socially unacceptable/. The verification cachet effect /is/ the consumer growth engine.
|
||||
|
||||
** Phase 3 (10⁶ → 10⁹ instances, years–generations)
|
||||
|
||||
| Instance count | Effect that starts | Growth driver generated |
|
||||
|-------+-------------------+------------------------|
|
||||
| 1M–10M | /Insurance loop closes:/ premiums for unverified code are 10× verified | Economic necessity drives adoption — not engineering preference, not regulation, but /cost of doing business/ |
|
||||
| 10M–100M | /[[id:827bc546-e887-5b7c-9b65-6392beaf0920][Verification monopoly]]:/ regulator references the early player's gate library | New entrants cannot compete with the installed proof base — the moat compounds with every new instance |
|
||||
| 100M–1B | /Compute as geopolitical asset:/ nations run Passepartout instances for digital sovereignty | Nation-state procurement — 100M to 1B happens via government mandate, not organic adoption |
|
||||
|
||||
Key observation: the insurance loop is the /completion of the flywheel/. At this point, adoption is no longer driven by Passepartout's features or benefits — it is driven by the /cost of non-adoption/. The flywheel transitions from pull (people want verification) to push (people cannot afford to be unverified).
|
||||
|
||||
* The Critical Path
|
||||
|
||||
The flywheel has two critical bottlenecks:
|
||||
|
||||
1. /First regulator encodes a rule as a gate./ This is the most leveraged event in Phase 0–1. It converts growth from organic to mandatory in a single domain. Whoever reaches a regulator first — and helps them write that first gate rule — wins that domain permanently.
|
||||
|
||||
2. /First insurer prices unverified code higher./ This is the Phase 2→3 transition. It converts growth from pull to push. The insurer does not need 1B instances to act — they need 10K instances with 2+ years of verifiable track records. The [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]] provides the actuarial data; the [[id:64708e1f-00e9-4cb7-b44b-ea0b98e5296d][attestation marketplace]] provides the reputation layer.
|
||||
|
||||
* Summary: Effects and Growth Are the Same Curve
|
||||
|
||||
| Adoption (instances) | Dominant effect | Growth mechanism |
|
||||
|---------------------+----------------+------------------|
|
||||
| 0 → 10² | Compliance cost drops | Enterprise sales — the effect /is/ the value proposition |
|
||||
| 10² → 10⁴ | Regulation becomes executable | Mandate — one regulator converts pull to push in a domain |
|
||||
| 10² → 10⁴ | AI safety shifts to engineering | Verified API gateway sells to /any/ LLM user, decoupled from Passepartout adoption |
|
||||
| 10⁴ → 10⁶ | Trust shifts from institutional to computational | Consumer adoption — cultural norm, not technical requirement |
|
||||
| 10⁶ → 10⁹ | Cost of non-verification exceeds cost of adoption | Insurance + regulation lock-in — economic necessity, not preference |
|
||||
|
||||
Each row's effect /is/ the growth driver for the next row's instance count. The flywheel is the product. Passepartout is the architecture. [[id:827bc546-e887-5b7c-9b65-6392beaf0920][The verification monopoly]] is the steady state.
|
||||
|
||||
* References
|
||||
|
||||
- [[id:b9fa4b7b-bc61-4d7f-918d-ff687b80f2ba][Systemic effects over time]]
|
||||
- [[id:d28adac8-08a1-40c4-ae43-b5d8d7b1743f][Growth phases — zero to billions]]
|
||||
- [[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][Development timeline]]
|
||||
- [[id:ed05cab4-88e9-4e25-b7c9-346fa39c69a0][Revenue per phase]]
|
||||
- [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][Compute marketplace]]
|
||||
- [[id:64708e1f-00e9-4cb7-b44b-ea0b98e5296d][Attestation and insurance]]
|
||||
- [[id:827bc546-e887-5b7c-9b65-6392beaf0920][Verification monopoly]]
|
||||
@@ -1,201 +0,0 @@
|
||||
:PROPERTIES:
|
||||
:ID: d28adac8-08a1-40c4-ae43-b5d8d7b1743f
|
||||
:ID: growth-strategy
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: Growth — Two Engines, One Infrastructure
|
||||
#+filetags: :passepartout:growth:network:strategy:social-protocol:
|
||||
|
||||
Passepartout has two independent growth engines that share the same infrastructure. The verification subsystem grows top-down through enterprise compliance sales — capital-efficient, revenue from day one. [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][The social protocol]] (the social network) grows bottom-up through community adoption — network-effect-powered, zero customer acquisition cost per user. Each engine would be incomplete alone. Together they form the full stack: verification funds the build, the network provides the users, and at every crossover point they make each other more valuable.
|
||||
|
||||
This page defines the combined growth strategy across four phases, with each engine advancing in parallel and reinforcing the other at specific transitions.
|
||||
|
||||
* The Two Engines
|
||||
|
||||
/Verification subsystem (top-down, revenue-funded):/
|
||||
- Customer: CISO, compliance buyer
|
||||
- Growth lever: Enterprise sales + gate rule library compounding
|
||||
- Revenue: $2-12M/year by month 12
|
||||
- Failure mode: Wrong pricing, too early for market
|
||||
- Entry: Direct enterprise compliance engagements
|
||||
|
||||
/Social protocol (bottom-up, community-driven):/
|
||||
- Customer: Organized communities, creators, developers
|
||||
- Growth lever: Multi-vector network effects (identity, publishing, payments, contracts, governance)
|
||||
- Revenue: Transaction fees, PDS hosting, marketplace commissions
|
||||
- Failure mode: Never reaches critical mass on any vector
|
||||
- Entry: Organized community onboarding pilot groups, then expand
|
||||
|
||||
* Phase 0: Bootstrapping (0 → 100 instances, 0 → 10K social protocol users, 3-12 months)
|
||||
|
||||
** Verification Engine
|
||||
|
||||
*Customer:* Enterprise compliance teams. Clear buyer (CISO), existing budget, pain that maps directly to gate rules.
|
||||
|
||||
*Growth lever:* Enterprise sales + direct integration. No network effects yet — value must be real without anyone else using it.
|
||||
|
||||
*Tactics:*
|
||||
1. Ship [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] MVP — verifies code, applies gate rules, produces compliance report.
|
||||
2. First sale encodes a regulation as gate rules, verifies the customer's deployment.
|
||||
3. Each engagement funds the next. Gate rule library grows with every customer.
|
||||
4. The [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]] bootstraps with one provider (you) selling verification to smaller instances.
|
||||
|
||||
*Revenue:* $2-12M from enterprise compliance engagements. Funds the team and the social protocol build.
|
||||
|
||||
** Social Protocol Engine
|
||||
|
||||
*Customer:* Organized communities — HOAs, clubs, cooperatives, PTAs, volunteer orgs, religious groups — any group that currently uses 3+ separate tools and has a leader who can onboard them.
|
||||
|
||||
*Growth lever:* Group density solves the cold start. The community exists before the platform. Onboard one HOA of 200 families, get 200 users at once.
|
||||
|
||||
*Tactics:*
|
||||
1. Identify 5-10 pilot communities via warm intros or personal networks.
|
||||
2. Each gets a white-glove onboarding: admin sets up their Collective Persona, invites members via share link.
|
||||
3. Members arrive to find a complete community space: announcement feed, group chat, task board, treasury, voting.
|
||||
4. The first real use case (budget vote, dues collection, contractor hire) is the killer demo.
|
||||
5. Ship identity + content + contracts + payments + governance. The bundle must work from day one for organized communities — they need all five layers.
|
||||
|
||||
*Revenue:* Minimal in Phase 0 ($20-100K in transaction fees). The goal is product-market fit with a specific community type, not revenue.
|
||||
|
||||
*Key metric for crossover:* Community retention at 90 days. If a community is still using the social protocol for its core operations after 90 days, the bundle has stickiness.
|
||||
|
||||
*Phase 0 crossover:* The first enterprise compliance customer needs employee identities. Their PDS deployment seeds social protocol identities for the compliance team. This is accidental — the enterprise's employees get DIDs as a side effect of their company buying verification. The protocol gets its first non-community users for free.
|
||||
|
||||
** Combined Summary
|
||||
|
||||
| Dimension | Verification | Social Protocol |
|
||||
|-----------+-------+-------|
|
||||
| Customer | CISO, compliance buyer | HOA president, club leader |
|
||||
| Entry | Cold sales | Warm intro to pilot communities |
|
||||
| Revenue | $2-12M | $20-100K |
|
||||
| Key metric | Instances deployed | Communities active at 90 days |
|
||||
| Failure mode | Wrong pricing, too early | No community finds PMF |
|
||||
| Build priority | Passepartout MVP | Note primitive, PDS, SCAL basics |
|
||||
|
||||
* Phase 1: Dual Growth (100 → 10K instances, 10K → 100K social protocol users, 12-24 months)
|
||||
|
||||
** Verification Engine
|
||||
|
||||
*Customer:* Two-sided — enterprise compliance (continuing Phase 0) plus individual developers adopting Passepartout through AGPL.
|
||||
|
||||
*Growth lever:* Open-source adoption + platform economics. The gate rule SDK lets developers create and sell their own gate rules.
|
||||
|
||||
*Tactics:*
|
||||
1. Gate rule SDK launch — developers encode compliance domains as products.
|
||||
2. Proof library compounding — every new instance contributes edge cases.
|
||||
3. Attestation marketplace — track record of correct verifications carries weight.
|
||||
4. Social protocol identities as employee benefit — every enterprise PDS includes DIDs for all employees.
|
||||
|
||||
*Revenue:* $10-50M. Verification appliances, marketplace fees, social protocol username registrations.
|
||||
|
||||
*Key metric:* Third-party gate rules published. Active developer count.
|
||||
|
||||
** Social Protocol Engine
|
||||
|
||||
*Customer:* Community refugees (banned subreddits, nuked Discord servers) + creators (OnlyFans/Patreon refugees who want to own their audience).
|
||||
|
||||
*Growth lever:* Crisis-driven migration + creator-led audience migration.
|
||||
|
||||
*Tactics:*
|
||||
1. Monitor deplatforming events. When a subreddit of 10K+ users gets banned, offer a ready-made social protocol community space within 24 hours.
|
||||
2. Ship creator tools: LSAT for paywalled content, Lightning subscriptions, Blind CDN for video distribution.
|
||||
3. The Phase 0 pilot communities now have members who need to hire each other. Freelance contracts emerge organically.
|
||||
4. Every enterprise PDS deployment from the verification subsystem includes employee DIDs. Those employees can join social protocol communities with zero friction.
|
||||
|
||||
*Revenue:* $1-5M. Transaction fees from contracts, LSAT subscriptions, PDS hosting.
|
||||
|
||||
*Key metric:* Communities onboarded. Paying subscribers. Contract volume.
|
||||
|
||||
** Phase 1 Crossover
|
||||
|
||||
This is the critical reinforcement point:
|
||||
|
||||
- Enterprise employees already have social protocol DIDs (from their company's PDS). They can join social protocol communities with one click — no registration, no password, no onboarding friction.
|
||||
- Social protocol communities naturally need verification. An HOA's contractor hire should be verified. A community's vote results should be provable. The verification engine built for enterprises is now useful for communities.
|
||||
- The compute marketplace now has two demand sources: enterprise verification (production workloads) and community verification (contract executions, attestation requests).
|
||||
|
||||
*Phase 1 crossover metric:* Percentage of social protocol transactions that use verification. Target: 10%+ by end of Phase 1.
|
||||
|
||||
* Phase 2: Convergence (10K → 1M instances, 100K → 10M social protocol users, 2-5 years)
|
||||
|
||||
** Verification Engine
|
||||
|
||||
*Customer:* Enterprise compliance (continuing) + verification marketplace (scaling) + insurance industry.
|
||||
|
||||
*Growth lever:* Environment subsystem premium enterprise features + insurance marketplace.
|
||||
|
||||
*Tactics:*
|
||||
1. [[id:c3b3dc41-945f-54e9-84eb-ca014114f1be][Environment subsystem]] premium ships SSO, compliance dashboards, fleet management.
|
||||
2. Insurance marketplace forms — actuaries price proof insurance based on track records of 10K+ instances.
|
||||
3. [[id:827bc546-e887-5b7c-9b65-6392beaf0920][Verification monopoly]] begins — the gate library is the largest, most cited, most battle-tested.
|
||||
|
||||
*Revenue:* $50-200M. Environment subsystem enterprise seats, verification appliances, insurance premiums.
|
||||
|
||||
** Social Protocol Engine
|
||||
|
||||
*Customer:* Freelancers, gig workers, small businesses. The organized communities from Phase 0-1 now have enough history that their reputation graph carries real weight.
|
||||
|
||||
*Growth lever:* Professional network effects. A freelancer's contract history on the social protocol is portable proof of reliability.
|
||||
|
||||
*Tactics:*
|
||||
1. Freelancer marketplace emerges organically — communities that already use contracts start hiring across communities.
|
||||
2. The Algorithm Marketplace creates differentiation — users choose their feed curation logic.
|
||||
3. Social protocol identities hit 1M. The namespace has real scarcity. Premium username auctions produce significant revenue.
|
||||
4. Enterprise adoption of the social protocol happens because employees already have DIDs. Companies start using social protocol spaces for internal collaboration.
|
||||
|
||||
*Revenue:* $20-100M. Transaction fees, PDS hosting, marketplace commissions, username renewals.
|
||||
|
||||
** Phase 2 Crossover
|
||||
|
||||
The two engines begin to merge:
|
||||
|
||||
- Verification is no longer an enterprise-only product. It is a network service consumed by every social protocol transaction.
|
||||
- The social protocol's reputation graph becomes the best source of verification track records. Actuaries price insurance based on DID history. The insurance products that the verification subsystem enables are /powered by/ social protocol data.
|
||||
- Enterprise employees use the same DID for compliance work and community participation. The boundary between "work identity" and "personal identity" is a Persona toggle — same infrastructure, different roles.
|
||||
|
||||
*Phase 2 crossover metric:* Percentage of verification requests that originate from social protocol transactions. Target: 50%+ by end of Phase 2.
|
||||
|
||||
* Phase 3: Infrastructure (1M → 10M+ instances, 10M → 1B+ social protocol users, 5-15 years)
|
||||
|
||||
** Both Engines
|
||||
|
||||
At this scale, the distinction between verification and the social protocol becomes meaningless. Verification is the compute layer. The social protocol is the application layer. They are the same infrastructure:
|
||||
|
||||
- /Verification monopoly:/ The gate library is the most comprehensive proof library ever assembled. Regulators reference it. Insurers require it.
|
||||
- /Default identity:/ The social protocol DID is the default identity for internet users. New services offer social protocol login because users demand it.
|
||||
- /Insurance lock-in:/ Insurers price unverified code out of existence. The cost of /not/ verifying exceeds the cost of adopting Passepartout.
|
||||
- /Nation-state adoption:/ Countries run their own Passepartout instances for digital sovereignty. The compute marketplace is a sovereign asset.
|
||||
- /Installed base moat:/ A new entrant cannot replicate 10+ years of attestation history, 1B+ identities, and millions of verified contracts.
|
||||
|
||||
*Revenue:* $1B+. Certification monopoly revenue, infrastructure rent, marketplace fees, insurance underwriting, PDS hosting at global scale.
|
||||
|
||||
* The Combined Curve
|
||||
|
||||
| Phase | Verification scale | Social Protocol scale | Revenue | Crossover | Failure mode |
|
||||
|-------+-------------+-------------+---------+-----------+--------------|
|
||||
| 0 | 0→100 instances | 0→10K users | $2-12M | Enterprise PDS seeds first DIDs | Either engine stalls |
|
||||
| 1 | 100→10K inst | 10K→100K users | $11-55M | Employees join communities; communities need verification | Verification: developer UX. Social protocol: no vector reaches PMF |
|
||||
| 2 | 10K→1M inst | 100K→10M users | $70-300M | Most verification serves social protocol; most social protocol data feeds verification | Verification: scaling compute. Social protocol: UX polish gap |
|
||||
| 3 | 1M→10M+ inst | 10M→1B+ users | $1B+ | The layers are unified | Technology paradigm shift |
|
||||
|
||||
* Why This Works Together
|
||||
|
||||
Organized communities are the entry point that forces the social protocol to ship the full bundle from day one. An HOA using the social protocol for announcements, dues, contracts, and voting demonstrates the complete vision No marketing message can compete with a community member seeing their dues collected and a roof contract executed through one platform.
|
||||
|
||||
Enterprise compliance funds the build. A Phase 0 CISO engagement brings in $500K-2M, enough to pay a small team for a year. The same team ships the social protocol Note primitive, PDS, and SCAL. The enterprise revenue buys time for the community adoption to find PMF.
|
||||
|
||||
The crossover is automatic. Enterprise employees get DIDs from their company's PDS. They join social protocol communities because the DID works everywhere. Communities need verification for their contracts and votes. The verification engine is already running. The two engines were never separate — they were always the same infrastructure, just adopted by different users at different times.
|
||||
|
||||
* References
|
||||
|
||||
- [[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][Development timeline]]
|
||||
- [[id:ed05cab4-88e9-4e25-b7c9-346fa39c69a0][Revenue streams]]
|
||||
- [[id:5961e469-53a3-5f3c-ab72-3c83ef91963f][Investment thesis]]
|
||||
- [[id:57f9538a-6270-4302-8d07-d742168419eb][Social-first alternative (now integrated)]]
|
||||
- [[id:8c7b9812-f8d6-4347-8915-ce8e520b7914][Entry strategy — organized communities]]
|
||||
- [[id:1bc22b89-d3eb-4f6d-bcfc-2b0c19c8ed8f][Social protocol competitive landscape]]
|
||||
- [[id:b9fa4b7b-bc61-4d7f-918d-ff687b80f2ba][Systemic effects]]
|
||||
- [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][Compute marketplace]]
|
||||
- [[id:827bc546-e887-5b7c-9b65-6392beaf0920][Verification monopoly]]
|
||||
- [[id:64708e1f-00e9-4cb7-b44b-ea0b98e5296d][Social protocol contracts]]
|
||||
- The [[id:0f949f6c-4cf1-49eb-b9a4-ebcac27ee548][Social protocol Social Space requirements]] define how organized communities interact through the gate stack. See also Social Protocol Specification — full requirements (spec repo at /tmp/agora)
|
||||
755
projects/passepartout/strategy/game-theory.org
Normal file
755
projects/passepartout/strategy/game-theory.org
Normal file
@@ -0,0 +1,755 @@
|
||||
:PROPERTIES:
|
||||
:ID: 72db9428-d6e4-472d-9693-49335f888e48
|
||||
:CREATED: [2026-05-25 Mon]
|
||||
:END:
|
||||
#+title: Game Theory
|
||||
#+filetags: :passepartout:strategy:adoption:game-theory:
|
||||
|
||||
Why the adoption trajectory is structural, not just plausible. This
|
||||
document models the key strategic interactions as formal games with
|
||||
payoff matrices and Nash equilibria. Phase numbers refer to the
|
||||
[[id:6d2e3f4a-5b6c-7d8e-9f0a-1b2c3d4e5f6a][Adoption]] document.
|
||||
|
||||
The central claim: the trajectory toward verified computing is the unique
|
||||
stable equilibrium of a multi-player game, not one of several possible
|
||||
outcomes. This document models the five core games — enterprise adoption,
|
||||
regulator commitment, hyperscaler defense, social protocol platform
|
||||
competition, and geopolitical competition between nation states — and
|
||||
shows that each has a unique Nash equilibrium that
|
||||
reinforces the others.
|
||||
|
||||
* Game 1: Enterprise Adoption (coordination with network effects)
|
||||
|
||||
Two firms in a regulated industry choose whether to adopt a gate or
|
||||
maintain their current compliance process. Their payoffs depend on what
|
||||
the other firm does and on the regulator's stance (set independently in
|
||||
Game 2).
|
||||
|
||||
**Strategy sets:** {Adopt Gate, Maintain Current Audit}
|
||||
|
||||
**Payoff parameters:**
|
||||
|
||||
Let:
|
||||
- C = annual compliance cost under current audit ($200K-$1M)
|
||||
- G = annual gate subscription cost ($50K)
|
||||
- R = risk of audit failure (probability × penalty, ~$500K/yr expected)
|
||||
- D = competitive disadvantage if rival adopts gate and you don't (productivity gap, estimated 2-5% of compliance-adjacent revenue)
|
||||
- N = network effect benefit if both adopt (shared gate rules, interoperable proofs, collective regression suite)
|
||||
|
||||
All values are per-firm per-year.
|
||||
|
||||
**Payoff matrix (firm A row, firm B column):**
|
||||
|
||||
| | B adopts gate | B maintains audit |
|
||||
|---|---|---|
|
||||
| A adopts gate | (-G + N, -G + N) | (-G, -D) |
|
||||
| A maintains audit | (-D, -G) | (-C - R, -C - R) |
|
||||
|
||||
**Nash equilibria:**
|
||||
|
||||
1. Both adopt gate is a Nash equilibrium if G - N < C + R. Since G ≈ $50K,
|
||||
C ≈ $200K-$1M, R ≈ $500K, and N is positive, this inequality holds
|
||||
strongly — adopting the gate strictly dominates maintaining the audit
|
||||
when both firms adopt.
|
||||
|
||||
2. Both maintain audit is also a Nash equilibrium if D < C + R - G. If
|
||||
the competitive disadvantage of being the only non-adopter is small,
|
||||
both firms can get stuck in the current audit even though adoption
|
||||
would make both better off. This is a classic coordination failure.
|
||||
|
||||
**What breaks the coordination failure:**
|
||||
|
||||
The two equilibria exist because each firm's payoff from adopting
|
||||
depends on the other firm's choice. But the game changes when:
|
||||
|
||||
- **The regulator encodes a rule as a gate.** This removes the audit
|
||||
option for both firms — adoption becomes mandatory. The game collapses
|
||||
to a single outcome.
|
||||
- **Insurance differentiates on verification.** The compliance cost C
|
||||
becomes C + I (insurance premium surcharge for unverified), where I
|
||||
can be 2-10x of C. This pushes D < C + R + I - G even for the first
|
||||
adopter, making unilateral adoption dominant.
|
||||
- **One firm has a large enough D that they adopt unilaterally.** If
|
||||
the competitive disadvantage of being the only non-adopter exceeds the
|
||||
adoption cost, the first firm switches, and the second firm follows
|
||||
because -G + N > -D. This is how the flywheel starts.
|
||||
|
||||
**Key insight:** The coordination failure exists only in the absence of
|
||||
regulatory mandate or insurance differentiation. Both of these are
|
||||
themselves equilibrium outcomes of separate games (Game 2 and Game 3
|
||||
interaction). The enterprise adoption game does not create a structural
|
||||
barrier — it creates a timing problem that the other games resolve.
|
||||
|
||||
* Game 2: Regulator Commitment
|
||||
|
||||
A regulator chooses how to enforce a rule. An industry of N firms has
|
||||
already chosen their adoption status (partly determined by Game 1).
|
||||
|
||||
**Strategy sets:**
|
||||
- Regulator: {Encode as gate, Maintain paper-based enforcement}
|
||||
- Fate chooses the political environment: {Pro-gate, Anti-gate}
|
||||
|
||||
**Payoff parameters:**
|
||||
|
||||
Let:
|
||||
- E = enforcement effectiveness (paper: 0.3, gate: 0.95 on a 0-1 scale)
|
||||
- L = legitimacy cost of choosing the "wrong" approach (0 if aligned with
|
||||
political environment, k > 0 if misaligned)
|
||||
- T = political turnover risk (probability that the next administration
|
||||
reverses the decision)
|
||||
- B = benefit to regulator of career-defining legacy (gate: +M, paper: 0)
|
||||
- S = surveillance-value loss to the state when data becomes invisible to
|
||||
bulk collection (paper: 0, gate: -S, where S varies by regime type)
|
||||
|
||||
**Regulator's payoff function:**
|
||||
|
||||
U(gate) = αE + βB - γL(gate|environment) - δT - εS
|
||||
U(paper) = αE(paper) - γL(paper|environment) + δT(paper)
|
||||
|
||||
Where α, β, γ, δ, ε are the regulator's preference weights.
|
||||
|
||||
**Key parameter: S (surveillance-value loss)**
|
||||
|
||||
For a democratic regulator in an EU-style system, S ≈ 0 or small — bulk
|
||||
surveillance is constrained by law. The gate's privacy properties are a
|
||||
feature, not a cost. The regulator's choice depends primarily on E, B,
|
||||
and L.
|
||||
|
||||
For an authoritarian regulator, S is large. The gate makes their
|
||||
regulated entities invisible to bulk collection. Even with high E and B,
|
||||
the payoff may be negative. The regulator's dominant strategy is to
|
||||
maintain paper enforcement or ban gates.
|
||||
|
||||
**Nash equilibria by regulator type:**
|
||||
|
||||
1. **Democratic/pro-rule-of-law regulator:** U(gate) > U(paper) when
|
||||
α(E_gate - E_paper) + βB > γ(L_gate - L_paper) + δ(T_gate - T_paper).
|
||||
Since E_gate >> E_paper, B > 0, and S ≈ 0, the gate dominates for
|
||||
any reasonable parameter range. Unique equilibrium: encode gate.
|
||||
|
||||
2. **Authoritarian/high-surveillance regulator:** U(gate) may be
|
||||
negative if εS > α(E_gate - E_paper) + βB. Unique equilibrium:
|
||||
maintain paper or ban gates.
|
||||
|
||||
3. **Captured regulator:** If incumbents (Game 3) successfully lobby,
|
||||
γ(L_gate|pro-incumbent) can be made large. The equilibrium depends on
|
||||
whether the capture is stronger than the enforcement benefit.
|
||||
|
||||
**How Game 1 and Game 2 interact:**
|
||||
|
||||
If Game 1 reaches "both adopt gate" without the regulator, the
|
||||
regulator's payoff from encoding increases further — there is now proven
|
||||
infrastructure, lowering L and T. This makes encoding more attractive
|
||||
even for a borderline regulator.
|
||||
|
||||
If Game 1 is stuck in coordination failure (both maintain), the
|
||||
regulator can break it by encoding — this is the most leveraged
|
||||
intervention. A forward-leaning regulator who encodes early creates the
|
||||
condition for Game 1 to tip.
|
||||
|
||||
**What changes the equilibrium:**
|
||||
|
||||
- A high-profile AI harm event increases B and decreases L for the
|
||||
regulator choosing gate (the public demands action).
|
||||
- An incumbent lobbying campaign increases γ(L_gate) if the regulator
|
||||
is vulnerable to capture.
|
||||
- A regime change can flip S from 0 to large or vice versa.
|
||||
|
||||
* Game 3: Hyperscaler Defense
|
||||
|
||||
An incumbent hyperscaler (AWS, Azure, GCP) chooses how to respond to the
|
||||
gate architecture. Enterprise adoption level a ∈ [0,1] is a parameter.
|
||||
|
||||
**Strategy sets:**
|
||||
- Hyperscaler: {Fight, Accommodate, Co-opt}
|
||||
- Fight: lobby against gate standards, bundle a fake "verified" wrapper,
|
||||
use procurement lock-in to deter adoption
|
||||
- Accommodate: support gate instances on their infrastructure, capture
|
||||
revenue from the compute that gate instances need
|
||||
- Co-opt: acquire or clone the gate provider, offer gate-as-a-service
|
||||
on their terms
|
||||
|
||||
**Payoff parameters:**
|
||||
|
||||
Let:
|
||||
- R_h = hyperscaler's annual revenue from the enterprise segment that
|
||||
gates target ($B+ per hyperscaler in regulated markets)
|
||||
- S_h = share of R_h that depends on unrestricted data access
|
||||
(surveillance advertising, training data extraction, platform lock-in)
|
||||
- P_h = cost of fighting (lobbying spend, engineering cost of fake
|
||||
wrapper, reputation damage if exposed)
|
||||
- A_h = revenue from accommodating (compute for gate instances, storage
|
||||
for proof logs — lower margin but insulated from competition)
|
||||
- C_h = cost of co-opting (acquisition price or clone engineering cost)
|
||||
|
||||
**Hyperscaler's payoff by strategy and adoption level a:**
|
||||
|
||||
| Strategy | a < 0.1 (Phase 0-1) | a > 0.1 (Phase 2+) |
|
||||
|----------+---------------------+---------------------|
|
||||
| Fight | -P_h + (1-k)R_h (preserves most revenue but spends on lobbying) | -P_h + (1-k')R_h (lobbying less effective; revenue erosion accelerates) |
|
||||
| Accommodate | A_h × a (small but growing revenue from gate compute) | A_h × a + residual non-gate R_h (gate revenue grows, non-gate revenue declines) |
|
||||
| Co-opt | -C_h + R_h (full control but high cost) | -C_h + R_h (but harder to execute — gate ecosystem has network effects) |
|
||||
|
||||
Where k, k' are revenue erosion rates from gate adoption (k < k').
|
||||
|
||||
**Nash equilibria:**
|
||||
|
||||
1. **At low adoption (a < 0.1):** Fight dominates if -P_h + (1-k)R_h >
|
||||
A_h × a and -P_h + (1-k)R_h > -C_h + R_h. The hyperscaler tolerates
|
||||
the lobbying cost because it preserves most of their business model.
|
||||
This is the equilibrium in Phases 0-1.
|
||||
|
||||
2. **At high adoption (a > 0.1):** If the gate ecosystem has enough
|
||||
momentum that A_h × a + residual > fight payoff, and co-opt is
|
||||
infeasible (network effects of the open regression suite, AGPL
|
||||
license, community), then Accommodate becomes dominant. The
|
||||
hyperscaler accepts the two-tier outcome and captures what they can
|
||||
from gate compute.
|
||||
|
||||
3. **Co-opt is only dominant if C_h < P_h + kR_h — the hyperscaler must
|
||||
believe they can acquire the gate provider cheaper than fighting or
|
||||
losing revenue. The AGPL license and the open nature of the
|
||||
regression suite make co-opt difficult (you can buy the code but you
|
||||
can't buy the community).
|
||||
|
||||
**Key insight:** The hyperscaler's optimal strategy changes with
|
||||
adoption level. At low adoption they fight because the cost is low and
|
||||
the revenue preservation is high. At a threshold adoption level, the
|
||||
fight becomes more expensive than accommodation. This threshold is
|
||||
determined by S_h — the share of revenue dependent on unrestricted data
|
||||
access. A hyperscaler with high S_h (Google, whose advertising business
|
||||
depends on data) will fight harder and longer than a hyperscaler with
|
||||
lower S_h (AWS, whose revenue is more infrastructure-based).
|
||||
|
||||
**What changes the equilibrium:**
|
||||
|
||||
- A high S_h means the fight threshold is higher — the hyperscaler
|
||||
tolerates more revenue erosion before accommodating.
|
||||
- AGPL license and community ownership raise C_h (cost of co-opting)
|
||||
and lower the probability of co-opt succeeding.
|
||||
- If adoption jumps suddenly (regulator encode in Game 2), the
|
||||
hyperscaler may skip the fight phase entirely and move directly to
|
||||
accommodation.
|
||||
|
||||
* Game 4: Social Protocol Platform Competition
|
||||
|
||||
The social protocol does not compete with any single platform. It offers
|
||||
an alternative to the entire paradigm of centralized internet services —
|
||||
a single protocol that replaces 20+ products across social graph,
|
||||
publishing, video, messaging, e-commerce, payments, contracts, identity,
|
||||
code hosting, collaboration, and freelancing. See the [[id:1bc22b89-d3eb-4f6d-bcfc-2b0c19c8ed8f][Social Protocol
|
||||
Competitive Landscape]] for the full platform map.
|
||||
|
||||
**Why this is a different kind of game:**
|
||||
|
||||
Unlike the institutional games (binary adopt/don't-adopt decisions by
|
||||
firms), the social game is a multi-front platform competition where:
|
||||
|
||||
1. The protocol competes against 20+ incumbents simultaneously, each with
|
||||
its own network effects and switching costs.
|
||||
2. No single incumbent can copy the bundle — Meta cannot offer portable
|
||||
identity (it destroys their surveillance model), Google cannot offer
|
||||
private messaging (it destroys their ad model), Stripe cannot offer
|
||||
contracts and social, DocuSign cannot offer payments.
|
||||
3. The protocol's value proposition is not "Twitter but better" — it is
|
||||
"one account replaces every platform you use."
|
||||
4. Users do not switch all at once. They join for one use case and
|
||||
discover the rest. This is a sequential expansion game.
|
||||
|
||||
**The entry vector game entry choice:**
|
||||
|
||||
The protocol must choose which use case to lead with. Each candidate has
|
||||
different payoff parameters:
|
||||
|
||||
| Entry vector | Cold start | ARPU | Bundle necessity | Competitive response | Failure mode |
|
||||
|-------------+------------+------+-----------------+---------------------+--------------|
|
||||
| Organized communities (HOAs, clubs, PTAs) | Solved (groups exist as units) | Low ($20-100K fees) | Full | Negligible (no incumbent targets this segment) | No community finds PMF |
|
||||
| Community refugees (banned subreddits, nuked discords) | Solved (arrive together) | Low-medium | Partial | Medium (Reddit/Discord defensive) | Migrations don't stick |
|
||||
| Creators (OnlyFans, Patreon, adult content) | High (individual migration) | High ($1-5M fees) | Partial (identity + content + payments) | High (OnlyFans, Stripe, payment processors) | Creator acquisition cost too high |
|
||||
| Freelancers (Upwork, Fiverr) | Low (scattered, no density) | Medium | Full (contracts + payments + reputation) | Low (Upwork network effects weak) | No dispute resolution trust |
|
||||
| Developers (GitHub) | High (open-source communities exist) | Low | Partial (code + identity) | Very high (Microsoft/GitHub moat) | Developer habit inertia |
|
||||
|
||||
**The entry vector game payoff matrix (protocol chooses primary vector,
|
||||
fate chooses incumbent response strength):**
|
||||
|
||||
Let:
|
||||
- U_x = users acquired through vector x at Phase 0
|
||||
- C_x = engineering cost to ship the features vector x requires
|
||||
- R_x = revenue from vector x users
|
||||
- I_x = incumbent response strength (0 = none, 1 = existential fight)
|
||||
- S_x = stickiness (probability user stays for other capabilities after
|
||||
joining for vector x)
|
||||
|
||||
Expected protocol payoff for choosing vector x:
|
||||
P(x) = U_x × (R_x + S_x × future_value_of_expansion) - C_x - D_x
|
||||
|
||||
Where D_x is damage from incumbent response (lobbying, FUD, feature
|
||||
parity, price cuts) weighted by I_x.
|
||||
|
||||
**Nash equilibria by entry vector:**
|
||||
|
||||
1. **Organized communities (Phase 0):** I_x ≈ 0 (no existing platform
|
||||
serves this segment well). U_x is bounded but guaranteed (groups
|
||||
exist). S_x is high (full bundle forces exposure to all capabilities).
|
||||
Unique equilibrium: this is the dominant entry strategy.
|
||||
|
||||
2. **Creators (Phase 0 parallel):** I_x is high (OnlyFans, Stripe,
|
||||
payment processors have incentive to block). But R_x is also high
|
||||
(highest ARPU). U_x is unpredictable (depends on creator acquisition
|
||||
cost). Multiple equilibria: high-I/low-U leads to "do not enter,"
|
||||
low-I/high-U leads to "enter." The outcome depends on whether payment
|
||||
discrimination against adult content is acute enough to overcome
|
||||
switching friction.
|
||||
|
||||
3. **Freelancers (Phase 2):** I_x is low (Upwork's network effects are
|
||||
weak — both sides multi-home). But S_x requires the reputation graph
|
||||
from Phase 0-1 to exist first. This is a sequential game — the
|
||||
payoff from enter in Phase 2 depends on having entered Phase 0-1
|
||||
successfully.
|
||||
|
||||
**The asymmetric bundle advantage:**
|
||||
|
||||
The protocol's structural advantage is that it competes with 20+
|
||||
incumbents, but no incumbent competes with the protocol. Each incumbent
|
||||
faces a different threat:
|
||||
|
||||
| Incumbent | Threat level | Can adapt? | Adaptation would require |
|
||||
|-----------+-------------+------------+--------------------------|
|
||||
| Meta (Facebook, Instagram) | Existential | No | Abandon surveillance advertising and portable user data — their entire business model |
|
||||
| Google (YouTube, Gmail, Google Docs) | High | No | Abandon data mining for ads — their entire business model |
|
||||
| Microsoft (GitHub, LinkedIn, Office) | Moderate | Partial | Accept decentralized identity — but Windows/Office lock-in is different from data mining |
|
||||
| Twitter/X | Medium | No | Algorithmic feed is their product — giving up curation control destroys their ad model |
|
||||
| Stripe | Low | No | Cannot offer social, contracts, and identity — outside their competence |
|
||||
| Discord | Medium | Possible | Can add more features but cannot offer portable identity or zero-fee payments |
|
||||
| Substack/Medium | Medium | Possible | Can improve creator tools but cannot match zero-fee + censorship resistance |
|
||||
| OnlyFans/Patreon | Low | No | Payment discrimination is structural (banking regulations) — not a choice they can undo |
|
||||
| DocuSign | Low | No | Contracts + payments + social is outside their competence |
|
||||
| Reddit | Low | Possible | Decentralized moderation would destroy their ad business |
|
||||
|
||||
Key insight: of the 20+ incumbents, most (Meta, Google, Twitter, Stripe,
|
||||
DocuSign) cannot adapt because adaptation requires abandoning their
|
||||
business model. A few (Discord, Substack, Reddit) can make marginal
|
||||
improvements but cannot match the bundle because they don't control the
|
||||
other layers. Zero incumbents can match the full protocol.
|
||||
|
||||
**Geopolitical dimension: free speech and association infrastructure:**
|
||||
|
||||
The social protocol is not just a consumer product. Its architecture
|
||||
makes it naturally censorship-resistant and surveillance-resistant:
|
||||
|
||||
- Speech on the protocol cannot be removed by any government because
|
||||
there is no central server to issue takedown orders to. Each user
|
||||
controls their own PDS; content is addressed by CID, not hosted on
|
||||
a platform URL.
|
||||
- Association on the protocol cannot be surveilled because the relay
|
||||
network routes by DID, not IP. The state can see that a message was
|
||||
sent but cannot determine who sent it to whom without controlling
|
||||
the entire relay graph.
|
||||
- Organisation on the protocol cannot be disrupted because Collective
|
||||
Personas exist cryptographically — there is no office to raid and
|
||||
no server to seize.
|
||||
|
||||
This makes the protocol a direct geopolitical tool. For citizens in
|
||||
restrictive regimes (China, Russia, Iran, Belarus, Myanmar, Eritrea,
|
||||
and dozens of others), the protocol offers the first infrastructure
|
||||
that enables free speech and association that their government cannot
|
||||
control, surveil, or shut down.
|
||||
|
||||
This changes the entry vector analysis:
|
||||
|
||||
| Entry vector | Previously framed as | Geopolitical frame adds |
|
||||
|-------------+---------------------+------------------------|
|
||||
| Community refugees | Banned subreddits, nuked discords | Political dissidents, exiled journalists, banned NGOs — users fleeing state censorship, not just platform moderation |
|
||||
| Creators | OnlyFans/Patreon refugees | Journalists and writers under threat in authoritarian regimes — their incentive is not just revenue but survival |
|
||||
| Organized communities | HOAs, clubs, PTAs | Exile communities, diaspora groups, cross-border activist networks — users with an organizational structure that cannot exist on any centralized platform |
|
||||
|
||||
The geopolitical entry vectors have different payoff parameters than
|
||||
the consumer ones. Their cold start is solved not by group density but
|
||||
by necessity (the alternative is censorship or imprisonment). Their
|
||||
stickiness S_x is near-maximal because the protocol is not a convenience
|
||||
but a lifeline. Their ARPU may be low but their **strategic value** is
|
||||
high — a single dissident community successfully using the protocol
|
||||
demonstrates censorship resistance to millions.
|
||||
|
||||
**How this changes Game 5 (geopolitical competition):**
|
||||
|
||||
The legitimacy cost L_i for a state that bans the protocol was modeled
|
||||
in Game 5 as a general cost. But the social protocol's free speech
|
||||
dimension makes L_i much larger than a standard trade restriction:
|
||||
|
||||
- A state that bans the protocol is not just blocking a technology — it
|
||||
is telling its citizens "we are afraid of you speaking freely."
|
||||
- The protocol makes the ban visibly ineffective — citizens who can
|
||||
access the relay network retain their speech. The state either
|
||||
accepts visible defiance or invests in internet shutdowns, both of
|
||||
which carry high legitimacy costs.
|
||||
- The protocol's verification layer means that a banned instance can
|
||||
still *prove* it is operating correctly. A state that claims to have
|
||||
shut down gates cannot fake compliance.
|
||||
|
||||
This creates a new dynamic in Game 5: states that ban the protocol face
|
||||
a legitimacy cost that grows with the protocol's adoption in free-world
|
||||
jurisdictions. The more citizens in free countries use the protocol, the
|
||||
more citizens in restricted countries know what they are missing, and
|
||||
the higher the legitimacy cost of the ban.
|
||||
|
||||
**The interaction between Game 4 (social) and Game 5 (geopolitical):**
|
||||
|
||||
| Direction | Effect |
|
||||
|-----------+--------|
|
||||
| Game 4 → Game 5 | Social protocol adoption in free-world jurisdictions increases L_i for restrictive states (citizens in restrictive regimes see what they're missing; free-world users amplify dissident content). |
|
||||
| Game 4 ← Game 5 | A restrictive stance in Game 5 (China bans gates, Russia blocks relays) makes the social protocol's censorship resistance the *only* option for citizens in those countries, accelerating adoption as a human rights tool. |
|
||||
| Game 4 → Game 2 | Social protocol's demonstrated censorship resistance gives democratic regulators evidence that verification is compatible with free speech, lowering their L(gate|political) in Game 2. |
|
||||
|
||||
The net effect: the social protocol's geopolitical dimension does not
|
||||
just make it more resilient — it creates a positive feedback loop with
|
||||
the geopolitical game that no purely consumer platform can generate.
|
||||
|
||||
**Tech industry alignment: natural allies:**
|
||||
|
||||
The protocol creates winners and losers in the tech industry. Companies
|
||||
whose business model depends on surveillance advertising (Meta, Google,
|
||||
Twitter/X, TikTok) are structural losers — the protocol's verification
|
||||
layer blocks their data extraction. But companies whose business model
|
||||
is compatible with or enhanced by verification are structural winners.
|
||||
These companies have an incentive to embrace the protocol as a
|
||||
competitive weapon against their surveillance-dependent rivals.
|
||||
|
||||
| Company | Business model | Gate compatibility | Incentive to embrace | What they gain |
|
||||
|---------+---------------+-------------------+---------------------+----------------|
|
||||
| Apple | Hardware (iPhone, Mac) + services (iCloud, App Store) | High — privacy is their brand, Secure Enclave is already a proto-gate | Strong — verification structurally disadvantages Meta and Google, Apple's main competitors in services and AR | New hardware differentiation ("the verified iPhone"), new services (iCloud PDS, gate appliance), brand reinforcement |
|
||||
| Microsoft | Enterprise software (Office, Azure) + OS (Windows) | Medium — Azure can host gates, but Windows telemetry conflicts | Moderate — enterprise clients want verification, but Windows surveillance revenue is small | Azure differentiation for regulated industries, Office integration with gate proofs |
|
||||
| Cloudflare | Edge infrastructure (CDN, DNS, security) | High — already privacy-forward, Workers platform could host gate logic | Strong — gate-compatible edge services are a new product category | New revenue from gate relay and verification edge services |
|
||||
| Samsung | Hardware (phones, TVs, appliances) | Medium — Android allows gate installation, Knox security platform | Moderate — can differentiate Galaxy as "gate-compatible Android" | Hardware differentiation, B2B enterprise sales |
|
||||
| IBM | Enterprise services + consulting | High — compliance is their core market | Strong — gate rule consulting is a natural service line | New consulting practice, mainframe integration |
|
||||
| Amazon/AWS | Cloud infrastructure + advertising + retail | Mixed — AWS can host gates, but Amazon advertising depends on data | Conflicted — AWS division may embrace, advertising division fights | AWS can capture gate compute revenue but loses advertising data access |
|
||||
|
||||
**The Apple scenario as a case study:**
|
||||
|
||||
Apple's incentive to embrace the protocol is the strongest of any major
|
||||
tech company because:
|
||||
|
||||
1. Apple's revenue does not depend on surveillance — 80%+ comes from
|
||||
hardware and services that work identically with or without data
|
||||
extraction. The protocol's privacy properties cost Apple nothing.
|
||||
2. Apple's brand is built on privacy ("what happens on your iPhone
|
||||
stays on your iPhone"). Integrating a DID-based identity system and
|
||||
gate-compatible Secure Enclave makes this claim verifiable rather
|
||||
than aspirational.
|
||||
3. Apple's main growth competitors (Meta in AR/VR, Google in services
|
||||
and AI) are structurally threatened by verification. Meta's entire
|
||||
business model collapses if advertising cannot extract user data.
|
||||
Google's AI advantage depends on unrestricted data access. The
|
||||
protocol harms them more than it harms Apple.
|
||||
4. Apple already has the hardware foundation: the Secure Enclave, M-series
|
||||
chips with隔离 zones, and iCloud Keychain are all proto-gate
|
||||
infrastructure. Shipping a gate-compatible iPhone would be a
|
||||
feature update, not a new product.
|
||||
|
||||
Apple's optimal strategy: embed the protocol's DID system into Apple
|
||||
ID, ship gate-compatible hardware in the next iPhone generation,
|
||||
position iCloud as a PDS hosting service, and market the entire stack
|
||||
as "privacy you can prove." This would instantly put gate capability
|
||||
in 1B+ existing devices and create a distribution channel no other
|
||||
protocol project has ever achieved.
|
||||
|
||||
**The strategic consequence for the five games:**
|
||||
|
||||
If a major compatible company (Apple, Cloudflare, or IBM) embraces the
|
||||
protocol:
|
||||
|
||||
- **Game 1 (enterprise adoption):** Apple's endorsement massively lowers
|
||||
G (gate cost) because enterprise buyers already have Apple hardware.
|
||||
The coordination failure breaks faster.
|
||||
- **Game 3 (hyperscaler defense):** A compatible hyperscaler (Cloudflare,
|
||||
Azure) providing gate-compatible infrastructure creates an
|
||||
accommodation path for enterprise users, reducing the fight incentive.
|
||||
- **Game 4 (social protocol):** Apple's distribution gives the social
|
||||
protocol a built-in user base of 1B+ devices. The cold start problem
|
||||
in every entry vector is solved by the installed base.
|
||||
- **Game 5 (geopolitical):** A US-based company (Apple) embracing the
|
||||
protocol makes it harder for the US to restrict it. Apple's
|
||||
lobbying power counterbalances Meta and Google's anti-gate lobbying.
|
||||
|
||||
The protocol does not need any major company to embrace it — the
|
||||
trajectory is viable without them. But if even one does, the timeline
|
||||
shortens from decades to years.
|
||||
|
||||
**Sequential expansion game:**
|
||||
|
||||
The protocol expands through categories sequentially, not simultaneously.
|
||||
Each phase builds the conditions for the next:
|
||||
|
||||
| Phase | Vector | Capabilities shipped | Enables next phase by |
|
||||
|-------+--------+----------------------+-----------------------|
|
||||
| 0 | Organized communities | Full bundle (identity + content + payments + contracts + governance) | Proving the bundle works for real coordination |
|
||||
| 1 | Refugees + creators | LSAT (paywalled content), Lightning subscriptions | Building reputation graph and creator audience |
|
||||
| 2 | Freelancers | SCAL stack, arbitration guilds | Reaching contract marketplace critical mass |
|
||||
| 3 | Institution crossover | Enterprise-grade verification | Leveraging network for institutional products |
|
||||
|
||||
This is not a choice between vectors — it is a sequence where each
|
||||
phase unlocks the next. The protocol can fail at any stage if the
|
||||
current vector never reaches critical mass.
|
||||
|
||||
**How the social game interacts with the institutional games:**
|
||||
|
||||
The social and institutional games are independent in their causal logic
|
||||
but connected through resource flows:
|
||||
|
||||
- **Institutional → Social:** Compliance revenue would accelerate the
|
||||
social protocol's development timeline, but the architecture is
|
||||
self-developing after Stage 2 — the bootstrap loop means engineering
|
||||
does not depend on external funding. Revenue is amplificatory, not
|
||||
necessary.
|
||||
- **Social → Institutional (late stage):** At Phase 3+, the social
|
||||
network's users become the distribution channel for institutional
|
||||
products. Institutional verification tools sell as fulfillment orders
|
||||
to a network that already exists.
|
||||
- **Social → Institutional (ongoing):** Social contract disputes generate
|
||||
real-world edge cases for the collective regression suite, making the
|
||||
certification more valuable for institutional buyers.
|
||||
|
||||
**Asymmetric coupling:** The two sides are largely independent in both
|
||||
directions. Institutional success can exist without social success
|
||||
(compliance sales work with zero social users). Social success can exist
|
||||
without institutional success — the social protocol reaches critical
|
||||
mass through pure platform competition, and its development is not
|
||||
blocked by lack of institutional revenue because the architecture is
|
||||
self-developing after Stage 2 (the agent writes its own code; the
|
||||
bootstrap loop makes engineering self-sustaining). The coupling is
|
||||
amplificatory, not foundational: each side's success makes the other
|
||||
more valuable, but neither depends on the other to survive.
|
||||
|
||||
* Game 5: Geopolitical Competition
|
||||
|
||||
Nation states do not act in isolation. Each regulator's choice (Game 2)
|
||||
is shaped by what other states are doing, creating a strategic game
|
||||
between major geopolitical blocs. This game determines whether the
|
||||
protocol remains unified or fragments into incompatible networks.
|
||||
|
||||
**The players:**
|
||||
|
||||
| Player | Surveillance dependence | Regulatory sophistication | Gate incentive | Key constraint |
|
||||
|--------+------------------------+--------------------------+----------------+----------------|
|
||||
| EU | Low (GDPR limits bulk collection) | High (AI Act, NIS2, eIDAS) | Strong — gates solve enforcement at scale | Must maintain coherence across 27 member states |
|
||||
| US | High (NSA, FBI surveillance apparatus) | Fragmented (sectoral agencies, no unified AI law) | Conflicted — financial regulators want verification, intelligence community wants visibility | Tech incumbents (Meta, Google) lobby against; surveillance state fights gates structurally |
|
||||
| China | Total (social credit system, mass surveillance) | Top-down (state dictates standards) | Negative — gates block surveillance entirely | Would develop state-controlled "verified" alternative with backdoors |
|
||||
| UK | Medium (Investigatory Powers Act) | Medium (emerging AI safety framework) | Positive — post-Brexit wants regulatory leadership | Must balance US alliance with EU regulatory alignment |
|
||||
| India | Medium (growing surveillance infrastructure) | Developing (DPDP Act 2023) | Positive — leapfrog to verification without legacy audit industry | Wants sovereignty; may resist a standard defined by EU or US |
|
||||
|
||||
**Strategy sets:**
|
||||
|
||||
Each state chooses one of:
|
||||
- **Promote:** Encode gate rules, subsidize adoption, advocate as international standard
|
||||
- **Tolerate:** Allow gate instances but don't mandate; let the market decide
|
||||
- **Restrict:** Ban or backdoor gate instances; require state-approved verification
|
||||
- **Compete:** Develop an alternative state-controlled verification standard
|
||||
|
||||
**Payoff parameters for state i:**
|
||||
|
||||
Let:
|
||||
- S_i = surveillance-value loss from gate adoption (0 for EU, high for China)
|
||||
- E_i = enforcement benefit from automated regulatory compliance
|
||||
- T_i = trade dependency on states with incompatible stances
|
||||
- A_i = alliance alignment pressure (cost of diverging from key allies)
|
||||
- L_i = legitimacy gain/loss from gate stance — includes not just public
|
||||
opinion and human rights reputation, but the specific cost of being
|
||||
seen to block free speech and association infrastructure. This
|
||||
parameter grows with the social protocol's adoption in free-world
|
||||
jurisdictions, because each new user in a free country makes the
|
||||
ban's censorship intent more visible to citizens in restricted
|
||||
countries.
|
||||
- K_i = first-mover advantage if state defines the standard (tech industry
|
||||
attracted, standard-setting fees, geopolitical influence)
|
||||
|
||||
**Payoff function:**
|
||||
|
||||
U_i(stance) = αE_i - βS_i(stance) - γT_i(stance) + δA_i(stance) + εL_i + φK_i(stance)
|
||||
|
||||
**Key equilibria by scenario:**
|
||||
|
||||
1. **EU promotes, US tolerates, China restricts — the fragmentation
|
||||
equilibrium.** EU encodes gates as the AI Act enforcement mechanism.
|
||||
US allows gate instances but does not mandate them (compromise between
|
||||
financial regulators wanting verification and intelligence community
|
||||
opposing it). China bans all gate instances that it cannot surveil and
|
||||
develops a backdoored "verified" alternative. Global enterprises
|
||||
operate dual configurations: EU-compliant gate instances for European
|
||||
operations, non-verified for China, mixed for US. The protocol
|
||||
fragments into two tiers: "free world" protocol and "China-controlled"
|
||||
alternative, but the free-world protocol remains functionally unified
|
||||
because the EU and US standards are technically compatible (even if US
|
||||
doesn't mandate enforcement).
|
||||
|
||||
2. **The EU also restricts — the worst case.** If the EU, under pressure
|
||||
from member states with surveillance priorities, mandates data
|
||||
localization or backdoors for gate instances, the protocol's core
|
||||
value proposition (verification cannot be bypassed by the state) is
|
||||
broken. The EU and US would converge on a weakened standard that
|
||||
preserves some surveillance capability, and the protocol loses its
|
||||
structural advantage. This scenario requires a significant shift in
|
||||
EU governance toward surveillance — possible but unlikely given GDPR
|
||||
and current AI Act trajectory.
|
||||
|
||||
3. **EU promotes, US promotes, China isolates — the best case.** The US
|
||||
resolves its internal conflict in favor of financial regulators and AI
|
||||
safety advocates (triggered by a high-profile AI harm event that makes
|
||||
gates politically necessary). US and EU jointly promote gates as the
|
||||
international standard. China isolates itself with an incompatible
|
||||
alternative. Global enterprises standardize on the EU-US protocol.
|
||||
This is the scenario that maximizes the protocol's growth trajectory.
|
||||
|
||||
4. **Cold War standoff — US restricts, EU tolerates.** The US
|
||||
intelligence community wins the internal debate and bans unrestricted
|
||||
gate instances (requiring backdoors for law enforcement). The EU
|
||||
tolerates but does not mandate. The protocol survives in the EU but
|
||||
loses the largest enterprise market (US-based global firms). Growth
|
||||
slows significantly but does not stop — the EU market alone (450M
|
||||
people, major regulated industries) is enough to sustain the
|
||||
trajectory.
|
||||
|
||||
**The race dynamic:**
|
||||
|
||||
The first major jurisdiction to encode gates as a regulatory standard
|
||||
gains first-mover advantage (K_i). The standard they define — rule
|
||||
format, proof requirements, certification process — becomes the
|
||||
default. Late adopters must either adopt the existing standard (ceding
|
||||
some sovereignty) or fragment the market. This creates a race:
|
||||
|
||||
- **EU is best positioned.** AI Act enforcement begins 2026-2027. The EU
|
||||
can encode gate rules as the compliance mechanism for high-risk AI
|
||||
systems. If they do this before the US resolves its internal conflict,
|
||||
the EU defines the standard and the US becomes a standard-taker.
|
||||
- **US could catch up.** A single AI harm event that causes measurable
|
||||
financial damage ($1B+) could shift US political will. If the US then
|
||||
moves faster than the EU through executive action, they could define
|
||||
the standard instead.
|
||||
- **China cannot win the race but can fragment it.** China cannot adopt
|
||||
the protocol without losing surveillance. But they can fund an
|
||||
alternative standard, pay developing countries to adopt it, and create
|
||||
a bifurcated global market.
|
||||
|
||||
**How Game 5 interacts with Games 1-4:**
|
||||
|
||||
- Game 5 determines the parameter S (surveillance-value loss) for each
|
||||
regulator in Game 2. A state that chooses "restrict" in Game 5 has
|
||||
high S in Game 2, shifting the regulator's equilibrium.
|
||||
- Game 5 determines whether enterprises face compatible or incompatible
|
||||
requirements across jurisdictions, which affects their Game 1 payoff
|
||||
(N = network effect benefit is lower if the protocol fragments).
|
||||
- Game 5 outcome affects the hyperscaler's S_h (if gates are legal in
|
||||
the US, AWS can accommodate; if banned, they must fight).
|
||||
- Game 4 (social) is the most resilient to geopolitical fragmentation —
|
||||
individual users can still participate in the protocol regardless of
|
||||
their state's stance, as long as the relay network operates across
|
||||
borders.
|
||||
|
||||
**The stability claim for Game 5:**
|
||||
|
||||
The protocol has a structural defense against geopolitical fragmentation
|
||||
that no previous decentralized technology had: the gate itself.
|
||||
Verification is self-authenticating — a gate instance in a non-EU
|
||||
jurisdiction can still prove compliance with EU gate standards. The
|
||||
protocol does not need states to agree; it only needs each state to
|
||||
allow at least one path for verification to exist. A state that bans
|
||||
gates loses the economic benefits of verification (lower compliance
|
||||
costs, AI safety, efficient contracts) without gaining enforcement
|
||||
capability (because banned gates will exist in other jurisdictions
|
||||
anyway). This creates a ratchet: once verification is adopted by enough
|
||||
economically significant jurisdictions, non-adopting states face a
|
||||
growing competitive disadvantage that eventually exceeds their
|
||||
surveillance benefit.
|
||||
|
||||
* The combined game: why the trajectory is stable
|
||||
|
||||
The five games interact through their parameters:
|
||||
|
||||
1. Game 1 (enterprise adoption) can have two equilibria, but Game 2
|
||||
(regulator commitment) and the insurance loop (Game 3 consequence)
|
||||
both break the coordination failure by changing the dominant strategy
|
||||
for the first mover.
|
||||
|
||||
2. Game 2 (regulator commitment) has a unique equilibrium for
|
||||
democratic regulators: encode gates. The only failure mode is
|
||||
authoritarian suppression or capture, both of which are
|
||||
jurisdiction-specific — they fragment the protocol but don't stop it
|
||||
globally.
|
||||
|
||||
3. Game 3 (hyperscaler defense) has a threshold that depends on
|
||||
adoption level. Since Games 1 and 2 push adoption past that
|
||||
threshold, the hyperscaler's optimal strategy shifts from fight to
|
||||
accommodate. They do not defect back to fight once adoption is high
|
||||
because the sunk cost of fighting has already been incurred and the
|
||||
revenue base has already shifted.
|
||||
|
||||
4. Game 4 (social protocol) is structurally independent of the
|
||||
institutional games — it does not depend on any enterprise outcome.
|
||||
Its trajectory is driven by the asymmetric bundle advantage: 20+
|
||||
incumbents, zero of whom can match the full protocol. The binding
|
||||
constraint is not competition but status quo inertia — the protocol
|
||||
must demonstrate one use case that is dramatically better, then
|
||||
expand from there.
|
||||
|
||||
5. Game 5 (geopolitical competition) determines whether the protocol
|
||||
fragments or remains unified. The default equilibrium is
|
||||
fragmentation between surveillance and rule-of-law blocs, but the
|
||||
free-world protocol remains functionally unified because
|
||||
verification is self-authenticating — states don't need to agree.
|
||||
The ratchet dynamic means non-adopting states face growing
|
||||
competitive disadvantage over time.
|
||||
|
||||
**The stability claim:**
|
||||
|
||||
The only way the trajectory fails is if one of the following parameter
|
||||
conditions holds:
|
||||
|
||||
- **Game 1 parameter failure:** G + N > C + R even with insurance
|
||||
differentiation. This would require gate costs to be higher than
|
||||
compliance savings — unlikely given the 4-20x cost ratio, but
|
||||
possible if the gate implementation is expensive.
|
||||
- **Game 2 parameter failure:** εS > α(E_gate - E_paper) + βB for all
|
||||
major regulators. This requires a coordinated shift toward high-
|
||||
surveillance governance across all regulated markets — possible but
|
||||
requires a global authoritarian turn.
|
||||
- **Game 3 parameter failure:** S_h ≈ 1 and C_h < P_h + kR_h — the
|
||||
hyperscaler both depends entirely on unrestricted data and can
|
||||
successfully co-opt the gate provider before the ecosystem reaches
|
||||
critical mass. The AGPL license and open community are the defense
|
||||
against this.
|
||||
- **Game 4 parameter failure:** every entry vector fails to demonstrate
|
||||
a use case dramatically better than the status quo, OR the social
|
||||
protocol never achieves critical mass in any vector. This is possible
|
||||
if the bundle is too complex for even organized communities (the
|
||||
lowest-friction vector).
|
||||
- **Game 5 parameter failure:** the EU shifts toward surveillance
|
||||
governance, adopting data localization or backdoor mandates for gate
|
||||
instances. This breaks the protocol's core value proposition in its
|
||||
most natural market. This scenario requires a significant shift in EU
|
||||
political trajectory — possible but unlikely given GDPR and current
|
||||
AI Act direction.
|
||||
|
||||
If none of these parameter conditions hold, the unique equilibrium
|
||||
across all five games is: gates win on the institutional side, and the
|
||||
protocol has a viable trajectory on the social side via at least one
|
||||
entry vector. The two sides reinforce each other but do not depend on
|
||||
each other for survival — each can succeed independently, and together
|
||||
they compound.
|
||||
|
||||
* Failure modes as parameter shifts
|
||||
|
||||
The failure modes from the [[id:6d2e3f4a-5b6c-7d8e-9f0a-1b2c3d4e5f6a][Adoption]] document can now be re-expressed as
|
||||
parameter changes:
|
||||
|
||||
- **Agent quality insufficient:** G increases (gate requires too much
|
||||
human correction, raising effective cost). If G + N > C + R, Game 1
|
||||
reaches "both maintain audit" and the regulator's encoding in Game 2
|
||||
becomes less attractive (E_gate drops because gates are unreliable).
|
||||
- **State suppression:** εS dominates for all major regulators. Game 2
|
||||
equilibrium shifts to "maintain paper/ban gates" in significant
|
||||
jurisdictions. Protocol fragments.
|
||||
- **Bootstrap loop stalls:** Same as agent quality — G stays high for
|
||||
too long. Game 1 fails to tip.
|
||||
- **Neither adoption reaches critical mass:** Games 1 and 2 both fail —
|
||||
enterprise adoption stalls at Phase 1 (Game 1 coordination failure
|
||||
unresolved) and social protocol never achieves network effects
|
||||
(different game, not modeled here).
|
||||
37
projects/passepartout/strategy/impact.org
Normal file
37
projects/passepartout/strategy/impact.org
Normal file
@@ -0,0 +1,37 @@
|
||||
:PROPERTIES:
|
||||
:ID: 92ccd074-04a0-4e45-a44f-9da24ea20a9b
|
||||
:CREATED: [2026-05-25 Mon]
|
||||
:END:
|
||||
#+title: Impact
|
||||
#+filetags: :passepartout:strategy:adoption:impact:
|
||||
|
||||
The wider consequences of broad adoption, across both the verification
|
||||
(institutional) and social protocol tracks. Phase numbers below refer
|
||||
to the social adoption phases, defined in
|
||||
[[id:6d2e3f4a-5b6c-7d8e-9f0a-1b2c3d4e5f6a][Adoption]]. Each phase has
|
||||
its own detailed treatment with sector-specific analysis.
|
||||
|
||||
- [[id:a0b1c2d3-e4f5-6789-0abc-def012345678][Phase 0]] — 10-10² users. First enterprise compliance savings, first
|
||||
organized protocol communities, creator migration. Nothing breaks.
|
||||
- [[id:b1c2d3e4-f5a6-7890-1bcd-ef0123456789][Phase 1]] — 10²-10⁴ users. Compliance consultancies lose clients, first
|
||||
regulator encode, community refugees discover censorship resistance,
|
||||
creators keep 95%. First structural unbundling signals.
|
||||
- [[id:c2d3e4f5-a6b7-8901-2cde-f01234567890][Phase 2]] — 10⁴-10⁶ users. Insurance differentiates on verification,
|
||||
contract marketplace reaches critical mass, platform unbundling
|
||||
accelerates. Mutual insurance pools emerge on the social protocol.
|
||||
Economic destruction begins in earnest.
|
||||
- [[id:d3e4f5a6-b7c8-9012-3def-012345678901][Phase 3]] — 10⁶-10⁸ users. Cybersecurity and surveillance advertising
|
||||
collapse for the verified segment. Institution crossover — universities,
|
||||
newsrooms, regulators adopt protocol attestation. The end of the
|
||||
platform era. Financial services face structural disruption: compliance
|
||||
industry collapse, credit bureau obsolescence, accounting profession
|
||||
transformation. Commercial mutual insurance pools form. The protocol
|
||||
becomes human rights infrastructure.
|
||||
- [[id:e4f5a6b7-c8d9-0123-4ef0-123456789012][Phase 4]] — 10⁸-10⁹ users. Two-tier computing is the stable
|
||||
equilibrium. Messaging, websites, and email restructured at the
|
||||
protocol layer. Financial services fully transformed: banks as gate
|
||||
operators, capital markets restructured, payment systems replaced,
|
||||
accounting profession rebuilt around attestation logic. Mutual
|
||||
insurance mature at all scales — social, commercial, and
|
||||
reinsurance pools of pools. The economic center of gravity has
|
||||
moved from intermediation to verification infrastructure.
|
||||
@@ -1,20 +0,0 @@
|
||||
:PROPERTIES:
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: 5961e469-53a3-5f3c-ab72-3c83ef91963f
|
||||
:END:
|
||||
#+title: Investment Thesis
|
||||
#+filetags: :passepartout:economics:investment:thesis:
|
||||
|
||||
The early player benefits from every other instance of Passepartout. Every deployed instance feeds edge cases into the [[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][regression suite]], grows the [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]], and validates the hardware designs. Network effects are positive sum.
|
||||
|
||||
Three revenue horizons:
|
||||
|
||||
- **Low-hanging fruit (year one, $2M-$12M):** [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][verification appliances]], [[id:c34940cc-090e-57c4-8020-e78b1d32b96c][domain gate rule subscriptions]], [[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][evaluation harness certification]], migration services
|
||||
- **Medium-term (1-3 years, $10M-$50M):** [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]], Relay Network, Lisp Machine hardware; [[id:2e390c1d-65f3-5fb3-b898-ac3fc4291ee7][premium usernames]] ($10M/yr), [[id:1a2b38df-20ba-58ca-ba55-a072be67bd0d][PDS hosting]] ($18M/yr)
|
||||
- **Big money (3-10 years, $100M-$1B+):** [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]] (UL certification for AI), [[id:2f783eb4-638e-5afa-9b59-6224d086a712][infrastructure lock-in]], planetary compute marketplace
|
||||
|
||||
The [[id:5f55bbe6-d243-5766-8ccf-5c5cc88a6542][impact on the AI and GPU industry]] — token demand compression, GPU inference plateau, and the rise of CPU-native verification hardware — reshapes the trillion-dollar market these revenue streams depend on.
|
||||
|
||||
The [[id:68ffa49f-f0d8-42cf-8b69-ae69de8bb815][Social protocol governance and physical assets]] requirements cover how the network manages shared infrastructure. The switching costs compound. The [[id:aa6d062e-a520-5d14-8773-00687ed9c689][network effects]] are positive sum. The market is nearly a trillion dollars.
|
||||
|
||||
The defensible entity is "the organization that best understands how to adapt [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] to your domain" — not "the organization that owns Passepartout."
|
||||
@@ -3,7 +3,7 @@
|
||||
:ID: 67faf52f-9126-50a7-b87e-2bedc610dac7
|
||||
:ID: caaeee11-ba6f-5566-aecd-f171b4c459c0
|
||||
:END:
|
||||
#+title: IP Strategy — Licensing + Patents
|
||||
#+title: Licensing and Patents
|
||||
#+filetags: :passepartout:ip:licensing:patents:agpl:commercial:legal:
|
||||
|
||||
**AGPLv3 for the public repository.** AGPL closes the ASP loophole: anyone who modifies the software and offers it over a network must release their modified source. Combined with a patent strategy, this creates [[id:aa6d062e-a520-5d14-8773-00687ed9c689][moats]] against proprietary forks.
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
:ID: 9af13fff-9725-542b-93b1-a555bc74ad72
|
||||
:ID: 0b5a8a74-cfd6-542d-bc88-4eb3cd8626f9
|
||||
:END:
|
||||
#+title: Why Lisp Is Economically Viable Now — Zero Marginal Cost
|
||||
#+title: Lisp Economics
|
||||
#+filetags: :passepartout:economics:lisp:history:C:viability:cost:marginal:zero:
|
||||
|
||||
The 1980s trade-off was: C is cheap enough for the market. Correctness is a luxury the market cannot afford. The 2020s trade-off is: C is expensive for the market. Incorrectness has become the dominant cost of software. Lisp's verification infrastructure is now the cheaper option.
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
:ID: aa6d062e-a520-5d14-8773-00687ed9c689
|
||||
:ID: 2f783eb4-638e-5afa-9b59-6224d086a712
|
||||
:END:
|
||||
#+title: Competitive Barriers — Moats and Infrastructure Lock-in
|
||||
#+title: Moats
|
||||
#+filetags: :passepartout:economics:moats:competition:lock-in:switching:
|
||||
|
||||
Re-evaluated: time is not the primary moat. A Phase 4+ [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] fed on Wikipedia + Wikidata can build a general ontology in two weeks. The organic growth advantage collapses for general knowledge.
|
||||
@@ -11,8 +11,9 @@ Re-evaluated: time is not the primary moat. A Phase 4+ [[id:28c46769-c14b-42aa-a
|
||||
**Actual moats (weaker than initially assumed):**
|
||||
1. **Domain-specific gate rules** — thin. A few hundred lines of Lisp data. Write once, trivial to copy. Not a real moat.
|
||||
2. **Empirical decision history** — every HITL decision is a Merkle fact. A fresh instance has none. Makes *your* instance more valuable but doesn't prevent competition — it's a switching cost, not a barrier to entry.
|
||||
3. **[[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][Evaluation harness (regression suite)]]** — thousands of test cases accumulated from every bug fix. Cannot be ingested from public data. Strongest residual moat.
|
||||
4. **Infrastructure integration** — specific Docker compose layouts, Traefik patterns, Authentik configs encoded as gate rules. A competitor's infrastructure is different.
|
||||
3. **Curated empirical parameter database (provenance store)** — force field parameters, solvation model coefficients, scoring function weights, training dataset descriptors, and validity envelopes accumulated over years of use. Each entry carries a source citation, confidence interval, and validation history. A competitor starting fresh has no curated parameters, no accumulated validation comparisons against experiment, and no community-sourced validity envelopes. This is a data moat that compounds with every deployed instance: each instance contributes new validated parameters and benchmark comparisons to the collective provenance store via the social protocol, making the network's cumulative empirical knowledge increasingly difficult to replicate. See [[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][evaluation harness]] for how the same network effect applies to regression test cases.
|
||||
4. **[[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][Evaluation harness (regression suite)]]** — thousands of test cases accumulated from every bug fix. Cannot be ingested from public data. Strongest residual moat.
|
||||
5. **Infrastructure integration** — specific Docker compose layouts, Traefik patterns, Authentik configs encoded as gate rules. A competitor's infrastructure is different.
|
||||
|
||||
**Strongest competitor strategy:** Not copying your gate rules — offering the same architecture as a service with their own pre-seeded general knowledge and a consulting engagement to customize gate rules. The AGPL prevents closing the architecture but does not prevent offering it as a service with a customization layer.
|
||||
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
:ID: outbound-sales-compliance
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: Outbound Sales — Legal Framework & Compliance Architecture
|
||||
#+title: Outbound Sales Strategy
|
||||
#+filetags: :passepartout:compliance:legal:gdpr:outbound:
|
||||
|
||||
The outbound sales pipeline touches leads across multiple jurisdictions. This page maps the applicable laws, the compliance requirements at each stage of the pipeline, and how [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]]'s gate stack can enforce them mechanically.
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: 1a2b38df-20ba-58ca-ba55-a072be67bd0d
|
||||
:END:
|
||||
#+title: Personal Data Store as a Service
|
||||
#+title: Personal Data Store
|
||||
#+filetags: :passepartout:social-protocol:revenue:pds:saas:
|
||||
|
||||
Classic open-core SaaS model (GitLab, Sentry, PlanetScale). The Merkle fact store exposed on [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][the social protocol]] can be self-hosted (free, AGPL) or hosted by the early player.
|
||||
|
||||
32
projects/passepartout/strategy/phase-0-impact.org
Normal file
32
projects/passepartout/strategy/phase-0-impact.org
Normal file
@@ -0,0 +1,32 @@
|
||||
:PROPERTIES:
|
||||
:ID: a0b1c2d3-e4f5-6789-0abc-def012345678
|
||||
:CREATED: [2026-05-25 Mon]
|
||||
:END:
|
||||
#+title: Phase 0 — Impact
|
||||
#+filetags: :passepartout:strategy:adoption:impact:
|
||||
|
||||
Phase 0 spans 10 to 10² users. The system is live but barely visible.
|
||||
See the [[id:92ccd074-04a0-4e45-a44f-9da24ea20a9b][Impact]] overview for context.
|
||||
|
||||
**Verification:** Nothing breaks. The conventional world does not notice.
|
||||
First enterprise compliance savings ($200K→$50K). First gate rule
|
||||
packages. Unit economics demonstrated.
|
||||
|
||||
**Social protocol:** First organized communities using the full bundle
|
||||
(identity + publishing + payments + contracts + governance). The
|
||||
experience of unified identity — one account replacing five platforms —
|
||||
creates a new expectation: software should be integrated, not siloed.
|
||||
First creator migration: an OnlyFans or Patreon refugee who cannot be
|
||||
deplatformed discovers censorship resistance is not abstract — it is the
|
||||
reason they still have an income.
|
||||
|
||||
**Financial services:** None at this scale. The first enterprise
|
||||
compliance savings are in general regulated industries (pharma, finance
|
||||
compliance), not in core banking or markets. The protocol is not yet a
|
||||
financial services product.
|
||||
|
||||
**Economics:** Verification revenue from gateway subscriptions and gate
|
||||
rules ($50-200K per enterprise). Social protocol revenue from community
|
||||
fees and creator subscriptions ($1-5M). Small. Insufficient to sustain
|
||||
development — the system is self-developing through the bootstrap loop,
|
||||
not dependent on this revenue.
|
||||
41
projects/passepartout/strategy/phase-1-impact.org
Normal file
41
projects/passepartout/strategy/phase-1-impact.org
Normal file
@@ -0,0 +1,41 @@
|
||||
:PROPERTIES:
|
||||
:ID: b1c2d3e4-f5a6-7890-1bcd-ef0123456789
|
||||
:CREATED: [2026-05-25 Mon]
|
||||
:END:
|
||||
#+title: Phase 1 — Impact
|
||||
#+filetags: :passepartout:strategy:adoption:impact:
|
||||
|
||||
Phase 1 spans 10² to 10⁴ users. The protocol's existence becomes
|
||||
visible to those paying attention. See the [[id:92ccd074-04a0-4e45-a44f-9da24ea20a9b][Impact]] overview for context.
|
||||
|
||||
**Verification:** Compliance consultancies lose first clients. SaaS
|
||||
companies win RFPs by integrating proof logs. First regulator encode —
|
||||
the most leveraged event in the institutional trajectory. API gateway
|
||||
subscriptions decouple value from instance adoption.
|
||||
|
||||
**Social protocol:** Community refugees arrive — a banned subreddit or
|
||||
nuked Discord server rebuilds on the protocol, discovering that their
|
||||
new home cannot be taken away. Organized communities reach hundreds of
|
||||
users coordinating through the protocol. Creators keep 95%+ of
|
||||
subscription revenue instead of 70%, and discover that no payment
|
||||
processor can cut them off. The concept of "portable identity" enters
|
||||
the vocabulary — users realize that the reputation they build belongs to
|
||||
them, not to a platform.
|
||||
|
||||
**Impact on platforms:** First structural signal that the unbundling has
|
||||
begun. A community that leaves Reddit for the protocol does not return.
|
||||
A creator who migrates from OnlyFans does not split revenue again. Each
|
||||
departure is permanent because the protocol offers the bundle (identity
|
||||
+ audience + payments + contracts) that no single incumbent can match.
|
||||
|
||||
**Financial services:** Still no direct impact on core financial
|
||||
services. Payment processors (Stripe, PayPal) begin to notice lost
|
||||
volume from protocol-native transactions, but the absolute numbers are
|
||||
small — millions of dollars in a trillion-dollar industry. The
|
||||
compliance consulting disruption touches financial compliance (KYC/AML
|
||||
consulting firms lose first clients), but no bank or insurer has adapted
|
||||
yet.
|
||||
|
||||
**Economics:** Verification revenue from gateway subscriptions and gate
|
||||
rules ($50-200K per enterprise). Social protocol revenue from community
|
||||
fees and creator subscriptions ($1-5M). Small but accelerating.
|
||||
161
projects/passepartout/strategy/phase-2-impact.org
Normal file
161
projects/passepartout/strategy/phase-2-impact.org
Normal file
@@ -0,0 +1,161 @@
|
||||
:PROPERTIES:
|
||||
:ID: c2d3e4f5-a6b7-8901-2cde-f01234567890
|
||||
:CREATED: [2026-05-25 Mon]
|
||||
:END:
|
||||
#+title: Phase 2 — Impact
|
||||
#+filetags: :passepartout:strategy:adoption:impact:
|
||||
|
||||
Phase 2 spans 10⁴ to 10⁶ users. The protocol's economic weight becomes
|
||||
measurable. See the [[id:92ccd074-04a0-4e45-a44f-9da24ea20a9b][Impact]] overview for context.
|
||||
|
||||
**Verification:** First regulator encode makes adoption mandatory in a
|
||||
domain. Cloud revenue decelerates as Lisp machines replace racks of x86
|
||||
servers. Compliance industry sees 30-50% paper audit reduction.
|
||||
Insurance differentiates on verification — actuarial wedge forms.
|
||||
|
||||
**Social protocol:** Contract marketplace reaches critical mass.
|
||||
Freelancers and cross-border workers use the protocol for verifiable
|
||||
contracts and escrow, bypassing Upwork's 20% fee and jurisdictional
|
||||
legal uncertainty. The reputation graph from Phase 0-1 communities now
|
||||
carries real economic weight — a proven history of verified transactions
|
||||
is more valuable than any platform's rating system. Cross-jurisdiction
|
||||
transactions execute with no reference to any state's legal system.
|
||||
|
||||
**Impact on platforms:** The unbundling accelerates. Stripe loses
|
||||
payment volume in protocol communities — Lightning is free, Stripe takes
|
||||
2.9% + $0.30. DocuSign loses contract volume — SCAL contracts are
|
||||
native to the protocol, not a separate subscription. Upwork and Fiverr
|
||||
lose freelancers who bypass the platform fee by contracting directly
|
||||
through the protocol. Discord loses communities that migrate to
|
||||
cryptographically owned Social Spaces. These are not competitive
|
||||
responses the incumbents can match — Stripe cannot offer social and
|
||||
contracts, Discord cannot offer zero-fee payments and portable identity.
|
||||
|
||||
**Financial services:**
|
||||
|
||||
*Insurance differentiation — the actuarial wedge:*
|
||||
|
||||
This is the first structural impact on a core financial service.
|
||||
Insurers who adopt verification (using gate logs for underwriting)
|
||||
develop a pricing advantage over insurers who rely on self-reported data.
|
||||
The wedge works as follows:
|
||||
|
||||
- A verified insurer attests property condition, security system status,
|
||||
driver behaviour, or inventory integrity through gate logs. The data
|
||||
is cryptographically proven and cannot be fabricated.
|
||||
- An unverified insurer relies on customer statements, paper forms, and
|
||||
spot audits. Their data is noisy and expensive to collect.
|
||||
- The verified insurer prices 15-30% lower because their risk model is
|
||||
better. Policyholders migrate. The unverified insurer bleeds
|
||||
low-risk customers and is left with a riskier pool — classic adverse
|
||||
selection in reverse.
|
||||
- At scale, the wedge widens as the verified insurer accumulates more
|
||||
data and refines their gate rules. After 2-3 years, the unverified
|
||||
insurer cannot compete on price without adopting verification
|
||||
themselves.
|
||||
|
||||
This is not a regulatory mandate — it is a competitive dynamic that
|
||||
drives adoption without requiring a regulator to act. Insurance
|
||||
differentiation is the most organically potent force for verification
|
||||
adoption in the financial sector at this phase.
|
||||
|
||||
*Mutual insurance — first social protocol pools:*
|
||||
|
||||
Phase 2 is where the first mutual insurance pools form on the social
|
||||
protocol. These are small-scale, community-level arrangements, but
|
||||
they demonstrate the structural difference the protocol enables.
|
||||
|
||||
The three problems that have always limited mutual insurance:
|
||||
|
||||
1. **Adverse selection** — high-risk members join, low-risk members
|
||||
leave, the pool collapses.
|
||||
2. **Fraud** — members claim for events that did not happen or inflate
|
||||
losses.
|
||||
3. **Governance overhead** — someone must collect contributions, verify
|
||||
claims, manage reserves. This either costs money (killing small-pool
|
||||
economics) or concentrates power (creating insider risk).
|
||||
|
||||
The protocol addresses all three at the architecture level:
|
||||
|
||||
- **Adverse selection:** The pool queries the reputation graph — how
|
||||
long has a member's DID existed, how many contracts have they
|
||||
fulfilled, have they been party to an arbitration dispute? A newcomer
|
||||
with a fresh DID and no history pays higher contributions until they
|
||||
have enough verified history for standard rates. This mirrors social
|
||||
insurance where community members vouch for each other, except the
|
||||
vouching is verifiable.
|
||||
- **Fraud:** A claim requires a gate attestation. For some events this
|
||||
is direct (a weather oracle attests to flood damage in a postal code).
|
||||
For others it requires social attestation (two pool members with
|
||||
verified DIDs attest they witnessed the damage). Any fraud requires
|
||||
collusion across multiple verified identities, each of whom loses
|
||||
reputation if detected. The cost of successful fraud exceeds the
|
||||
benefit for most cases.
|
||||
- **Governance:** The pool is a Collective Persona. Contributions are
|
||||
automatic on schedule. Payouts execute automatically when a claim
|
||||
gate rule passes. The reserve balance is transparent on the proof
|
||||
log. Disputes go to the protocol's arbitration guilds. Overhead drops
|
||||
from "hire a part-time administrator" to "define the contribution
|
||||
and claim rules once."
|
||||
|
||||
At Phase 2, mutual pools are small — neighbourhood risk-sharing
|
||||
(appliance failure, minor medical bills, income disruption), hobbyist
|
||||
guilds (equipment damage for a shared workshop), or community groups
|
||||
(shared liability for a community garden or event). Members know each
|
||||
other socially, which is a strong check on adverse selection and fraud
|
||||
independently of the protocol. The protocol handles the mechanics that
|
||||
would otherwise require a treasurer and a spreadsheet.
|
||||
|
||||
These pools would never be economical as conventional insurance products
|
||||
— the premium is too small to justify administrative cost. The protocol
|
||||
makes them viable because the marginal cost of running a pool is near
|
||||
zero once the gate rules are defined. This is the first demonstration
|
||||
that the protocol enables risk-sharing arrangements that the market
|
||||
cannot serve.
|
||||
|
||||
*Cross-border payments:*
|
||||
|
||||
The contract marketplace enables a new kind of cross-border payment. A
|
||||
worker in Kenya receives payment as a Lightning transaction through a
|
||||
protocol contract. The employer in Germany sends euros; the contract
|
||||
executes a currency conversion gate rule and delivers satoshis to the
|
||||
worker's DID. The cost is near-zero. The settlement is instant. The
|
||||
worker needs no bank account, no remittance service, no Western Union.
|
||||
This is Phase 2 because it requires the contract marketplace to have
|
||||
critical mass, which it reaches at this phase.
|
||||
|
||||
**Governance and law — first hints:**
|
||||
|
||||
The arbitration guilds that handle contract marketplace disputes are the
|
||||
first proto-legal institution built on the protocol. A dispute between a
|
||||
freelancer in Nigeria and a client in Germany goes to a guild rather
|
||||
than to either country's courts. The guild's jurisdiction is neither
|
||||
territorial nor contractual in the conventional sense — it is consented
|
||||
to by both parties through the contract's arbitration clause. The guild
|
||||
applies its own procedural rules, renders a decision, and the escrow
|
||||
gate executes the outcome automatically.
|
||||
|
||||
This is a new legal phenomenon: private law that is both trans-
|
||||
jurisdictional and self-executing. No state court enforces the guild's
|
||||
judgment — the protocol does. The guild's legitimacy comes from its
|
||||
reputation on the protocol, not from a state's delegation of authority.
|
||||
At Phase 2, this is limited to small-value commercial disputes, but
|
||||
the structural precedent is set.
|
||||
|
||||
Separately, the first dissident communities and opposition organizers in
|
||||
authoritarian regimes begin using the protocol for secure coordination.
|
||||
The repression they face is the first evidence that the protocol's
|
||||
censorship resistance is a political fact, not a technical curiosity.
|
||||
These early political users are invisible to most of the protocol's
|
||||
user base, but they matter disproportionately to the long-term
|
||||
trajectory — they create a use case that no consumer application can
|
||||
match and no government can tolerate.
|
||||
|
||||
**Economics:**
|
||||
|
||||
On the destruction side: cloud revenue deceleration in regulated
|
||||
markets, compliance industry revenue loss ($60-100B of the $200B market
|
||||
affected), early platform revenue loss at Stripe, DocuSign, and Upwork.
|
||||
On the creation side: contract marketplace fees ($20-100M), gate rule
|
||||
consulting, insurance differentiation revenue. Capital begins
|
||||
reallocating from intermediation to infrastructure.
|
||||
315
projects/passepartout/strategy/phase-3-impact.org
Normal file
315
projects/passepartout/strategy/phase-3-impact.org
Normal file
@@ -0,0 +1,315 @@
|
||||
:PROPERTIES:
|
||||
:ID: d3e4f5a6-b7c8-9012-3def-012345678901
|
||||
:CREATED: [2026-05-25 Mon]
|
||||
:END:
|
||||
#+title: Phase 3 — Impact
|
||||
#+filetags: :passepartout:strategy:adoption:impact:
|
||||
|
||||
Phase 3 spans 10⁶ to 10⁸ users. Both the verification and social
|
||||
protocol tracks become visible at macroeconomic scale. See the
|
||||
[[id:92ccd074-04a0-4e45-a44f-9da24ea20a9b][Impact]] overview for context.
|
||||
|
||||
**Verification:** Cybersecurity industry collapses for the verified
|
||||
segment ($200B destroyed). Surveillance advertising becomes structurally
|
||||
impossible in regulated markets ($600B destroyed). Certified gate
|
||||
library is the most comprehensive proof base ever assembled. Insurance
|
||||
penalizes non-verification by 10x.
|
||||
|
||||
**Social protocol:** Institution crossover — universities issue verified
|
||||
credentials, newsrooms publish with provenance, regulators adopt
|
||||
protocol attestation because the network already has their users. The
|
||||
verification products that institutional compliance sells as enterprise
|
||||
software are now fulfillment orders for a network that already exists.
|
||||
A university does not choose to issue DIDs; it chooses to stop issuing
|
||||
paper diplomas that cannot be verified. A newsroom does not choose to
|
||||
adopt provenance; it chooses to stop publishing articles that can be
|
||||
forged. The protocol is the path of least resistance because the
|
||||
infrastructure is already in place.
|
||||
|
||||
**Impact on centralized platforms:** The end of the platform era. The
|
||||
20+ incumbents that defined the internet for two decades (Meta, Google,
|
||||
Twitter, YouTube, Reddit, Discord, Stripe, DocuSign, OnlyFans, Upwork,
|
||||
GitHub, Medium, Substack) have lost their structural position. Their
|
||||
network effects are broken because the protocol offers portable
|
||||
identity, portable reputation, and portable audiences. A Facebook user
|
||||
can leave without losing their social graph. A GitHub contributor can
|
||||
move their repos without losing their contribution history. A Substack
|
||||
writer can take their subscribers. Each individual platform can still
|
||||
operate, but the lock-in is gone. Users stay because they choose to,
|
||||
not because they cannot leave.
|
||||
|
||||
**Social/Cultural:** A fundamental shift in how people understand
|
||||
identity and reputation online. Teenagers growing up in this period
|
||||
learn that their digital identity is theirs — not something a platform
|
||||
can revoke. The concept of "building an audience on a platform" is
|
||||
replaced by "building a reputation on the protocol." The 20+ separate
|
||||
accounts, logins, friend lists, and reputations that defined the 2010s
|
||||
are replaced by one identity with multiple personas. This is not just
|
||||
a UX improvement — it is a change in the power relationship between
|
||||
users and the services they use.
|
||||
|
||||
**Political/Geopolitical:** The social protocol becomes a human rights
|
||||
infrastructure. Dissidents in authoritarian regimes use it because it
|
||||
is the only option their government cannot surveil or shut down.
|
||||
Journalists in exile use it because their publication cannot be blocked
|
||||
at the domain level. Groups under threat (ethnic minorities, LGBTQ+
|
||||
communities in hostile jurisdictions, opposition organizers) use it
|
||||
because the right of association is technically guaranteed, not
|
||||
politically granted. States that attempt to block the protocol face a
|
||||
legitimacy crisis: a ban is visibly censorship, and citizens in
|
||||
free-world jurisdictions who use the protocol amplify the content that
|
||||
the ban tries to suppress.
|
||||
|
||||
**Financial services — structural disruption phase:**
|
||||
|
||||
This is the phase where the protocol's impact on financial services
|
||||
becomes structural rather than marginal. Several sectors face
|
||||
transformation simultaneously.
|
||||
|
||||
*Compliance industry collapse — financial edition:*
|
||||
|
||||
The compliance industry ($200B/yr globally) is hit hardest in its
|
||||
financial segment. KYC/AML compliance — each bank spending $50M-500M/yr
|
||||
on identity verification, transaction monitoring, and regulatory
|
||||
reporting — becomes a gate rule. A bank running a gate does not need
|
||||
separate KYC officers, AML monitoring systems, or regulatory filing
|
||||
teams. The gate attests that a transaction satisfies the relevant rules
|
||||
before it executes. The compliance department shrinks from hundreds of
|
||||
people to a handful of gate rule maintainers.
|
||||
|
||||
For financial compliance consultancies (the Big Four's risk advisory
|
||||
practices, specialist AML firms), this is existential. Their value
|
||||
proposition — "we help you comply with regulations" — is replaced by
|
||||
"here is a gate rule that encodes the regulation." The consulting
|
||||
engagement shifts from annual compliance reviews to one-time gate rule
|
||||
specification.
|
||||
|
||||
*Credit bureaus disrupted:*
|
||||
|
||||
A DID's verifiable transaction history replaces the credit bureau.
|
||||
Underwriting becomes a programmable gate rule — verified income history
|
||||
+ verified payment history + verified asset ownership yields a credit
|
||||
score algorithmically, without Equifax or Experian aggregating consumer
|
||||
data centrally. The credit bureau model — collect data on everyone, sell
|
||||
it to lenders, and hope the data is accurate — is structurally obsolete
|
||||
because the protocol makes credit-relevant data available at the source,
|
||||
attested by the institution that generated it.
|
||||
|
||||
The implication for lenders: a loan application from a DID with five
|
||||
years of verified transaction history is more informative than any
|
||||
credit score, because the data is complete, verified, and cannot be
|
||||
fabricated. The lender's own gate queries the DIDs verifiable history
|
||||
and returns a credit decision. No data broker in the middle.
|
||||
|
||||
*Accounting profession transformation begins:*
|
||||
|
||||
The first enterprises run their ledgers on gates. A general ledger gate
|
||||
attests each transaction: who sent what to whom, when, under which
|
||||
contract, with which regulatory approvals. The "books" are a query over
|
||||
the attestation log. Triple-entry accounting — the idea that has existed
|
||||
since the 1980s but never deployed at scale — becomes the natural mode:
|
||||
each transaction is signed by both parties and recorded in a shared
|
||||
proof log. Reconciliation between two entities' books becomes a single
|
||||
query: both sides submit their attestation logs, and the gate checks
|
||||
whether they agree.
|
||||
|
||||
The year-end audit, traditionally a weeks-long manual process, becomes a
|
||||
gate rule check that runs in minutes. The question shifts from "are the
|
||||
books correct?" (answered by an auditor exercising professional
|
||||
judgment) to "was the gate rule correctly specified?" (answered by a
|
||||
verification engineer testing the rule). The profession begins its
|
||||
transformation: transaction checking shrinks; attestation logic design
|
||||
grows. Forensic accounting — finding fraud in unstructured data —
|
||||
shrinks because fraud leaves cryptographic evidence in the attestation
|
||||
log. Gate rule design — defining what constitutes a valid transaction
|
||||
under GAAP or IFRS — becomes the new core competency.
|
||||
|
||||
The Big Four's audit practices face the same disruption as compliance
|
||||
consultancies. Their product is trust, and the protocol replaces trust
|
||||
with verification.
|
||||
|
||||
*Commercial mutual insurance:*
|
||||
|
||||
Phase 3 is where mutual insurance moves from neighbourhood pools to
|
||||
commercial-scale arrangements. Industry-specific pools form in sectors
|
||||
underserved by conventional insurance or where the protocol's
|
||||
verification naturally serves the risk:
|
||||
|
||||
- **Small manufacturer equipment pools:** A group of 50-200 factories in
|
||||
the same industrial district pool equipment breakdown risk. Each
|
||||
member's gate attests to machine uptime, maintenance logs, and safety
|
||||
inspection results. A member with better-maintained equipment pays
|
||||
lower contributions. Claims are verified by attestation rather than
|
||||
adjuster visits.
|
||||
- **Freelancer income protection pools:** Platform workers with verified
|
||||
contract histories pool income disruption risk. Contributions are a
|
||||
small percentage of each completed contract. A member who loses a
|
||||
major client (attested by a drop in contract volume) receives a
|
||||
payout until they rebuild. No conventional insurer offers this product
|
||||
because the underwriting cost exceeds the premium.
|
||||
- **Vehicle damage pools for delivery drivers:** A group of last-mile
|
||||
delivery drivers pools vehicle damage and liability. Telemetry from
|
||||
gate-attested vehicle logs determines fault and contribution levels.
|
||||
Safer drivers pay less. The pool can offer lower rates than commercial
|
||||
auto insurance because the underwriting is granular and automated.
|
||||
|
||||
These pools are viable at Phase 3 because:
|
||||
1. The reputation graph from Phases 0-2 provides enough signal for
|
||||
underwriting without an insurance application process.
|
||||
2. The contract marketplace from Phase 2 provides the infrastructure
|
||||
for contributions and payouts.
|
||||
3. The arbitration guilds (matured through the Phase 2 contract
|
||||
marketplace) can handle pool disputes.
|
||||
4. A pool's transparent proof log attracts members who trust
|
||||
verifiable reserves over an insurer's balance sheet.
|
||||
|
||||
The structural difference from conventional mutual insurance companies:
|
||||
formation cost approaches zero (define the rules, invite members, no
|
||||
incorporation or regulatory filing), transparency is built-in (the proof
|
||||
log is the reserve report), exit is individual (a member takes their
|
||||
verified history to another pool), and pools compete on rule design
|
||||
rather than brand or distribution.
|
||||
|
||||
*Payment systems:*
|
||||
|
||||
Card networks face their first structural pressure. Visa and Mastercard
|
||||
process trillions of dollars through a verification infrastructure that
|
||||
costs 1.5-3% per transaction. The protocol demonstrates cryptographic
|
||||
verification at a cost measured in millicents. The gap is too large to
|
||||
ignore. Regulators in the most forward-leaning jurisdictions begin
|
||||
asking why settlement takes three days when protocol settlement is
|
||||
atomic. The question is not regulatory mandate — it is that the existent
|
||||
alternative makes the existing system look absurd.
|
||||
|
||||
**Governance and law — structural pressure:**
|
||||
|
||||
*Evidence — the wedge:*
|
||||
|
||||
Gate attestations begin appearing as evidence in court, and they are
|
||||
unlike anything the legal system has seen. A gate attestation is
|
||||
cryptographically signed by a verified DID, timestamped on the proof
|
||||
log, and linked to the chain of prior attestations. A party cannot
|
||||
credibly dispute that a transaction happened — they can only dispute
|
||||
what it meant. This shifts commercial litigation from fact-finding to
|
||||
interpretation, and it creates a two-tier evidence system: cases
|
||||
involving gate-attested facts resolve faster and cheaper than cases
|
||||
relying on conventional documentary evidence.
|
||||
|
||||
Courts in forward-leaning jurisdictions begin formally recognizing gate
|
||||
attestations as self-authenticating evidence under evidentiary rules
|
||||
analogous to the business records exception or notarized documents.
|
||||
Once one major jurisdiction does this, litigants in every jurisdiction
|
||||
have an incentive to present gate-attested facts because they are
|
||||
cheaper to admit and harder to challenge.
|
||||
|
||||
*Discovery — automated:*
|
||||
|
||||
In any dispute between parties who use the protocol, discovery becomes a
|
||||
gate query: "show me all transactions between DID A and DID B that
|
||||
satisfy these conditions." The cost drops from millions of dollars and
|
||||
armies of document reviewers to the cost of specifying and running a
|
||||
query. For disputes that cross the protocol-conventional boundary (one
|
||||
party on the protocol, one off), the protocol side's relevant facts are
|
||||
trivially discoverable while the conventional side requires traditional
|
||||
discovery. This asymmetry creates a powerful incentive for adoption —
|
||||
being on the protocol means discovery costs are near-zero.
|
||||
|
||||
*Regulatory law — rule encoding:*
|
||||
|
||||
The regulatory lawyers who specialized in "how do we comply with this
|
||||
regulation" face the same disruption as compliance consultancies.
|
||||
The answer becomes "specify a gate rule that encodes the regulation's
|
||||
requirements." The work shifts from interpretation (what does the
|
||||
regulation mean) to engineering (how do we encode this requirement
|
||||
correctly). Legal interpretation does not disappear — someone must
|
||||
determine what a regulation means before it can be encoded — but it
|
||||
contracts from a year-round advisory function to a one-time
|
||||
specification exercise per regulation.
|
||||
|
||||
*Lobbying and campaign finance — verifiable:*
|
||||
|
||||
If a lobbyist registers a DID and attests their interactions with
|
||||
legislators, the proof log makes lobbying visible: not the content of
|
||||
the conversations, but that they happened, when, and between whom.
|
||||
This is far more transparent than current disclosure regimes, which
|
||||
rely on self-reporting and have significant loopholes. Forward-leaning
|
||||
jurisdictions begin requiring lobbyist DIDs and gate-attested
|
||||
interaction logs.
|
||||
|
||||
Campaign finance undergoes a similar transformation. A contribution
|
||||
that violates campaign finance law cannot enter a candidate's DID
|
||||
without being flagged by the contribution gate rule. Enforcement
|
||||
shifts from investigatory (the FEC detects violations after the fact,
|
||||
if at all) to preventive (the gate rule refuses the contribution
|
||||
before it can be accepted). This eliminates most forms of campaign
|
||||
finance abuse that involve over-limit, foreign, or anonymous
|
||||
contributions.
|
||||
|
||||
*Political organizing — uncensorable:*
|
||||
|
||||
Political movements begin organizing through the protocol at a scale
|
||||
that governments notice. In authoritarian states, opposition groups use
|
||||
the protocol for secure coordination — membership lists, meeting
|
||||
scheduling, collective decision-making through Collective Personas.
|
||||
The government cannot surveil the membership or disrupt the
|
||||
coordination without controlling the entire relay graph.
|
||||
|
||||
In democratic states, the impact is subtler but significant. Grassroots
|
||||
movements organize through the protocol to bypass party structures.
|
||||
A local campaign can verify that a petition signatory is a registered
|
||||
voter in the district (through the residency gate) while preserving
|
||||
the signatory's privacy from the campaign itself. Verified petitions
|
||||
carry more weight than conventional ones because the signatures are
|
||||
cryptographically proven, not a list of names that could be fabricated.
|
||||
|
||||
*Election experiments:*
|
||||
|
||||
The first forward-leaning jurisdictions experiment with the protocol
|
||||
for election verification. The pilot is usually limited: voter
|
||||
registration verification through the residency gate, or ballot
|
||||
tracking through the proof log. The outcome is a drastic reduction in
|
||||
the cost of election administration and a significant increase in
|
||||
public confidence — the proof log makes it possible for any citizen
|
||||
to verify that their vote was counted without revealing how they
|
||||
voted.
|
||||
|
||||
The technical challenges become visible during these pilots:
|
||||
authentication (how to verify that a DID corresponds to a living,
|
||||
eligible voter without creating a surveillance infrastructure),
|
||||
coercion (how to prevent a voter from proving how they voted to a
|
||||
vote-buyer), and privacy (how to break the link between DID and vote
|
||||
while preserving verifiability). None of these are unsolvable, but
|
||||
all require specific cryptographic infrastructure (mix networks,
|
||||
homomorphic tallying, deniable receipts) that the protocol does not
|
||||
ship as a default capability. The pilots reveal that elections require
|
||||
a specialized gate configuration, not a generic one.
|
||||
|
||||
**Economics:**
|
||||
|
||||
Verification destruction: cybersecurity ($200B), surveillance advertising
|
||||
($600B), conventional computing institutional revenue ($400B+) — total
|
||||
$800B-$1.5T/yr in value transferring. Verification creation:
|
||||
certification fees ($5-20B), gate rule consulting ($1-5B), ASIC
|
||||
manufacturing ($1-5B), verification engineering as a profession.
|
||||
|
||||
Social protocol destruction: platform intermediation fees destroyed
|
||||
across 20+ categories — Stripe's 2.9%, Upwork's 20%, Medium's 10%,
|
||||
OnlyFans's 20%, eBay's 15%, Substack's 10%. Estimated total: $200-500B/yr
|
||||
in platform fees eliminated. Social protocol creation: contract
|
||||
marketplace fees ($100M-$1B), creator direct revenue (creators keep
|
||||
95%+ instead of 70-80%, net gain to creators of $50-100B/yr), PDS
|
||||
hosting services, premium identity names, compute marketplace fees.
|
||||
|
||||
Net effect: approximately $1-2T/yr in value reallocation from
|
||||
intermediaries (platforms, compliance, cybersecurity, advertising) to
|
||||
infrastructure (verification, protocol, contracts) and creators/users.
|
||||
The efficiency gain is 10-100x in most categories.
|
||||
|
||||
Labor market transition: 6M+ verification-side jobs displaced
|
||||
(compliance, IT ops, cybersecurity, ad tech). 1-2M social-side jobs
|
||||
displaced (platform moderation, ad sales, platform-specific development).
|
||||
New roles on both sides: gate rule developer, verification engineer,
|
||||
attestation auditor on the verification side; protocol integrator,
|
||||
reputation curator, persona designer on the social side. Structural
|
||||
unemployment gap of 5-10 years, same pattern as the
|
||||
manufacturing-to-services transition of the 1970s-1990s.
|
||||
530
projects/passepartout/strategy/phase-4-impact.org
Normal file
530
projects/passepartout/strategy/phase-4-impact.org
Normal file
@@ -0,0 +1,530 @@
|
||||
:PROPERTIES:
|
||||
:ID: e4f5a6b7-c8d9-0123-4ef0-123456789012
|
||||
:CREATED: [2026-05-25 Mon]
|
||||
:END:
|
||||
#+title: Phase 4 — Impact
|
||||
#+filetags: :passepartout:strategy:adoption:impact:
|
||||
|
||||
Phase 4 spans 10⁸ to 10⁹ users. Two-tier computing is the stable
|
||||
equilibrium. See the [[id:92ccd074-04a0-4e45-a44f-9da24ea20a9b][Impact]] overview for context.
|
||||
|
||||
**Verification:** Two-tier computing is the stable equilibrium. Verified
|
||||
instances handle all transactions of significant economic value.
|
||||
Conventional computing serves entertainment, casual use, and legacy
|
||||
systems that have not migrated — but its economic significance has
|
||||
shrunk dramatically. The surveillance advertising model that funded
|
||||
most of the conventional internet for two decades is extinct in
|
||||
regulated markets and structurally declining everywhere else. ASIC mass
|
||||
production makes verification cheaper than conventional compute for
|
||||
verified tasks.
|
||||
|
||||
**Social protocol:** The protocol is default identity for significant
|
||||
transactions. Portable reputation, earned through verified actions and
|
||||
lost through verified breaches of trust, replaces platform-bound rating
|
||||
systems as the primary signal of trustworthiness online. The
|
||||
distinction between "corporate verified identity" and "community
|
||||
reputation" has blurred — they are the same cryptographic graph.
|
||||
|
||||
Pseudonymity remains available — anyone can create a DID without linking
|
||||
it to a real-world identity — but the economic weight of reputation
|
||||
makes persistent pseudonyms more valuable than throwaway identities for
|
||||
high-value interactions. This is not anonymity's end; it is a shift
|
||||
from purely anonymous transactions (where neither party has any signal
|
||||
about the other) to pseudonymous accountable transactions (where each
|
||||
party has a cryptographic history they choose to reveal). Whistleblowers,
|
||||
activists, and anyone with a legitimate need for anonymity can still
|
||||
operate through ephemeral DIDs and uncensorable relay networks — the
|
||||
protocol does not require KYC or real-name verification.
|
||||
|
||||
**Foundation internet categories:**
|
||||
|
||||
*Messaging:*
|
||||
|
||||
DIDComm has replaced the protocol layer of person-to-person and group
|
||||
communication. Messaging is now a native capability of your identity —
|
||||
you message someone by their DID, not by which app they use. WhatsApp,
|
||||
Signal, Telegram, and iMessage still exist as client applications, but
|
||||
the lock-in is broken: any DID-compatible client can reach any other.
|
||||
The platform is no longer the gatekeeper of who you can talk to.
|
||||
Interoperability, long the holy grail of messaging, is achieved not
|
||||
through regulation or corporate cooperation but through architectural
|
||||
unification at the protocol layer.
|
||||
|
||||
*Websites:*
|
||||
|
||||
Publishing has shifted from "host content on a server" to "publish a
|
||||
Note from your PDS." Websites still exist as rendering surfaces —
|
||||
browsers still render HTML — but the content they display is
|
||||
protocol-native. Domain names resolve to DIDs, not IP addresses; a
|
||||
domain seizure by a state or hosting provider does not remove the
|
||||
content. The web has become a viewing layer over protocol-native
|
||||
content, not the primary storage and identity layer it was in the 2010s.
|
||||
This is similar to how the web became a viewing layer over databases —
|
||||
the difference is that the user controls the database.
|
||||
|
||||
*Email:*
|
||||
|
||||
Directed Notes have replaced email for most person-to-person and
|
||||
business communication. The Note primitive — already used for
|
||||
publishing, messaging, payments, and contracts — handles asynchronous
|
||||
directed communication with end-to-end encryption, cryptographic sender
|
||||
verification, and spam-free routing (relays only deliver to subscribed
|
||||
DIDs). Email persists as a legacy protocol for organizations that have
|
||||
not migrated, similar to how fax persisted alongside email. But its
|
||||
primacy for business communication is over — a contract sent as a Note
|
||||
carries a proof chain; a contract sent as an email attachment is just
|
||||
a file.
|
||||
|
||||
**Financial services — full transformation:**
|
||||
|
||||
*Banking:*
|
||||
|
||||
Banks have transformed from financial infrastructure operators to gate
|
||||
operators — the interface between fiat currency and the protocol. A
|
||||
retail bank's primary functions (safe-keeping, money movement, lending)
|
||||
are now gate primitives:
|
||||
|
||||
- **Deposit safe-keeping:** The bank's internal ledger is a gate that
|
||||
attests to the state of each depositor's account. A depositor can
|
||||
query their balance through any compliant client. The "bank run"
|
||||
risk is structurally different because the gate can attest to
|
||||
solvency in real time.
|
||||
- **Money movement:** Sending money from one bank's customer to
|
||||
another's is a gate-to-gate transaction. The sending gate attests
|
||||
"this DID has the funds, the transfer is authorized, the
|
||||
regulatory checks pass." The receiving gate attests "the funds
|
||||
arrived, the credit is posted." Settlement is atomic — no batch
|
||||
processing, no end-of-day reconciliation, no correspondent banking
|
||||
chain. A cross-border transfer that took 3-5 days in 2025 now
|
||||
settles in milliseconds at gate verification cost.
|
||||
- **Lending:** A loan application is a gate query: the borrower's DID
|
||||
presents its verified transaction history (income, payment patterns,
|
||||
existing debts), the lender's gate runs the underwriting rule, and
|
||||
the loan contract executes as a protocol Note. The cost of
|
||||
originating a loan drops from hundreds of dollars (underwriter +
|
||||
credit bureau pull + document processing) to the marginal cost of a
|
||||
gate rule execution.
|
||||
- **KYC/AML:** These are no longer separate functions performed by
|
||||
compliance departments. They are gate rules applied to each
|
||||
transaction. The cost of financial compliance for a bank drops from
|
||||
5-15% of operating expenses to a gate subscription fee. The
|
||||
financial compliance industry ($50B+ in the banking sector alone) has
|
||||
collapsed to a fraction of its former size.
|
||||
|
||||
The banking license still exists — the regulatory framework for who can
|
||||
operate a fiat-to-protocol gate — but the operational cost of being a
|
||||
bank drops so dramatically that new entrants proliferate. Community
|
||||
banks and credit unions, which struggled with compliance costs in the
|
||||
2010s and 2020s, can now compete with the largest institutions because
|
||||
the gate levels the compliance playing field.
|
||||
|
||||
*Capital markets:*
|
||||
|
||||
The entire trade lifecycle — order, match, clear, settle, report — is a
|
||||
sequence of gate verifications:
|
||||
|
||||
- **Order placement:** A signed DID message from a verified investor.
|
||||
The gate checks: is this DID authorized to trade this security? Does
|
||||
the investor's account have sufficient funds? Is the order compliant
|
||||
with position limits?
|
||||
- **Matching:** The exchange (still exists as a venue, not an
|
||||
infrastructure provider) runs a matching gate rule: match buy and
|
||||
sell orders that satisfy the same security, price, and settlement
|
||||
terms.
|
||||
- **Clearing:** An escrow gate holds both sides' consideration until
|
||||
settlement conditions are met. No central counterparty needed for
|
||||
most instruments.
|
||||
- **Settlement:** Atomic transfer. The security (represented as a token
|
||||
on the protocol with full legal provenance) and the funds exchange
|
||||
simultaneously. No T+1 or T+2 settlement window. No DTCC or
|
||||
Euroclear processing chain.
|
||||
- **Reporting:** The immutable proof log serves as the regulatory
|
||||
record. Regulators query it directly rather than receiving periodic
|
||||
filings. The cost of trade reporting drops to zero.
|
||||
|
||||
The intermediaries that existed because of trust deficits — clearinghouses,
|
||||
custodians, depositories — have lost their structural position. The
|
||||
NYSE or LSE still exists as a listing venue and matching service, but
|
||||
the infrastructure underneath is protocol-native.
|
||||
|
||||
Going public is a gate rule: the company's verified financials satisfy
|
||||
exchange listing requirements, the offering is structured as a
|
||||
protocol-native securities issuance, and the gate ensures ongoing
|
||||
reporting compliance. The cost of an IPO drops from millions of dollars
|
||||
to the cost of gate rule specification and audit.
|
||||
|
||||
Secondary markets for private securities become liquid because transfer
|
||||
is a gate rule, not a legal process requiring lawyers and consent from
|
||||
every existing shareholder. A startup employee can sell vested shares on
|
||||
a secondary market with the same ease as trading public stock, subject
|
||||
to programmable lock-up gate rules.
|
||||
|
||||
*Insurance and mutual insurance:*
|
||||
|
||||
**Conventional insurance:** Insurers who did not adopt verification in
|
||||
Phase 2-3 are now structurally uncompetitive. The actuarial wedge has
|
||||
widened to 5-10x. A verified insurer can quote a comprehensive policy
|
||||
at a price point that an unverified insurer cannot match because their
|
||||
underwriting is based on actual verified data rather than statistical
|
||||
proxies and self-reported forms. Most commercial insurance has migrated
|
||||
to verification-based underwriting.
|
||||
|
||||
**Mutual insurance at all scales:**
|
||||
|
||||
Mutual insurance has matured into three tiers:
|
||||
|
||||
- **Social mutuals (dozens to low hundreds):** Neighbourhood pools for
|
||||
shared risk — appliance failure, minor medical bills, income
|
||||
disruption. These are the original Phase 2 pools, now standardized.
|
||||
Formation is a few clicks: define the contribution schedule, define
|
||||
the claim gate rules, invite members. The protocol handles
|
||||
everything else. These pools cover risks that no conventional insurer
|
||||
would serve because the premium per member is too small.
|
||||
|
||||
- **Commercial mutuals (hundreds to thousands):** Industry-specific
|
||||
pools that compete with commercial insurers. A typical example: a
|
||||
pool of 500 small manufacturers that covers equipment breakdown,
|
||||
business interruption, and liability. The pool's underwriting is
|
||||
granular to the individual member — risk tiering based on verified
|
||||
maintenance logs, safety records, and claims history — rather than
|
||||
the broad category pricing of conventional commercial insurance.
|
||||
Members with better verified records pay substantially less, which
|
||||
creates a feedback loop: safer operations → lower premiums → more
|
||||
investment in safety → safer operations.
|
||||
|
||||
- **Reinsurance pools (pools of mutuals):** The most architecturally
|
||||
novel tier. Groups of mutuals pool at a higher layer to cover
|
||||
correlated risk — a natural disaster that triggers claims across
|
||||
multiple neighbourhood pools, or an industry-wide downturn that
|
||||
triggers claims across multiple commercial pools. A gate rule on
|
||||
each member mutual's claim rate triggers a payout from the larger
|
||||
pool. This mirrors how traditional reinsurance works (Lloyd's,
|
||||
Swiss Re), but fully automated and transparent — the proof log of
|
||||
each member mutual serves as the financial report for the larger
|
||||
pool's underwriting.
|
||||
|
||||
The structural advantage of protocol-native mutual insurance over
|
||||
conventional insurance:
|
||||
|
||||
| Dimension | Conventional insurance | Protocol mutual |
|
||||
|-----------+----------------------+-----------------|
|
||||
| Formation cost | Millions (licensing, capital reserve, compliance) | Near zero (define gate rules, invite) |
|
||||
| Transparency | Annual financial statements | Real-time proof log |
|
||||
| Exit cost | Policy cancellation, search for new carrier | DID takes verified history to any pool |
|
||||
| Competition axis | Brand + distribution + claims service | Gate rule design + contribution structure |
|
||||
| Risk tiering | Broad categories (age, geography, industry) | Granular (individual verified behaviour) |
|
||||
| Fraud detection | Investigative (after claim filed) | Structural (fraud requires collusion across verified identities) |
|
||||
|
||||
The most important consequence: mutual insurance becomes viable for
|
||||
categories that conventional insurance cannot profitably serve.
|
||||
Microinsurance in developing markets, where the premium is measured in
|
||||
dollars per year and the administrative cost of a conventional policy
|
||||
exceeds the premium. Niche occupational risks too small for an actuary
|
||||
to model. Pre-existing conditions that conventional insurance excludes
|
||||
— a mutual pool of people with the same condition can self-insure
|
||||
because adverse selection is symmetric (everyone has the condition, so
|
||||
no one is selecting out).
|
||||
|
||||
*Payment systems:*
|
||||
|
||||
Card networks (Visa, Mastercard) have lost their structural position in
|
||||
the verified economy. Their product — authorization + clearing +
|
||||
settlement at 1.5-3% — is replaced by protocol-native payment attestation
|
||||
at millicents per transaction. The card networks still process
|
||||
transactions in the conventional internet tier, but the highest-value
|
||||
and highest-volume transactions have moved to the protocol.
|
||||
|
||||
The correspondent banking system for cross-border payments has
|
||||
essentially disappeared. A verified DID in one jurisdiction sends to a
|
||||
verified DID in another jurisdiction. The exchange rate is the only
|
||||
friction. SWIFT, which processed 15,000 messages per second at its peak,
|
||||
is a legacy messaging protocol for conventional-bank-to-conventional-bank
|
||||
communication. The protocol's transaction volume has surpassed it by
|
||||
orders of magnitude.
|
||||
|
||||
Central bank digital currencies, where they exist, operate on the
|
||||
protocol's verification layer. A CBDC gate attests to the state of each
|
||||
digital currency unit — issued by the central bank, held by a verified
|
||||
DID, transferred through gate-signed transactions. Programmable monetary
|
||||
policy becomes feasible: the central bank sets a gate rule for reserve
|
||||
requirements, and every bank's compliance is attested in real time.
|
||||
|
||||
*Accounting:*
|
||||
|
||||
The accounting profession has completed its transformation. The general
|
||||
ledger is a gate. Every transaction is attested. Triple-entry accounting
|
||||
is the standard — every transfer has the sender's signature, the
|
||||
recipient's signature, and the protocol's proof log entry. Reconciliation
|
||||
between two entities is a single gate query: do both attestation logs
|
||||
agree?
|
||||
|
||||
The year-end audit is a gate rule that runs continuously. The auditor's
|
||||
annual sign-off is replaced by a cryptographic attestation: "the gate
|
||||
rule was correctly specified and the attestation log satisfies it."
|
||||
Audit opinions are real-time, not retrospective.
|
||||
|
||||
The accounting profession has split into two tracks:
|
||||
|
||||
1. **Gate rule designers** — accountants who specify attestation rules
|
||||
for accounting frameworks (GAAP, IFRS, tax codes, regulatory
|
||||
reporting). This is the growth track. A gate rule designer is part
|
||||
accountant, part verification engineer. They define what constitutes
|
||||
a valid transaction, a correct recognition event, or a permissible
|
||||
reportable item.
|
||||
2. **Forensic accountants** — trace fraud through attestation logs. This
|
||||
track shrank but has not vanished. Fraud still occurs when gate
|
||||
rules are mis-specified or when collusion across multiple verified
|
||||
identities creates a false attestation. The work is more technical
|
||||
and more impactful — a fraud finding in an attestation log is a
|
||||
mathematical proof, not a judgment call.
|
||||
|
||||
The Big Four's audit practices are a fraction of their former size.
|
||||
Their consulting and advisory practices, now oriented around gate rule
|
||||
design and verification integration, have partially absorbed the lost
|
||||
revenue. The profession employs fewer people than it did, but each
|
||||
practitioner is more leveraged — a single gate rule designer defines
|
||||
attestation logic that applies to millions of transactions, rather than
|
||||
a single audit team checking thousands.
|
||||
|
||||
**Governance and law — full transformation:**
|
||||
|
||||
*Legislation — laws as gate rules:*
|
||||
|
||||
A law that can be encoded as a gate rule is perfectly enforced. The
|
||||
question is no longer "does this transaction comply with the law?"
|
||||
It is "does this transaction pass the gate rule?" This changes the
|
||||
nature of legislation fundamentally.
|
||||
|
||||
A regulator considering a new rule now thinks in two registers: the
|
||||
natural-language statute (subject to interpretation, litigation, and
|
||||
evasion) and the gate rule (self-executing, unambiguous, and
|
||||
enforceable at the point of action). Some laws are natural for
|
||||
encoding — transaction reporting thresholds, emissions limits, safety
|
||||
standards, tax rates. Others are not — prohibitions on "unfair or
|
||||
deceptive acts" (FTC Act Section 5), "reasonable care" standards,
|
||||
or any rule that relies on context-dependent judgment.
|
||||
|
||||
The central legislative challenge of the protocol era is deciding what
|
||||
NOT to encode. A gate rule that perfectly enforces a bad law is worse
|
||||
than imperfect enforcement of a good one. A prohibition on "excessive
|
||||
risk-taking by banks" cannot be encoded without first defining
|
||||
excessive in terms a gate can evaluate — and that definition will be
|
||||
gamed. A gate rule cannot exercise prosecutorial discretion, grant
|
||||
jury nullification, or make equitable exceptions. The legislative
|
||||
choice to leave a law unencoded is a choice to preserve human judgment
|
||||
in its enforcement, and it should be as deliberate as the choice to
|
||||
encode.
|
||||
|
||||
Every parliament or legislature that adopts gate rule capability also
|
||||
establishes a gate rule auditing office — analogous to a
|
||||
congressional budget office or legislative counsel, but for technical
|
||||
impact assessment. Before a bill with a gate rule is enacted, the
|
||||
auditing office runs the proposed gate rule against real transaction
|
||||
data to answer: what does it actually do? Who does it affect? Can it
|
||||
be evaded? Are there unintended consequences? This is not optional
|
||||
oversight — it is a necessary function because a gate rule's effects
|
||||
are precisely knowable only by running it, and enacting a rule without
|
||||
knowing its effects is legislative malpractice.
|
||||
|
||||
*Law practice — contract engineering:*
|
||||
|
||||
The legal profession has split into two tracks, more sharply than
|
||||
accounting:
|
||||
|
||||
1. **Contract engineers** — lawyers who design gate rules that encode
|
||||
contractual intent. Instead of writing "Party A shall deliver the
|
||||
goods within 30 days of receiving payment," the contract engineer
|
||||
specifies: a payment-received event triggers a delivery-required
|
||||
obligation, tracked on a shared proof log, with automatic escrow
|
||||
release upon attested delivery and arbitration trigger on dispute.
|
||||
This is a fundamentally different skill from conventional contract
|
||||
drafting — it requires understanding both the legal framework (what
|
||||
constitutes a binding agreement) and the verification framework
|
||||
(what constitutes a provable event). This track is the growth
|
||||
track, absorbing talent from the contracting bar.
|
||||
|
||||
2. **Litigators for the protocol** — lawyers who argue about what gate
|
||||
rules mean when they produce outcomes the parties did not intend.
|
||||
If a gate rule says "pay X when condition Y occurs" and the parties
|
||||
disagree about whether condition Y actually occurred despite the
|
||||
attestation, the dispute is about the attestation's validity or the
|
||||
rule's specification, not about the facts. This track is smaller
|
||||
than the commercial litigation bar of the platform era, because the
|
||||
volume of disputes drops drastically. Most commercial disputes
|
||||
never reach a lawyer — the gate rule executes according to its
|
||||
specification, and if the specification was correct, there is
|
||||
nothing to dispute.
|
||||
|
||||
3. **What survives intact:** Constitutional law, criminal law (where
|
||||
discretion, intent, and proportionality matter), family law,
|
||||
human rights law, and any area where the law balances competing
|
||||
interests rather than verifying compliance with rules. These
|
||||
require human judgment that cannot be encoded as gate rules. A
|
||||
family court deciding custody is not a gate rule problem. A
|
||||
prosecutor deciding whether to charge is not a gate rule problem.
|
||||
Asylum adjudication is not a gate rule problem. The protocol
|
||||
transforms commercial and regulatory law; it does not touch the
|
||||
core of adjudicative judgment.
|
||||
|
||||
*Elections:*
|
||||
|
||||
Elections have fully adopted the protocol's verification infrastructure
|
||||
for registration and tallying. The voter registry is a gate — it
|
||||
attests that a DID corresponds to a living, eligible voter in a
|
||||
specific district. The tally is a gate rule — it counts the attested
|
||||
votes and produces a result that any citizen can verify by querying
|
||||
the proof log. The "stolen election" narrative that depends on
|
||||
uncertainty about who voted or whether votes were counted accurately
|
||||
has lost its evidentiary basis — the proof log is public and any
|
||||
citizen can independently verify the count.
|
||||
|
||||
The ballot itself goes through a privacy-preserving mix that severs
|
||||
the link between DID and vote. The protocol's relay network provides
|
||||
the foundation: votes enter through one relay, are shuffled through a
|
||||
mix network, and emerge as an anonymized set that the tally gate rule
|
||||
counts. The voter receives a cryptographic receipt that their vote
|
||||
entered the mix, but cannot prove to a third party which candidate
|
||||
they selected. Coercion resistance is structural — a vote-buyer cannot
|
||||
verify that the voter voted as instructed.
|
||||
|
||||
Not every jurisdiction has adopted protocol-native elections.
|
||||
Authoritarian states continue to run conventional elections (or no
|
||||
elections), and the contrast between their non-verifiable outcomes and
|
||||
the protocol's transparent ones is a legitimacy problem they cannot
|
||||
solve. A state that claims an election result without a verifiable
|
||||
proof log is making a claim that the protocol's citizens can
|
||||
demonstrate is unsupported — not by accusing the state of fraud, but
|
||||
by pointing to the absence of evidence that a protocol-native
|
||||
election would provide as a matter of course.
|
||||
|
||||
*Parliaments and legislatures:*
|
||||
|
||||
Legislatures have adapted to the protocol era with institutional
|
||||
changes:
|
||||
|
||||
- **Gate rule auditing offices** — independent bodies that analyze
|
||||
proposed gate rules before enactment. Staffed by a mix of lawyers,
|
||||
verification engineers, and domain experts. A bill that references
|
||||
a gate rule must include the rule's specification and the auditing
|
||||
office's impact analysis before it can be voted on. This creates a
|
||||
new legislative bottleneck — a bill cannot be enacted without a
|
||||
technical analysis of what the gate rule actually does.
|
||||
- **Technical question time** — legislators must understand at a
|
||||
conceptual level what a gate rule does and what it means to encode
|
||||
a policy preference as a verification rule. This does not require
|
||||
every legislator to be a programmer, but it requires enough
|
||||
technical literacy to ask "what happens when this gate rule
|
||||
interacts with that one?" Legislatures that cannot develop this
|
||||
capacity find themselves irrelevant to the most consequential
|
||||
policy decisions of the era.
|
||||
- **Legacy law committees** — committees responsible for reviewing
|
||||
existing laws to determine whether each should be encoded as a gate
|
||||
rule, left as conventional legislation, or repealed. This is a
|
||||
multi-decade project analogous to the codification of the common
|
||||
law in the 19th and 20th centuries, but compressed — a state's
|
||||
entire regulatory code must be assessed for whether each rule is
|
||||
suitable for gate encoding, and the assessment itself is a
|
||||
significant undertaking.
|
||||
|
||||
*Local and national politics:*
|
||||
|
||||
Political organization has been transformed by the protocol's structural
|
||||
properties:
|
||||
|
||||
- **Constituent verification:** A politician can verify that a message
|
||||
claiming to come from a constituent actually comes from someone in
|
||||
their district. The constituent's DID attests to their residency
|
||||
gate. This eliminates astroturfing as a political tactic — a
|
||||
campaign that claims "thousands of constituents are angry about X"
|
||||
can be verified or refuted by checking whether the DIDs behind the
|
||||
messages are actually in the district.
|
||||
- **Direct democracy:** The protocol makes it technically feasible to
|
||||
hold frequent, verifiable referenda. The coordination costs —
|
||||
identifying the electorate, distributing ballots, collecting votes,
|
||||
verifying the count — are eliminated by the protocol
|
||||
infrastructure. The question of whether this is desirable is
|
||||
political, not technical: do we want more direct democracy, or do
|
||||
we want to preserve representative structures that filter for
|
||||
deliberation and expertise?
|
||||
- **Campaign finance compliance:** The contribution gate rule is the
|
||||
standard enforcement mechanism. A candidate's DID cannot accept
|
||||
contributions that violate campaign finance law — the gate rule
|
||||
refuses them before they arrive. Enforcement agencies shift from
|
||||
investigating violations to auditing gate rule specifications.
|
||||
- **Organizing freedom:** A political movement can organize through
|
||||
the protocol with the same censorship resistance as any other
|
||||
community. The government cannot surveil the membership, disrupt
|
||||
the coordination, or block the movement's publication. This
|
||||
applies symmetrically to movements the government likes and
|
||||
movements it does not. The protocol does not distinguish between a
|
||||
democratic opposition in an authoritarian state and a hate group
|
||||
in a democratic one — both have the same architectural protection.
|
||||
This symmetry is the hardest political fact of the protocol era,
|
||||
and democratic states must confront it without the ability to
|
||||
selectively suppress.
|
||||
|
||||
*The authoritarian dimension — the asymmetry problem:*
|
||||
|
||||
The protocol's privacy and censorship resistance properties are
|
||||
asymmetrical: they protect citizens from government more than they
|
||||
protect government from citizens. This is by design, but it creates a
|
||||
structural tension that democratic states must navigate.
|
||||
|
||||
A democratic state that depends on surveillance for tax enforcement,
|
||||
crime investigation, or national security finds that the protocol
|
||||
limits what it can see. A gate attestation proves that a transaction
|
||||
occurred but reveals nothing about the parties' identities beyond what
|
||||
the gate rule requires. The state cannot demand to see the full
|
||||
transaction log because the gate does not store it — the proof log
|
||||
stores attestations, not content.
|
||||
|
||||
This is not a bug or a loophole. It is the protocol's core architectural
|
||||
choice: verification enables compliance without surveillance. A tax
|
||||
gate rule can attest that the correct tax was paid on a transaction
|
||||
without revealing the transaction's amount or the parties' identities
|
||||
to the tax authority. The tax authority learns "tax was correctly
|
||||
paid" rather than "here is all the data about every transaction."
|
||||
|
||||
Authoritarian states face a starker choice. They can ban the protocol
|
||||
(which is visibly ineffective — citizens who can access the relay
|
||||
network retain their speech and association). They can accept the
|
||||
protocol's limits (which means their surveillance state stops working
|
||||
for citizens who use it). Or they can create their own state-controlled
|
||||
verified network (which defeats the purpose — citizens will know it
|
||||
is surveilled and treat it accordingly). All three options are bad
|
||||
from the state's perspective; the protocol is designed so that there
|
||||
is no good option for a state that wants to surveil its citizens.
|
||||
|
||||
The asymmetry is the protocol's most important political feature.
|
||||
It is also its most vulnerable — a democratic state under sufficient
|
||||
threat (terrorism, foreign interference, pandemic) may decide that
|
||||
surveillance capability is worth sacrificing verification. The
|
||||
protocol cannot prevent a democratic state from choosing
|
||||
surveillance; it can only ensure that the choice is visible and
|
||||
deliberate rather than the default operating mode.
|
||||
|
||||
The internet of 2010-2030 was defined by centralized platforms that
|
||||
extracted value from user data and locked users into walled gardens.
|
||||
The internet of 2030+ is defined by a protocol that gives users
|
||||
ownership of their identity, reputation, content, and data. Centralized
|
||||
platforms (Meta, Google, Twitter, Reddit, Discord) still exist as
|
||||
applications, but their lock-in is broken — portable identity and
|
||||
portable reputation mean users stay because they choose to, not because
|
||||
they cannot leave. The conventional internet does not shut down, but
|
||||
its economic center of gravity has moved: the most valuable transactions,
|
||||
the most trusted interactions, and the highest-margin services now
|
||||
operate on the verified protocol layer. The conventional internet
|
||||
becomes what the web was to AOL — the same physical infrastructure,
|
||||
but a fundamentally different economic and architectural layer on top.
|
||||
|
||||
**Economics:** Two-tier economy is stable. Verification infrastructure
|
||||
companies are $500B-$2T in combined market cap. Protocol-based commerce
|
||||
processes trillions of dollars in annual transaction value with near-zero
|
||||
intermediation fees. The creator economy is 5-10x larger than in the
|
||||
platform era because creators keep 95% instead of 70%. The freelance
|
||||
economy is 2-3x larger because escrow and arbitration are trustless.
|
||||
The contract market is global, not jurisdictional. The labor market has
|
||||
fully restructured — "verification engineer" and "protocol integrator"
|
||||
are standard career paths. The earnings gap between protocol-sector
|
||||
workers and legacy-sector workers is a policy concern, similar to the
|
||||
college/non-college wage gap of the 20th century.
|
||||
@@ -4,7 +4,7 @@
|
||||
:ID: 558154ea-e63a-4c45-998c-26ce8588585b
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: Revenue — Streams, Timing, and First-Mover Window
|
||||
#+title: Revenue
|
||||
#+filetags: :passepartout:revenue:index:business-model:compliance:first-mover:
|
||||
|
||||
This page is the entry point for revenue generation thinking across all three Passepartout subsystems. Revenue splits cleanly across the two development phases defined in [[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][time estimates]]. Each component enables different revenue primitives.
|
||||
|
||||
@@ -1,194 +0,0 @@
|
||||
:PROPERTIES:
|
||||
:ID: 57f9538a-6270-4302-8d07-d742168419eb
|
||||
:ID: alternative-growth-social-first
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: Alternative Growth — Social-First Scenario
|
||||
#+filetags: :passepartout:growth:strategy:alternative:
|
||||
|
||||
The existing growth-strategy assumes institution-first growth: compliance → developer → consumer → regulatory. This page documents an alternative path: grow as a general-purpose social identity network, let institutions catch up later. Passepartout's three subsystems ([[id:c3b3dc41-945f-54e9-84eb-ca014114f1be][the verification subsystem]], [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][the social protocol]]) are the same; the order of operations and the primary growth levers differ fundamentally.
|
||||
|
||||
* Why This Path Exists
|
||||
|
||||
The institution-first scenario ([[id:d28adac8-08a1-40c4-ae43-b5d8d7b1743f][growth strategy]]) takes the product's core technical capability — verification — and finds the customer with the clearest pain. That is the safe bet. But Passepartout ships with a second product that has nothing to do with verification: the social protocol, a unified publishing network, contract platform, payment network, and decentralized identity layer rolled into one. No product on the market offers this combination — ENS is names, Bluesky is social, Stripe is payments, DocuSign is contracts. The social protocol replaces all four with one provable layer.
|
||||
|
||||
The social-first scenario leans into what the social protocol is /as a product/, not what Passepartout is /as a technology/. Publishing, payments, contracts, and identity are all mass-market primitives. They can grow without ever mentioning ACL2, gate rules, or compliance. Verification is the infrastructure underneath, invisible to users until they need it.
|
||||
|
||||
Historical precedent: Instagram was a check-in app with filters. The camera and social graph came first; the advertising platform came later. Twitter was SMS broadcast; the real-time news network was emergent. In each case the product that users wanted had a different shape than the product that ultimately captured value.
|
||||
|
||||
* Phase 0: Unified Digital Existence Layer (0 → 10K users, 3-12 months)
|
||||
|
||||
The key premise: the social protocol is not an identity product. It is four layers in one — a publishing network, a contract platform, a payment network, and decentralized infrastructure — all unified under a single identity. No product on the market offers this combination. ENS is names only. Bluesky is social only. Stripe is payments only. The social protocol replaces all of them with one provable layer.
|
||||
|
||||
Customer: Anyone who touches more than one of these layers today and feels the friction of managing separate accounts, separate reputations, and separate data silos. The most likely first adopters:
|
||||
- Creators who publish across platforms and want verified ownership of their content
|
||||
- Freelancers and contractors who send invoices, sign agreements, and manage multiple identities
|
||||
- Crypto-natives who understand self-sovereignty but are tired of blockchain UX
|
||||
- Developers building agents that need a persistent identity, payment channel, and data store
|
||||
|
||||
The /minimum viable social protocol/ must ship all four layers at Phase 0. Not fully featured, but functional — enough that a user can register, publish a signed post, send a payment, and sign a simple contract using one identity. The value is in the unification: one account replaces four.
|
||||
|
||||
Growth lever: Multi-vector network effects. The social protocol grows not on a single curve but on four simultaneous curves:
|
||||
1. Publishing: each new creator attracts readers, who may become creators
|
||||
2. Payments: each new payment user creates liquidity that makes the network more useful for everyone
|
||||
3. Contracts: each new contract written on the social protocol creates a template and a precedent
|
||||
4. PDS: each new PDS increases the federation surface and the [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]] supply
|
||||
|
||||
Any of these can be the primary growth vector in a given market. If publishing stalls in one region, payments might take off. This redundancy dramatically increases the probability that /some/ vector finds PMF.
|
||||
|
||||
Tactics:
|
||||
|
||||
1. /Entry point optimization./ Ship all four layers but actively measure which one drives signups in each channel. If a blog post about "verified publishing" drives 10× more signups than a post about "decentralized identity," double down on publishing. The platform is unified enough that users who join for one reason discover the other three.
|
||||
|
||||
2. /Creator tools./ Offer a one-click "publish with provenance" widget. A creator writes on Substack, Medium, or their own blog, pastes the social protocol embed, and every post is automatically signed and timestamped. Readers see a blue checkmark that links to the social protocol attestation. This is a /better/ blue checkmark than Twitter's because it's cryptographically verifiable — and it works /across/ platforms.
|
||||
|
||||
3. /Freelancer onboarding./ Ship an invoice-and-contract template: "Send a verified invoice. Get a signed contract. Get paid on the social protocol." The freelancer registers once, and their invoices, contracts, and payment history are provably theirs. This is a /productivity tool/ first and a social network second — users join to get paid, stay because their professional reputation is on it.
|
||||
|
||||
4. /PDS hosting as infrastructure./ The PDS is the backbone, not the headline. Freemium model: first 1GB free, $5-15/mo for unlimited. The PDS stores your identity, content, contracts, and payment history in one place. The value prop: /one account, one data store, one reputation, everywhere/.
|
||||
|
||||
5. /Fee-based revenue./ The social protocol takes 0.5-2% on payment transactions and 5-10% on marketplace contracts (data [[id:67faf52f-9126-50a7-b87e-2bedc610dac7][licensing]], compute). These fees are invisible to users (built into the platform layer) and scale with usage. Unlike subscription revenue, they require zero active selling — the platform grows, fees follow.
|
||||
|
||||
Revenue:
|
||||
| Stream | Year 1 target | Mature |
|
||||
|--------+--------------+--------|
|
||||
| Payment processing fees (0.5-2%) | $100K-1M | $10-50M/yr |
|
||||
| PDS hosting subscriptions | $50K-200K | $1-3M/yr |
|
||||
| Marketplace contract commissions | $20K-100K | $5-20M/yr |
|
||||
| Premium username auctions | $50K-300K | $2-5M/yr |
|
||||
| Creator tools (Pro tier) | $50K-200K | $2-10M/yr |
|
||||
| Total | $270K-1.8M | $20-88M/yr |
|
||||
|
||||
The fees are the key difference from my earlier estimate. The social protocol's payment and contract layers generate revenue /per transaction/ without requiring subscription growth. A user who never pays for PDS hosting still generates fees if they send a payment or sign a contract on the network.
|
||||
|
||||
Key metric: Platform usage across any of the four layers. Fee volume (total value processed through payments + contracts). Not DAU — a user who joins for payments and never publishes is still generating revenue.
|
||||
|
||||
Failure mode: The unified platform is harder to explain than a single-purpose product. "One account for identity, publishing, payments, and contracts" sounds like a pitch deck, not a product. The risk is that the /scope/ of the social protocol makes it incomprehensible — users don't know what problem it solves because it solves too many. The mitigations: optimize for a single entry vector per channel, let users discover the others naturally.
|
||||
|
||||
* Phase 1: Network Effects — The Social Graph (10K → 1M users, 1-3 years)
|
||||
|
||||
Customer: The early adopter base expands to include privacy-conscious mainstream users. The trigger is a /platform failure event/: a major platform bans a creator, de-platforms a community, or suffers a data breach. When that happens, the social protocol is ready — it offers the same social primitives (messaging, identity, publishing) but with ownership.
|
||||
|
||||
Growth lever: Metcalfe's law + switching cost. Each new user makes the network more valuable. But the real lock-in is the /reputation graph/: attestations, signatures, and data provenance are cumulative. A user with 3 years of verified activity on the social protocol cannot replicate that on any other platform. The switching cost grows with time.
|
||||
|
||||
Tactics:
|
||||
|
||||
1. Ship verified messaging. Every message between social protocol users is signed and timestamped. No third party can modify or delete it. The product pitch: /Twitter, but your tweets are yours, and nobody can rewrite history/.
|
||||
|
||||
2. Publish an attestation API. Third-party services (news outlets, marketplaces, social platforms) can query the social protocol to verify a user's reputation. News comments show "verified human, 2yr history, no abuse flags." This creates /outbound value/ — the network becomes useful to people who aren't even on it.
|
||||
|
||||
3. Offer PDS-to-PDS federation. Social protocol instances communicate directly. No central server. This differentiates from every centralized platform and gives a structural privacy advantage that no amount of VC funding can replicate.
|
||||
|
||||
4. Introduce data licensing. Users can license their verified data to AI training companies, researchers, advertisers — on their own terms, with their own price. The social protocol takes a 10-15% commission. This creates a /revenue share/ that users understand viscerally. Compare: X/Twitter makes billions selling user data and gives nothing back. Social protocol users get paid.
|
||||
|
||||
5. Verification becomes visible. Each user's profile shows a "verification score" based on the length and depth of their attested history. Long-time users get a visible badge. This creates status competition around the /one thing nobody else can offer/: provable history.
|
||||
|
||||
Revenue:
|
||||
| Stream | Year 3 target | Mature |
|
||||
|--------+--------------+--------|
|
||||
| PDS hosting subscriptions | $500K-2M | $10-50M/yr |
|
||||
| Data licensing commissions | $200K-1M | $20-100M/yr |
|
||||
| Premium username renewals | $100K-500K | $5-10M/yr |
|
||||
| Verified badge program | $100K-300K | $2-5M/yr |
|
||||
| Attestation API (per-query) | $50K-200K | $5-20M/yr |
|
||||
| Total | $1-4M | $42-185M/yr |
|
||||
|
||||
Key metric: Daily active PDS users. Inter-instance messages per day. Attestation API queries.
|
||||
|
||||
Failure mode: Network effects fail to trigger because the user experience is not /better/ than existing platforms — it's /different/. Different is not enough. The product must match or exceed the UX of mainstream social platforms while offering the ownership advantage. If the UX gap is too large, users stay on Twitter/Bluesky/Threads despite the privacy cost.
|
||||
|
||||
* Phase 2: The Institution Crossover (1M → 10M users, 2-5 years)
|
||||
|
||||
Customer: At 1M+ active identities, the network has critical mass. Institutions (universities, media companies, government agencies, enterprises) can no longer ignore it because /their users are on it/. The crossover happens organically: a university registrar wants to issue verified credentials. A newsroom wants to publish with verified provenance. A regulator wants to use the social protocol's attestation infrastructure because it already has users.
|
||||
|
||||
Growth lever: Institutional network effects. Every institution that joins brings 10K-100K users with it (employees, students, customers). Each new institutional user increases the value of verification for everyone else. The growth curve becomes logistic with institutional jumps, not smooth organic growth.
|
||||
|
||||
Tactics:
|
||||
|
||||
1. Ship the environment subsystem enterprise bundle (SSO, compliance reports, fleet management, audit logging). This was the /entire/ Phase 0-1 of the institution-first scenario. Here it is a Phase 2 feature — built to serve institutions that are already /inside/ the network, not sold to cold prospects.
|
||||
|
||||
2. Offer verified credentialing: degrees, certifications, professional licenses, issued on the social protocol, verifiable by anyone. The institution pays for the issuance. The graduate gets a portable, provable credential.
|
||||
|
||||
3. Offer provenance publishing: news organizations publish articles signed by their social protocol identity. Readers verify provenance in one click.
|
||||
|
||||
4. Verification appliances are now a /fulfillment order/, not a sales pitch. Institutions already inside the network ask: "Can we run our own instance?" The answer is yes — here is an environment subsystem appliance. The gate rule SDK is a value-up, not a product.
|
||||
|
||||
5. The compute marketplace activates naturally. With 10M+ users and thousands of institutions, compute supply and demand are both present without bootstrapping.
|
||||
|
||||
Revenue:
|
||||
| Stream | Year 5 target | Mature |
|
||||
|--------+--------------+--------|
|
||||
| Enterprise environment subsystem seats | $5-20M | $50-200M/yr |
|
||||
| Verified credential issuance | $2-10M | $20-100M/yr |
|
||||
| Compute marketplace fees | $1-5M | $50-200M/yr |
|
||||
| PDS hosting (scaled) | $2-10M | $20-50M/yr |
|
||||
| Data licensing (scaled) | $1-5M | $20-100M/yr |
|
||||
| Verification appliances | $2-10M | $50-100M/yr |
|
||||
| Total | $13-60M | $210-750M/yr |
|
||||
|
||||
Key metric: Institutional join events. Environment subsystem subscriptions. Credentials issued.
|
||||
|
||||
Failure mode: The institution crossover never comes because the social graph stalls at 1M users — enough for a niche, not enough for critical mass. The network becomes a high-quality-but-small community like early App.net or Mastodon. Verification is real but irrelevant because the rest of the world is on different platforms. The institution-first scenario is still possible from here (direct enterprise sales), but the supposed advantage of "users first" has not materialized.
|
||||
|
||||
* Phase 3: Default Infrastructure (10M → 1B+, 5-15 years)
|
||||
|
||||
Customer: At this scale, the social protocol is the default identity and communication layer for a significant fraction of internet users. New users join because /everyone is there/. Institutions join because /everyone is there/. The regulatory capture that the institution-first scenario required as a /growth lever/ happens here as a /consequence/ — regulators adopt social protocol attestation because it is the standard.
|
||||
|
||||
Growth lever: Default status. The network is the path of least resistance. A new social platform would need to replicate not just the user base but the entire attestation history, compute marketplace, and institutional infrastructure. The moat is not legal (regulation) but practical (installed base + cumulative value).
|
||||
|
||||
Tactics: Similar end state to the institution-first scenario — [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]], certified appliance sales, insurance marketplace, nation-state deployments. The difference is the /path/ and the /character/ of the moat:
|
||||
|
||||
- Institution-first moat: regulatory lock-in. You comply because the law requires it.
|
||||
- Social-first moat: installed-base lock-in. You join because everyone is there.
|
||||
|
||||
The regulatory moat is faster to deploy but brittle (a change in government can undo it). The installed-base moat is slower to build but self-reinforcing.
|
||||
|
||||
Revenue: Same end state as growth-strategy.org Phase 3 — $1B+ across certification, infrastructure rent, marketplace fees, and insurance underwriting.
|
||||
|
||||
* Comparison: Two Paths Side By Side
|
||||
|
||||
| Dimension | Institution-first | Social-first |
|
||||
|-----------+------------------+-------------|
|
||||
| First customer | CISO, compliance buyer | Creators, devs, payment users |
|
||||
| First revenue | $2-12M (year 1) | $500K-3M (year 1) |
|
||||
| Time to $10M ARR | 12-24 months | 2-4 years |
|
||||
| Time to $50M ARR | 2-4 years | 4-7 years |
|
||||
| Time to $1B+ | 5-15 years | 8-20 years |
|
||||
| Capital requirement | Low (revenue-funded) | Low-Moderate (fees fund growth) |
|
||||
| Marketing cost | Sales team + compliance mktg | Community + product-led growth |
|
||||
| Key execution skill | Enterprise sales | Consumer product + platform design |
|
||||
| Network effect trigger | Developer SDK (Phase 1) | Multi-vector: any of 4 layers |
|
||||
| Phase 0 offer | Compliance report | Unified identity + pub + pay + contract |
|
||||
| Moat type | Regulatory + insurance | Installed base + attestation |
|
||||
| Moat durability | Good (legal) | Strong (practical) |
|
||||
| Entry vectors | One: compliance pain | Four: publishing, payments, contracts, ownership |
|
||||
| Failure mode | Wrong pricing, too early | Any vector stalls — but all 4 must |
|
||||
|
||||
* Assessment: Which Is More Likely?
|
||||
|
||||
I initially assessed institution-first as significantly more likely. The unified-layer correction narrows the gap considerably. Here is the revised assessment:
|
||||
|
||||
The social-first path's strongest argument — which I dismissed too quickly — is that the social protocol is not competing with any single product. A competitor who beats it on publishing (Substack, Medium) cannot also beat it on payments (Stripe, PayPal) and contracts (DocuSign, LexisNexis) and identity management — simultaneously. The unification is not a feature; it is the structural advantage. Each layer reinforces the others, and competing against the whole stack requires matching all four, which no existing product does.
|
||||
|
||||
The multi-vector growth also matters. The institution-first path has one entry vector (compliance pain) and one failure mode (wrong pricing or too early). The social-first path has four entry vectors, and any one of them reaching PMF carries the other three. The probability that publishing /or/ payments /or/ contracts /or/ identity ownership finds product-market fit is higher than the probability that any single one does.
|
||||
|
||||
The fee-based revenue model further improves Phase 0 economics. Payment processing fees scale with transaction volume, not user count. A small number of high-value users (freelancers sending invoices, creators selling subscriptions) can generate meaningful revenue before the network reaches critical mass.
|
||||
|
||||
However: the core tension remains. The team building Passepartout is a deep-tech verification team — their competence is ACL2, gate rules, provably correct systems. The social-first path requires the team to also be a consumer product team — UX design, growth loops, community management, creator partnerships, payment infrastructure, fraud detection. That is not /impossible/ (the team can hire) but it is a different company than the one building [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]].
|
||||
|
||||
The institution-first path monetizes the team's /existing/ competence from day one. The social-first path requires building a second competence (consumer platform) that does not exist yet. This is the real distinction, not the product's inherent potential.
|
||||
|
||||
My updated assessment: the institution-first path is still higher probability, but not by the wide margin I initially claimed. The gap is narrower because the social protocol as a unified layer is genuinely unprecedented.
|
||||
|
||||
The hybrid path may be the strongest: ship the four-layer social protocol as a public platform /alongside/ the enterprise compliance sales.
|
||||
|
||||
* References
|
||||
|
||||
- [[id:d28adac8-08a1-40c4-ae43-b5d8d7b1743f][Primary growth strategy — institution-first]]
|
||||
- [[id:ed05cab4-88e9-4e25-b7c9-346fa39c69a0][Revenue streams by component]]
|
||||
- [[id:64708e1f-00e9-4cb7-b44b-ea0b98e5296d][Social protocol contract platform details]]
|
||||
- [[id:528a0f6c-6fd6-41ed-9d59-237958bdaef2][Effects and growth as interleaved curves]]
|
||||
- [[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][Development timeline — Phase Zero and End State]]
|
||||
|
||||
#+begin_quote
|
||||
The social-first path is attractive because the end state is stronger. But the path to it requires building a consumer product alongside the deep-tech verification infrastructure — essentially running two startups in parallel. The [[id:0f949f6c-4cf1-49eb-b9a4-ebcac27ee548][Social protocol Social Space requirements]] describe the community interaction model that makes the social-first path viable..
|
||||
#+end_quote
|
||||
@@ -3,7 +3,7 @@
|
||||
:ID: agora-contracts
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: Passepartout Social Protocol — Smart Contracts and the Contract Marketplace
|
||||
#+title: Smart Contracts and Contract Marketplace
|
||||
#+filetags: :passepartout:social-protocol:contracts:revenue:smart-contracts:
|
||||
|
||||
The social protocol's infrastructure — DIDs (identity), DIDComm (communication), PDS (state), gate rules (logic), ACL2 (verification) — together form a full smart contract platform. Every piece is already in the architecture. This page describes what contracts are possible, how they generate revenue, and why the social protocol's approach is structurally stronger than existing platforms.
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
:ID: agora-entry-strategy
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: Passepartout Social Protocol Entry Strategy — Finding the Low-Hanging Use Cases
|
||||
#+title: Social Protocol Entry Strategy
|
||||
#+filetags: :passepartout:social-protocol:strategy:entry:go-to-market:
|
||||
|
||||
The social protocol replaces 20+ centralized platforms across social, publishing, video, messaging, e-commerce, contracts, and identity. But attempting to launch all at once guarantees failure — the cold start problem kills any network that requires everything to work before anything is useful.
|
||||
@@ -180,5 +180,5 @@ Organized communities are the entry point because they force the protocol to be
|
||||
- Social Protocol Platform Replacement Strategy
|
||||
- Social Space — Collective Personas and Governance
|
||||
- Exchange and Contracts — SCAL, Escrow, Arbitration
|
||||
- [[id:57f9538a-6270-4302-8d07-d742168419eb][Social-first growth scenario]]
|
||||
- [[id:57f9538a-6270-4302-8d07-d742168419eb][Adoption — social process section]]
|
||||
- [[id:1bc22b89-d3eb-4f6d-bcfc-2b0c19c8ed8f][Full competitive landscape]]
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: 1d074690-a279-59cb-b91d-e9a22ae104ad
|
||||
:END:
|
||||
#+title: Passepartout Social Protocol — The Society (Decentralized Network)
|
||||
#+title: Social Protocol Overview
|
||||
#+filetags: :passepartout:social-protocol:network:dids:
|
||||
|
||||
Passepartout Social Protocol is the decentralized identity and communication layer that connects [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] instances:
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: 2e390c1d-65f3-5fb3-b898-ac3fc4291ee7
|
||||
:END:
|
||||
#+title: Premium Username Registry on Passepartout Social Protocol
|
||||
#+title: Premium Username Registry
|
||||
#+filetags: :passepartout:social-protocol:revenue:names:registry:
|
||||
|
||||
The DID system is permissionless — anyone generates their own DID via HD key derivation. But human-readable @handles (short names, common words, brand names) are naturally scarce. The early player controls the namespace registry.
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: efc76898-03f7-57ba-923d-35d65da88bb7
|
||||
:END:
|
||||
#+title: The Per-Domain Sufficiency Flip
|
||||
#+title: Sufficiency Flip
|
||||
#+filetags: :passepartout:sufficiency:flip:domain:knowledge:
|
||||
|
||||
The sufficiency flip is not a single event — it happens independently for each domain, and some domains never flip.
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
:ID: dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: Development Velocity and Timeline Estimates
|
||||
#+title: Development Timeline
|
||||
#+filetags: :passepartout:economics:development:timeline:velocity:orders-of-magnitude:
|
||||
|
||||
The [[id:2cdca4b0-6b41-44b4-acb0-af21d0e27b00][orders-of-magnitude time framework]] reveals that the original single-timeline estimate conflated two qualitatively different projects. The line counts are in plausible ranges for Lisp's density (~5-10× fewer lines than C++ for equivalent functionality), but the phases differ in their feedback regimes, constraints, and failure modes. The honest picture splits into two distinct phases.
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: 29e4dbf3-cf19-589c-8b14-389e8a39d564
|
||||
:END:
|
||||
#+title: Upgrade and Distribution Lifecycle
|
||||
#+title: Upgrade Lifecycle
|
||||
#+filetags: :passepartout:economics:upgrade:distribution:ontology:
|
||||
|
||||
Once instances diverge in both code and knowledge, naive git pull breaks things. [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]]'s architecture already has the primitives for safe upgrades:
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: 84a537b4-4256-50c8-91f5-dd5b4538418f
|
||||
:END:
|
||||
#+title: Verification Appliance (Hardware)
|
||||
#+title: Verification Appliance
|
||||
#+filetags: :passepartout:revenue:hardware:fpga:tenstorrent:
|
||||
|
||||
An FPGA or Tenstorrent card pre-loaded with a mature [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] image, [[id:c34940cc-090e-57c4-8020-e78b1d32b96c][domain-specific gate rules]], and a hardware root of trust. No cloud dependency.
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
:ID: 45258a2d-1675-562c-9024-5d1eb2f1ea56
|
||||
:ID: a5d59d12-b23e-58d6-a81b-9b8b06556949
|
||||
:END:
|
||||
#+title: The Evaluation Harness — Collective Regression Suite as Certification Monopoly
|
||||
#+title: Evaluation Harness
|
||||
#+filetags: :passepartout:economics:monopoly:certification:big-money:revenue:evaluation:regression:suite:collective:
|
||||
|
||||
#+hierarchy: 1 vision 2 service 3 spec
|
||||
@@ -29,6 +29,8 @@ The accumulated regression suite — thousands of edge cases from every deployed
|
||||
**Target:** AI labs proving their agents' capabilities, enterprise procurement requiring independent verification.
|
||||
**Price:** $50K-$200K per certification.
|
||||
|
||||
**Model certification extends this:** the same evaluation harness certifies not just gate decisions but model validity. A neural force field or docking scoring function is certified against the provenance store — validated training data, benchmark performance, distribution match pass rate, validity envelope coverage. The certification answers: "is this model trustworthy for this domain?" not just "did the gate decide correctly." A model that passes provenance certification earns the same verified badge as a gate stack that passes the regression suite. For enterprise buyers running regulated simulations (drug discovery, materials design, structural engineering), model certification may matter more than gate certification — it tells them whether the numbers they are looking at are physically meaningful.
|
||||
|
||||
The regression suite grows with every deployment, making the certification increasingly valuable over time. The early player's suite is the largest because they started first. This is the [[id:a5d59d12-b23e-58d6-a81b-9b8b06556949][collective regression suite]] mechanism in action.
|
||||
|
||||
10 certifications in year one = $500K-$2M.
|
||||
|
||||
Reference in New Issue
Block a user