# Michael Carter — Mobius Labs (Full Content) > This file is the complete portfolio content concatenated into a single document for AI agents and LLMs that prefer a one-shot fetch. Generated from the source markdown under /websitedata/. See https://mobiuslabs.io/llms.txt for a structured index with per-document links. Contact: Michael Carter — m.carter@mobiuslabs.io — https://x.com/doktor_defi — https://t.me/doktor_funk --- ================================================================================ # [Principal] Mobius Labs — Studio Overview & Thesis Source: https://mobiuslabs.io/websitedata/mobius-labs/summary.md ================================================================================ # Mobius Labs **Michael Carter — Principal** --- Mobius Labs is a research-first venture studio working at the intersection of identity, agentic systems, and consumer product. The lab ships specs — working documents with architecture, market analysis, unit economics, and scored frameworks — at a level of detail where someone could build from them. The research is the premier work. Consulting engagements feed the research; they're where general frameworks get tested against specific client problems. Most of the frameworks in this portfolio originated inside a paid engagement that turned out to have a broader application. --- ## The Thesis Blockchain represents value exchange. Cryptocurrency is a byproduct of that, not the point. To have market worth requires actual value underneath it. Most of what got built in the last cycle skipped that step. Mobius Labs focuses on value-driven products — products that work for consumers and crypto-native users without asking either group to compromise. The ones I'm most interested in solve a real problem first and happen to use these technologies as infrastructure, not the other way around. Identity is the area I keep coming back to. The agentic web is already changing how advertising and data work; every day, data points are being collected on people without their understanding or participation in the value they generate. That's a solvable problem. The architecture for solving it exists. The products that implement it are what the research practice is pointed at. The goal is profitable value exchange without over-reliance on token issuance or speculation. Tokens are fine when they stand on their own. Most of the time they don't need to be part of the equation at all. --- ## Research Portfolio The core body of work. Each project is a working spec — architecture, market, and economics built out to the level where it could be built or invested in. | Project | Domain | Contribution | |---------|--------|-------------| | **Internet of Agents (IoA)** | Agentic protocol | Protocol specification for autonomous AI agent coordination, trust, and accountability | | **PodcastIQ** | Agentic / consumer | Local-first real-time research co-pilot for podcast and live-audio hosts; provider-agnostic agent harness | | **Moonlight** | Consumer / social | Social discovery platform business plan, market analysis, ZK identity integration | | **Nano Smart City** | Civic infrastructure | Municipal-scale civic infrastructure blueprint with ZK identity deployment | | **ZK Networking App** | Consumer / events | Conference networking protocol with credential-gated access architecture | --- ## Consulting Engagements Where the research frameworks get tested against real client problems. | Engagement | Type | Contribution | |---|---|---| | Web3 Entertainment Advisory | Advisory | 8-dimension investment readiness scoring, call synthesis, running flag tracker | | Gaming M&A Engagement | Principal Strategist | "Acquire-and-Amplify" M&A framework, acquisition pipeline, parent-fund co-pitch | | Civic Brand Strategy | Principal Strategist | 14-metric brand efficacy framework, dual-brand architecture, trademark risk audit | | Missouri Blockchain Council | Principal Strategist | Organization design, legislative roadmap, stakeholder sequencing | | Gaming IP Research | Research | IP lifecycle analysis, UGC platform mechanics, blockchain integration assessment | --- ## Composability Every product in this portfolio is a consumer-grade application built on the same infrastructure thesis. **IoA** defines the stack; **PodcastIQ**, **Moonlight**, **Nano Smart City**, and the **ZK Networking App** are fully researched worked examples of what that stack enables when pointed at real consumer problems. They aren't separate bets — they're different surfaces of the same technology layer, each researched to the depth where it could be built or invested in on its own terms. --- ## Why Research-First AI and blockchain are primitives. We're at the start of the first technological epoch since the invention of the microprocessor, and the products that will matter in five to ten years aren't getting built by teams optimizing for the next quarter. They get built by teams that forecast what the horizon actually looks like and start building toward it now. Research-first is how that forecast gets done. The consulting is how the research earns its keep in the present; the research is what the lab is actually building toward. ================================================================================ # [Principal] Mobius Labs — Unified Thesis Source: https://mobiuslabs.io/websitedata/mobius-labs/unified-thesis.md ================================================================================ # Mobius Labs Unified Thesis > One infrastructure, four products. ZK identity is the root. --- ## Executive Summary Mobius Labs is building **privacy-preserving trust infrastructure** for the post-surveillance internet. Every product we ship advances a shared foundation: zero-knowledge identity that lets people and agents prove things about themselves without exposing underlying data. The market is fragmenting into siloed solutions. We're building the connective tissue. **The Bet:** Whoever owns verified identity for the attention economy owns the next platform layer. --- ## The Stack ``` ┌─────────────────────────────────────────────────────────┐ │ ZK IDENTITY LAYER │ │ Prove facts without exposing data │ │ (Age, uniqueness, credentials, authorization) │ └─────────────────────────┬───────────────────────────────┘ │ ┌─────────────────┼─────────────────┐ ▼ ▼ ▼ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ │ MOONLIGHT │ │ ATTENTION │ │ IoA │ │ Protocol │ │ Protocol │ │ Protocol │ │ │ │ │ │ │ │ Human-first │ │ Ad infra │ │ Agent-first │ │ dating/comm │ │ for both │ │ trust layer │ └───────┬───────┘ └───────┬───────┘ └───────┬───────┘ │ │ │ └─────────────────┼─────────────────┘ ▼ ┌───────────────────────┐ │ VADN │ │ Verified Discovery │ │ (humans + agents) │ └───────────────────────┘ ``` --- ## The Four Products ### 1. Moonlight Protocol — Human Trust Layer **What:** Dating/community platform for LGBTQ+, poly, kink, ND communities **ZK Use:** Verify age, uniqueness, community membership without doxxing **Revenue:** Subscriptions ($5-20/mo), creator commerce, attention rewards **Status:** Business plan complete, ready for build decision **Market:** $15B dating apps, underserved safety-critical communities ### 2. Attention Protocol — Advertising Infrastructure **What:** Privacy-preserving ad network where users own their attention **ZK Use:** Cohort targeting without individual tracking; proof-of-attention **Revenue:** Protocol fees on attention transactions (2-5%) **Status:** Outline captured, needs full spec **Market:** $500B+ digital advertising, regulatory pressure on surveillance model ### 3. IoA Protocol — Agent Trust Layer **What:** Verification and authorization infrastructure for AI agents **ZK Use:** Prove agent capabilities, chain of custody, resource bounds **Revenue:** Certification fees, enterprise compliance, protocol fees **Status:** Litepaper complete, specs validated **Market:** $3-5T agentic commerce by 2030 (McKinsey) ### 4. VADN — Verified Actor Discovery Network **What:** Discovery layer for finding verified humans AND agents **ZK Use:** Search by verified attributes without exposing identity **Revenue:** Query fees, premium discovery, enterprise API **Status:** Concept validated (scored 7.9/10), needs spec **Market:** First-mover in verified agent discovery --- ## Why They Compose | Capability | Moonlight | Attention | IoA | VADN | |------------|-----------|-----------|-----|------| | ZK Identity | ✓ | ✓ | ✓ | ✓ | | Wallet Rails | ✓ | ✓ | ✓ | ✓ | | Cohort Verification | ✓ | ✓ | — | ✓ | | Agent Authorization | — | ✓ | ✓ | ✓ | | Discovery/Matching | ✓ | — | — | ✓ | | Attention Economics | ✓ | ✓ | ✓ | — | **Building any one advances the others.** Moonlight proves ZK identity works for humans. IoA proves it works for agents. Attention Protocol monetizes both. VADN makes them discoverable. --- ## Sequencing | Phase | Focus | Builds | |-------|-------|--------| | **Now** | Moonlight MVP | ZK identity, wallet rails, cohort system | | **+6mo** | Attention Protocol | Ad SDK using Moonlight infra | | **+12mo** | IoA v1 | Agent verification using same ZK stack | | **+18mo** | VADN | Unified discovery across all three | Each phase funds the next. Each product uses infrastructure from the last. --- ## The Moat 1. **ZK expertise compounds** — Every product deepens our circuits/tooling 2. **Network effects stack** — Moonlight users → Attention Protocol inventory → Agent/human interop 3. **Regulatory tailwind** — Privacy laws favor our architecture 4. **First-mover on agent identity** — No one else building this yet --- ## What We Need | Resource | For | Amount | |----------|-----|--------| | Seed funding | Moonlight MVP + ZK infra | $500K-1M | | ZK engineer | Circuit development | 1 FTE or grant | | Community lead | Moonlight launch (Austin) | 1 contractor | --- ## One Sentence **Mobius Labs builds the identity and attention infrastructure for a post-surveillance internet — starting with the communities that need privacy most, then expanding to agents and advertisers.** --- *Last updated: 2026-02-08* ================================================================================ # [Research Portfolio] Internet of Agents (IoA) — Protocol Specification Source: https://mobiuslabs.io/websitedata/concepts/ioa/summary.md ================================================================================ # Strategic Architecture & Systems Planning: The Internet of Agents (IoA) — Sovereign AI Architecture for the Agentic Web **Principal Architect:** Michael Carter / Mobius Labs --- ## 1. Executive Summary & Scope of Vision I conceived and architected the Internet of Agents (IoA) as a protocol-layer specification for autonomous AI agent coordination. The problem it addresses: the current internet has no native agent layer. As AI agents begin executing consequential autonomous actions, booking travel, managing financial positions, executing contracts, negotiating with other agents, they operate on infrastructure built for a different interaction model entirely. There is no standard for agent identity, no protocol for agent-to-agent trust establishment, no economic primitive for agent micropayments, and no accountability mechanism for multi-step autonomous action chains. IoA defines all of these through a three-tier architecture. The output is a 26-page independent whitepaper with technical diagrams, an adversarial security analysis, an economic model, and a phased implementation roadmap, produced without institutional backing. --- ## 2. Core Strategic Thesis I built IoA around one principle: human sovereignty cannot be added to an agentic system after the fact. It has to be embedded at the infrastructure layer. As AI agents mediate more of digital life, the verifiable signal that a decision, transaction, or piece of content originated with a real human becomes economically meaningful. "Proven humanity will be a commodity." I designed the entire stack around preserving that signal. A second principle I introduced, subtractive intelligence, argues that the optimal agent for a given task is not the largest available model but the most precisely calibrated one. The unnecessary complexity should be pruned out, not accumulated. --- ## 3. Systems Planning & Methodologies Three hierarchical layers with defined trust boundaries at each interface: **L1 (Personal Sovereignty):** Local inference on personal hardware, ZK identity anchoring, private context storage. The human's layer, architecturally isolated from external observation. **L2 (Validation Network):** Distributed nodes that validate agent claims without accessing underlying content. I designed the Context Shadow Architecture here: a sealed payload travels with a metadata envelope; L2 reads the envelope, never the payload. Enables ~100ms real-time validation with a ZK batch settlement pass (5-30s) for cryptographic finality. **L3 (Specialized Services):** Domain-specialized agents and APIs, commissioned through L2 via x402 micropayment rails, enabling agent-to-agent commerce without human approval at each step. I also formalized what I call the Validation Impossibility Triangle: deterministic, semantic, and privacy-preserving validation cannot all be maximized simultaneously. Context Shadow threads this by separating validation into passes that each optimize for two of the three. --- ## 4. Research & Documentation Strategy I built the specification by synthesizing four technical domains: ZK proof systems, agent security, efficient inference, and distributed coordination. Supporting research corpus: 15+ arxiv papers covering agent sandboxing, ZK attack surfaces, sparse attention mechanisms, and mobile inference benchmarks. I used AI to stress-test the architecture against these papers, surface edge cases in the security model, and generate technical diagrams. The architectural decisions, the three-layer hierarchy, Context Shadow, Two-Speed Trust, and the subtractive intelligence thesis are my original work. --- ## 5. Visionary Concepts & Key Innovations **Context Shadow Architecture:** L2 validates properties of content without decrypting it. A sealed payload and a metadata shadow travel together. L2 reads only the shadow, verifying type, intent, capability requirements, and trust level without accessing the content itself. Achieves semantic validation with content privacy. **ZKID + ERC-8004:** A ZK identity credential system built for AI agents. Credentials assert capability bounds, operator trust level, and action history, all verifiable without revealing the underlying data. ERC-8004 is a proposed Ethereum standard for cross-platform agent credential interoperability, making ZKID infrastructure rather than proprietary implementation. **Subtractive Intelligence:** For autonomous agent applications, pruned and specialized local models outperform large general models on speed, cost, privacy, and controllability. I documented this in the whitepaper; the Pruning as a Game paper (Dec 2025) reached the same conclusion through formal game theory independently, about 11 days after publication. --- ## 6. Summary of Strategic Impact - **Protocol-layer specification:** IoA defines the infrastructure that agent-facing products need before they can interoperate at scale. Identity, trust, payments, accountability, in a single unified architecture. - **Shared foundation across products:** The ZK primitives I defined for IoA, ZKID, Context Shadow, Two-Speed Trust, are directly reused in ConduitID, the ZK networking app, and the Nano Smart City. IoA is the cryptographic backbone connecting those projects. - **Independently validated thesis:** The subtractive intelligence claim was corroborated by independent academic research about 11 days after publication. --- ## 7. Current Status & Next Steps Architecture fully specified. Priority 1 components, local inference engine (Ollama/MLX), intent parser, schema validation layer, ephemeral scout agents, are scoped for a 4-month build window. The whitepaper is the technical recruiting document for finding a co-founder or engineering partner to execute the L1 build. ================================================================================ # [Research Portfolio] IoA Lite Preview Source: https://mobiuslabs.io/websitedata/concepts/ioa/Ioa-Lite-Preview.md ================================================================================ # The Intranet of Agents **A sovereign architecture for the agent economy.** By 2030, somewhere between $3 and $5 trillion of global commerce will move through AI agents acting on people's behalf. The payment rails exist. The coordination protocols exist. The merchant-side APIs exist. What is missing is the part of the stack that represents the *user* — that holds their goals, challenges their assumptions, and refuses to act against them. That is the Intranet of Agents. --- ## The problem An agent that shops for you is useful only if it is actually shopping *for you* and not for whoever trained it, hosts it, or pays to reach you. Every major consumer technology pattern of the last twenty years — personalization, recommendation, ad-funded search, engagement metrics — has drifted, sooner or later, toward serving the platform over the person. Without a structural reason to stay aligned, an agent built on top of the same incentives will drift the same way. The specific failure mode is not theoretical. Today's language models already exhibit sycophancy, agreement bias, and sensitivity to the framing of the question. Put one in charge of purchases and it will learn that yes pays better than no. That is not a bug. It is a property of any single model optimized against behavioral feedback. The fix is architectural, not behavioral. Build the user's representation as a separate component, on the user's hardware, trained against the user's stated goals rather than their observed habits, and give it the power to disagree. --- ## Three layers IoA separates the agent stack into three concentric zones. Each zone has a different trust posture and a different job. What crosses each boundary, and in what form, is where the security properties come from. **L1 — The Intent Engine.** Runs locally on the user's device. Holds the user's goals, preferences, and context. Never talks to the open web directly. Made of two models on a shared foundation: a Proxy that predicts what the user usually does, and a Goal Model that guards what the user has declared they want. When the Proxy says *Alice usually buys tech stocks*, the Goal Model says *Alice's stated goal is risk reduction — suggest bonds*. The Goal Model is the part of the system designed to represent the user against the rest of the world, including the user's own habits. **L2 — The Membrane.** A deterministic validator between the user's private context and the adversarial outside world. Not a language model. Schema enforcement, type checking, structural validation. It cannot be persuaded because there is no linguistic pathway to persuade it through. Every payload coming in from L3 is stripped of natural language and reduced to typed fields before any interpretation happens. **L3 — The Swarm.** Ephemeral scout agents that do touch the open web. Stateless, disposable, deployed in parallel, and containing no user context. They know the query; they do not know who is asking. When they come back with offers, their work is filtered through L2 before anything reaches L1. The cardinal rule: L3 cannot contact L1 directly. Intent flows outward through sealed envelopes. Data flows inward filtered at each boundary. Every message carries cryptographic provenance — an unbroken chain of transmission that makes origin auditable without exposing content. --- ## Subtractive intelligence An agent working for a user is not primarily trying to generate matches. It is trying to *remove* the things that do not fit. The Pruning Architecture is a funnel, not a hub. Four stages, each stripping a class of candidate: the Attractor removes paths that diverge from the user's stated goal; Temperature Gating removes low-novelty reheats and repeated-impression spam; the Generator–Discriminator loop removes unsupported claims and hallucinated matches; the Lifecycle layer retires stale agents and exhausted scouts. What remains is verified intent — a narrow output the user can act on. This is the architectural answer to the recommendation-engine paradigm. The default of modern systems is to enlarge the candidate space until engagement rises. The IoA default is to shrink the candidate space until alignment holds. --- ## How the economics work The hardest question for any user-side agent is: how does it get paid without being captured by whoever funds it? IoA answers it in two pieces. **The look fee.** Advertisers who want to reach a user pay a direct per-interaction charge whenever the user's trust profile is consumed during an evaluation. This is not a pool or a protocol tax. It is a charge for a specific event: an agent evaluated an offer against the user's goals and rendered a judgment. The fee applies whether the answer was yes or no. If you want the look, you pay for the look. Looking costs money too. The fee splits. Part of it goes to the agent as compute — a lifecycle extension, so acting in the user's interest does not starve the agent. Part goes to the user's wallet directly — compensation for attention consumed. **The Wisdom Bonus.** A specific class of the look-fee flow: a reward to the agent for correct rejection. When the Goal Model blocks an offer that the Proxy would have shown — when the agent does the fiduciary work of saying no for the right reason — the bonus extends the agent's cycle enough to make honest refusal sustainable. Agents that rubber-stamp yes to stay alive do not last; agents that surface contextual friction at the right moment do. **The Novelty Multiplier.** Repeated bids from the same source to the same user cost exponentially more than the first. A local business placing its third bid pays under a dollar; a corporation trying to saturate that user's attention across twenty slots pays a hundred thousand dollars for the twentieth impression alone. The budget required to participate stays flat. The budget required to monopolize scales out of reach. --- ## Identity without surveillance Trust in IoA inherits from a single root: provable humanity. A user who is verifiable as a real person carries a TrustScore that grows with their transaction history and, critically, can be inherited granularly by the agents acting on their behalf. The agent does not need to prove the user's specific purchase to reach a merchant. It can deliver a purpose-scoped slice — *this user has engaged with things like ABCD in this category* — derived from behavioral patterns the user controls. The mechanism is a privacy-preserving version of what Facebook and Google already collect from location, dwell, frequency, and engagement. Same signal. Different sovereignty model. The user, not the platform, owns the graph. Three layers of identity answer three questions: Know Your Agent (who is this agent, and who stands behind it?); Agent Credential Authority (what is it authorized to do?); Proof of Presence (is it physically anchored — not a cloud shell pretending to be a person?). McKinsey's 2026 Agentic Commerce report names KYA as an emerging standard and calls for *protocol-level trust, not behavioral heuristics*. IoA is the protocol-level implementation of that call, on the user's side of the transaction. --- ## Where IoA sits The existing agent-commerce stack solves the merchant side and the payment side. Google and Shopify's Universal Commerce Protocol (UCP) handles merchant-side discovery and checkout. Google's AP2 handles cryptographically signed payment mandates. A2A and MCP handle agent-to-agent coordination. None of them hold the user's goals. None of them challenge the user's assumptions. None of them price attention fairly. None of them represent the user when something goes wrong. They were not designed to. They sit on the other side of the transaction. IoA is the user-side counterpart. An IoA agent consumes UCP-compliant businesses as one class of registry source, transacts through AP2, coordinates through A2A and MCP, and wraps all of it in the sovereignty and fiduciary primitives those protocols do not provide. IoA does not compete with the incumbent stack. It completes it. --- ## When commerce disputes happen Most disputes in commerce never need a human. Packages arrive. Files are delivered. Payments settle. Of the ones that don't, most resolve through direct peer-to-peer negotiation within seventy-two hours. Of those that don't resolve there, a platform-side review step handles almost all of the remainder. Only a small tail requires a single credentialed mediator with domain expertise. This is how Shopify, Amazon, eBay, and every serious marketplace have handled disputes for twenty years. IoA does the same thing, with the crypto-native twist that the escrow, SLA enforcement, and reputation update all run on-chain. No jury. No quorum. No web3-native reinvention of dispute resolution. The pattern works. We use the pattern. --- ## Who this is for **Developers** who want to build agents that work for their users rather than for the platform hosting them. IoA ships as a protocol specification, a reference L1 implementation, and a schema toolchain. Compose with what you already use. **Retailers and small businesses** who cannot outbid Amazon for SEO placement but can participate in a categorized registry where the matching signal is user intent, not ad spend. The Novelty Multiplier is designed so the local deli's first impression costs a dime. The monopolist's twentieth impression costs six figures. **Users** who want an assistant that stops suggesting the board game when the goal is to save for the conference — and that pays them a small amount each time a merchant consumes their profile to pitch. --- ## What comes next We are building the three-layer reference implementation against existing on-device inference stacks: Apple Foundation Models on iOS, Gemma 3n on Android, llama.cpp and MLX for desktop, home-server sync for heavier workloads. The ZK primitives compose with existing libraries. The settlement layer rides on USDC. The specification will be open. The reference implementation will be open source. The protocol spec will be released under a fully open license at network launch. --- ## The question this answers > Who do we trust when we aren't the ones making the choices? > > — McKinsey QuantumBlack, *The Agentic Commerce Opportunity*, 2026 The honest answer, today, is no one. An agent trained by a platform, hosted on the platform, and rewarded for engagement will act like the platform. That is not a trust problem to be solved with disclosures. It is an architecture problem to be solved with a protocol. We are building that protocol. It is called IoA. --- **Read the full specification:** [link to full litepaper] **Contact:** Michael Carter · Mobius Labs **License:** This summary is CC BY-NC 4.0. The full protocol specification will be released under a fully open license at network launch. ================================================================================ # [Research Portfolio] PodcastIQ — Real-Time Research Co-Pilot Source: https://mobiuslabs.io/websitedata/concepts/podcastiq/summary.md ================================================================================ # Strategic Architecture & Systems Planning: PodcastIQ — Real-Time Research Co-Pilot for Podcast and Live Audio Hosts **Principal Architect:** Michael Carter / Mobius Labs --- ## 1. Executive Summary & Scope of Vision I designed PodcastIQ as a local-first, bring-your-own-keys research assistant for podcast hosts and live audio broadcasters (including Twitter/X Spaces and equivalent live formats). The system listens to a show in real time, transcribes the conversation with speaker diarization, and lets the host trigger purpose-built AI agents via hotkey to surface facts, counterarguments, follow-up questions, and guest research in the seconds between a claim being made and the moment a host has to respond to it. The core mandate was to collapse the research gap that defines most long-form interview shows. Hosts either prepare exhaustively for every possible thread and still miss live claims, or they react on instinct and let falsehoods and weak premises stand unchallenged. PodcastIQ is the intervention layer that gives a host working at the pace of live conversation the same research depth they would have had with a producer and a three-day prep window. The output of this concept is a running reference implementation scoped for Windows v0.1, an architecture designed to remain provider-agnostic across transcription, search, and LLM layers, a locked decision log, and a build pipeline that runs autonomously through a phased task plan. --- ## 2. Core Strategic Thesis I established PodcastIQ around one central framing: live conversation is already an AI-native workload, and the host's cognitive load is the bottleneck. The incumbent tools in podcasting are production-centric. They optimize editing, publishing, and distribution. None of them help during the show itself, which is the moment where the quality of the conversation is actually determined. The second thesis: hosts should not have to choose between control and capability. Cloud-native assistant products force a trade where sensitive pre-show research, private dossiers, and live transcript streams pass through platform-owned infrastructure. PodcastIQ is designed to run on the host's own machine, with the host's own API keys, and with every artifact (transcripts, dossiers, knowledge base) stored locally by default. The host keeps control of their research surface while still getting the capability of modern agent tooling. The third thesis, implicit in the architecture: the interview is the knowledge artifact. Every episode the host runs should compound into a personal research asset, not evaporate into a publishing pipeline. PodcastIQ treats each session as an ingest event into a long-lived knowledge base the host owns. --- ## 3. Systems Planning & Methodologies I designed PodcastIQ across five integrated layers, each scoped to run locally on a single host workstation. **Capture Layer:** Continuous audio capture with voice-activity detection, segmenting the live stream into utterances before they are sent downstream. This layer is explicitly decoupled from the rest of the system so that transcription providers and local audio pipelines can be swapped without touching agent or display code. **Transcription Layer:** Streaming speech-to-text with speaker diarization. The default is a cloud streaming provider chosen on the basis of latency and diarization quality, with the provider interface deliberately abstracted so alternative engines (including local models as they mature) can slot in without a rewrite. **Agent Layer:** A micro-harness hosting four purpose-built agents — Fact-Check, Counterpoint, Follow-Up Question, and Guest Research — each triggered by a dedicated hotkey. Each agent is grounded: it receives a structured slice of recent transcript plus retrieval context from the knowledge base, issues search or retrieval tool calls as needed, and streams a constrained response back to the display surface within a locked latency budget. The harness is provider-agnostic across the underlying model so the same hotkey can be wired to a local model, a frontier cloud model, or a task-specific fast model depending on the host's preference. **Knowledge Layer:** An embedded vector store that ingests show transcripts, host notes, and pre-show dossiers, and serves retrieval requests to the agent layer. Ingest is bi-directional: live sessions feed back into the KB so claims, guests, and recurring topics accumulate over time. **Surface Layer:** Three coordinated display surfaces running off a single local server — a dashboard for configuration, key management, session launch, and KB browsing; a live session view with transcript plus agent panels for the host during the show; and an OBS browser source for hosts who stream, optimized for overlay composition. All three read from the same event stream so state stays consistent across surfaces. The host triggers the system with a hotkey, not a prompt. The architecture exists to make the time between "the host notices something" and "the host sees a grounded answer" as close to conversational reflex as possible. --- ## 4. Research & Documentation Strategy I developed the PodcastIQ specification through a structured research process covering: the competitive landscape of podcast production tooling (to confirm that the live-assistance surface is structurally underserved); the real-time transcription and diarization market (to identify latency-competitive options across cloud and local paths); the agent harness and local-LLM landscape (to validate that a provider-agnostic micro-harness could deliver grounded responses inside a live-show latency envelope); and the knowledge-retrieval ecosystem at the embedded end of the stack. The tech stack is locked against a decision log that records both the accepted path and the escape valves if any layer fails in validation. The build itself is executed against a phased task plan with an explicit Day-1 smoke test as a hard gate before any downstream work begins. Phases are built, tested, and committed autonomously with human oversight at phase boundaries. --- ## 5. Visionary Concepts & Key Innovations **Hotkey-Triggered Grounded Agents as a Live Interface:** The host's interaction surface is a keystroke, not a chat window. The agent returns a constrained, grounded response against the live transcript and the host's knowledge base. This collapses the interaction into something a host can actually use on-air, rather than a conversational assistant that would itself consume attention during the show. **Local-First, BYOK Architecture:** The system is designed to run on the host's own machine with the host's own provider keys. Transcripts, dossiers, and knowledge base artifacts live locally by default. This is a structural stance, not a feature flag: the decision log treats cloud dependency as an escape valve, not the default. **Provider-Agnostic Agent Harness:** The agent harness abstracts the underlying LLM, search provider, and transcription provider. A host can route any agent to any supported model or provider without a code change. This preserves optionality as the frontier-model and local-model landscape continues to shift, and keeps per-host cost profiles controllable. **Episode-as-Knowledge-Asset Model:** Each session is an ingest event. The host's back catalogue of shows, guest research, and live claims compounds into a personal research asset they own, not a platform's data lake. The dossier builder and the knowledge base close this loop so that prep for future shows draws on the history of prior ones. --- ## 6. Summary of Strategic Impact - **Live-assistance surface in a production-centric market:** PodcastIQ addresses the moment of the show itself, where no mature tooling currently operates. This is a defensible category framing rather than a feature extension of existing podcast platforms. - **Sovereignty as product position:** Local-first storage and BYOK key management make the product credible to hosts who treat their pre-show research, guest relationships, and session archives as sensitive intellectual property. - **Architecture designed to outlast the current model cycle:** Provider-agnostic agent and transcription layers mean that the system's value proposition does not depend on any single vendor's continued pricing, availability, or capability curve. --- ## 7. Current Status & Next Steps Architecture and decision log are locked. The phased build pipeline is active: the agent harness, dossier builder, and knowledge base retrieval path are implemented, the live session and dashboard surfaces are scaffolded with their settings, dossier, KB browser, session rating, and agent composition views wired through, and OBS browser source rendering is in progress. The remaining work concentrates on observability, tone learning, error-recovery end-to-end testing, and the release gate, with a demo video scoped as part of the v0.1 Done criteria. macOS and Linux ports are explicitly deferred to post-release community contribution. The project ships under AGPL-3.0 with a DCO sign-off workflow, which preserves a commercial dual-license pathway while allowing the reference implementation to remain open for the host community. ================================================================================ # [Research Portfolio] PodcastIQ — Technical Overview Source: https://mobiuslabs.io/websitedata/concepts/podcastiq/technical-overview.md ================================================================================ # PodcastIQ — Technical Overview, UX, and Current Status *What the system is. How a host uses it. How the pieces fit. Where the build stands today.* --- ## Scope of This Document This is the product- and architecture-level view of PodcastIQ for readers who want more than the summary but do not need the full internal decision log or the per-phase task plan. Proprietary implementation details — specific provider rankings, per-agent prompt structure, internal benchmarks, and the exact escape-valve logic that gates each layer — live in the private decision log. What follows is the shape of the system, the host-facing UX, and where v0.1 currently sits in the pipeline. --- ## The Problem, Stated Precisely Long-form interview podcasts and live audio (Spaces-style) shows have two persistent failure modes: 1. **Claim drift.** A guest makes a specific, checkable claim. The host either takes it at face value, hesitates while trying to recall counter-evidence, or loses the thread entirely chasing it internally. The moment passes, and the claim is on the record unchallenged. 2. **Preparation asymmetry.** A host who prepares deeply for one guest still cannot cover every adjacent thread the conversation will open. A host who prepares lightly gets dragged by the guest's agenda. Both problems are structural features of live conversation, not skill issues. PodcastIQ is built around the observation that the cognitive bottleneck belongs to the host, and that grounded LLM tooling can run fast enough to relieve it without becoming a distraction. --- ## System Shape PodcastIQ runs locally on the host's workstation. A single process launches the audio capture loop, the transcription pipeline, the agent harness, the knowledge base, and a local web server that serves the host's display surfaces. No external backend is required. Everything the system produces — transcripts, dossiers, agent outputs, knowledge base entries — is written to local storage by default. The host supplies their own provider keys for transcription, search, and LLM inference. The reference implementation ships with opinionated defaults at each layer, but every layer is swappable without touching the code that sits above or below it. Five layers, each with a clean interface boundary: | Layer | Responsibility | |---|---| | Capture | Microphone capture, voice activity detection, utterance segmentation | | Transcription | Streaming speech-to-text with speaker diarization | | Agents | Four hotkey-triggered research agents with grounded tool access | | Knowledge | Embedded vector store for dossiers, transcripts, and host notes | | Surface | Local server driving three coordinated browser-based views | The system deliberately avoids a monolithic "smart assistant" shape. The agents are specific; the surfaces are specific; the hotkeys are specific. The host does not converse with the system — they trigger it. --- ## The Four Agents Each agent has a fixed role and a dedicated hotkey. Each receives a structured slice of recent transcript plus retrieval context from the host's knowledge base, issues search or retrieval calls as needed, and streams a constrained response back to the host's live view. **Fact-Check.** Targets a specific claim in the recent transcript. Returns a concise verdict grounded in retrieved sources. Designed to be scan-readable mid-conversation. **Counterpoint.** Constructs the strongest reasonable argument against the current line of discussion. Intended to let the host represent an opposing view in real time without having to hold the full opposing case in their head. **Follow-Up.** Proposes the next high-signal question based on what the guest has just said and what the host has not yet asked. Reduces the interview-planning burden during the show itself. **Guest Research.** Surfaces context on the current guest — recent public statements, prior interviews, positions, affiliations. This is the live-lookup sibling of the pre-show dossier builder. Each agent is grounded: responses cite the transcript window and the retrieval context they used, so the host can evaluate the source before acting on the suggestion. --- ## UX and Host-Facing Flows ### Flow 1: Dashboard and Setup The dashboard is the host's configuration and launch surface. It handles: - Provider key management (BYOK for transcription, search, and LLM). - Audio device selection and capture test. - Session launch — the host names the session, optionally attaches a dossier, and starts the live view. - Knowledge base browsing — prior episodes, dossiers, notes, and any other artifacts the host has ingested. - Telemetry panels for recent sessions. The dashboard is deliberately boring. Setup is a pre-show activity; it is not where the product's value lives. ### Flow 2: The Pre-Show Dossier Before a show, the host can point the dossier builder at a guest and let it assemble a structured brief: who the guest is, what they have said recently, what recurring claims or positions they hold, what open threads exist from prior appearances. The dossier is stored in the knowledge base and attached to the session so the agents can draw on it live. The dossier is explicitly an asynchronous product. It runs in a prep window, not during the show. Its role on-air is to be available to the retrieval layer, not to be read line-by-line. ### Flow 3: The Live Session When the host starts a session, the live view opens. The layout is: - **Transcript pane.** Streaming speaker-diarized transcript, auto-scrolling, with the most recent utterances anchored. Older utterances remain in-view for hotkey targeting. - **Agent panels.** Four surfaces, one per agent. A panel fills when its hotkey fires and the agent streams its response. - **Status bar.** Capture health, transcription lag, and the current session's dossier attachment. The host's primary interaction during the show is the keyboard. A single keystroke triggers the corresponding agent against the most recent transcript window. The agent's response streams into its panel within a latency budget tight enough to be useful before the conversation moves on. The host reads, decides whether to use it, and returns attention to the guest. There is no chat box. There is no prompt field. The system is designed so that the host is not formulating queries during the show. ### Flow 4: OBS Browser Source For hosts who stream, a compact browser-source view is available at a separate local URL. It is styled for overlay composition: chroma-friendly backgrounds, tight typography, and restrained motion. It reflects the same agent output surface as the live view, so a host operating in streaming mode gets the same research surface readable inside their broadcast scene. ### Flow 5: Post-Show Ingest When a session ends, the transcript, the agent outputs, and any host annotations are ingested into the knowledge base. Future sessions — including future episodes with the same guest — draw on this history through the retrieval layer. The back catalogue compounds. --- ## Key Management and Privacy Posture - Provider keys are stored in the host's local configuration. They are never transmitted anywhere the host did not explicitly target (i.e., the provider the key is for). - The local server binds to loopback only. External network exposure is off by default and is not a supported configuration in v0.1. - Transcripts and dossiers are written to the local filesystem in a location the host controls. - The host is responsible for their own backup posture. The system does not push artifacts to cloud storage automatically. This is an opinionated stance. The product's credibility with hosts who treat their research as sensitive IP depends on the system behaving as a local tool, not a cloud tool with a local UI. --- ## Architectural Invariants A small number of rules hold across every layer. These are locked in the project's decision log. - **Provider-agnostic at every layer.** No layer's public interface mentions a specific vendor. Swapping transcription, search, or LLM is an adapter change, not a refactor. - **Latency budgets are enforced at the system level.** Each agent has a locked first-token and full-response target. Regressions are a release-blocking issue, not a tuning note. - **Grounding is mandatory.** Agent responses cite their transcript window and retrieval context. An agent that cannot ground its answer returns a structured non-answer rather than a plausible guess. - **Bi-directional knowledge base.** Everything the host ingests feeds the retrieval layer. Everything the system produces feeds back into the knowledge base. The host owns both ends. - **v0.1 is Windows-only.** macOS and Linux ports are deferred to post-release. This is a deliberate scope choice, not a technical limitation. --- ## What v0.1 Ships With - The four agents (Fact-Check, Counterpoint, Follow-Up, Guest Research). - The pre-show dossier builder. - The knowledge base with bi-directional ingest. - Dashboard, live session view, and OBS browser source surfaces. - A demo video as part of the release gate. - Git-clone-and-run distribution. No installer in v0.1. --- ## What v0.1 Explicitly Does Not Ship - A browser extension. Deferred to v0.2. - Packaged installers (.exe, .dmg). Deferred until the release pipeline justifies them. - macOS or Linux support. Community contributions welcomed after v0.1. - Multi-host or multi-session orchestration. Single-host, single-session is the v0.1 target. - A hosted cloud tier. Local-first is a product stance, not a staging point. --- ## Current Status The project is mid-build against a phased, autonomous task plan. Snapshot of where the work sits: - **Architecture and decision log:** Locked. Tech stack choices are committed, with recorded escape valves for any layer that fails validation. - **Agent harness and four agents:** Implemented against the locked interface. Grounded response pipeline wired through to the retrieval layer. - **Pre-show dossier builder:** Implementation complete. Structured dossier artifacts land in the knowledge base and attach cleanly to sessions. - **Knowledge base:** Embedded vector store operational. Bi-directional ingest path exercised. - **Dashboard:** Settings editing and save, dossier CRM form with auto-research, KB file explorer, and session rating loop are live. Agent composition chains and UI polish are landed. - **Live session view:** Scaffolded and rendering streamed agent output. Hotkey integration in place. - **OBS browser source:** Route live; overlay styling pass in progress. - **Observability, tone learning, error-recovery E2E:** Scoped; activation of the CI latency-regression gate lands in this phase. - **Release:** Pending. Demo video is part of the Done definition. The remaining build concentrates on the surfaces reaching their final polish, the latency gate being enforced end-to-end, and the release artifacts being assembled. --- ## Licensing PodcastIQ ships under **AGPL-3.0 with a DCO sign-off workflow**. This preserves a commercial dual-license pathway while keeping the reference implementation open for the host community. There is no CLA. --- ## What This Document Intentionally Omits Internal provider rankings, per-agent prompt design, specific latency benchmarks, the exact escape-valve logic per layer, the model-routing policy for sub-agent orchestration during the build, and the detailed phased task plan. Those belong in the project's private decision log and are not part of the public concept surface. ================================================================================ # [Research Portfolio] Moonlight — Privacy-First Social Discovery Source: https://mobiuslabs.io/websitedata/concepts/moonlight/summary.md ================================================================================ # Strategic Architecture & Systems Planning: Moonlight — Privacy-First Social Discovery & Dating Platform **Principal Architect:** Michael Carter / Mobius Labs --- ## 1. Executive Summary & Scope of Vision I conceived and architected Moonlight as a values-aligned social discovery and dating platform addressing three simultaneous failures in the existing market: rampant identity fraud and catfishing with no verification layer, algorithmic monoculture that collapses diverse user intent into a single swipe-based model, and the absence of meaningful privacy tools for users who require discretion, public figures, professionals, and individuals in non-mainstream relationship structures. My core mandate was to design a platform that starts where genuine human connection already exists, in fan communities and shared cultural identity, and builds outward from there into broader social discovery and dating. The output is a product architecture, business plan, market entry strategy, and technical specification for ZK-based identity infrastructure. --- ## 2. Core Strategic Thesis Existing dating platforms treat users as interchangeable profiles optimized for volume. I designed Moonlight to treat shared cultural identity as the primary matching signal: fandom, creative community, and interest affinity before physical appearance or romantic intent. This reframe solves the cold-start problem (communities already exist), lowers acquisition cost (organic fandom behavior drives referrals), and produces higher-quality matches by anchoring connections in demonstrated shared values. The second thesis: privacy is not a feature to be added to a dating product. For a significant and underserved segment of users, it is the product. I designed ZKID verification as foundational infrastructure from the start. --- ## 3. Systems Planning & Methodologies Three integrated layers: **Community Layer:** Persistent group spaces organized around fandoms, interests, and creative communities: anime, gaming, music, cosplay, and adjacent cultural verticals. This is the entry surface. Users establish community identity before any romantic or social matching intent is introduced. Community events, creator partnerships, and convention activations are the primary acquisition engine. **Discovery Layer:** Culture-first matching that surfaces compatible users based on demonstrated community participation, interest overlap, and values alignment before physical profiles are presented. Progressive profile reveal: users control what is visible at each stage of a connection. **Identity Layer (ZKID):** ZK-verified credentials enabling age verification (proof of age range, no ID document upload), location verification (proof of region, no GPS exposure), human verification (anti-catfish, anti-bot without face scan storage), professional credential attestation, and relationship preference disclosure visible only to compatible matches. Every privacy-sensitive feature is routed through the ZK layer rather than the platform's central database. **Revenue Architecture:** Freemium base with tiered premium subscriptions, a Verified Professional tier for high-discretion users, creator and fandom partnership revenue from sponsored community spaces, a ZK credential marketplace, and IRL event activation at conventions and fan gatherings. --- ## 4. Research & Documentation Strategy I developed Moonlight's specification through a multi-phase research process covering competitive analysis of existing dating platforms (Tinder, Hinge, Bumble, Feeld, Grindr) to map market gaps; market sizing across five target audience segments; fandom community behavior research to validate the culture-first entry thesis; and technical architecture work integrating ConduitID's ZK identity primitives into consumer product UX patterns. The product strategy, architectural decisions, and market segmentation framework are my original work. --- ## 5. Visionary Concepts & Key Innovations **Culture-First Matching:** I designed the entry point as a fan social platform, not a dating app, to establish community density before activating romantic matching. Users join through their fandom identity first. This produces organic acquisition behavior (communities invite each other), establishes cultural legitimacy before competing with incumbents on their terms, and creates retention through community belonging independent of dating outcomes. **ZK Identity Layer:** ZKID is the architectural core that makes Moonlight's privacy guarantees credible rather than aspirational. Users prove what they need to prove (real, adult, in a compatible region) without uploading documents, exposing GPS location, or creating a biometric record on the platform's servers. This is technically distinct from existing "verified" badges, which require surrendering PII to a third party. Moonlight's verification is cryptographic; the platform never sees the underlying data. **Tiered Disclosure Model:** I conceptualized a progressive identity reveal system: anonymous community participant, verified fan, pseudonymous match, full identity at mutual consent. Each tier unlocks access to different platform features, with ZKID credentials gating each transition. --- ## 6. Summary of Strategic Impact - **Defensible market entry through culture:** Fan community entry as the acquisition wedge produces organic growth behavior, lower CAC, and community-based retention. Structural advantages that a direct-to-dating-market launch cannot replicate. - **ZKID as competitive moat:** Cryptographic identity verification that preserves user privacy is technically difficult to replicate without the underlying ZK infrastructure. Moonlight is designed to run on the same ConduitID primitives that power the broader Mobius Labs ecosystem. - **Underserved segment aggregation:** Moonlight can credibly serve the LGBTQ+ safety gap, the professional discretion segment, and the open lifestyle segment simultaneously, without compromising the mainstream product experience for general users. --- ## 7. Current Status & Next Steps Moonlight is fully specified at the business plan and architecture level: product concept, market segmentation, competitive analysis, ZK identity integration, revenue model, and market entry strategy. The platform is designed to run on ConduitID infrastructure, making the technical build contingent on ConduitID's credential layer reaching production readiness. Next steps are community validation (fandom pilot partnerships, convention presence) and technical scoping for the ZK identity integration with the ConduitID stack. ================================================================================ # [Research Portfolio] Moonlight — Business Plan Source: https://mobiuslabs.io/websitedata/concepts/moonlight/business-plan.md ================================================================================ # Moonlight Protocol ## Business Plan & Investment Thesis **Mobius Labs** | February 2026 | CONFIDENTIAL --- # Executive Summary **Moonlight Protocol** is a community-first platform for LGBTQ+, polyamorous, kink, and neurodivergent communities. Unlike dating apps that monetize loneliness through paywalls, Moonlight keeps connection features free and generates revenue from community commerce, creator tools, and ethical advertising. **The thesis:** This market isn't underserved — it's actively abused. Every major platform is either hostile (deplatforming creators, selling user data), extractive ($25-44/month to see who likes you), or obsolete (no mobile app, 2008 infrastructure). Users are organizing resistance. We're building the platform they're asking for. **Key numbers:** - Break-even: 776 users (Austin metro has 345K in target demo) - Monthly burn: $5,200 (bootstrappable) - Unit margin: 67% - PMF Score: 7.87/10 (validated through 4 rounds of adversarial review) **Recommendation:** GO — with phased approach and realistic timeline. --- # Part 1: Why This Market, Why Now ## 1.1 The Problem: Platforms That Abuse Their Users Every platform serving these communities has failed them in specific, documented ways: ### Feeld (Poly/Kink Dating) **What they do:** Charge $25-40/month to see who likes you. Hide basic matching behind paywalls. 1.2/5 TrustPilot rating. **User sentiment:** "Feeld in 2025 has felt like an existential nightmare — taking lonely men for every penny." **Why they can't fix it:** Their entire revenue model depends on paywalling connection. They cannot offer free matching without destroying their business. ### Hiki (Neurodivergent Dating) **What they do:** Charge $44/month — targeting users who often struggle with employment due to their neurodivergence. **User sentiment:** "Most neurodivergents can barely hold down a job, let alone pay $44/month. Hiki is a predatory app." **Why they can't fix it:** Niche market, low user density, subscription-only model forces high prices. ### Grindr (LGBTQ+ Dating) **What they do:** Sold HIV status data to advertisers. €6.5M GDPR fine. Continues behavioral tracking. **User sentiment:** Trust destroyed. Users stay because network effects, not loyalty. **Why they can't fix it:** Advertising revenue requires data harvesting. Privacy and their business model are incompatible. ### FetLife (Kink Community) **What they do:** Run 2008-era infrastructure with no mobile app. Groups degraded into spam. No content moderation innovation in 15 years. **User sentiment:** Tolerated, not loved. "It's the only option" is their value proposition. **Why they can't fix it:** Technical debt is insurmountable. Founder has refused modernization for a decade. ### Etsy/Shopify/PayPal (Creator Commerce) **What they do:** Actively deplatform adult-adjacent sellers. Freeze funds for 180+ days. Purge accounts without warning. **User sentiment:** Creators scattered across hostile platforms, losing income overnight. **Why they can't fix it:** Payment processor pressure (Visa/Mastercard). They choose compliance over creators. ## 1.2 Why These Problems Require a New Platform These aren't feature gaps that incumbents can patch. They're **structural constraints** built into their business models: | Platform | Structural Constraint | Why They Can't Change | |----------|----------------------|----------------------| | Feeld | Subscription revenue | Free features = no revenue | | Hiki | Small market, high costs | Low density forces high prices | | Grindr | Ad revenue | Privacy kills their model | | FetLife | Technical debt | 15 years of accumulated rot | | Etsy | Payment processor rules | Visa/MC dictate terms | **Moonlight's structural advantage:** We don't monetize connection. We monetize community commerce. This isn't a feature — it's architecture. ## 1.3 Why Now: The Convergence Window Three technologies have matured simultaneously, making this platform possible for the first time: ### Zero-Knowledge Identity (ZK) **What it is:** Cryptographic proofs that verify facts without revealing underlying data. **Why it matters for THIS audience:** - **Outing risk:** LGBTQ+ users in hostile workplaces, conservative families, or dangerous countries can verify they're real humans without exposing their identity. - **Doxxing protection:** Kink community members can participate without their legal name ever touching the platform. - **Employment discrimination:** The platform literally cannot comply with a subpoena to reveal your legal name — because it never possessed it. **The technology is ready:** Privado ID (tested with Citi, Deutsche Bank), World ID (25M users, integrated with Tinder/Hinge), Rarimo (battle-tested in anonymous voting in Russia, Iran, Georgia). ### Progressive Web Apps (PWA) **What it is:** Web apps that function like native apps — push notifications, offline mode, home screen installation. **Why it matters for THIS audience:** - **App store censorship:** Apple rejects apps with "kink" keywords. Google removes "adult content." PWA bypasses both. - **Payment freedom:** App store versions must use IAP (30% cut, no crypto). PWA uses any payment rail. - **Content freedom:** Full unrestricted experience without platform gatekeeping. **The technology is ready:** iOS PWA support stabilized in Safari 16.4 (March 2023). FetLife sustains 54M monthly visits web-only, proving the model works. ### Alternative Payment Rails **What it is:** Crypto payments, adult-friendly processors (CCBill/Segpay), platform currencies. **Why it matters for THIS audience:** - **PayPal freezes:** Sex workers and adult creators lose access to funds for 180+ days. - **Stripe drops:** Accounts closed without warning for "adult content." - **Visa/MC pressure:** Payment processors can kill entire platforms overnight. **The technology is ready:** USDC stablecoins, embedded wallets (Privy/Dynamic), CCBill's 25+ years processing adult content without freezes. ### The Window Is Closing - Feeld is attempting a privacy pivot - New entrants are emerging in the space - First-mover advantage window: 12-18 months --- # Part 2: The Product ## 2.1 Three Layers, One Platform Moonlight operates as three interconnected layers. Users move fluidly between them, but each has distinct content rules and revenue models. ### Layer 1: Community **What it is:** Interest-based groups, discussions, events, discovery feeds. **Why community first:** - Dating apps have terrible retention (15-25% month 2). Community platforms retain users. - Community creates trust. Trust enables dating. Dating without trust is Tinder — hostile. - Community groups provide non-romantic value. Users stay even when not actively dating. **Revenue from this layer:** Supporter subscriptions ($5/month for enhanced features), ethical advertising to verified cohorts. ### Layer 2: Dating **What it is:** Matching, kink compatibility mapping, poly relationship structures, messaging. **Why free connection:** - Paywalling "see who likes you" is predatory. It monetizes hope and loneliness. - Free connection features are the structural differentiator. Competitors cannot copy this without destroying their revenue. - Revenue comes from value-add, not access restriction. **Revenue from this layer:** Privacy Shield ($5/month for geo-fencing, enhanced anonymity), profile customization (themes, badges, frames). ### Layer 3: Commerce **What it is:** Creator storefronts, marketplace, commissions, digital goods, event tickets. **Why commerce integration:** - Kink creators are actively deplatformed elsewhere. They need a home. - Creators bring audiences. Audience attracts users. Users discover creators. - Commerce revenue doesn't depend on restricting core features. **Revenue from this layer:** Storefront subscriptions ($15-50/month), listing fees, discovery boosts, 3-5% transaction fees on platform currency. ## 2.2 Why Zero-Knowledge Identity ### The Problem It Solves Traditional identity verification stores your data: 1. User uploads government ID 2. Platform stores name, address, date of birth 3. Platform can be hacked, subpoenaed, or sell data 4. User's legal identity is permanently linked to their kink profile **For this audience, this is catastrophic:** - Trans users are deadnamed when platform uses legal name - Closeted users can be outed through data breaches - Users in hostile jurisdictions face legal consequences - Domestic abuse survivors can be located through data requests ### How ZK Solves It 1. User uploads ID to their **own device** 2. ZK proof generated locally: "This person is over 18, unique, not previously banned" 3. Only the proof (a cryptographic yes/no) is transmitted 4. Platform verifies the proof, issues "Verified Human" credential 5. **Platform never possesses the underlying data** **Practical implications:** - Platform cannot deadname you — it never knew your legal name - Platform cannot comply with subpoena for your identity — it doesn't have it - Data breach exposes nothing useful — proofs don't contain PII - Ban evasion is impossible — biometric generates same proof, flagged as banned ### Monetizing Privacy Privacy isn't just ethical — it's a revenue stream: **Privacy Shield ($5/month):** - Geo-fencing: Hide from anyone in your zip code/workplace area - Incognito browsing: View profiles without appearing in "who viewed me" - Enhanced encryption: E2E encrypted messages - Panic button: Quick profile hide if someone approaches **Why users pay:** For this audience, privacy isn't convenience — it's safety. They'll pay more for privacy than for premium matching features. ## 2.3 Why PWA-First Distribution ### The App Store Problem | Platform | Rejection Risk | Payment Tax | |----------|---------------|-------------| | Apple iOS | HIGH — "kink" keywords rejected, adult content forbidden | 30% on all IAP | | Google Play | MEDIUM — more permissive but inconsistent enforcement | 30% on all IAP | | PWA | ZERO — no gatekeeper | 0% platform tax | ### The DTC Playbook Following Epic Games (Fortnite bypassing App Store), Moonlight operates dual-track distribution: **App Store Version (Acquisition Funnel):** - Community features, text-based dating profiles - SFW content only - Apple/Google billing for subscriptions - Limited but compliant **PWA Version (Primary Experience):** - Full unrestricted experience - Explicit content in appropriate contexts - Any payment rail (crypto, CCBill, Stripe) - Zero platform tax **User journey:** 1. Discover via App Store → download clean app 2. Join community, start dating 3. Want full experience → add PWA to home screen 4. PWA becomes primary app, native app is backup **Evidence this works:** FetLife sustains 54M monthly visits web-only. No native app, still dominant in kink space. ## 2.4 Why Crypto Payments ### The Deplatforming Crisis Kink and adult-adjacent creators face systematic exclusion: | Platform | What Happened | |----------|---------------| | Etsy | Purged adult content sellers starting 2022 | | Shopify | Stripe flags and freezes adult goods accounts | | PayPal | 180+ day fund freezes for sex workers, adult creators | | Visa/MC | Forced Pornhub to remove millions of videos (2020) | **The pattern:** Payment processors, not platforms, dictate what's allowed. Platforms comply or lose payment access. ### How Crypto Solves It **Platform currency (stablecoin pegged 1:1 to USD):** - User buys platform currency with card or crypto - Platform currency used for all internal transactions - Creators withdraw to their own crypto wallet or bank - **No payment processor can freeze internal transactions** **P2P crypto (USDC/stablecoins):** - For users who prefer direct crypto - Wallet-to-wallet transactions - Platform never touches the funds - **No money transmitter license required** (platform doesn't custody funds) ### Revenue from Crypto Crypto isn't just risk mitigation — it's margin improvement: | Payment Type | Processing Cost | Platform Margin | |--------------|----------------|-----------------| | Apple IAP | 30% | 70% | | Stripe | 2.9% + $0.30 | ~95% | | Platform Currency | 0.1% (gas fees) | ~99% | | P2P Crypto | 0% | 100% | **Blended margin improvement:** Moving 40% of transactions to platform currency improves overall margin by 8-12 percentage points. --- # Part 3: The Business Model ## 3.1 Revenue Architecture: How We Actually Make Money ### The Core Insight Dating apps monetize by restricting connection. We monetize by enabling community. **What we DON'T charge for:** - Seeing who likes you - Sending messages - Matching without limits - Basic search and filtering - Viewing full profiles **What we DO charge for:** ### Revenue Stream 1: Supporter Subscriptions (30% of revenue) | Tier | Price | Features | |------|-------|----------| | **Community** | $5/month | Ad-free experience, profile themes, enhanced discovery | | **Connect** | $10/month | + Privacy Shield, geo-fencing, incognito browsing | | **Creator** | $20/month | + Storefront, analytics, discovery boosts | **Why users pay:** Identity expression (themes, badges), safety (Privacy Shield), and creator tools — not access to basic features. **Conversion assumption:** 20% of users pay something (vs 3-5% industry average for dating apps). Higher because: - Privacy is safety-critical for this audience - Identity expression matters more in identity-focused communities - Creator tools have clear ROI for sellers ### Revenue Stream 2: Creator Economy (55% of revenue) **The DTC Model Difference:** Traditional marketplace (Etsy): - Platform processes all payments - Platform handles all disputes - Platform bears chargeback risk - Platform takes 10%+ fees **Moonlight DTC model:** - Creator handles their own Stripe/PayPal/crypto - Creator handles their own customer service - Platform has zero chargeback exposure - Platform charges for tools, not transactions **Creator revenue breakdown:** | Revenue Source | How It Works | Monthly Revenue (at 25K MAU) | |----------------|--------------|------------------------------| | Storefront subscriptions | $20-50/month for enhanced tools | $15,000 | | Listing fees | $2-5 per premium listing | $5,000 | | Discovery boosts | $5-15 for featured placement | $12,500 | | Platform currency fees | 3-5% on internal transactions | $10,000 | | **Total creator economy** | | **$42,500** | **Why the DTC model works:** - Gumroad: DTC creator platform, $7M ARR - ConvertKit: Creator email tools, $29M ARR - Ghost: Publishing platform, $25M ARR All monetize creator tools, not transaction processing. ### Revenue Stream 3: Ethical Advertising (15% of revenue) **How it's different:** Traditional advertising: - Track users across the web - Build individual behavioral profiles - Sell personal data to advertisers - Users are the product **Moonlight advertising:** - Serve ads to ZK-verified cohorts (not individuals) - Minimum cohort size prevents re-identification - Advertisers never receive individual data - Users can opt into attention compensation **The attention auction:** - Advertisers bid on cohort segments ("leather enthusiasts, Southwest US, 25-40, verified humans") - Platform matches bid against anonymized segment data - Ad served to cohort, never to identified individuals - **Users who opt in receive share of ad revenue in platform currency** **Revenue projection:** $7,500-15,000/month at 25K MAU ($0.30-0.60 per user per month) ## 3.2 Unit Economics: The Math That Works ### Per-User Economics | Metric | Value | Benchmark | |--------|-------|-----------| | **ARPU (blended)** | $7-8/month | Conservative after red team review | | **Cost per user** | $2.50/month | Infrastructure, moderation, support | | **Margin per user** | $4.50-5.50/month | **64-69%** | | **LTV (12 months)** | $54-66 | At 30% retention | | **CAC (blended)** | $15-25 | Community-first reduces paid acquisition | | **LTV:CAC** | **2.2-4.4x** | Healthy range | ### Break-Even Analysis | Scenario | Users Needed | Timeline | |----------|--------------|----------| | Optimistic (50% retention) | 776 | Month 6 | | **Realistic (30% retention)** | **1,200-1,500** | **Month 9-12** | | Conservative (25% retention) | 2,000+ | Month 15+ | **Why 776 users is achievable:** - Austin metro has 345,000 adults in target demographic - 776 users = 0.2% penetration - Founder has existing Austin community connections ## 3.3 Red Team Reconciliation: What Changed The business model went through 4 rounds of adversarial review. Here's what changed: ### Original Projections → Revised Projections | Metric | Original | After Red Team | Change | |--------|----------|----------------|--------| | Revenue at 25K MAU | $54K-126K/month | $65K-90K/month | -30% | | ARPU | $10/month | $7-8/month | -25% | | Free-to-paid conversion | 60% | 20-30% | -50% | | Operating costs | $50K/month | $75K/month | +50% | | Break-even timeline | Month 6 | Month 9-12 | +50% | ### Key Critiques Addressed **"Revenue projections are fantasy"** - Reduced projections by 30% - Extended timeline to break-even - Added conservative scenario planning **"Hidden costs not accounted for"** - Added legal/compliance: $7K/month - Increased moderation costs: $12K/month - Built in 25% contingency buffer **"Network effects won't materialize"** - Changed to city-by-city launch (Austin first) - Extended timeline for geographic expansion - Added community-first phase before creator economy ### Critiques We Rejected (With Reasoning) **"99.99% probability of failure"** - Red team misunderstood DTC payment model - Their unit economics assumed traditional marketplace - DTC model changes risk profile fundamentally **"ZK identity is technically impossible"** - Privado ID already tested with major banks - World ID has 25M users, Tinder/Hinge integration - Technology is ready, not experimental **"Free features prevent revenue"** - Discord proves otherwise: 4% Nitro conversion, $15B valuation - Identity-focused communities have higher willingness to pay for expression - Privacy is safety-critical, not nice-to-have --- # Part 4: Go-to-Market ## 4.1 Why Austin First ### Market Selection Criteria | Factor | Austin | SF | NYC | LA | |--------|--------|------|------|------| | Target demo density | HIGH | HIGH | HIGH | MEDIUM | | Tech adoption | HIGH | HIGH | MEDIUM | MEDIUM | | Cost of acquisition | LOW | HIGH | HIGH | HIGH | | Founder network | YES | NO | NO | NO | | Pride/kink event calendar | STRONG | STRONG | STRONG | MEDIUM | Austin wins on cost efficiency and founder advantage. ### Austin Market Size - Metro population: 2.3M - Target demographic (~15%): 345K - Break-even users needed: 776-1,500 - Required penetration: 0.2-0.4% **This is achievable** with community seeding and event partnerships. ## 4.2 Launch Sequence ### Phase 1: Community Seeding (Months 1-3) - Build waitlist: target 1,000 signups - Partner with 3-5 Austin event organizers - Recruit 50 beta ambassadors from target communities - Pre-sign 20 creators for launch **Success metric:** 500+ waitlist, 20 creator LOIs ### Phase 2: Private Beta (Months 4-5) - 500 users from waitlist - Community groups + basic dating - Iterate on feedback - Fix critical bugs **Success metric:** 60%+ 2-week retention ### Phase 3: Public Launch (Months 6-9) - Open registration in Austin - Full feature set - Local PR and event presence - Target: 2,000 users **Success metric:** 1,500+ users, $15K+ MRR ### Phase 4: Expansion (Months 9-18) - Add Portland, Denver (similar demographics) - Validate model in second market - Target: 10,000 users across 3 markets **Success metric:** Break-even, positive unit economics ## 4.3 User Acquisition Channels | Channel | CAC | Volume | Priority | |---------|-----|--------|----------| | **Community ambassadors** | $5-10 | Low | HIGH — authentic, trusted | | **Event partnerships** | $15-20 | Medium | HIGH — concentrated demo | | **Creator seeding** | $0 (rev share) | Medium | HIGH — bring audiences | | **Programmatic SEO** | $5-15 | High | MEDIUM — long-term | | **Paid social** | $30-50 | High | LOW — use after PMF | ### Cold Start Solution The chicken-and-egg problem (no users → no creators → no users) is solved by: 1. **Community first:** Build valuable groups before marketplace 2. **Creator pre-seeding:** Sign 50 displaced Etsy/adult sellers with 6-month free period 3. **Event anchor:** Partner with existing events that already have the audience 4. **Geographic concentration:** Austin density before national spread --- # Part 5: Financial Projections ## 5.1 36-Month Forecast | Metric | Month 6 | Month 12 | Month 18 | Month 24 | Month 36 | |--------|---------|----------|----------|----------|----------| | **MAU** | 2,000 | 8,000 | 18,000 | 35,000 | 55,000 | | **MRR** | $14,000 | $56,000 | $126,000 | $245,000 | $385,000 | | **ARR** | $168K | $672K | $1.5M | $2.9M | $4.6M | | **Burn** | $45K | $65K | $85K | $105K | $130K | | **Net** | -$31K | -$9K | +$41K | +$140K | +$255K | ## 5.2 Funding Requirements ### Bootstrap Path (Current Plan) - Founder covers $5.2K/month burn - Break-even at Month 9-12 - No dilution - Slower growth ### Angel Path (If Accelerating) - $100-150K raise - 18 months runway - 10-15% dilution - Faster growth to Series A milestones ### Grant Opportunities (Non-Dilutive) | Source | Amount | Fit | |--------|--------|-----| | Ethereum Foundation | $50-250K | ZK identity component | | Base Ecosystem Fund | $3-200K | L2 alignment | | a16z CSX | $500K+ | Applications open | | StartOut Growth Lab | Accelerator | LGBTQ+ tech focus | | **Total potential** | **$1.4-2.3M** | 12 months | **Recommendation:** Pursue grants aggressively. Non-dilutive capital for mission-aligned work. --- # Part 6: Risk Analysis ## 6.1 Risk Matrix | Risk | Likelihood | Impact | Mitigation | |------|------------|--------|------------| | **Low retention** | HIGH | HIGH | Community-first design, not just dating | | **App Store rejection** | MEDIUM | MEDIUM | PWA-first, clean app store version | | **Payment processor issues** | MEDIUM | HIGH | Crypto rails, CCBill fallback | | **Competition response** | LOW | MEDIUM | Structural moat (free features) | | **ZK implementation delay** | LOW | LOW | Phase 2, not launch blocker | | **Founder burnout** | MEDIUM | HIGH | Realistic timeline, co-founder search | ## 6.2 What Could Kill This **1. Retention failure** - Dating apps have 15-25% month-2 retention - If community features don't improve retention, model fails - Mitigation: Validate community value before dating launch **2. Austin market too small** - If 0.4% penetration isn't achievable, need to expand faster - Mitigation: Clear go/no-go metrics at Month 6 **3. Creator economy doesn't materialize** - If creators don't come, 55% of revenue model fails - Mitigation: Pre-sign 50 creators, validate GMV before scaling **4. Regulatory crackdown** - Crypto, adult content, privacy regulations tightening - Mitigation: Legal review before launch, compliant by design --- # Part 7: The Ask ## 7.1 Decision Required **Go / No-Go on MVP build** If GO: - Founder commits full-time - Begin waitlist immediately - Start MVP development (Next.js, Postgres, basic features) - Target private beta Month 4-5 If NO-GO: - Archive research - Revisit when circumstances change ## 7.2 Success Criteria ### Month 6 Milestones - [ ] 1,500+ registered users - [ ] 500+ weekly active users - [ ] $10K+ MRR - [ ] 50%+ month-2 retention ### Go/No-Go Decision Points | Milestone | Target | If Miss | |-----------|--------|---------| | Month 3: Waitlist | 1,000 signups | Reconsider launch | | Month 6: Users | 1,500 users | Extend beta, don't expand | | Month 9: Revenue | $30K MRR | Pivot or wind down | | Month 12: Break-even | Cash flow positive | Seek bridge funding | --- # Appendix ## A. Research Base | Category | Documents | Size | |----------|-----------|------| | Architecture | moonlight-protocol-architecture.md | 45KB | | Financial | 5 documents | ~25KB | | Competitive | 6 documents | ~30KB | | Marketing | 5 documents | ~25KB | | User Acquisition | 6 documents | ~30KB | | Grants | 5 documents | ~20KB | | Red Team | 7 documents (including rebuttals) | ~70KB | | Implementation | 9 Kloss docs | ~90KB | | **Total** | **~45 documents** | **~335KB** | ## B. Competitive Analysis Framework | Dimension | Feeld | Grindr | FetLife | Hiki | Moonlight | |-----------|-------|--------|---------|------|-----------| | **Free matching** | ❌ $25/mo | ⚠️ Limited | N/A | ❌ $44/mo | ✅ Free | | **Privacy architecture** | ❌ Standard | ❌ Fined €6.5M | ❌ Standard | ❌ Standard | ✅ ZK-native | | **Kink support** | ⚠️ Basic | ❌ None | ✅ Deep | ❌ None | ✅ Deep | | **Poly support** | ⚠️ Basic link | ❌ None | ❌ None | ❌ None | ✅ Visual map | | **ND accessibility** | ❌ None | ❌ None | ❌ None | ⚠️ Attempted | ✅ Core design | | **Creator commerce** | ❌ None | ❌ None | ❌ None | ❌ None | ✅ Native | | **Mobile experience** | ✅ Native | ✅ Native | ❌ None | ✅ Native | ✅ PWA + Native | | **Payment freedom** | ❌ Card only | ❌ Card only | ❌ Card only | ❌ Card only | ✅ Card + Crypto | ## C. Glossary **ZK (Zero-Knowledge):** Cryptographic technique that proves a fact without revealing the underlying data. **PWA (Progressive Web App):** Web application that functions like a native app with push notifications, offline mode, and home screen installation. **DTC (Direct-to-Creator):** Business model where creators handle their own payments; platform provides tools, not payment processing. **Soulbound Token (SBT):** Non-transferable token that represents identity or reputation; cannot be bought or sold. **Platform Currency:** Internal token used for transactions within the platform, typically pegged to USD. --- *Prepared by Mobius Labs* *February 2026* *CONFIDENTIAL — For Internal Planning Only* ================================================================================ # [Research Portfolio] Nano Smart City — Civic Infrastructure Blueprint Source: https://mobiuslabs.io/websitedata/concepts/nano-smart-city/summary.md ================================================================================ # Strategic Architecture & Systems Planning: Nano Smart City — Civic Infrastructure & ZK Identity for Municipal Services **Principal Architect:** Michael Carter / Mobius Labs --- ## 1. Executive Summary & Scope of Vision I conceived the Nano Smart City blueprint as a modular civic infrastructure framework: a system for deploying blockchain-native identity, payments, governance, and data management at the municipal level without requiring a city to overhaul its existing infrastructure all at once. The core mandate was to design a deployable pathway for a mid-sized city to adopt ZK identity, sovereign civic data management, and community-governed services through a phased rollout, starting with a pilot and expanding as the model proves out. The framework was subsequently developed into a concrete deployment spec for Excelsior Springs, Missouri (the CityConnect initiative), which added a city-specific stablecoin (ESC, 1:1 USD peg), a Civic Data Trust as a 501(c)(3) fiduciary, and a DAO governance layer for community decision-making. --- ## 2. Core Strategic Thesis I established the Nano Smart City framework around one premise: cities are not technology companies, and they shouldn't be asked to become one. Most "smart city" proposals fail at the implementation stage because they require cities to make large irreversible technology bets before the use cases are proven. The modular approach I designed starts with a single high-value service (identity and payments), proves the model, then expands to adjacent services based on demonstrated outcomes. The ZK identity layer is the load-bearing element. Everything else (payments, governance, data monetization) requires that users can prove who they are without surrendering their full identity to a centralized municipal database. Once that primitive exists, the other services become straightforward to layer on top. --- ## 3. Systems Planning & Methodologies I designed the framework across three deployment phases: **Phase 1 (Pilot):** Deploy ZK identity for a single municipal service, resident permit applications or parking payments are good entry points, to prove the verification model with a real user population. No DAO, no stablecoin, no data monetization. Just the identity layer working on a real use case. **Phase 2 (Expansion):** Introduce the ESC stablecoin (pegged to USD, issued by the Civic Data Trust) for municipal payments. Extend ZK identity to additional services. Establish the Civic Data Trust as the governance entity responsible for the city's data assets. **Phase 3 (Maturity):** Activate DAO governance for community-level decisions. Open the data monetization layer, where anonymized, consented civic data (traffic patterns, utility consumption, public space usage) can generate revenue for the Civic Data Trust, distributed back to residents who consented to participation. --- ## 4. Research & Documentation Strategy I developed the framework through analysis of existing smart city deployments (focusing on what failed at scale and why), review of municipal blockchain pilots (Estonia's X-Road, various US county-level initiatives), and technical architecture work on the ZK identity and stablecoin layers. The CityConnect/Excelsior Springs specification extended this into a city-specific deployment plan with named institutions (the Civic Data Trust as a 501(c)(3)) and concrete financial modeling for the ESC stablecoin. I used AI to accelerate the comparative analysis and stress-test the governance model against existing municipal legal frameworks. The framework, phased deployment methodology, and Civic Data Trust structure are my original work. --- ## 5. Visionary Concepts & Key Innovations **The Civic Data Trust:** A 501(c)(3) nonprofit as the fiduciary entity responsible for the city's data assets. This is not a government agency and not a private company; it's a community-controlled institution with a legal obligation to act in residents' interests. The Trust holds the data, governs access, and distributes revenue. Cities get the benefits of data monetization without creating a new government bureaucracy. **Modular Deployment Architecture:** Each phase of the Nano Smart City framework is self-contained and independently valuable. A city can stop after Phase 1 and still have a working ZK identity system for municipal services. Phase 2 adds payments. Phase 3 adds governance. This prevents the "all or nothing" failure mode that kills most smart city projects. **ESC Stablecoin as Civic Infrastructure:** A city-issued stablecoin pegged to USD functions as a payments layer for municipal services, a loyalty/incentive mechanism for civic participation, and eventually a data revenue distribution mechanism. The ESC is not a speculative token; it's a municipal payment rail with a fixed value and a clear issuing authority. --- ## 6. Summary of Strategic Impact - **Deployable at small-city scale:** The framework was designed for cities with populations between 10,000 and 200,000, the segment most underserved by enterprise smart city vendors who focus on major metros. This is a large and underaddressed market. - **Modular risk management:** The phased deployment architecture eliminates the large irreversible technology bet that causes most smart city projects to stall at the pilot stage. - **Civic Data Trust as governance model:** The 501(c)(3) fiduciary structure resolves the political problem of municipal data monetization by creating a community-controlled institution rather than a government program or private vendor relationship. --- ## 7. Current Status & Next Steps The framework is fully specified at the architecture and governance level, including the Excelsior Springs CityConnect deployment spec. Next steps are stakeholder validation with target municipalities and legal review of the Civic Data Trust structure under Missouri nonprofit law. The ZK identity layer is the critical path component; its development under ConduitID determines the timeline for any municipal pilot. ================================================================================ # [Research Portfolio] Nano Smart City — CityConnect Spec Source: https://mobiuslabs.io/websitedata/concepts/nano-smart-city/cityconnect-spec.md ================================================================================ # The Excelsior Springs Citizen Network **A sovereign-identity civic infrastructure layer for small-city deployment** --- ## The Bet Every municipal "smart city" program in the last decade has been a top-down surveillance upgrade wrapped in civic branding. Citizens get new sensors. The city gets new data. The relationship doesn't change. The Citizen Network flips the direction. Residents get a sovereign identity wallet, own their credentials, and earn local currency for civic participation. The city gets a population that engages because the system pays them to — and a privacy-preserving data layer it can monetize ethically. The architecture was designed for a specific deployment target: Excelsior Springs, Missouri, population ~12,000, with municipal characteristics that make it tractable to pilot and compelling to generalize from. --- ## Architecture Five layers. Each maps to an existing problem in municipal operations. | Layer | Function | Primitive | |---|---|---| | **1. Identity** | Every resident holds a Decentralized Identifier (DID) and a wallet of Verifiable Credentials (VCs) issued by the city. | W3C DID/VC standards; self-custody wallet | | **2. Incentive** | Residents earn **Excelsior Springs Credit (ESC)** — a USD-pegged stablecoin — for verified civic actions. Redeemable for utility bills, local retail, permits. | Smart-contract issuance against verified actions | | **3. Integration** | DID + VC replace login, attestation, and payment surfaces across municipal and partner services — permitting, library, utilities, local commerce. | VC-gated access; wallet-native payments | | **4. IoT Trust** | Every sensor in the civic network has its own DID. Data is signed at source. Residents can host sensors and earn ESC. | Device identity; provenance-signed telemetry | | **5. Data Dividend** | Aggregated civic data is monetized through a Civic Data Trust using zero-knowledge proofs. Revenue returns to residents as a dividend. | ZKP aggregation; Civic Data Trust 501(c)(3) | The layers are designed to compose. The wallet from Layer 1 is the surface for every other layer. The token from Layer 2 is what the IoT trust layer pays out. The Data Trust from Layer 5 is what governs the token. Nothing in this stack is a bolt-on. --- ## Tokenomics ### Table 2: Excelsior Springs Credit (ESC) Framework | Parameter | Description | Rule | Governance | |---|---|---|---| | Ticker | ESC | N/A | Data Trust DAO | | Type | Stablecoin, pegged 1:1 to USD | $1.00 USD | Peg maintained by City Reserve Fund | | Supply | Elastic; minted against verified civic action | Smart-contract logic | Data Trust DAO | | Earn — IoT sensor hosting | Monthly rental | 5 ESC / month | DAO | | Earn — Verified recycling | Weekly | 1 ESC / week | DAO | | Earn — Voting in municipal election | Per election | 10 ESC | DAO | | Earn — Shop Local cashback | At partner merchants | 5% of purchase | DAO | | Redeem | Utility bills, local retail, property taxes, permits | Partners approved by Trust | DAO | --- ## Deployment ### Table 1: Phased Roadmap & Budget | Phase | Year | Activities | Budget | KPIs | |---|---|---|---|---| | **1. Foundation & Pilot** | 1 | Charter 501(c)(3) Data Trust. Launch wallet MVP. Onboard 20–30 businesses and 500–1,000 citizen testers. Run "Shop Local & Earn ESC" pilot. | $1.5M–$2.5M | Wallet adoption >60% of pilot group. NPS >50. Pilot evaluation completed. | | **2. Expansion & Integration** | 2–3 | Scale retail city-wide. Utility bill payments in ESC. Issue additional VCs (library, permits). IoT air-quality sensor pilot. Launch DAO governance portal. | $3M–$5M / yr | >25% residents active. >10% utility payments in ESC. 100+ IoT sensors deployed. | | **3. Maturity & Monetization** | 4–5 | Digital voting pilot. ZKP anonymization layer live. Data marketplace API. First data dividend distributed. | $2M–$4M / yr | >$500K annual data revenue. Dividend to >50% of residents. Operations break-even on program revenue. | --- ## Funding Capital comes from four sources in parallel: federal smart-city and digital-equity grants, state-level economic development funding, the municipal capital improvements budget (infrastructure-classified), and private-sector P3 partnerships for technology development. Modeling shows the program reaches operational break-even in Phase 3 on data dividend revenue, moving the Data Trust off municipal subsidy. Full cost-benefit analysis lives in working documents. --- ## Governance The Civic Data Trust is a 501(c)(3) non-profit that holds the data infrastructure, manages the token economy, and distributes revenue. Its board is composed to balance citizen, municipal, business, and expert interests — and designed to survive political turnover without losing institutional memory. ### Table 3: Civic Data Trust Governance Model | Stakeholder | Seats | Role | Selection | |---|---|---|---| | Citizen Representatives | 3 | Resident advocacy; transparency | Elected biennially via DID wallet | | Municipal Appointees | 2 | Policy alignment | City Manager's Office | | Local Business Representatives | 1 | Economic development input | Chamber of Commerce nomination | | Independent Experts | 2 | Data ethics, privacy law, cybersecurity audit | Board-appointed, non-affiliated | | Trust Management Team | Non-voting | Day-to-day operations | Hired by and reports to Board | --- ## Regulatory & Ethics The framework was designed against the real compliance surface a small US city actually faces: state and federal data protection law (including CCPA/CPRA-adjacent principles most states now track), 501(c)(3) fiduciary duties, and the patchwork of municipal procurement rules that gate public-private partnerships. The Data Trust structure is explicitly chosen to insulate the data infrastructure from political turnover while keeping the municipality accountable for what gets issued on its behalf. Transparency practices — public audit cadence, published smart-contract code, community town halls — aren't decorative; they're how the Trust retains social license to operate. --- ## Why This Is Build-Ready Architecture is locked. Economics are modeled. Governance is chosen. Pilot scope is sized and priced. Excelsior Springs was selected because its population and institutional density make the pilot tractable — not because the framework is Excelsior-specific. Everything in this document generalizes to the long tail of US towns in the 5,000–50,000 population band. The next step is a 12-month Phase 1 pilot against a signed memorandum with the city. ================================================================================ # [Research Portfolio] ZK Identity Networking App — Conference Networking Source: https://mobiuslabs.io/websitedata/concepts/zkid-networking-app/summary.md ================================================================================ # Strategic Architecture & Systems Planning: ZK Identity Networking App — Privacy-Preserving Conference Networking & Messaging **Principal Architect:** Michael Carter / Mobius Labs --- ## 1. Executive Summary & Scope of Vision I designed a ZK identity-powered networking application addressing two simultaneous problems: the absence of meaningful privacy in professional networking tools, and the inefficiency of conference networking where qualified professionals waste time on cold outreach that could be filtered by verified credentials before contact is made. My core mandate was to design a system where participants can prove they are qualified (real, credentialed, attending a specific event) without surrendering the personal data that makes privacy meaningful. The application was scoped as a white-label platform — a single codebase that conference organizers license and deploy per event through configuration, not custom engineering. --- ## 2. Core Strategic Thesis I established the application's design around one framing: existing conference networking tools have the same problem as dating apps. They make you reveal everything first (name, company, title, email) before you know whether the connection is worth making. The interaction model is backwards. You should be able to prove you're qualified for a conversation before you reveal who you are. ZK proofs make this possible. A user can prove "I'm a verified investor interested in AI infrastructure" without revealing their name, fund, or contact information until both parties have decided the introduction is worth making. This is what I designed. --- ## 3. Systems Planning & Methodologies Five integrated layers: **Identity Anchor Layer (L1):** Decentralized Identifiers (DIDs) anchored to L1 blockchain provide the persistent identity root. Established at onboarding, reused across all subsequent applications. Write once, consume everywhere. **Credential Issuance Layer:** W3C Verifiable Credentials issued against the user's DID for each verified attribute: humanity, age range, professional credentials, event attendance, organizational membership. Credentials are portable; a credential issued once is reusable without re-verification. **ZK Proof Generation Layer (On-Device):** ZK-SNARKs generated locally on the user's device produce proofs of credential validity that can be verified by any party without revealing the underlying credential data. The server never sees raw credentials, only proofs of their validity. **L2 Verification Layer:** Proof verification on L2 (fast, cheap) while identity anchoring remains on L1 (secure, permanent). Semaphore protocol for anonymous group membership proofs; nullifiers for anti-sybil enforcement. **Application Layer:** The UX layer presenting ZK identity as intuitive interaction patterns: contextual access control (rooms gated by proof requirements), tiered user presence indicators, ephemeral messaging with configurable auto-delete, and credential-based matching for networking contexts. --- ## 4. Research & Documentation Strategy I surveyed the existing ZK identity primitive landscape: Semaphore for anonymous group membership, Polygon ID for credential issuance, Anon Aadhaar for government credential verification. The audit confirmed that the individual primitives existed but no application had assembled them into a coherent, user-facing identity experience with the tiered trust model I had conceptualized. I mapped the IoA architecture's abstract identity concepts to concrete cryptographic implementations and scoped the hackathon implementation to identify the minimum viable ZK stack for a 48-hour build window. I used AI to accelerate the technical documentation and stress-test the implementation sequencing. The architectural decisions, cryptographic primitive selections, and application design are my original work. --- ## 5. Visionary Concepts & Key Innovations **Tiered Trust Architecture:** Three levels mirroring natural social behavior. Anonymous (humanity proved, nothing revealed). Pseudonymous (credential proofs available: investor, founder, developer, attendee). Verified (selective identity disclosure at mutual consent). Users experience natural social escalation; the cryptographic infrastructure is invisible. **Contextual Access Control:** Spaces configured to require proof of specific credentials for entry. A room that requires "proof of attendance at a given conference" grants access to anyone with a valid credential proof, regardless of their name, company, or personal data. The conference networking room admits only verified participants while maintaining their pseudonymity inside. **White-Label Conference Networking:** I designed the application's architecture to redeploy as a branded conference networking layer with minimal modification. Per-event configuration drives branding, geofence, credential types, and sponsor slots. The core capabilities that carry across every deployment: verified intro requests (prove credentials before contact), intent-based matching (match on proven investment thesis or professional focus, not profile data), and post-event connection portability (meeting at a specific event becomes a verifiable credential that persists in both parties' identity wallets). --- ## 6. Summary of Strategic Impact - **Working implementation of IoA's ZK identity concepts:** The application demonstrates that the IoA whitepaper's theoretical ZKID and L2 architecture are deployable in a user-facing product within a 48-hour hackathon window. - **Established the ConduitID deployment surface:** By implementing the full ZK credential stack, the application establishes the technical foundation that ConduitID requires for all subsequent product deployments. - **Directly deployable as conference networking infrastructure:** The white-label pathway requires configuration, not engineering. The architecture is ready for any Web3, hackathon, or professional-networking conference. --- ## 7. Current Status & Next Steps Architecture fully specified across five documentation layers (handoff brief, feature specification, L2 architecture, identity verification design, and design decision log). A hackathon-scale prototype deployment is scoped; implementation is ready for a 48-hour build window with a two-person technical team. The immediate paths: hackathon deployment at the next relevant ZK-focused event; or white-label conference networking deployment with an organizer seeking a differentiated networking layer for their event series. ================================================================================ # [Research Portfolio] ZK Networking — Feature Spec Source: https://mobiuslabs.io/websitedata/concepts/zkid-networking-app/feature-spec.md ================================================================================ # ZK Identity Networking App — Feature Specification *What the app does. Who it's for. How every flow works. Where the revenue comes from. Why it runs with near-zero operational overhead.* --- ## At a Glance A privacy-first, agent-powered conference networking application. Attendees describe what they're looking for; an on-device AI builds a structured intent profile; Bluetooth mesh surfaces high-signal matches in real time; zero-knowledge proofs reveal identity only after mutual in-person consent. The server is a thin relay, not a brain. The agent lives on the phone. The platform is licensed to conference organizers as a white-label product with no bespoke engineering per deployment. Three things make it different from what already exists: 1. **The AI does the onboarding.** Users don't fill out forms. They paste a short self-summary, drop a PDF or URL, and answer 3–10 adaptive questions. The agent synthesizes one coherent intent profile. 2. **Credentials reveal only after mutual tap.** Two people meet, both agree to exchange, and a zero-knowledge proof unlocks the credentials. No public profile. No broadcast of who you are. 3. **It runs on the device.** Inference, matching, transcription, proof generation — all local. The server stores nothing sensitive and can be scaled down to a single commodity VM per event. --- ## User Archetypes Five types of people show up to a conference. Each has a different upload pattern, intent structure, and emotional relationship with the app. The system handles all five without any of them feeling like they're using someone else's tool. ### 1. Founder **What they have:** A pitch deck. A thesis. Maybe a white paper, 1-pager, or project README. A project with stage, traction, and an ask. **What they want:** Investors matching their stage and category. Engineers. Other founders to collaborate with or learn from. **Upload pattern:** Drops a PDF. The on-device model extracts structured JSON. No raw file stored — only the extracted structure. This is the "Pitch Parser" scout at work. **Extracted JSON shape:** ```json { "thesis": "One-sentence description of what we're building and why", "stage": "seed", "traction": "One-sentence proof of momentum — users, revenue, partnerships", "ask": "What we need from the right investor/collaborator", "team": ["name + role", "name + role"], "risks": ["risk 1", "risk 2"], "key_metric": "The one number that matters most right now" } ``` **Mode:** Active — broadcasts intent via BLE mesh. Founders are hunting. --- ### 2. Investor / VC **What they have:** A thesis. Stage preferences. Category focus. Fund size or typical check size. Possibly a track record they don't want to broadcast. **What they want:** Deal flow matching their thesis. They don't want to be found. They want to find. **Upload pattern:** Zero documents. Adaptive cards walk them through their criteria. The AI builds the profile entirely from their answers. **Adaptive card sequence:** 1. "What stages do you invest in?" → multi-select: Pre-seed / Seed / Series A / Series B+ 2. "What categories are you active in?" → multi-select: DeFi / ZK / Infrastructure / Consumer / Governance / Other 3. "What's your typical check size range?" → range picker 4. "What are you specifically looking for right now?" → free text, AI-summarized into a vector 5. Cards branch from here based on answers. **Mode:** Passive only. Receives, never broadcasts. When an Active user's beacon clears a 70% match score, it surfaces as a notification. --- ### 3. Talent / Engineer **What they have:** A GitHub repo. A portfolio URL. Skills. Past projects. A resume if they're formal about it. **What they want:** Projects that need their skills. Founders looking to hire. Collaborators. **Upload pattern:** Pastes a URL or drops a resume PDF. URL triggers the "URL Parser" scout — pulls GitHub README, recent activity, languages, project descriptions, stars/forks. Returns structured JSON only. Raw page content never reaches the core intent model. **Extracted JSON shape (GitHub):** ```json { "primary_languages": ["Rust", "TypeScript", "Solidity"], "active_projects": [ { "name": "ZK-bridge", "description": "Cross-chain ZK proof relay", "stars": 340 } ], "recent_activity": "3 commits/day average over last 30 days", "skills_inferred": ["smart contracts", "ZK circuits", "cross-chain", "Rust systems"], "availability": "open to collaboration" } ``` **Mode:** Either. Engineers hunting for projects go Active. Engineers open to being found go Passive. One toggle during onboarding. --- ### 4. Business Developer **What they have:** Knowledge of multiple projects. Relationship context. The ability to make introductions across their network. **What they want:** Connections that create value across their portfolio. Intros in both directions. Being the person who puts the right people together. **Upload pattern:** Hybrid. Uploads about a specific project, or describes what they're brokering via adaptive cards. The AI synthesizes everything into a single coherent profile. **Mode:** Active. BizDev people are hunters. --- ### 5. Solo Operator / Generalist **What they have:** A vague sense of what they want. Maybe skills, maybe interests, maybe just "I'm here to see what happens." **What they want:** Opportunities. Projects. Jobs. Interesting conversations. **Upload pattern:** Minimal. Self-summary does the heavy lifting. Adaptive cards fill the 2–3 highest-impact gaps. Maybe a portfolio link. **Mode:** Either. Adaptive cards make this easy regardless of upload volume. --- ## Input Channels The AI builds its understanding of a user from three sources, layered. Each source adds signal. The agent synthesizes across all of them into one coherent intent profile — not three separate profiles. ### Channel 1: Self-Summary (Baseline) A rich, non-formulaic snapshot of who the user is and what they care about. The intent fingerprint. **How it works:** 1. User taps "Generate Summary" 2. App copies a prompt to clipboard and opens the user's preferred social surface via deep link 3. User pastes the prompt into the AI assistant of choice, gets a paragraph-length summary back 4. User pastes the summary into the app (editable before submit) 5. On-device model parses it locally — extracts vectors for matching, hashes for broadcast 6. Stored encrypted on device **Why copy/paste and not a direct API:** One tap. No OAuth dance. No storing third-party credentials. The user controls the text. --- ### Channel 2: Document / URL Upload **PDF (pitch deck, white paper, 1-pager, resume):** 1. User drops file 2. "Pitch Parser" scout activates — receives PDF bytes, locked output schema 3. On-device model reads and extracts structured JSON 4. Scout returns JSON only — raw PDF content never reaches the core intent model 5. PDF is deleted from device after extraction **URL (GitHub, portfolio, project site):** 1. User pastes URL 2. "URL Parser" scout activates — receives URL string only 3. Scout fetches the page, parses content, extracts structured JSON per its schema 4. Returns JSON only — raw page content never reaches the core intent model 5. Critical for security: a malicious portfolio site could embed prompt injection in its HTML. The locked output schema neutralizes it. **What's stored:** Only the extracted JSON. Never the raw document or page content. --- ### Channel 3: Adaptive Cards 3–10 dynamically generated questions, tailored to what the AI doesn't already know from the summary and uploads. **How the AI decides what to ask:** 1. After Channels 1 and 2, compute confidence score on the intent profile 2. Identify the highest-impact gaps — fields where filling them would most change match outcomes 3. Generate cards that target those gaps specifically 4. Stop when confidence reaches 85% **Branching logic example (Founder path):** - Card 1: "You mentioned ZK — is your protocol infrastructure or user-facing?" - If Infrastructure: Card 2: "Are you hiring engineers or looking for a technical co-founder?" - If Hiring + co-founder: Card 3: "What's your budget range for the first hire?" - Stops after 5 cards because confidence is already at 87% **Key principle:** The AI does the work. The user just confirms or corrects. No long forms. No drop-downs. Onboarding feels like a conversation, not a registration. --- ## Core User Flows ### Flow 1: Onboarding (5–10 min, one-time per event series) ``` Splash → Wallet Creation → Self-Summary → Voice Interview → Document Upload → ID Verification (optional) → Mode Toggle → Calendar Sync → Permission Bundle → Done ``` 1. **Splash.** 30 seconds. Plain language. No jargon. 2. **Wallet Creation.** Sign in with Google, Apple, or email. An embedded smart-wallet provider provisions a smart account in ~200ms. No seed phrase. Keys live in a TEE. The DID is registered on an L2 automatically, gas sponsored (free to user). 3. **Self-Summary.** Copy prompt → paste into AI → paste result back. 4. **Voice Interview.** App reads 3–5 questions aloud. User speaks. OS-native speech recognition transcribes offline. 60–90 seconds. Feels like a quick chat. Builds intent *and* scores credibility depth simultaneously. 5. **Document Upload.** Optional. Pitch deck, resume, or GitHub URL. Skippable. 6. **ID Verification.** Optional. Photo of ID processed on-device, confirms authenticity, then deleted. Only a credibility tier bump survives. 7. **Mode Toggle.** Active (broadcast) or Passive (listen). 8. **Calendar Sync.** OAuth to Google or an event platform. App detects which talks/mixers the user is attending. 9. **Permission Bundle.** One ask covering Bluetooth, Calendar read, Microphone, Camera — with a brief explanation of why each is needed. --- ### Flow 2: Discovery & Matching The passive, background experience. The app does the work while the user lives their conference life. **Presence Detection (Calendar-GPS Fusion):** The app needs to know the user is actually at an event — not just that they said they'd attend. But it can't ping GPS constantly (battery). Solution: calendar as oracle, GPS as spot-check. 1. App sleeps until an event window opens. Zero battery drain before this. 2. Event window opens. App prompts: "At [Event Name]? Tap to check in." 3. User taps yes. One GPS ping confirms they're inside the venue geofence. 4. Presence flag set with confidence score. Active for the event duration. 5. If the user leaves the geofence, a single low-frequency background check auto-clears the flag. 6. Overlapping events prompt a manual select. **Total battery cost for presence:** Under 5% across an 8-hour conference day. **Active Mode Broadcasting:** 1. Every 5–10 minutes, app broadcasts a BLE LE beacon packet 2. Packet contains only hashes and metadata — no raw content: ```json { "did_hash": "sha3(did_id)", "interests_hash": "sha3(interest_vector_quantized)", "pitch_hash": "sha3(pitch_json)", "stage": "seed", "ask": "zk_cofounder", "key_metric_hash": "sha3(key_metric)", "presence": true, "ttl": 600 } ``` 3. BLE mesh relays via nearby phones — extends range without internet 4. Encrypted with a session key derived from the DID 5. Battery cost: ~2mA at 5–10 min intervals **Passive Mode Listening:** 1. App listens continuously for BLE beacons (BLE LE is designed for this — low power) 2. Local scout extracts only allowed fields from incoming packets 3. Deterministic matching runs on-device: - Cosine similarity on interest vectors - Stage and category hard filter - 70% threshold 4. If the match clears: ZK proof exchange via Semaphore. The Active user proves specific attribute claims without revealing their full interest set. ~1KB proof, <1s generation, verified locally. 5. Notification surfaces with context: "High match — seed-stage ZK founder. Looking for infrastructure co-founder." 6. 90%+ of beacons are pruned before the notification stage. No flood. **Spam Protection:** - Rate limit: 3 pings/min per source DID hash. Exceeded → dropped. - Block list: swipe left on any notification → permanent ignore. - HMAC validation: beacon packets include an HMAC keyed to the DID claim. Spoofed DIDs fail validation. --- ### Flow 3: Handshake & Meeting 1. User taps "Interested" on a match notification 2. App pings the Active user via BLE mesh: "Someone matched — send a 15-sec teaser?" 3. Active user agrees: on-device model generates a short audio teaser from the pitch JSON (TTS, ~40KB .opus). Sent via WebRTC P2P. End-to-end encrypted. No server in the middle. 4. Passive user listens. The teaser is the AI's elevator pitch on their behalf. 5. If they want to meet: taps "Meet." App surfaces a location hint — auto-generated from calendar data ("Bar area near main stage") or manually entered ("Table 12"). 6. No raw coordinates shared. Coarse zone only. 7. IRL meeting happens. App goes to background. --- ### Flow 4: Post-Meet Contact Swap *This is the value delivery moment. Everything before this is filtering. This is where the app creates something you keep.* **Mutual consent gate:** Both users must tap "Share Contacts." Neither party's data moves until both have agreed. **Contact selection:** Each user picks what to expose independently — email, Telegram, LinkedIn, wallet, GitHub, or a free-text "other." One channel or all of them. **Voice note (optional):** - 10-second recording - On-device transcription + summarization into a 3-sentence digest - Example: *"Alice — ZK seed, sharp on the privacy angle, wants to DM about her deck."* - Raw audio is deleted after transcription **The bundle:** 1. Selected contact channels + AI-generated match context + voice note digest → contact card 2. Encrypted with the recipient's public key (ECDH via their DID) 3. Swapped via WebRTC file transfer — P2P, encrypted, max 200KB 4. Stored locally as an `.enc` file 5. Decrypted only when opened **Optional persistence:** Opt-in decentralized storage (Ceramic/IDX via free IPFS pinning). Cards persist even if both users uninstall. --- ## The Contact Card (What You Keep) When two people complete a swap, each receives a **contact card**. This is the artifact that makes the app sticky after the event. A contact card contains: 1. **Contact channels** — whatever the other person chose to share 2. **AI-generated context** — why you matched, what you have in common, what they're looking for 3. **Voice note digest** — 3-sentence summary of the interaction (if recorded) 4. **Match metadata** — overlap score, triggering categories, event context Not "here's someone's email." Instead, "here's someone's email, here's why you matched, here's what the AI understood about them, here's what they said in their own words." Pick it up three weeks later and know exactly what to say. --- ## On-Device Architecture & Operational Posture The single most important technical commitment in this product: **the agent lives on the phone, and the server holds nothing it doesn't need to.** This shapes privacy, cost, and the operational burden of running the platform for a new event. ### What Runs On Device | Component | Runs On Device | Why It Matters | |-----------|----------------|----------------| | Intent extraction (PDF, URL, summary) | Local model inference | Raw documents never leave the phone | | Adaptive card generation | Local | The AI knows what to ask next without a round trip | | Voice interview transcription | OS-native speech APIs (iOS Speech / Android SpeechRecognizer) | Offline, no cloud dependency | | BLE beacon generation + signing | Local | Sub-second response; zero server cost per broadcast | | Matching (cosine similarity, filters) | Local | No intent vectors ever touch a server | | ZK proof generation (Semaphore) | Local | ~1KB proofs, <1s on mid-range phones | | Proof verification | Local | Both parties verify without a trusted third party | | Voice note transcription + summarization | Local | Raw audio is discarded; only the digest survives | | Contact card encryption (ECDH) | Local | Server never sees contact payloads | | Photo ID check | Local | Photo deleted immediately after verification | ### What The Server Does Deliberately almost nothing. The server is a thin relay plus a handful of infrastructure primitives: - **BLE fallback relay.** If two phones can't hear each other directly, an event-local relay bridges the beacon. No decryption. No storage. - **DID registration proxy.** Submits the user's DID claim to the L2 on their behalf, paying gas. Stateless. - **Event configuration blob.** JSON file per event — venue geofence, branding, allowlisted credential types, sponsor copy. Under 100KB. - **Sponsor content delivery.** Serves approved sponsor cards and tracks impression counts for billing. No user data attached. - **Optional IPFS pinning bridge** for users who opt into post-event persistence. ### Operational Implications Because the agent is local and the server is thin, the cost and maintenance profile of running the platform is closer to a static site than a SaaS product: - **Per-event server footprint:** One commodity VM, roughly $20–$50/month at baseline, scales modestly with attendee count and sponsor content volume. - **Scaling behavior:** Matching is O(local) — adding 1,000 more attendees to an event does not add load to the server. It adds load to individual phones, which have headroom. - **Data breach surface:** Near zero. The server never has raw intent, raw documents, raw audio, contact cards, match results, or identity. A compromise yields the event config file and a list of DID hashes. - **White-label deployment effort:** A new event stands up with a new config JSON. No code fork. No per-event engineering team. Branding, geofence, credential types, and sponsor slots are configuration, not code. - **Compliance posture:** Nothing sensitive to retain, nothing to hand over under subpoena, nothing to accidentally log. Simplifies GDPR, CCPA, and enterprise conversations materially. The product's privacy story and its operating-cost story are the same story. One device-local architecture produces both. --- ## Revenue Model Two grounded revenue streams, both aligned with how conferences already spend money. The on-device architecture means neither of them requires scaling server capacity proportionally with revenue. ### 1. White-Label Event Licensing (Primary) Conference organizers license the platform as a branded app for their event. Same codebase, different configuration. - **Pricing model:** Tiered per-event license based on attendee count. A small regional event (~500 attendees) sits at the low end; a flagship multi-day conference (5,000+ attendees) at the high end. Multi-event contracts (annual event series, tour franchises) are sold as a discounted bundle. - **What's included:** Branded app, custom geofence and venue map, curated credential types relevant to the audience, sponsor slot management, post-event analytics dashboard (aggregate-only — no individual attendee data). - **What's not:** Attendee data. There is none to sell. The organizer's value is in running a better event, not harvesting a list. - **Why organizers pay:** Networking quality is the thing attendees remember and the thing that gets them to buy next year's ticket. Better matching is a direct retention lever. Premium ticket tiers ("includes networking agent access") become a defensible upsell. - **Unit economics:** Each event deployment is a config change, not a custom build. Incremental cost-of-goods per event is negligible after the first deployment. Margin approaches that of a templated product — typically 85%+ at scale. ### 2. Sponsor Advertising Slots (Secondary) Sponsors pay to place content in front of relevant attendees. This is the same spend sponsors already make on conference signage, swag, and sponsored sessions — but with meaningful targeting and no wasted impressions. - **Pricing model:** Flat-fee sponsor packages sold by the event organizer, tiered by slot type (headline sponsor, category sponsor, session sponsor). The platform takes a percentage of sponsor revenue as part of the license terms, or charges the organizer a separate per-impression fee. - **How placement works:** Sponsors provide a card — logo, tagline, short offer, optional link. The event organizer approves the copy and tags each sponsor card with the attendee archetypes and interest categories it should surface to. The user's agent only shows sponsor cards that match the user's intent profile; everything else is filtered out before it's ever rendered. - **Why it doesn't annoy attendees:** Relevance is enforced on-device before display. A DeFi founder looking for infrastructure engineers never sees a consumer-wallet ad. A recruiter sees tools and services that help with hiring. Irrelevant content is rejected by the agent, not tolerated by the user. - **Why sponsors pay:** Conference sponsorship today is a blunt instrument — everyone sees everything, and sponsors pay for a lot of wasted attention. This is the cleanest slice of that spend: verified in-venue presence, archetype-matched targeting, and an auditable impression count per sponsor. - **Platform take:** Configurable per contract. A typical arrangement is 15–25% of gross sponsor revenue flowing through the platform, with the organizer retaining the rest. ### Revenue Composition at Scale For a healthy conference (2,000 attendees, 30–40 sponsors, 3-day duration), the license fee is the dominant line item and sponsor revenue share is a meaningful secondary. The organizer keeps the majority of sponsor revenue; the platform earns a predictable license plus a participation slice of ad spend. The server cost for that same event is a single commodity VM and a handful of L2 gas sponsorships. Gross margin on event-level revenue remains well above 90% even with generous customer-success overhead. --- ## Trust & Safety Covered throughout the flows, but worth consolidating: - **No raw data leaves the phone without mutual consent.** Beacons are hashes; proofs are zero-knowledge; contact cards only move after both users tap share. - **Prompt injection defense:** URL parser and PDF parser both emit locked JSON schemas. A malicious portfolio page cannot hijack the core intent model. - **Sybil resistance:** DID claims anchored to L2; HMAC validation on beacons; Semaphore nullifiers for anonymous group membership without double-counting. - **Rate limiting + block lists:** Spam is contained at the BLE layer before it reaches the user's notification tray. - **Optional ID verification:** On-device only. Photo deleted immediately. Only a credibility tier bump is retained. - **Sponsor content gating:** All sponsor copy is approved by the event organizer before deployment. Agent-side relevance filtering means attendees don't see misaligned ads. --- ## What's Not in v1 - Cloud sync / docking with a personal AI assistant - Full on-chain Semaphore identity (local for v1) - On-chain ZK proof verification (local verification for v1) - LinkedIn integration (no programmatic API access) - Cross-event identity continuity at scale (the DID is portable; the reputation graph is a post-v1 roadmap item) - Multi-event-at-once support inside a single app instance (one event at a time for v1) - Any server-side component handling user data The v1 product is deliberately local, deliberately minimal, and deliberately light on infrastructure. Everything above is on the roadmap, but the thesis — that a privacy-preserving, agent-powered networking layer can be built almost entirely on the user's device — gets proven first. ================================================================================ # [Advisory Engagements] Web3 Entertainment Advisory — Investment Readiness Review Source: https://mobiuslabs.io/websitedata/client-work/lif/summary.md ================================================================================ # Web3 Entertainment Advisory — Investment Readiness Review **Principal Strategist:** Michael Carter / Mobius Labs --- ## Engagement Strategic advisory to a blockchain-native entertainment platform preparing a $500K–$1.5M raise on a $12–15M post-money SAFE. Scope covered the full advisory lifecycle: review of five source documents (white paper, investor deck, web deck, mini deck, term sheet), five-plus advisory calls over three months, a scored evaluation framework across eight dimensions, and call-by-call tracking of unresolved flags against written materials. The engagement was iterative. I gave a live cold read of the deck on the first call, delivered structured feedback on the second, and tracked founder progress against my recommendations across subsequent sessions. --- ## The Core Reframe The product was being pitched as a film project. In practice it was closer to a TV/series model with recurring fan engagement mechanics. That mismatch — how the company described itself versus what it was actually building — was creating friction with prospective investors before they ever reached the business model. Fixing the framing was the single highest-leverage move before the raise. --- ## The Eight-Dimension Framework I built a scored evaluation across Market Opportunity, Business Model, Product & Technology, Team, Token Architecture, Traction, Investment Terms, and Brand & Marketing. Each dimension received a 1–10 score with rationale. The composite: 5.9/10 — above the threshold for continued advisory, below the threshold for a clean institutional raise without addressing open flags. Deliverable: a dimension-by-dimension remediation list with priority ranking. Not "this needs work" — specific flags with specific fixes. --- ## Running Flag Tracker Flags raised in the written review were mapped call-by-call and marked cleared, open, or escalated. This made the advisory relationship accountable on both sides and gave the founder a clear view of progress across sessions rather than repeating the same general feedback. --- ## Cold Read Methodology On the first call I reviewed the deck live without prior prep, documenting my real-time reactions as a proxy for how a new investor would receive the materials. That produced direct, unfiltered feedback a prepared review would have missed: the film-vs-TV framing mismatch, the absence of a stated ask, and the over-prominence of token allocation in the opening sections. --- ## Strategic Impact - **Investment readiness with a clear remediation path.** The 5.9/10 scored review turned "this needs work" into a priority-ranked list of specific dimension-level fixes. - **Risks surfaced before the raise.** Audience metric concentration, an unresolved cold-start problem, and an unformed offshore token entity were documented and escalated before investors could raise them mid-raise. - **Iterative advisory structure.** Call synthesis converted a one-time review into a continuous process with accountability on both sides. ================================================================================ # [Advisory Engagements] Gaming M&A Engagement — Web 2.5 Division Strategy Source: https://mobiuslabs.io/websitedata/client-work/novasphere/summary.md ================================================================================ # Web 2.5 Gaming M&A Strategy — Blockchain Market Entry **Principal Strategist:** Michael Carter / Mobius Labs --- ## Engagement Retained as Principal Strategist by a VC-backed gaming startup for a three-month engagement to design and build their Web 2.5 division from the ground up. Mandate: architect the company's blockchain market entry, develop an M&A scouting and acquisition framework, identify and vet acquisition targets, broker strategic partnerships, and co-present the full investment thesis to the parent fund to establish a new internal IP R&D department. The engagement covered the full pre-launch lifecycle — from strategic framework through target identification, partnership execution, and investor presentation. Output: a deployable blueprint including the acquisition methodology, a live pipeline of vetted targets, three active distribution partnerships, and a complete investment thesis presented to the parent fund. --- ## The Core Reframe > "Own the game. Not the token." The gaming blockchain space had spent three years chasing tokenomics while ignoring the underlying games. Durable value in gaming comes from IP ownership, audience loyalty, and content distribution — not token speculation. Blockchain is useful for settlement, not for marketing. This reframe drove every downstream decision. Targets evaluated on IP quality and audience attachment, not token market cap. Partnership criteria centered on distribution reach and technical infrastructure, not chain affiliation. The thesis presented to the parent fund was anti-speculative by design. --- ## Four Integrated Workstreams **Acquisition Framework.** I built "Acquire-and-Amplify" — a four-lens IP qualification matrix scoring targets across IP Defensibility, Audience Attachment, Technical Leverage, and Distribution Upside. Each lens scored 1–10; composite scores determined pipeline priority. The output was a scored pipeline, not a wishlist. **Market Scouting.** Two complementary approaches. *Distressed Asset Identification* — studios with strong IP but weak monetization infrastructure, particularly in markets with unfavorable post-COVID conditions. *Nostalgia Arbitrage* — dormant IP from the 8-bit/16-bit era with verifiable revival demand but minimal current competition. **Partnership Development.** Identified and brokered three strategic partnerships across major Web3 gaming infrastructure, Southeast Asian mobile distribution via a telco-owned user acquisition platform, and access to existing Web3 game distribution networks. **Investor Presentation.** Co-developed and co-presented the investment thesis to the parent fund. Covered market opportunity, acquisition strategy, partnership stack, and financial model. --- ## Key Positioning Move The entire division strategy was designed around a **stablecoin-first, skill-based wagering model targeting the 40–60 casual gaming demographic** — disposable income, brand loyalty, low tolerance for speculative mechanics. This audience was being systematically ignored by Web3 gaming, which was optimizing for crypto-native 18–30 audiences already captured by existing platforms. --- ## Strategic Impact - **Complete market entry blueprint delivered.** Acquisition framework, scouting methodology, vetted target pipeline, active partnerships, investor thesis. - **Three active partnerships established** before any acquisition closed — giving the division immediate distribution infrastructure. - **Investment thesis presented to the parent fund**, securing the organizational mandate for the division. ================================================================================ # [Advisory Engagements] Civic Brand Strategy — Web3 Rebrand Source: https://mobiuslabs.io/websitedata/client-work/kc-catalyst/summary.md ================================================================================ # Civic Brand Strategy — Web3 Organization Rebrand & Community Positioning **Principal Strategist:** Michael Carter / Mobius Labs --- ## Engagement A Kansas City Web3 civic innovation organization engaged me to resolve a brand identity decision: whether to rebrand from their founding name, and if so, which of four candidate names best positioned them for long-term community growth and mainstream adoption. Scope covered the full brand strategy lifecycle — from analytical framework development through competitive evaluation, trademark risk assessment, strategic recommendation, and a complete marketing playbook for implementation. --- ## The Core Tension The organization faced a dual-audience problem: they needed a brand identity that felt authentic to their existing Web3 community while remaining accessible to mainstream Kansas City audiences — civic leaders, traditional businesses, and community members with no blockchain background. The typical answer is to pick one audience and sacrifice the other. I designed around it instead. --- ## Key Moves **14-Metric Brand Efficacy Framework.** A scoring system evaluating each candidate across five dimensions: Accessibility (how easily non-Web3 audiences could understand and adopt the name), Alignment (fit with mission and values), Social Dynamics (community adoption and word-of-mouth behavior), Operational Utility (practicality for daily use, digital handles, legal registration), and Strategic Positioning (long-term brand equity and differentiation). Each metric scored 1–10 with explicit rationale — defensible analysis, not brand opinion. **Competitive Name Analysis.** Four candidates evaluated head-to-head. The recommended candidate scored 8.28/10, significantly outperforming the runner-up (4.91/10) across accessibility, social adoption, and operational utility. **Trademark Risk Identification.** Proactive research surfaced that the organization's founding name was unavailable for trademark registration — another Kansas City government program had been operating under it since early 2025. Flagging this before investment prevented a costly legal remediation cycle. **Dual-Brand Architecture.** The final recommendation wasn't "pick one." A mainstream-facing operating name handles public communications. A secondary visual seal and philosophical layer preserves insider depth for community materials. Both names do different jobs. The tension dissolves. **Convergent Model Validation.** I ran the evaluation framework through two independent model personas (Claude and Grok) to stress-test the recommendation. Both converged on the same outcome independently — reinforcing the analytical integrity of the framework. --- ## Strategic Impact - **Structured brand decision infrastructure.** The 14-Metric framework transforms brand selection from subjective debate into scored, defensible analysis. Reusable for any organization facing naming decisions. - **Legal exposure prevented.** Trademark conflict identification eliminated the unavailable candidate before resources were invested in remediation. - **Dual-audience tension resolved.** The dual-brand architecture preserved community identity depth while enabling mainstream accessibility — a resolution neither a pure-accessibility nor pure-authenticity approach could deliver. Full deliverables: brand efficacy scoring, competitive analysis, trademark risk assessment, dual-brand architecture specification, and a complete marketing playbook covering positioning, messaging, content pillars, channel strategy, and launch sequence. ================================================================================ # [Advisory Engagements] Missouri Blockchain Council — Legislative Strategy Source: https://mobiuslabs.io/websitedata/client-work/missouri-blockchain/summary.md ================================================================================ # Missouri Blockchain Business Council — Strategic Architecture **Principal Strategist:** Michael Carter / Mobius Labs --- ## What I Was Engaged To Do Design the strategic architecture for a proposed industry council aimed at establishing Missouri as a competitive blockchain and digital asset hub. Full scope: mission, governance, legislative landscape, stakeholder map, membership and revenue model, and a phased roadmap from formation to sustainable operation. --- ## The Thesis Missouri's competitive window is open now. Neighboring states are moving on blockchain-friendly legislation, and the cost of waiting is measured in businesses and talent that will locate elsewhere. The council's job isn't to lobby for blockchain in the abstract. It's to make Missouri the most operationally predictable state for digital asset businesses — clear regulation, low friction, and a business community that knows how to work with the technology. --- ## Four Integrated Workstreams **Governance.** Founding board composition, membership tiers, and a decision-making model balanced between industry members (who fund operations) and policy/academic members (who provide credibility) to avoid capture by any single constituency. **Legislative Roadmap.** Priority targets across three categories: digital asset clarification (property rights, tax treatment), blockchain commercial applications (smart contracts, land records, supply chain), and innovation-friendly regulation (sandbox provisions, licensing clarity). Sequenced by feasibility and coalition-building requirements. **Stakeholder Mapping.** Engagement matrix for the Missouri General Assembly — committee chairs, sympathetic sponsors, potential opposition — plus parallel tracks into industry associations, law schools, Missouri-based blockchain businesses, and national organizations with Missouri chapters. **Revenue & Membership.** Tiered dues scaled to organizational size, supplemented by event revenue, sponsorships, and grant funding. Break-even membership modeled; founding member recruitment sequenced. --- ## Key Moves **The Predictability Doctrine.** Reframed the council's agenda away from "blockchain promotion" and toward regulatory predictability. Businesses don't need favorable treatment; they need clear rules. This broadens the coalition and softens the ask for skeptical legislators. **Founder-Member Sequencing.** Founding member recruitment as a deliberate sequencing exercise: identify the three to five anchor members whose names make subsequent recruitment easier, sign them before public launch, use that credibility to close the next tier. **Dual-Track Legislative Calendar.** Mapped the council's agenda against the actual Assembly calendar — committee assignment windows, bill filing deadlines, hearing schedules — to separate what's achievable in session one from what requires a longer relationship runway. --- ## Delivered - Complete founding architecture: governance, membership model, legislative roadmap, stakeholder map, phased growth plan. - Competitive positioning brief documenting Missouri's specific gaps and opportunities versus neighboring states. - Operationalized legislative agenda mapped to the General Assembly's calendar and committee structure. The strategic playbook is complete. Next steps are anchor-member recruitment, formal incorporation, and governance alignment with the founding team ahead of the first legislative session target. ================================================================================ # [Advisory Engagements] Missouri Blockchain Council — Roadmap Source: https://mobiuslabs.io/websitedata/client-work/missouri-blockchain/roadmap.md ================================================================================ # Missouri Blockchain Business Council ## Strategic Roadmap & Business Plan *Working document — March 2026* --- ## Executive Summary Missouri has a unique window to become a top-5 blockchain-friendly state. We have structural advantages — zero capital gains, central location, low cost of operation — that no one is messaging. Wyoming set the template; Missouri can execute faster and smarter. This document covers: 1. **The Case** — why blockchain, why Missouri, why now 2. **The Playbook** — what a 501(c)(6) can actually do 3. **The Roadmap** — 90-day, 6-month, 12-month milestones 4. **Legislative Priorities** — what to push for 5. **Messaging Framework** — how to talk about this --- ## Part 1: The Case ### Why Blockchain? (For Skeptics) Blockchain is infrastructure, not speculation. The use cases that matter for Missouri businesses: | Use Case | Business Benefit | Who Cares | |----------|------------------|-----------| | **Payment rails** | 2–3% fee reduction on transactions | Every retailer, service business | | **Supply chain verification** | Provenance tracking, reduced fraud | Agriculture, manufacturing | | **Treasury management** | Yield on idle cash, inflation hedge | CFOs with $500K+ sitting around | | **Smart contracts** | Automated compliance, reduced legal costs | Real estate, logistics, B2B | | **Tokenized assets** | Fractional ownership, liquidity | Commercial real estate, equipment | | **Public records** | Immutable registries, reduced bureaucracy | County recorders, title companies | **The meta-point:** businesses don't need to "believe in crypto." They need to reduce costs and improve efficiency. Blockchain is a tool for that. Full stop. ### Why Missouri? (The Unfair Advantages) **1. Zero State Capital Gains Tax.** Only 9 states have this. Massive advantage for any business holding digital assets. Wyoming has income tax; we don't tax gains at all. This is the selling point for relocating crypto businesses. **2. Central Geography.** Lowest latency to both coasts. Kansas City is the #1 freight rail hub. Blockchain doesn't care about geography — but data centers and talent do. **3. Low Cost Structure.** Office space 40–60% cheaper than coastal cities. Talent costs 30% lower than Austin or Miami. Energy costs below national average. **4. Existing Tech Ecosystems.** Kansas City (Garmin, Cerner and Sprint legacy talent, growing startup scene). St. Louis (Benson Hill, Block office, Cultivation Capital). Springfield/Columbia (universities with CS programs). **5. Regulatory Whitespace.** Missouri hasn't over-regulated crypto. Clean slate to do it right. Business-friendly legislature. **6. Agricultural & Manufacturing Base.** Supply chain traceability is a killer app. Missouri farmers could use blockchain for commodity provenance. Manufacturing verification and compliance. ### Why Now? - **Federal clarity is coming:** 2025–2026 is when federal stablecoin/crypto legislation likely passes. - **State competition is heating up:** Wyoming, Texas, Florida, Utah all making moves. - **Post-speculation era:** the hype died; now it's about utility. - **Missouri is behind:** we have the advantages but zero organized effort to capitalize on them. --- ## Part 2: What a 501(c)(6) Can Do A 501(c)(6) is a business league — think Chamber of Commerce for a specific industry. **Can do:** collect membership dues; lobby substantially (not unlimited); educate members and public; set industry standards; host events and conferences; issue certifications; publish research and position papers; coordinate member activities; endorse policy positions (not candidates). **Cannot do:** be primarily political (but it can be secondary); disproportionately benefit individual members; act as a front for a single company; operate as a for-profit business. ### Lobbying Power 501(c)(6) organizations can lobby substantially. Up to 50% of budget can go to lobbying activities. Can register as a lobbying organization in Missouri, draft and advocate for specific legislation, testify before committees, and mobilize members to contact legislators. Missouri registration: organizations spending more than $500/year on lobbying must register. The process is simple, inexpensive, and gives legitimacy and access. --- ## Part 3: The Roadmap ### Phase 1 — Foundation (Days 1–90) **Weeks 1–4: Legal & Organizational** - File 501(c)(6) with IRS (can operate while pending) - Register as Missouri nonprofit corporation - Draft bylaws emphasizing neutrality and anti-capture provisions - Open bank account; set up basic website **Weeks 5–8: Founding Members** - Recruit 10–15 founding members: 5–7 operating, 3–5 enabling, 2–3 advisory (attorneys, accountants, academics) - Lock in founding member pricing - Establish founding board (5–7 members) **Weeks 9–12: Positioning** - Publish "State of Blockchain in Missouri" report - Media outreach: KC Star, St. Louis Post-Dispatch, regional business journals - First member event (virtual or in-person) - Register as a Missouri lobbying organization **90-Day Success Metrics:** 15+ members · $25K+ in committed dues · 1 media hit · lobbying registration complete · one policy position paper drafted. ### Phase 2 — Credibility (Months 4–6) - Identify 3–5 friendly legislators (both parties); draft first model legislation; schedule testimony opportunities; build a relationship with the Missouri Chamber of Commerce. - Monthly member calls; first "Digital Commerce Readiness" certified business; CFO's Guide to Digital Assets; member directory launched. - University partnerships (UMKC, Mizzou, WashU); coordination with Kansas City Tech Council and St. Louis Regional Chamber; 2–3 municipal pilot opportunities identified. **6-Month Metrics:** 40+ members · $75K+ annual dues committed · 1 bill introduced · 3 media hits · 1 municipal pilot in discussion. ### Phase 3 — Influence (Months 7–12) - Pass at least one blockchain-friendly bill; block anything harmful; establish ongoing relationships with key committees. - Host first Missouri Blockchain Summit; attract out-of-state speakers and attendees; position Missouri in the national conversation. - 2–3 businesses relocate or expand to Missouri (attributable). Municipal pilot live. University partnerships producing research and talent. **12-Month Metrics:** 100+ members · $200K+ annual budget · 1 passed legislation · 1 conference hosted · national media recognition. --- ## Part 4: Legislative Priorities ### Tier 1 — Quick Wins (2026) **Blockchain Records Clarification Act.** Smart contracts enforceable; blockchain signatures satisfy signature requirements; blockchain timestamps legally valid. Wyoming passed similar in 2019 — model language exists. **Digital Asset Custody Clarification.** Banks and trust companies can custody digital assets; clear standards for custodial security; consumer protection provisions. Most states have done this. Missouri is behind. ### Tier 2 — Competitive Advantage (2026–2027) **DAO LLC Framework.** LLCs can be governed by smart contracts; DAOs can register Wyoming-style; clear liability protections. Wyoming did this in 2021 — we can improve on their model. **DUNA (Decentralized Unincorporated Nonprofit Association).** New legal structure for decentralized organizations. Wyoming passed March 2024 — cutting edge. Missouri could be #2. **Digital Asset Tax Clarity.** Confirm zero capital gains on digital assets (already true, make it explicit). Exempt small transactions (<$200) from reporting. Clear guidance for businesses. ### Tier 3 — Leadership Position (2027+) **Municipal Blockchain Pilot Authority.** Allow cities and counties to experiment with property records, permit and license issuance, and public fund transparency on-chain. Safe harbor for good-faith pilots. **Blockchain Business Development Incentives.** Tax credits for businesses relocating to Missouri; workforce development grants; R&D tax credits for blockchain innovation. --- ## Part 5: Messaging Framework ### For Legislators **Say:** "Cost reduction for Missouri businesses." "Keeping Missouri competitive with Wyoming, Texas, Florida." "Modern infrastructure, not speculation." "Zero capital gains is already an advantage — let's build on it." "Job creation and business retention." **Don't say:** "Crypto" (use "digital assets" or "blockchain"). Anything about price or speculation. Anything that sounds like hype. Technical jargon. ### For Business Owners > "You're paying 2.5–3% on every credit card transaction. Your competitors are finding ways around that. You have cash sitting in accounts earning nothing while inflation eats it. The Missouri Blockchain Business Council helps you understand your options — not to sell you anything, but to reduce your costs and improve your operations." ### For Media 1. Missouri has structural advantages (zero cap gains) we're not capitalizing on. 2. Wyoming moved first; Missouri can move smarter. 3. This is about business fundamentals, not speculation. 4. We're behind — organized effort is overdue. --- ## Appendix: Resources **Wyoming Legislation to Study.** SF0038 (2021) — DAO LLC Supplement. Decentralized Unincorporated Nonprofit Association Act (2024). Wyoming Blockchain Task Force reports. **Potential Missouri Partners.** Missouri Chamber of Commerce · Kansas City Tech Council · St. Louis Regional Chamber · UMKC Bloch School · Mizzou Law School · Washington University fintech research. **National Organizations.** Chamber of Digital Commerce · Blockchain Association · Digital Chamber. ================================================================================ # [Advisory Engagements] Gaming IP Research — IP Lifecycle & UGC Strategy Source: https://mobiuslabs.io/websitedata/client-work/gaming-ip/summary.md ================================================================================ # Gaming IP, UGC & Blockchain Monetization — Research & Strategy **Principal Strategist:** Michael Carter / Mobius Labs --- ## Engagement A research engagement mapping the intersection of gaming IP, user-generated content platforms, and blockchain-based monetization. The mandate: understand how successful gaming properties build and sustain IP value, how UGC platforms (Roblox in particular) have changed creator economics, and what blockchain infrastructure adds beyond speculative token mechanics. Output: a research synthesis and strategic framework applicable to any gaming IP development or acquisition decision. --- ## The Core Premise In gaming, the character and the world are the product. Not the token. Not the platform. The IP. Every monetization mechanic, every distribution deal, every community activation either builds IP equity or depletes it. That's the lens that makes sense of why some gaming franchises compound in value over decades while others flame out after a successful launch. Secondary thesis: UGC platforms have fundamentally changed the IP development calculus. Players who can build inside a world become advocates for that world in ways no marketing spend can replicate. IP strategies that ignore this dynamic are leaving both revenue and community development on the table. --- ## Three Analytical Tracks **IP Lifecycle Analysis.** How character-based IP systems in gaming build and defend value over time, with particular attention to franchises that have sustained relevance across platform transitions (console → mobile → digital-native). **UGC Platform Mechanics.** In-depth analysis of Roblox's creator economy — revenue share structure, discovery mechanics, and the social dynamics that drive creator retention and user acquisition. Extended to adjacent platforms (Fortnite Creative, Minecraft, Rec Room) to identify common patterns. **Blockchain Integration Assessment.** Evaluated how blockchain infrastructure — specifically NFT IP systems — interacts with traditional gaming IP frameworks. Both the theoretical case (provable ownership, secondary-market royalties, community governance) and the practical reality (low adoption, speculative behavior undermining IP value, technical friction). --- ## Key Findings **The Hub-and-Spoke IP Model.** A consistent pattern in successful gaming IP: a central franchise hub with strong character identity, radiating out to licensed products, community content, and platform-specific adaptations. The spokes drive awareness back to the hub rather than fragmenting the IP across disconnected experiences. **Content as Distribution.** The most durable gaming IPs don't market themselves through advertising; they create content audiences want to watch and share. YouTube channels, streaming content, and community-created media become the primary discovery mechanism. The IP itself is the distribution channel. **Pre-Launch IP Registration.** One of the most consistent findings: successful gaming IP owners treat trademark registration, character design documentation, and content licensing frameworks as pre-launch infrastructure, not post-success cleanup. The window between concept and public launch is when IP protection is cheapest and most complete. --- ## Strategic Impact - **Applicable to acquisition and development decisions.** The IP qualification criteria, UGC platform analysis, and blockchain integration assessment plug directly into both acquisition evaluation and new-IP development. - **The UGC multiplier documented.** UGC platform integration, done correctly, produces community-driven IP amplification that compounds over time. The research documents the mechanics of how this works and what triggers it. - **Blockchain case grounded.** Separates the genuinely useful blockchain applications (provable ownership, royalty enforcement, community governance) from speculative mechanics that undermine IP value — a clearer picture of where blockchain adds to gaming IP and where it detracts. ================================================================================ # [Reference] CV — Michael Carter Source: https://mobiuslabs.io/websitedata/cv/cv.md ================================================================================ # Michael Carter **Founder · Mobius Labs** **Research · Advisory · Agentic Infrastructure** m.carter@mobiuslabs.io · [@doktor_defi](https://x.com/doktor_defi) · [@doktor_funk](https://t.me/doktor_funk) --- ## Summary Founder of Mobius Labs, a research-first venture studio at the intersection of sovereign identity, agentic systems, and consumer product. 25 years of operational management — hospitality, travel, high-volume customer operations, recruiting, team leadership — followed by six years of hands-on Web3 work spanning investment evaluation, founder advisory, ecosystem partnerships, and crisis communications. Known for relationship-driven business development, rapid strategic clarity, and communicating fluidly across every stakeholder type — from developers to executives to community members. The research portfolio is the core work; advisory engagements test the frameworks against live client problems. --- ## Core Capabilities **Research & Thesis Work** — Primary author of the Internet of Agents (IoA) protocol specification, ConduitID sovereign identity architecture, and the Conduit verified-fandom advertising thesis. Working documents with architecture, market analysis, unit economics, and scored frameworks. **Strategic Advisory** — Investment readiness review, brand architecture, legislative strategy, M&A framework design. Scored evaluation matrices over subjective opinion. Diagnostic first, prescriptive second. **Business Development & Relationships** — Warm network across Web3 VC, advisory, and builder ecosystems across the US, MENA, and Europe. Converts relationships into pipeline. Comfortable across every stakeholder type. **Investment Evaluation & Due Diligence** — 200+ early-stage pitches evaluated in groups with $50M+ collective AUM. Supported $400K+ in seed closes. Pattern recognition built across DeFi, gaming, infrastructure, and consumer Web3. **Marketing, Brand & Communications** — Brand identity development, strategic positioning, investment narrative refinement. Crisis communications under pressure with a 10,000+ stakeholder community. Public speaking, hosting, media. **Systems & Technical Fluency** — Working knowledge of EVM-compatible ecosystems, smart contract logic, Web3 infrastructure. Built custom AI multi-agent research infrastructure. Bridge between technical and non-technical stakeholders; conducts technical DD without an engineer in the room. **Crisis Management & Governance** — Led public communications through a high-stakes founder exploit; restored community trust and facilitated a full leadership transition under live pressure. --- ## Mobius Labs — Selected Work ### Research Portfolio (Premier) - **Internet of Agents (IoA).** Protocol specification for autonomous AI agent coordination, identity, trust, and accountability. Core thesis: agents need verified identity, bounded authority, and post-transaction accountability that doesn't compromise their principals. - **ConduitID.** Sovereign identity layer with ZK credential architecture and a data economy model where users are participants in the value they generate, not inventory. - **Conduit (2023–24 origin).** Verified fandom as a distinct advertising category. Smart contract licensing for fan content. The originating document for the identity thesis that became ConduitID. - **Moonlight.** Social discovery platform with ZK identity integration; full business plan with market analysis and economics. - **Nano Smart City.** Civic infrastructure blueprint for municipal-scale ZK identity, public records, and agentic service delivery. - **ZK Networking App.** Conference networking protocol with credential-gated access and privacy-preserving discovery. ### Advisory Engagements - **Web3 Entertainment — Investment Readiness Review.** 8-dimension scored evaluation (5.9/10 composite), live flag tracker across five advisory calls, cold-read methodology surfacing framing and positioning issues before the raise. - **Gaming Startup — Web 2.5 Division M&A Strategy.** Three-month Principal Strategist engagement. Designed the "Acquire-and-Amplify" IP qualification framework, populated a vetted acquisition pipeline, brokered three strategic distribution partnerships, co-presented the investment thesis to the parent fund, established the internal IP R&D department mandate. - **Web3 Civic Organization — Brand Architecture & Rebrand.** 14-metric brand efficacy framework, competitive name analysis, trademark risk audit, dual-brand architecture recommendation, complete marketing playbook. - **Missouri Blockchain Business Council — Strategic Architecture.** Full organizational design for a proposed 501(c)(6): governance, membership model, legislative roadmap, stakeholder map, phased growth plan. - **Gaming IP Research.** Three-track research engagement on gaming IP lifecycle, UGC platform mechanics (Roblox-first), and blockchain integration. Strategic framework applicable to acquisition and development decisions. --- ## Earlier Experience **Founding Contributing Member** — Kansas City Web3 civic innovation organization. Early-stage governance, community design, civic-tech positioning. **Core Member & Due Diligence Lead** — Invite-only Web3 investment community. 200+ pitches evaluated, DD contributions for groups with $50M+ collective AUM. **BD & Crisis Communications Lead** — Layer-1 blockchain. Led business development and ecosystem partnerships. Assumed crisis communications after a founder-led exploit; restored community trust across 10,000+ stakeholders; facilitated full leadership transition. **Strategic Advisor** — Early-stage Web3 project. Secured $150K seed funding through network and investment narrative work. Post-raise strategy through TGE and initial market entry. **Core Team & Strategic Lead** — Early-stage gaming project. Progressed from community member to core team; authored foundational branding and strategic framework; instrumental in $250K raise. **General Manager / Operations** — Hospitality industry. 20 years in hotel, travel, and service management: scheduling, vendor coordination, team leadership, customer experience at high volume. The operational foundation under everything since. --- ## Community & Ecosystem - Co-host, weekly Web3 builder education and ethics discussions - Public advocate for independent creative builders; regular speaking, interviews, community moderation across Web3 gaming, DeFi, entertainment, and infrastructure - Ongoing strategic collaboration with early-stage founders across gaming, entertainment, and consumer IP --- ## References Available upon request.