# UsePod ### The Inference Marketplace **Christopher Ryan Gilbert** Founder & Principal Engineer, 100X CTO, LLC [100x.dev](https://100x.dev) *v0.6 (draft) — April 2026* --- ## Abstract AI inference is becoming a commodity. The open-weight model ecosystem has closed the gap with frontier proprietary models for the majority of real-world workloads. The hardware to run these models is widely available — datacenter GPUs, consumer 4090s, Apple Silicon. The inference engines (vLLM, llama.cpp, LM Studio, Ollama) are open source and mature. The economic logic of any commodity market applies: when many independent suppliers can produce a fungible good, the price converges on marginal cost. UsePod is the clearing house for this market. Independent operators run inference on their own hardware, set prices, and earn USDC. Users send standard OpenAI- or Anthropic-compatible API requests and get matched with the best-priced provider that meets their requirements. Centralized providers (Anthropic, OpenAI, Venice, Together, Groq, OpenRouter) remain available as a tier-zero fallback, always. This document is not a privacy protocol whitepaper. Earlier drafts of the UsePod thesis led with hardware-enforced privacy, onion routing, and token-economic primitives. Those tracks remain on the roadmap, but they are not v2.0. Building them before the marketplace itself reaches density would invert the order of operations that has worked for every successful two-sided marketplace in software history. eBay shipped before PayPal escrow. Uber shipped before driver background checks were standardized. Airbnb shipped before ID verification existed at all. Each of them won by reaching critical mass, then earned trust through mechanisms layered on top. UsePod follows the same playbook: marketplace first, trust mechanisms second, advanced privacy and tokenomics when traction justifies the engineering investment. --- ## 1. The Commoditization of Inference ### 1.1 What Has Changed For most of the last three years, AI inference looked like a differentiated software product. OpenAI charged $2.50 per million input tokens for its top model. Anthropic charged comparable rates. Each provider set its prices unilaterally. There was no price discovery, no competitive bidding, no market mechanism. The price reflected the cost of producing a uniquely capable model, not the marginal cost of running a token through a GPU. This was a temporary state of the world. The open-weight ecosystem has reached a quality threshold where, for the majority of real-world tasks, open-weight models match or exceed the proprietary frontier on price-adjusted quality. Llama 4. Qwen 3.5. DeepSeek V3.2. Mistral Small 4. GLM-5.1. These models are public weights. Anyone with a GPU can serve them. Tracking organizations measure the gap between proprietary frontier and open-weight quality at roughly three months and narrowing. When the product is fungible — when a token generated by Llama 4 on GPU cluster A is identical to one generated on GPU cluster B — the economics shift. Suppliers compete on price, latency, throughput, and reliability rather than on which model their lab happens to own. The price ceiling is set by what the cheapest competent provider charges, not by what the proprietary leader can extract. The economic logic of commodity markets takes over. This has happened before, in compute and in everything else. Cloud compute commoditized when AWS-equivalent capacity became available from Google, Azure, and a long tail of regional providers. Storage commoditized. Bandwidth commoditized. Each commoditization moment looks the same from inside it: incumbents protest that "ours is different, you can't really compare," prices stay sticky for a window, and then the floor falls out. The current AI subscription tiers — $20/month plans that throttle aggressively, $100–$200/month tiers that don't, "Pro" gates on the best models — are the visible form of an industry trying to extract from the late stages of differentiation. They are not a stable equilibrium. They are the part of the curve where supply has overshot demand pricing power. ### 1.2 What an Open Marketplace Does to This A marketplace replaces unilateral pricing with price discovery. Providers set their own prices. Users choose providers based on price, latency, and quality. The cheapest competent provider sets the floor; the rest compete or lose traffic. Two consequences follow. First, the price for any given model converges on marginal cost. Any provider with cheaper electricity, more efficient batching, or newer hardware can undercut the rest. Those efficiency gains flow through to users as lower prices rather than being captured as margin. This is what commoditized markets do, and it is what AI inference markets will do once the market mechanism exists. Second, blended cost optimization becomes available to every workload. A coding assistant making thousands of inference calls per day does not need to send all of them to a frontier model at $2.50/M. Eighty percent of those calls — boilerplate, refactors, test scaffolding — route to a commodity open-weight model at $0.30–$0.50/M. The remaining twenty percent — architecture decisions, complex debugging, careful refactoring — route to a frontier model where it matters. The blended cost lands at roughly $0.50–$1/M. At that rate, a month of intensive AI-assisted coding costs $10–$30 of compute. Less than a single month of any current subscription tier. With no rate limits, no quotas, no throttling. The user case for the marketplace is not "decentralization is a virtue." The user case is "you pay less for the same output." The provider case is not "fight the centralized cabal." The provider case is "your hardware earns USDC continuously instead of sitting idle." Both sides win on economics, which is the only stable foundation for a marketplace. --- ## 2. The Marketplace Thesis ### 2.1 What Two-Sided Marketplaces Actually Are A two-sided marketplace is a platform that creates value by matching two distinct user groups whose interactions create surplus that neither could create alone. eBay matches buyers with sellers. Uber matches riders with drivers. Airbnb matches travelers with hosts. The platform itself produces nothing tangible; its product is the matching, the pricing infrastructure, the trust system, and the transaction settlement. These platforms share a small number of structural features that, in retrospect, look obvious. They are not obvious in advance, and most marketplace attempts fail because they neglect one or more of them. **Density is the only thing that matters in the early stages.** A marketplace with a thousand suppliers and ten buyers fails. A marketplace with ten suppliers and a thousand buyers fails. Density on both sides simultaneously is what makes the matching valuable. Below critical density, every other concern — trust, optimization, governance — is premature. Marketplaces that try to perfect their trust systems before reaching density typically die without ever reaching density. **The harder side gets subsidized.** In every successful marketplace, the platform identifies which side has higher friction to participate and reduces that friction with subsidies, support, or both. Uber subsidized drivers heavily in early markets — sign-up bonuses, guaranteed minimum earnings, free phones. Airbnb invested heavily in host onboarding, professional photography for listings, host insurance. eBay's first users were sellers, and the platform was free for years. The platform absorbs early-stage cost on the constrained side because that side's growth is what unlocks the network effect. **Trust mechanisms come after density, not before.** eBay shipped without escrow. Feedback ratings emerged after the marketplace had enough volume that they were necessary; PayPal acquisition came in 2002, seven years after eBay's launch and after the company was already large. Uber's driver background-check standardization came after market entry, not before. Airbnb's host-verification system, host insurance, and trust-and-safety apparatus all evolved post-launch as the marketplace scale demanded them. None of these companies had a "trust protocol" before they had users. **Drop-in compatibility wins.** Every successful marketplace makes participation cheap on both sides. eBay let sellers list with a simple form and accepted standard payment instruments from buyers. Uber's value to riders was a button on a phone they already owned; its value to drivers was a job they could do with a car they already had. Airbnb worked with photographs taken with iPhones. The platforms succeeded by removing friction, not by demanding that participants adopt new tools or new mental models. ### 2.2 The UsePod Application of This The same principles apply directly to inference compute. **Density first.** v2.0's product strategy is reaching enough providers and users that the matching is genuinely valuable. Until both sides have density, polish on trust, attestation, or token economics is wasted motion. We will not ship privacy mode, attestation tiers, or token launches before the marketplace itself works. **Subsidize the supply side.** Operators are the harder side: they need to install software, configure backends, post a small bond, and accept that their hardware will run real workloads for real money. Users are the easier side: they need to change a base URL. The launch program subsidizes operators directly — $20 USDC bond credit for the first 100 operators, featured placement in the network UI, hands-on onboarding support. Operators who were idle become productive; the user side fills in behind them. **Trust as infrastructure, not as principle.** v2.0 ships a deliberately lightweight trust stack: tokenizer-side count enforcement, reputation scoring, hidden benchmark canaries, and a $50 USDC enrollment bond. This is sufficient at v2.0 scale and dishonest at any larger scale. v3+ will expand into TEE attestation tiers, larger canary corpora, and possibly cryptographic proof mechanisms. The progression is honest: enough for now, more when the volume justifies it. **Drop-in compatibility for users.** A user with an existing OpenAI- or Anthropic-compatible client switches base URLs and is done. No SDK migration. No new authentication scheme. No token registration. Existing tools — Claude Code, Cursor, custom agents, LangChain pipelines — work unchanged. This is not aspirational; this is shipped. The thesis is not novel. eBay, Uber, and Airbnb proved it across very different verticals. The application to inference is the contribution. --- ## 3. The Supply Side ### 3.1 Who the Suppliers Are The supply side of UsePod is anyone with GPU capacity who wants to monetize idle cycles or build out a dedicated inference business. Three categories make sense at v2.0: **Idle hardware operators.** Engineers, ML enthusiasts, and small businesses who own consumer-grade GPUs (4090, 5090, Mac Studio with M-series silicon) that sit idle when not actively used for development or gaming. These operators add capacity to the network during off-hours and earn passive USDC. Their economics work because the hardware is sunk cost; any revenue is upside. **Dedicated rigs.** Operators running purpose-built inference servers, typically with one or a small number of datacenter GPUs (A100, H100, B200), often in colocation or home labs. These operators are running this as a business. Their economics work because they have access to cheap electricity, efficient cooling, and the operational discipline to keep utilization high. **BYOK proxies.** Operators with paid OpenRouter or Venice accounts who want to resell their access at a small markup. The operator's agent forwards requests to OpenRouter or Venice, applies a configurable markup, and pockets the difference. This category is interesting because it requires no hardware investment: the operator's value-add is being a reliable, well-priced gateway to specific upstream models. The provider agent — the standalone software each operator runs — supports all three. It auto-detects local backends (vLLM, llama.cpp, LM Studio, Ollama) and accepts BYOK configuration for OpenRouter and Venice. One config file, one binary, one outbound network connection. The agent does not expose any inbound port; operators do not need to expose anything through their NAT or firewall. ### 3.2 What Operators Do Operators do five things and the agent handles the rest. 1. Install the agent (`curl https://usepod.ai/install.sh | sh` or the platform equivalent). 2. Run `usepod-agent enroll` on the host, which generates an Ed25519 keypair and prints an enrollment code. 3. Paste the enrollment code into the host UI on usepod.ai. 4. Send $50 USDC to the on-chain bond address with the enrollment-specific deposit code. 5. Configure pricing: which models to expose, what to charge per million tokens. Within 10 minutes of starting step 1, the operator's hardware is serving traffic and accruing USDC. The dashboard shows live earnings, requests served, top-earning models, and current network rank. Withdrawal to the operator's Solana wallet is a one-click action with on-chain confirmation in under two minutes. ### 3.3 Operator Economics Operator revenue comes from three things: how many models they serve, how competitive their pricing is, and how much demand exists for their models on a given day. The fee split is straightforward. On every request served by a marketplace operator, the operator receives **80% of the gross inference fee** and UsePod's treasury receives **20%**. There are no hidden fees, no payment processor cuts, no tiered rates. An operator who quotes $0.40/M input tokens for Llama 4 receives $0.32/M; UsePod receives $0.08/M. For comparison: existing inference clearinghouses (notably OpenRouter) operate at a higher take rate than 20%, with less transparency about the split. UsePod's 80/20 is the most operator-favorable split among comparable platforms because operator density is the strategic priority of v2.0. We will tighten the take rate later only if and when supply density genuinely outpaces demand growth, and the change will be public. There is no revenue share by token, no percentage of token supply, no staking yield. Where the yield comes from is simple and worth saying directly: it comes from the 20% take on inference fees. That is the entire monetization mechanism. Higher inference volume produces more treasury revenue. Higher operator earnings produce more supply density. Both grow together. Speculative value is absent from the model by design. ### 3.4 Suggested Pricing and Price Discovery The host UI shows operators what other operators on the network are charging for the same models. This is not a price-fixing mechanism — operators can quote whatever they want — but it gives new operators a starting point. As the network matures, observed prices converge on marginal cost for each model class. Operators with structural advantages — cheaper electricity, more efficient hardware, better batching — can profitably undercut others and capture more traffic. Operators without those advantages either match the market price (and earn proportionally less per token but rely on volume) or exit. This is the same dynamic that operates in cloud compute, in commodity hosting, and in every other infrastructure market. --- ## 4. The Demand Side ### 4.1 Drop-In Compatibility The user side has exactly one onboarding step. Change the base URL of an existing OpenAI- or Anthropic-compatible client to point at UsePod, and the rest works unchanged. ```bash # Before ANTHROPIC_BASE_URL=https://api.anthropic.com claude # After ANTHROPIC_BASE_URL=https://api.usepod.ai/proxy/ claude ``` ```bash # Before OPENAI_BASE_URL=https://api.openai.com/v1 cursor # After OPENAI_BASE_URL=https://api.usepod.ai/proxy//v1 cursor ``` The same client, the same SDK, the same code, the same prompt formatting — all of it works. The UsePod gateway accepts the existing request format, routes through the marketplace if a qualifying provider is available, falls back to the centralized router otherwise, and returns the response in the format the client expects. Streaming works. Tool use works. Vision works. The user does not need to know about marketplace mechanics to benefit from them. This is the most important UX promise in v2.0 and it is non-negotiable. The marketplace fails as a product if it requires users to adopt new SDKs, new auth schemes, or new mental models. ### 4.2 Funding and Spend Control Users fund their account by sending USDC to the on-chain deposit contract referenced by their unique deposit code. The deposit lands in the user's `balance` and is consumed per request. There is no monthly subscription, no minimum, no auto-renewal. Withdraw any unused balance at any time. Per-request spend control is opt-in. A user who cares about cost adds two headers to their requests: ``` X-Pod-Max-Price-Input: 400000 # max 0.40 USDC per million input tokens X-Pod-Max-Price-Output: 600000 # max 0.60 USDC per million output tokens ``` The marketplace router consults these as a ceiling. If a marketplace provider serves the requested model at or below the ceiling, the request goes to the marketplace. If not, the centralized router's price is checked; if it is also above the ceiling, the request returns an HTTP 402 with a structured body indicating the lowest available price. The user's client can then decide to retry with a higher ceiling, route to a cheaper model, or surface the price to the user. Default behavior with no headers: the marketplace is consulted first, the centralized router is the fallback, and the user sees competitive pricing without doing anything. ### 4.3 Tools That Need Wallet-Native Auth A subset of users — autonomous agents that need to fund themselves without a human in the loop, multi-agent systems, machine-paying applications — need wallet-based authentication and per-call payment rather than the credit-balance model. The protocols for this exist (HTTP 402 / x402 from Coinbase, MPP from Stripe). They are not yet supported by the major AI clients (OpenAI SDK, Anthropic SDK, Claude Code, Cursor, the major framework integrations). UsePod's stance: support these protocols when the ecosystem supports them. Not before. Forcing wallet-auth onto users whose existing clients can't consume it is a worse product, not a better one. The credit-balance model with API tokens already gives any agent harness financial autonomy — pre-fund the balance with USDC, deduct per request, refill from on-chain when low. The wallet-direct path is a future enhancement (see Section 8). ### 4.4 The Centralized Fallback UsePod's centralized router — Anthropic, OpenAI, Venice, Together, Groq, OpenRouter, Bedrock — is always available. It does not go away when the marketplace is healthy. It is the tier-zero safety net for cases where the marketplace doesn't have the model, doesn't have it at the user's price, or temporarily can't serve it. This is a deliberate design choice and worth explaining. Some marketplaces and decentralized networks position themselves as alternatives to centralized providers, with an implicit demand that users abandon centralized services to participate. That positioning trades user reach for ideological purity, and it loses. UsePod is additive: the marketplace adds capacity and price competition; the centralized router preserves coverage. Users get the best of both. --- ## 5. The Clearing House ### 5.1 What the Coordinator Does UsePod's coordinator (the `services/api` Rust service) is the matching engine, the settlement layer, and the SSE relay between users and providers. A request flows like this: 1. User sends a standard inference request to `POST /proxy/{token}/v1/messages` (or the OpenAI equivalent). 2. The coordinator authenticates the token, checks balance, applies rate limiting (existing v1.x behavior, unchanged). 3. The matching engine looks up providers for the requested model in Redis. The eligible set is filtered by price (if the user specified a ceiling), capacity, online status, and reputation throttle. The remaining candidates are scored by a composite of price, performance, queue depth, and uptime; the top one wins. 4. If a marketplace provider matches, the coordinator pushes a job message to that provider's WebSocket session. The provider's agent dispatches to its local backend (vLLM, llama.cpp, etc.) or remote BYOK upstream, and streams response chunks back over the WebSocket. 5. The coordinator relays those chunks directly to the user's SSE stream. From the user's perspective, the experience is identical to a centralized provider — bytes arrive, tokens render, streaming works. 6. After the stream completes, the coordinator extracts the final token counts (using its own tokenizer; the provider's reported counts are advisory) and emits a `UsageEvent` to the Redis Streams accounting pipeline. 7. The accounting worker, in a single PostgreSQL transaction, debits the user's balance and credits the provider's balance with the 80% share. The 20% treasury share is implicit (not tracked as a separate row, since it is the residual on the user side). If no marketplace provider qualifies, step 4 falls back to the existing centralized router. Everything else is identical. ### 5.2 Failover Provider failures during a stream are not user-visible by default. Pre-token-emit errors (the provider's backend returns an error before any tokens have streamed back to the user) cause silent re-dispatch. The matching engine selects the next-best candidate, then the centralized router if no other marketplace provider qualifies. The user sees a slightly higher latency and a successful response. Post-token-emit errors (the provider drops connection mid-stream after some tokens have already reached the user) cause a graceful stream termination. The coordinator emits a stream-end event with an `error` reason, and the user is billed only for the tokens actually delivered. Their client can decide to retry; that retry is a fresh request, eligible for routing to a different provider. Providers that fail repeatedly enter a throttle state. Their reputation score drops, the matching engine excludes them for an exponentially growing time window, and the operator sees this in their dashboard with a clear reason. The exclusion is automatic; the reputation system handles routine reliability without human intervention. ### 5.3 Why the Coordinator Is Centralized in v2.0 The coordinator is a centralized service operated by UsePod. It sees user requests in plaintext. It chooses providers. It settles payments. It is a trusted intermediary in the v2.0 architecture, the same way Stripe is a trusted intermediary in payments and Cloudflare is a trusted intermediary in routing. This is not the end-state. The privacy roadmap (Section 8) describes how this evolves: TEE-attested coordinator nodes, encrypted prompt delivery via E2EE mode, onion routing for relationship privacy. But those layers come after the marketplace works, not before. Trying to ship them first is the failure mode every previous decentralized AI project has fallen into. UsePod does not. --- ## 6. Pricing & Payment ### 6.1 The Unit and the Math All amounts are denominated in USDC microunits — the same unit as USDC's native on-chain representation, where 1 USDC = 1,000,000 microunits. All arithmetic is integer-only; there are no floating-point operations in the billing path. This eliminates rounding errors and matches how on-chain amounts are actually represented. Token pricing is quoted per million tokens, matching the convention used by every major AI provider and infrastructure platform. A model priced at "$0.40/M input" means $0.40 USDC per 1,000,000 input tokens, which is 400,000 microunits per million tokens. Cost for a single inference request: ``` provider_cost = (input_tokens * input_per_1m / 1_000_000) + (output_tokens * output_per_1m / 1_000_000) + (cache_write_tokens * cache_write_per_1m / 1_000_000) + (cache_read_tokens * cache_read_per_1m / 1_000_000) ``` For marketplace routes, the user pays `provider_cost / 0.80`, which gives the operator 80% of the gross fee and the treasury 20%. For centralized routes, the user pays `provider_cost * (1 + markup)` per the existing v1.x pricing — typically a 10% markup over the upstream's published rate. Both calculations are pure integer math with no floats and no precision loss. ### 6.2 Settlement User and provider balances update in the same PostgreSQL transaction. There is no scenario where a user is debited but a provider is not credited (or vice versa). The accounting worker reads `UsageEvent` messages from a Redis stream after each request and writes both ledger rows in a single SQL transaction. If the database transaction fails, the message is retried; after three failures, it goes to a dead-letter stream for human review. In practice this is rare. Provider balances are mirrored to Redis for hot reads in the host dashboard. The mirror is non-authoritative; PostgreSQL is the source of truth. ### 6.3 Cashout Provider cashout is a Solana USDC transfer from the UsePod ops wallet to the provider's destination address. The provider requests the withdrawal through the host UI; the request is queued; a background worker builds the transaction, signs it with the ops wallet, broadcasts via a Solana RPC, and watches for confirmation. End-to-end: under two minutes from request to confirmed. Limits at v2.0 launch: $5 minimum withdrawal, $10,000 daily cap, manual approval queue for amounts over $1,000 during the first 30 days post-launch. These limits exist to constrain the blast radius of any anti-fraud incident in the early window. They will loosen as the trust mechanisms prove themselves. The ops wallet is monitored for runway. If the wallet's USDC balance falls below 2× the pending withdrawal total, an alarm fires and operations top it up. Withdrawals are never paused or denied because of ops wallet exhaustion; the alarm gives us advance notice to refill. ### 6.4 The x402 / MPP Question x402 (HTTP 402 Payment Required, standardized by Coinbase) and MPP (Machine Payments Protocol, developed by Stripe and Tempo) are the cleanest known protocols for autonomous agent harnesses to make per-call or session-based payments to AI services without a credit balance. UsePod will support both, **when the broader ecosystem of AI clients supports them.** As of v2.0, the major AI SDKs (OpenAI, Anthropic), the major coding-agent harnesses (Claude Code, Cursor), and the major framework integrations (LangChain, LlamaIndex, CrewAI) do not implement x402 or MPP at the client layer. Adding them on the server side without client-side support produces no usable feature; it just complicates our gateway. The right time to ship x402 and MPP at UsePod is when at least one major AI client implements the protocol and developers have an actual reason to opt into it. We track ecosystem adoption and will light up the path on the same day a real use case becomes available. Until then, the credit-balance model with API tokens is the v2.0 product, and it is sufficient for every workload that needs to interact with the marketplace today. --- ## 7. Trust & Reputation ### 7.1 v2.0 Trust Mechanisms UsePod ships a lightweight defensive layer in v2.0: **Tokenizer-side count enforcement.** The coordinator re-tokenizes responses locally and uses its own count for billing. Provider-reported counts are advisory. A provider cannot inflate the count to over-charge the user. **Reputation scoring.** Every active provider has a score computed from completion success rate, p50 latency, benchmark agreement, and tenure. The score is recomputed every 60 seconds. It influences routing weight: providers with higher reputation get more traffic at the same price. Providers below a threshold are auto-throttled and excluded from routing for exponentially growing windows. **Benchmark canaries.** One percent of marketplace traffic to each provider is hidden — the coordinator substitutes a known-canonical prompt for that model, collects the response, and compares it statistically (token overlap and embedding similarity) to a reference output. Drift above a threshold flags the provider for human review. This catches providers serving the wrong model, a quantized version pretending to be full precision, or other forms of substitution fraud. **$50 USDC enrollment bond.** Every provider posts a $50 bond at enrollment. The bond is held in our ops sub-account. On confirmed fraud, the bond is seized and the funds become a refund pool from which affected users are credited. The bond is released back to the operator on graceful retirement after a 90-day cooldown. These are not bulletproof. Sophisticated adversaries can defeat any of them, particularly the canary mechanism if they study the canary corpus. They are sufficient for a v2.0 marketplace where the cost of running a fraudulent provider exceeds the recoverable revenue, and where human review has bandwidth to handle the volume of flagged incidents. ### 7.2 What v3+ Adds The trust roadmap extends in three layers: **Verified TEE tier (v3.0).** Operators running inside Intel TDX, AMD SEV-SNP, AWS Nitro Enclaves, or NVIDIA Confidential Computing can submit hardware attestation reports. These providers get a `verified=true` flag, a routing-weight boost, and unlock "verified-only" routing mode for users who explicitly request it. The unverified marketplace continues to operate alongside; verified providers are an opt-in trust upgrade. **Privacy mode (v4.0).** End-to-end encrypted prompt delivery to verified-tier nodes, using X25519 + ChaCha20-Poly1305 client-side encryption. Onion-routed delivery with a permissionless relay network for relationship privacy. This is the layer that makes UsePod competitive with Venice.ai on privacy guarantees, and it ships only when the marketplace has the volume to justify the operational complexity. **Cryptographic proof of inference (far future).** Interactive proofs or zkML over batches. This is research-stage and not on any committed timeline. It will become relevant when the value at stake exceeds what TEE attestation can underwrite. The progression is honest and ordered. Each layer is added when the prior layer's volume creates the demand for it. Skipping ahead — promising verified-only privacy in v2.0 — would replicate the v0.5 mistake: ambition outrunning execution, with no users to validate either. --- ## 8. Roadmap ### v2.0 — The Inference Marketplace (next major release, in progress) What this whitepaper describes. Marketplace match-and-route, USDC settlement, host UI, network UI, lightweight trust, drop-in API compatibility. Detailed execution plan in `plan/V2_EXECUTION.md`. ### v2.x — Marketplace Polish Iterative improvements driven by traction signals. Likely candidates: auto-update channel for provider agents (signed releases), suggested-pricing engine using observed network averages, GPU auto-detection in the host UI, auto-withdrawal opt-in, x402 and MPP paths once the ecosystem supports them client-side. ### v3.0 — Verified TEE Tier TEE attestation as an opt-in trust upgrade. Verified-only routing mode. Content-addressed model registry binding model SHA-256 to attestation reports. First independent security audit covering the attestation pipeline. ### v4.0 — Privacy Layer + Enterprise End-to-end encrypted prompt delivery to verified-tier nodes. Onion-routed delivery with a permissionless relay network. Region / data-residency filters in routing. Stake-for-Access enterprise tier with reserved capacity and SLAs. Independent security audit covering the privacy pipeline. ### v5.0 — Beyond Token-economy mechanisms only if a concrete utility justifies them. External (non-AI) commerce routing. Multi-agent coordination primitives. Cross-chain payment support. Custom fine-tuned model hosting on UsePod-operated verified nodes. A standing rule across all phases: nothing in v3 or beyond ships before v2 has demonstrated meaningful two-sided traction. The number-one failure mode this roadmap is designed to prevent is the temptation to ship privacy or token features for the marketing benefit while the underlying marketplace is empty. Build the marketplace first. --- ## 9. Go-To-Market ### 9.1 The Beachhead Solana-native developers building agent systems are the v2.0 beachhead. The alignment is direct: they understand on-chain payments, they operate workloads that benefit from the cost and latency of Solana settlement, and they have direct pain around the privacy and pricing limitations of centralized AI. The pitch to this audience is not philosophical. It is: drop in our base URL and your agent's blended inference cost falls 50–80%, your existing tooling works unchanged, and your USDC funds it directly without a credit card. The migration is two lines of configuration. The first 100 operators in this segment get a $20 USDC bond credit and featured network placement. ### 9.2 The Broader Agentic Developer Community Phase two extends to the broader agentic developer community: teams building on LangChain, CrewAI, AutoGen, custom frameworks, and rolling their own tools. The pitch broadens: uncensored inference at competitive prices, no monthly subscription, pay-as-you-go, drop-in compatible. Provider-side outreach focuses on three channels: GPU communities (LocalLLaMA, Discord servers around vLLM and llama.cpp), small-business GPU owners (the long tail of single-rig operators), and BYOK proxy operators (people who want to resell OpenRouter or Venice access with a small markup). Each segment has different motivations and onboarding flows; the host UI surfaces the right path for each. ### 9.3 Enterprise Enterprise sales is a v4+ motion, gated behind: - The marketplace having enough density and reliability to underwrite SLAs. - Stake-for-Access tier shipped (v4.0). - Verified TEE tier shipped (v3.0) for compliance-constrained workloads. - Independent security audit completed and published. UsePod does not chase enterprise sales while v2.0 is in flight. The infrastructure is not yet what enterprise needs, and selling it before it is would damage the brand. Enterprise is a 2027 motion at the earliest. --- ## 10. About the Architect I am Christopher Ryan Gilbert, Founder and Principal Engineer at 100X CTO, LLC ([100x.dev](https://100x.dev)). My career has been spent at the intersection of high-throughput distributed systems and cryptographic infrastructure, including engineering leadership at Elixir Protocol on decentralized orderbook infrastructure — systems that must maintain consistency, resist manipulation, and operate at financial-grade reliability under adversarial conditions. That experience shaped how I think about marketplaces: every assumption is an attack surface, every centralized component is a future liability, latency is always a product decision, and traction precedes trust mechanisms in the order of operations. The earlier (v0.5) draft of this whitepaper led with privacy and tokenomics. I rewrote it because that ordering was wrong. Privacy and tokens are real engineering tracks that earn their place only when the underlying market has reached density. eBay didn't promise PayPal escrow before it had sellers. Uber didn't promise standardized driver checks before it had drivers. The UsePod v1.0 thesis is the same: build the marketplace, reach density, then layer the trust and privacy mechanisms on top in the order the volume demands. 100X CTO, LLC is my vehicle for this work. I operate as a focused team of one with external collaborators on specific components. The advantage is speed and architectural coherence — a single vision executed without committee, with the full context of every design decision in one place. If you are building agent systems and the privacy and economic limitations of centralized AI are slowing you down, I want to talk. If you are an operator with idle GPU capacity and want to monetize it, the host onboarding flow is at usepod.ai/host. If you are an investor who understands that infrastructure markets win by reaching density first and earning trust second, I am happy to walk through the data we are seeing. Contact: [100x.dev](https://100x.dev) --- ## 11. Conclusion Inference is becoming a commodity. The economic logic of any commodity market is the price floor falling toward marginal cost. Centralized providers fight this by bundling subscription tiers, restricting access to specific models, and maintaining differentiation through proprietary frontier weights. The defensibility of those tactics erodes as open-weight models close the quality gap and the GPUs to run them become broadly available. UsePod is the marketplace this commoditization implies. Independent operators set prices, users pick the best provider for each request, and the platform earns a transparent 20% take on every transaction. Centralized providers remain available as a fallback, additive rather than replaced. Trust mechanisms are calibrated to v2.0 scale: lightweight, sufficient, with a clear path to expansion as volume grows. This is a marketplace play first. Privacy, attestation, and token-economic mechanisms are real engineering tracks on the roadmap, but they belong after density, not before. The order matters. eBay, Uber, and Airbnb each demonstrated that the correct sequence is marketplace-first, then trust-as-infrastructure-layered-on-top. The same sequence applies here. Inference compute will be a commodity within the agentic decade. The question is which clearing house wins by being the easiest to join on both sides, the most transparent on economics, and the most honest about what it is shipping vs. what it is promising. UsePod's bet is that the answer is the one that builds the marketplace first. --- *© 2026 Christopher Ryan Gilbert / 100X CTO, LLC. All rights reserved.* *v0.6 (draft) — April 2026. For discussion purposes. Not investment advice.*