Architecture reframe: rename triad/Stoa/Logos/Agora → Passepartout
- Renamed ideas/stoa/ → ideas/passepartout/, all stage files prefixed passepartout- - Renamed triad-index/overview/systemic-effects → passepartout-* under passepartout/ - Renamed ideas/agora/ → ideas/passepartout-social-protocol/, stripped agora- prefixes - Merged overview and environment pages into architecture; deleted 3 redundant files - Renamed growth-strategy → enterprise-growth-strategy - Renamed alternative-growth-social-first → social-growth-strategy - Removed all Greek names: Stoa, Logos, Agora as product names - Updated 50+ files of cross-references to new naming - Kept org-id UUIDs intact throughout
This commit is contained in:
Hermes
201
ideas/enterprise-growth-strategy.org
Normal file
201
ideas/enterprise-growth-strategy.org
Normal file
@@ -0,0 +1,201 @@
|
||||
: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)
|
||||
Reference in New Issue
Block a user