117 lines
9.1 KiB
Org Mode
117 lines
9.1 KiB
Org Mode
:PROPERTIES:
|
||
:ID: growth-strategy
|
||
:CREATED: [2026-05-23 Sat]
|
||
:END:
|
||
#+title: Growth — Zero to Billions Across Time Scales
|
||
#+filetags: :passepartout:growth:network:strategy:
|
||
|
||
How the triad grows from zero instances to planetary infrastructure. Each phase is a qualitatively different growth regime, with its own customers, levers, and failure modes.
|
||
|
||
The growth curve is logistic, not exponential from day one. Enterprise first (linear, high value per node), then developer-led (quadratic, moderate per node), then regulatory/insurance-driven (punctuated). The stacked network effects make each subsequent phase easier to scale than the previous one — but each phase must be solved /before/ the next can begin.
|
||
|
||
* Phase 0 → 1: Zero to Enterprise (0 → 100 instances, 3-12 months)
|
||
|
||
** 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.
|
||
|
||
** How it works:**
|
||
|
||
1. Ship the MVP ([[file:time-estimates.org]]) — a Passepartout that verifies code, applies gate rules, and produces a compliance report.
|
||
2. First sale is a compliance engagement: encode a regulation as gate rules, verify the customer's deployment, produce a report their auditor accepts.
|
||
3. Each engagement funds the next. Gate rule library grows with every customer. This compounds — each new regulation encoded is a product, not a project.
|
||
4. The compute marketplace ([[file:compute-marketplace.org]]) bootstraps with one provider (you) selling verification to smaller instances. No liquidity problem because you are both sides of the market initially.
|
||
|
||
** Key metric:** Deployed instances. Gate package revenue. Regulations encoded.
|
||
|
||
** Failure mode:** Wrong pricing. Too early for market. The compliance buyer exists but the product must replace an existing process, not add a new line item.
|
||
|
||
** Phase 0 revenue:** $2M-$12M (from [[file:investment-thesis.org]]). Funds the team, keeps the lights on.
|
||
|
||
* Phase 1: 1 to 10³ — Enterprise to Developer Ecosystem (100 → 10,000 instances, 12-24 months)
|
||
|
||
** 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. The marketplace has supply.
|
||
|
||
** How network effects kick in:**
|
||
|
||
1. /Proof library compounding:/ Each new instance contributes edge cases to the regression suite ([[file:collective-regression-suite.org]]). Ten instances have a good proof library; a hundred have a great one; a thousand have a library no single organization could build alone. The curve is super-linear in instances.
|
||
|
||
2. /Compute marketplace liquidity:/ 100+ instances means providers and consumers exist simultaneously. The marketplace can price verification in real time. No single instance needs to provision for peak load — they buy burst compute from the marketplace.
|
||
|
||
3. /Attestation starts working:/ With 100+ instances, a track record of correct verifications carries weight. The attestation marketplace ([[file:agora-contracts.org]]) has enough data for reputation scores. The first insurance products become possible.
|
||
|
||
** Revenue growth:** $10M-$50M. Verification appliances scale from project to program. Marketplace fees begin. Agora usernames ([[file:agora-usernames.org]]) start generating recurring revenue.
|
||
|
||
** Key metric:** Third-party gate rules published. Marketplace monthly transaction volume. Active developer count.
|
||
|
||
** Failure mode:** Developer adoption stalls because the AGPL experience is not polished enough. Gate rule SDK is too hard to use. This phase requires the most product attention — the first thousand developers must succeed.
|
||
|
||
* Phase 2: 10³ to 10⁶ — Developer to Mainstream (10,000 → 1M, 2-5 years)
|
||
|
||
** Customer:** Consumers + small businesses. PDS as a service ([[file:pds-as-a-service.org]]) becomes a consumer product. Agora usernames go mainstream.
|
||
|
||
** Growth lever:** Consumer network effects. Each new PDS makes the Agora network more valuable. Each new user is a potential compute provider, gate rule buyer, and data licensor.
|
||
|
||
** How it works:**
|
||
|
||
1. /Stoa premium ([[file:revenue-hub.org]]) ships enterprise features./ SSO, compliance dashboards, fleet management. The enterprise buyer from Phase 1 upgrades from project to org-wide deployment.
|
||
|
||
2. /Agora identity reaches critical mass./ Username registrations cross 100K. The namespace has value — short names are scarce. The auction market ([[file:agora-usernames.org]]) produces real revenue.
|
||
|
||
3. /Compute marketplace hits density./ 1M+ instances means verification is ubiquitously available. Latency drops because there is always a provider within network distance. The marketplace transitions from /can I find a provider/ to /which provider gives the best price/.
|
||
|
||
4. /Insurance marketplace forms./ With 10K+ instances and 2+ years of verifiable track records, actuaries can price proof insurance. The first products: /gate rule correctness insurance/ and /compute provider SLA insurance/.
|
||
|
||
** Revenue growth:** $50M-$500M. Compute marketplace fees become the dominant revenue stream. PDS hosting at scale. Username registry renewals compound.
|
||
|
||
** Key metric:** Agora identities. PDS count. Verified operations per day. Marketplace gross merchandise value.
|
||
|
||
** Failure mode:** Consumer adoption requires UX polish the engineering team may deprioritize. The terminal-based Stoa works for developers but not for mainstream users. Qt integration (Stoa v2 from [[file:stoa.org]]) is the gating dependency.
|
||
|
||
* Phase 3: 10⁶ to 10⁹ — Mainstream to Infrastructure (1M → 1B+, 5-15 years)
|
||
|
||
** Customer:** Nation-states. Enterprises that cannot justify unverified infrastructure. Anyone who needs insurance.
|
||
|
||
** Growth lever:** Regulatory mandate + insurance feedback loop. Verification is no longer a choice — it is a requirement for participation in the insured economy.
|
||
|
||
** How the loop closes:**
|
||
|
||
1. /Verification monopoly ([[file:verification-monopoly.org]]):/ The early player's gate library is the largest, most battle-tested, most cited. Regulators reference it. Insurers require it. A new entrant cannot replicate 10+ years of edge cases embedded in 1M+ instances.
|
||
|
||
2. /Insurance lock-in:/ Insurers price unverified code out of existence. Premiums for unverified deployments are 10× or more. The cost of /not/ verifying exceeds the cost of adopting the triad. This is the insurance parallel to what happened with fire safety — buildings without sprinklers cannot get insured.
|
||
|
||
3. /Nation-state adoption:/ The compute marketplace is a sovereign asset. Countries that run their own triad instances have verified digital sovereignty. Countries that do not are dependent on foreign verification infrastructure. The geopolitics are self-reinforcing (see [[file:triad-systemic-effects.org]]).
|
||
|
||
** Revenue growth:** $1B+. Certification monopoly revenue. Infrastructure lock-in rent. Marketplace fees at global scale. Insurance underwriting profits.
|
||
|
||
** Key metric:** Percentage of global compute running on verified stack. Number of nation-state triad deployments. Insurance premiums written against gate rules.
|
||
|
||
** Failure mode:** Technology shift makes the approach obsolete. A fundamentally different verification paradigm (quantum proof systems, for example) could bypass ACL2. The installed base is a moat, not a guarantee.
|
||
|
||
* Growth Curve Summary
|
||
|
||
| Phase | Scale | Timeframe | Revenue | Primary lever | Failure mode |
|
||
|-------+-------+----------+---------+--------------+--------------|
|
||
| 0 | 0→100 | 3-12 mo | $2-12M | Enterprise sales | Wrong pricing, too early |
|
||
| 1 | 10²→10⁴ | 1-2 yr | $10-50M | Open source + SDK | Developer UX |
|
||
| 2 | 10⁴→10⁶ | 2-5 yr | $50-500M | Consumer network effects | UX polish gap |
|
||
| 3 | 10⁶→10⁹ | 5-15 yr | $1B+ | Regulation + insurance | Tech paradigm shift |
|
||
|
||
Each phase's revenue funds the next. Phase 0 pays for the team. Phase 1 funds the product. Phase 2 builds the moat. Phase 3 is the end state.
|
||
|
||
The network effects stack across phases: Phase 0's proof library makes Phase 1's marketplace valuable. Phase 1's developer ecosystem makes Phase 2's consumer product compelling. Phase 2's installed base makes Phase 3's regulatory capture possible. No phase can be skipped — and no phase guarantees the next.
|
||
|
||
* References
|
||
|
||
- [[file:time-estimates.org][Development timeline]] — the engineering underpinning
|
||
- [[file:revenue-hub.org][Revenue streams]] — what each phase sells
|
||
- [[file:investment-thesis.org][Investment thesis]] — the three revenue horizons
|
||
- [[file:triad-systemic-effects.org][Systemic effects]] — where this all leads
|
||
- [[file:compute-marketplace.org][Compute marketplace]] — the liquidity engine
|
||
- [[file:verification-monopoly.org][Verification monopoly]] — the end state moat
|
||
- [[file:agora-contracts.org][Agora contracts]] — attestation, insurance, governance
|
||
- [[file:collective-regression-suite.org][Collective regression suite]] — how proof libraries compound with scale
|
||
- [[file:infrastructure-lock-in.org][Infrastructure lock-in]] — why switching costs compound
|