diff --git a/ideas/agora-entry-strategy.org b/ideas/agora-entry-strategy.org
new file mode 100644
index 0000000..022a7dc
--- /dev/null
+++ b/ideas/agora-entry-strategy.org
@@ -0,0 +1,183 @@
+:PROPERTIES:
+:ID:       agora-entry-strategy
+:CREATED:  [2026-05-23 Sat]
+:END:
+#+title: Agora Entry Strategy — Finding the Low-Hanging Use Cases
+#+filetags: :passepartout:agora:strategy:entry:go-to-market:
+
+The Agora 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.
+
+This page identifies the entry points that require the least technical maturity, target the most acute pain, and demonstrate the full bundle (identity + content + payments + contracts + governance) as early as possible.
+
+* The Entry Criteria
+
+Any viable entry point must score well on all three axes:
+
+1. /Pain intensity/ — how broken is the current solution for this group? The pain must be acute enough to overcome the friction of adopting an immature ecosystem.
+2. /Community density/ — can they switch as a group? Scattered individuals cannot bootstrap network effects. A guild migrating together solves the cold start.
+3. /Technical maturity/ — how much of the spec must ship? Lean towards entry points that work on a minimal build and layer up.
+
+Plus a fourth that emerges from the discussion:
+
+4. /Bundle necessity/ — does this use case require multiple layers at once, or does one layer suffice? Entry points that only use identity + content teach users a narrow view of the Agora. Entry points that force the bundle (identity + content + payments + contracts + governance) demonstrate the /real/ product.
+
+* Candidate Entry Points Ranked
+
+** 1. Organized Communities (strongest candidate)
+
+/Description:/ Neighborhood associations, housing cooperatives, clubs, volunteer orgs, religious groups, sports teams, PTAs, investment clubs, open-source projects, research collaboratives — any group that needs to communicate, organize, pool resources, and make decisions together.
+
+/Pain::/ Today they use a patchwork: Reddit or Discord for communication, Google Sheets for resource tracking, Venmo for dues, DocuSign for agreements, Trello for tasks, Zoom for meetings. /Five separate tools with no unified identity, no shared reputation, no portable history./ When leadership changes, everything breaks — the new treasurer has to recreate the spreadsheet, the new mod inherits a Discord server they don't control.
+
+/Density:/ Very high. These groups /already exist/ as organized units. You don't need to build a social graph — the social graph is the group. If an HOA of 200 families joins the Agora, all 200 arrive at once.
+
+/Tech needed:/ Moderate. Needs:
+- Identity (Personas, PDS for each member)
+- Social Spaces (feeds, announcements, group chat via DIDComm)
+- Contract Notes (tasks, assignments, dues tracking)
+- Governance modules (voting, constitutions, role management)
+- Lightning payments for dues and pooled funds
+
+/Bundle necessity:/ High. This use case /requires/ the bundle. A group chat alone doesn't solve the problem. They need identity + communication + tasks + payments + governance all in one place, with a unified data model.
+
+/Why this is low-hanging:/ The group already exists. The switching costs are low because the alternative is five separate tools that don't integrate. The Agora doesn't need to be better than Discord at chat — it needs to be better than /Discord + Sheets + Venmo + Trello/ combined, which is a much lower bar.
+
+/Killer demo:/ "Your HOA needs a new roof. A member proposes it in a feed post. The treasurer issues a payment request as a Contract Note. 180 families vote via quadratic voting, 150 approve. The contract auto-collects dues via Lightning, issues the payment to the contractor with a HODL invoice escrow, and the contractor's proof of completion releases the funds. Every step is signed, timestamped, and auditable. No spreadsheets, no separate bank accounts, no chasing checks."
+
+** 2. Community Refugees (highest density)
+
+/Description:/ Communities that have been deplatformed or are at risk: subreddits that got banned, Discord servers that got nuked, Facebook groups that lost their admin, Telegram channels under pressure. These groups will migrate and are actively looking for alternatives.
+
+/Pain:/ Acute. Their existing community infrastructure is gone or at risk. They need a new home /now/ and the fear of losing it again makes them receptive to sovereignty arguments.
+
+/Density:/ Maximal. A banned subreddit of 50K users is 50K users arriving together.
+
+/Tech needed:/ Low. They primarily need identity + content (feeds, comments, basic moderation). Payments, contracts, and governance can layer on afterward.
+
+/Bundle necessity:/ Low-medium. They join for one reason (surviving as a community) and can discover the rest later. But the migration is urgent enough that they adopt with minimal features.
+
+/Risk:/ They might leave when the crisis passes. But if they've built reputation, pooled resources, and documented decisions on the Agora during their refuge, the switching cost to go back is real.
+
+** 3. Adult Creators / OnlyFans Refugees (highest willingness to pay)
+
+/Description:/ Creators who have been deplatformed, payment-processed-discriminated, or who want to own their audience. The OnlyFans model takes 20%. Stripe bans adult content. Creators earn $50K-500K/yr and have strong incentive to bypass intermediaries.
+
+/Pain:/ Very high. Direct financial loss from platform fees and payment discrimination. Existential risk of deplatforming with no audience portability.
+
+/Density:/ Medium. Creators are scattered and their audiences follow them, not the platform. Migration requires the creator to lead their audience.
+
+/Tech needed:/ Medium-high. Needs LSAT for paywalled content, Lightning for payments, PDS for storage, Blind CDN for distribution. The /spec is ready/ but the implementation is non-trivial.
+
+/Bundle necessity:/ Medium. Uses identity + content + payments. Contracts and governance are lower priority initially.
+
+/Why compelling:/ This group has money and will pay for a working solution. They are the fastest path to /revenue/.
+
+** 4. Weak Rule-of-Law Contracts (highest long-term impact)
+
+/Description:/ Small businesses and individuals in countries where contract enforcement is unreliable or corrupt. Cross-border freelancers who can't trust local courts. Sellers in markets without dispute resolution.
+
+/Pain:/ Very high. There is no good solution today. Informal trust networks are the only alternative.
+
+/Density:/ Low. These are one-off transactions, not communities.
+
+/Tech needed:/ Very high. Requires full SCAL: Ricardian contracts, HODL escrow, multi-level arbitration guilds, reputation slashing, financial collateralization.
+
+/Bundle necessity:/ High. Uses identity + contracts + payments. Content and governance are secondary.
+
+/Risk:/ This is the hardest technical build and the hardest go-to-market (scattered users, no density). But once it works, it has the strongest moat — /no one else offers verifiable contract enforcement without a state./
+
+** 5. Developers / OSS (lowest risk, lowest reward)
+
+/Description:/ Open-source developers who want decentralized code hosting with signed commits, Lightning bounties, and governance.
+
+/Pain:/ Low-medium. GitHub works well. The pain is ideological (dependency on Microsoft) more than practical.
+
+/Density:/ High. Developer communities are well-connected and migrate together (e.g., a popular repo moving to the Agora brings all contributors).
+
+/Tech needed:/ Low-medium. Merkle DAGs for code, Contract Notes for issues/PRs, Lightening for bounties.
+
+/Bundle necessity:/ Low. Developers would use just code hosting initially. The other layers are bonus.
+
+* Recommended Sequence
+
+** Phase 1: Organized Communities
+
+Target: HOAs, clubs, volunteer orgs, cooperatives, religious groups, PTAs — any group that currently uses 3+ separate tools.
+
+Why first: lowest cold-start risk (groups exist, migrate as units), highest bundle necessity (forces adoption of identity + content + tasks + payments + governance simultaneously), moderate technical build.
+
+Go-to-market:
+- Identify 5-10 pilot communities with personal connections or warm intros
+- Onboard each as a Collective Persona with one onboarding session
+- The community admin invites members via DID (email link, QR code, share code)
+- Members arrive to find a fully set-up community space: announcement feed, group chat, task board, treasury, voting
+- The first "killer demo" happens naturally when the community's first real decision is conducted through the Agora
+
+KPI: Number of organized communities. Community retention rate. Contract volume (tasks, dues, votes).
+
+** Phase 2a: Community Refugees (parallel track)
+
+Target: Banned or at-risk subreddits, Discord servers, Facebook groups.
+
+Why second: highest density per event, but needs Phase 1 to have a working product and some community momentum to point at.
+
+Go-to-market:
+- Monitor deplatforming events. When a subreddit of 10K+ users gets banned, the community is actively looking — outreach within 24 hours
+- Offer a ready-made Agora community space with import tools (archive of the banned sub, migration guide)
+- The Mod Collective Persona concept lets the migrated community feel familiar: same mods, same rules, same culture — just sovereign
+
+Risk: These communities might not stay. Mitigation: make the Agora community space good enough that they don't want to leave. The mod tools, governance modules, and integrated payments give them capabilities Reddit never had.
+
+** Phase 2b: Adult Creators (revenue track)
+
+Target: OnlyFans/Patreon creators with audience independence motivation.
+
+Why parallel: highest ARPU, fastest path to revenue. Requires LSAT implementation which can be scoped independently.
+
+Go-to-market:
+- Find 5-10 creators who have been deplatformed or are vocally anti-OnlyFans
+- Offer a white-glove migration: set up their PDS, import their content archive, configure their subscription tiers
+- The creator posts to their existing audience: "I'm now on Agora. Join me here."
+- Their audience follows. 1K paying subscribers at $10/mo = $120K/yr on the platform.
+
+** Phase 3: Freelancers / Gig Workers
+
+Target: Upwork/Fiverr refugees, cross-border freelancers.
+
+Why third: needs Phase 1+2 to have a reputation graph and some contract volume before the escrow/arbitration layer is credible.
+
+Go-to-market:
+- The same communities onboarding from Phase 1 now have members who need to hire each other
+- A community member posts a task with a Lightning bounty. Another completes it. The contract is recorded.
+- This is organic — the use case emerges from the community, not from a marketing campaign
+
+** Phase 4: Weak Rule-of-Law
+
+Target: Global south, cross-border trade, any jurisdiction where the courts are unreliable.
+
+Why last: needs the full SCAL stack, arbitration guilds with track records, and enough installed base that reputation slashing is a real deterrent.
+
+* The Thesis
+
+The Agora does not need millions of users to prove its value. It needs /one organized community/ to use the full bundle and see what happens. When an HOA of 200 families votes on the budget, collects dues via Lightning, and executes a roof contract with HODL escrow — all in one platform, all verified — the demo sells itself.
+
+Organized communities are the entry point because they force the Agora to be the /entire/ product from day one, not just another social app. The group that joins for communication stays because of contracts, pays because of Lightning, and governs because of the modules. That is the full vision, delivered to one group at a time.
+
+* Summary Table
+
+| Priority | Entry point | Pain | Density | Tech | Bundle | Revenue | Risk |
+|----------+-------------+------+---------+------+--------+---------+------|
+| 1 | Organized communities | High | Very high | Moderate | Full | Dues/contract fees | Low (groups exist) |
+| 2a | Community refugees | Very high | Maximal | Low | Partial | Future contracts | Medium (may leave) |
+| 2b | Adult creators | Very high | Medium | Med-high | 3/4 layers | High fees | Medium (LSAT build) |
+| 3 | Freelancers | High | Low | High | 3/4 layers | Escrow fees | Medium (density) |
+| 4 | Weak rule-of-law | Very high | Very low | Very high | 4/4 layers | Arbitration | High (cold start) |
+
+* References
+
+- [[file:agora.org][Agora overview]]
+- [[file:../agora/docs/agora-requirements-01-overview.org][Agora Protocol Overview — Platform Replacement Strategy]]
+- [[file:../agora/docs/agora-requirements-05-social.org][Social Space — Collective Personas and Governance]]
+- [[file:../agora/docs/agora-requirements-06-exchange-and-contracts.org][Exchange and Contracts — SCAL, Escrow, Arbitration]]
+- [[file:alternative-growth-social-first.org][Social-first growth scenario]]
+- [[file:competitive-landscape-agora.org][Full competitive landscape]]