# VVV: Crypto AI's Most Underappreciated Revenue Story Source: https://x.com/YanLiberman/status/2056797867415916997 ## Summary Venice, a privacy-first AI inference platform, is presented as undervalued, with its VVV token at about a $660M market cap and $1.12B fully diluted value. The case rests on an estimated current ARR of about $60M, derived from roughly 3.0M signups as of May 16, 2026 and an assumed 150K paying subscribers, and on new ARR being added at an annualized rate of about $200M. On current ARR, VVV trades at roughly 11x revenue, compared with 26x for OpenRouter, which is named as a private inference peer. The API revenue figures are estimates, since the text says they are not directly disclosed. ## Article Venice is a privacy-first AI inference platform that lets users access frontier and open-source models without identifying themselves to the underlying model provider. I think it's the most complete privacy solution in the AI market today: anonymous proxying, open-source model routing, hardware-attested TEE inference, and end-to-end encrypted inference all live in one consumer product, with the privacy mode selectable per request. No other player offers all four. The business has been growing meaningfully. Most Crypto Twitter discussion of Venice understates current revenue, recent growth, and the forward trajectory. Venice recently started publishing daily subscriber data, and three weeks of granular data show a clear acceleration in new subscription ARR additions: That continued addition rate is the central assumption of this thesis. I also believe API revenue has been tracking alongside subscription growth recently, an assumption explained in detail in the Current State and Growth section below. Anchoring to a conservative $100M/yr sub addition rate (matching the late-April pace), and assuming API adds the same amount, total 12-month forward revenue additions land at approximately $200M The recent acceleration suggests meaningful upside to that figure if the pace holds. This writeup walks through what makes Venice's position interesting: Privacy Tiers: A privacy architecture that goes meaningfully deeper than the standard "private AI chat" framing. User Categories: Venice's audience arrives by being pushed off the easy path (content policy, compliance, threat model, principle) rather than by marketing. Market Size: A growing market for privacy-segmented inference that the consumer-chat framing usually undersells. Competitive Landscape: Venice's bundle of privacy depth, uncensored model access, and crypto-native distribution is currently unique among competitors. Token Design & VVV Valuation: VVV and DIEM mechanics that translate platform growth into token value, and how VVV's multiple stacks up against private inference peers like OpenRouter, Fireworks, and Together AI. After the recent rally and pullback to $14, VVV trades at ~$660M market cap and ~$1.12B FDV. Current ARR sits at approximately $60M (built up in the Current State and Growth section below), being added to at an annualized rate of approximately $200M and accelerating. On current ARR, VVV trades at roughly 11x revenue (19x FDV), a discount to private inference peer OpenRouter at 26x. On a 12-month forward ARR of approximately $260M ($60M current base plus $200M of annualized additions), VVV trades at roughly 2.5x revenue (4.3x FDV). Current State and Growth Venice recently began publishing daily subscriber additions. Combined with periodic public signup announcements, those two data streams let me build both a current ARR estimate and a forward trajectory. To estimate current ARR, I work from the signup totals. Based on the cadence of public announcements over time, total signups have been growing at roughly 300K per month. The most recently confirmed milestone is approximately 3.0M signups as of May 16, 2026, up from approximately 2.0M as of February 1, consistent with the 300K/month pace. Assuming ~5% lifetime paid conversion (likely conservative given the daily data suggests faster conversion of new signups), that translates to approximately 150K active paying subscribers as of mid-May. Until mid-late April, only the basic $18/month Pro plan existed; the rollout of Pro+ ($68/month) and Max ($200/month) tiers has begun shifting the mix, but the overwhelming majority of the paid base remains on $18. Weighted ARPPU is approximately $18-19/month, implying current sub MRR of approximately $2.8M, or roughly $33M sub ARR. This is the subscription component only; API revenue is layered in later in this section to arrive at a full current ARR estimate. On the forward trajectory, the pace of new subscription ARR additions has been accelerating. At the late-April pace, the company was adding approximately $2M of new subscription ARR per week. By the most recent week (May 10-16), that pace had stepped up to roughly $2.6M per week, which annualizes to a $134M sub addition rate. For the central case in this writeup, I anchor to a conservative $100M annualized figure to avoid overstating recent acceleration. Net growth will be modestly lower once churn is factored in, but at current scale that gap is small enough to be directionally immaterial, and the gross pace forms the core of the forward-looking case in this writeup. The three weeks of granular data (April 26 - May 16) show a clear ramp: Week 1 to Week 3 saw daily MRR additions grow by approximately 34%. With API revenue assumed to track 1:1 with new sub MRR (explained below), the implied total annualized addition rate has stepped up from ~$200M to ~$268M over the same window. Two things appear to be driving the inflection: the launch of Pro+ and Max tiers gives higher-WTP users options they didn't have before, lifting weighted ARPPU; and paid conversion appears to have accelerated post-tier-expansion. API revenue is the harder piece to size since it isn't directly disclosed. My base case is that new API run-rate has been added at approximately 1:1 with new subscription MRR recently, with historical additions running below that ratio. The result is a current API ARR base that is meaningful but somewhat below subscription ARR, narrowing toward parity over time. The reasoning behind a roughly 50/50 split starts with peer benchmarks. Among large closed-model platforms, ChatGPT runs at roughly 25% API and 75% subscription, since a massive consumer subscriber base keeps API at a smaller share. Anthropic runs at roughly 80% API and 20% subscription, given its developer- and enterprise-leaning user base. Venice sits structurally between the two: privacy positioning that doesn't pull casual consumers the way ChatGPT does, but a broader paid user base than Anthropic's enterprise-heavy mix. A 50/50 split lands in the middle of that range. That bracketing is reinforced by two pieces of Venice-specific evidence. First, Venice's API has built substantial developer distribution over time. OpenRouter routes Venice models, Fleek defaults all hosted agents to Venice inference, and Cursor, Brave Leo (via BYOM), and VSCode community extensions all support Venice. These integrations have accumulated over the past year-plus, supporting the case that API is a real and material business with production traffic at scale. Second, the recent ramp in token throughput far exceeds what subscriber growth alone could account for. Daily token throughput grew from 20B in early February to 60B+ in early May, roughly 3x in three months. Over the same window, the paid subscriber base grew by approximately 50% (from ~100K to ~150K paying subs). The Pro+/Max tier expansion in mid-April moved only a small fraction of new signups to higher-ARPPU plans, and even generous assumptions about per-user token consumption from those tiers can't bridge the gap. The bulk of the token ramp appears to be coming from per-use API workloads: agentic deployments, integration partners scaling production traffic, and similar high-volume use cases. Estimating current API ARR is harder than subscription ARR because the 1:1 ratio appears to be a more recent development; before mid-April, the API share was likely smaller. Using a midpoint assumption that API has averaged ~70-80% of sub historically with 1:1 happening recently, current API ARR is approximately $25-30M. Current total ARR estimate: ~$55-65M, midpoint approximately $60m The API portion is worth a brief caveat: it's based on current usage run-rate annualized rather than recurring subscription commitments, and therefore carries higher inherent volatility than the subscription portion. A heavy API customer reducing usage can produce a meaningful drop in API run-rate without comparable churn in the subscription base. Cross-checking against year-to-date revenue: based on the token throughput ramp from 20B/day in early February to >60B/day in early May, Venice has generated at least $30M of cumulative revenue in 2026. That figure is consistent with current ARR landing in the $55-65M range, a base growing rapidly toward a $200M annualized addition rate. Importantly, the annualized addition rate is not the same as revenue earned during the next 12 months. New ARR adds linearly through the year, so a $200M annualized addition rate sustained through 2026 translates to roughly $100M of new revenue earned during the year, on top of the current ARR base contributing another ~$60M. Total revenue earned over the next 12 months should land in the $150-200M range, with ARR at the end of that 12-month window approximately $260M gross of churn ($60M current + $200M of new ARR added). The backward look is mostly a footnote. Venice is currently on pace for roughly $200M of annualized ARR additions, and the real question is whether today's pace is the floor or the start. The variables that matter: whether subscription growth holds, whether API usage continues to scale faster than subscriptions, how much churn emerges as the cohort matures, and whether the addressable market can support continued growth at this rate. The market sizing question is easier to answer once you understand what Venice actually does. The cleanest grounding is a privacy ladder of LLM interactions, where each rung represents a different set of privacy assumptions and Venice's modes slot into specific tiers. Privacy Tiers The ladder below ranks cloud-based AI usage by a narrow but important axis: who can associate plaintext prompts with the user's identity. It does not solve every privacy problem. Device compromise, payment trails, account metadata, subpoena risk, and endpoint security remain separate issues. But it clarifies what actually changes as users move from default chatbots to Venice's higher-privacy modes. The level numbering (0–7) is mine, used to situate Venice against the broader landscape. Venice's own taxonomy uses only the four named modes: Anonymous, Private, TEE, and E2EE, mapping to Levels 3, 4, 6, and 7 below. The strongest privacy option isn't on the ladder at all. Running an open-source model on hardware you own, with no cloud involvement, beats anything downstream. GLM 5.1 or Qwen 3.6 on a beefy Mac or workstation, no network calls, no third party in the loop. Nothing matches 'the prompt never leaves my machine,' assuming the machine itself is reasonably hardened. But it's not the path most people will take. Hardware is expensive. The OSS models that fit locally still trail the closed-lab frontier on the hardest tasks. You lose integrations and 24/7 cloud-side operation, and you take on responsibility for maintaining the whole stack. Setting local aside, the ladder below covers the realistic options for cloud-based inference. The detailed level-by-level breakdown follows, including the metaphors that ground each tier: Level 0: "ChatGPT, Claude, or Gemini, signed in, default." Your prompts go to the lab tied to your account. They see who you are and what you ask. On consumer tiers, conversations may be used to improve future models unless you opt out, and they live in your chat history server-side. There are real commitments here (no selling data, retention limits, deletion controls), but you're identified, retained, and on consumer tiers potentially in the training pipeline. Most people are here. Architecturally, this same posture applies to any hosted-API consumer service regardless of where the provider is based. Hosted plans from Chinese providers (DeepSeek hosted, GLM / Zhipu, MiniMax, Qwen direct) sit at this same architectural level: the provider sees plaintext, identity is account-linked, retention and training policies vary by provider. Users often pick these for price, since they're often dramatically cheaper than Anthropic or OpenAI. What jurisdiction your data ends up under depends on the specific provider, the endpoint you're hitting, the region, and the contract. Don't assume you're getting US or EU-style data handling just because the model is cheap. Metaphor: You go directly to a consultant (the model) at a big firm (the AI provider). They read your memo, answer your question, and file a copy in their records under your name. They might use anonymized versions of past memos to train other consultants or improve their service. Level 1: "ChatGPT Temporary Chat / Claude Incognito Chat." Same provider, same identity, same plaintext on their servers. The conversation doesn't appear in your history, the model doesn't carry it forward, and per policy it's excluded from training. Useful for sensitive one-offs you don't want shaping your account. The provider still knows it's you and still sees the full prompt; what they can't do is keep it long-term or use it for training. Hidden from your own history, not from the lab. Metaphor: Same direct interaction with the consultant (the model), but you ask them to keep this specific memo out of your main file. They read it, answer, and put it in a temporary drawer (Incognito Chat) that gets cleared after a while. They still know it's you and saw what you sent. Level 2: "Anthropic API, Claude for Work, ChatGPT Enterprise, OpenAI API." Move from consumer chat to commercial terms. The contract excludes your data from training. Retention is short, typically around 30 days for safety review, sometimes zero on enterprise tiers. You have legal recourse if the policy is violated. The lab still sees plaintext during inference and ties traffic to your API key, but the guarantees are stronger and contractually enforceable. This is the privacy posture most companies actually use, and it's a real upgrade over consumer chat. But it's still policy-based, not architectural. The reasons to climb higher are real: future policy changes, compelled disclosure, breaches, or the lab itself going bad. Metaphor: You sign a contract with the consulting firm (enterprise/API terms) under no-copy, no-cross-client, short-retention terms with legal recourse if they violate. Same direct interaction with the consultant (the model), who reads your memo and knows it's from you, just stricter rules about what happens to the memo after. Level 3: "Venice Anonymous mode." A proxy sits between you and the lab and strips your identity before forwarding. The lab sees prompt content in plaintext but doesn't know it's you. They see "request from Venice." For prompts that don't identify you by content, this breaks the link between your queries and your name, and long-run profiling at the lab gets a lot harder. For prompts that do identify you by content (your firm, your deal, your name), it's largely cosmetic. The content gives you up regardless. You've also added Venice as a trust party. DIY-ing this isn't realistic. You'd be the only user of your own proxy, and one-user anonymity isn't anonymity. Metaphor: A courier service (Venice) handles delivery. The courier strips your name off the memo before handing it to the consultant (the model). The consultant reads the content but doesn't know who sent it; the courier service knows both. Level 4: "Open-source models on Together AI / Fireworks / Groq, or Venice Private mode." Switch to an open-source model and the closed labs drop out for that traffic. They're not in the loop because you're not using their model. Trust shifts to whoever hosts the OSS model. Different vendor, similar contractual guarantees, often more privacy-aligned culture (especially Venice Private). You give up some capability, though the gap has gotten smaller. GLM 5.1, Qwen 3.6, Minimax M2.7, and DeepSeek V4 hold their own on everyday coding, writing, and analysis. Whether they hit parity with the top closed models depends a lot on the benchmark; closed labs still tend to win on long-context work, multimodal tasks, and complex agent workflows. You've also reduced concentration risk and you're trusting fewer parties. Is this strictly more private than Level 3? It depends what you care about. Level 3 keeps your identity hidden from a frontier lab; Level 4 reveals your identity to a smaller player but cuts the lab out entirely. Different priorities, different orderings. This only helps for traffic you actually route through OSS. Mixed usage means the labs still see whatever you send them. Within Level 4, providers also differ on where the GPU work happens: Together, Fireworks, and Venice Private specify their data centers, while aggregators like OpenRouter route to whichever underlying provider is cheapest, which can include providers running in jurisdictions you didn't choose. For users who care about that (avoiding API calls routed to certain countries), the named-host options are meaningfully different from route-to-cheapest aggregators, which also add a trust hop. Metaphor: You take your memo to a different consulting firm (an OSS-model host like Together AI, Fireworks, or Venice in Private mode) directly. The original firm sees nothing because you've stopped using them. The new consultant (a different model) reads your memo and knows it's from you, same direct interaction structure as before just with a different firm. Level 5: "DIY: vLLM on RunPod / Lambda Labs / AWS." Skip the inference-as-a-service layer entirely. Rent a raw GPU, install vLLM or TGI yourself, load the weights, expose your own endpoint. No inference vendor sees your traffic, just the cloud host whose hardware your VM runs on. The cloud host can technically inspect your VM if motivated or compelled. They have stronger compliance posture, contractual protections, and audit trails than smaller inference vendors though. The trade: you've moved from a small vendor's policy to a hyperscaler's, at the cost of real engineering and ops work. Metaphor: You hire your own consultant (your own model, self-hosted) who works exclusively for you in a private office (a VM you've rented from a cloud host like RunPod, Lambda Labs, or AWS). No consulting firm sits in between, just you and the consultant you've personally engaged. The building owner (the cloud host) has technical access if motivated, but generally has stronger compliance posture than the smaller firms in earlier levels. Level 6: "Venice TEE mode." Here the privacy guarantee changes character. TEE and E2EE are both available to any paid Pro subscriber; the choice between them is per request, not per plan. For TEE inference, Venice routes to GPU hosts running confidential-computing technology from NEAR AI Cloud and Phala Network on NVIDIA H100 and H200 hardware. NEAR and Phala provide the protocol and tooling; the GPUs themselves are operated by third-party hosts using that tech. Confidential-compute features on the GPU prevent the operator from reading what's inside the enclave at runtime. Remote attestation lets your client cryptographically verify what code is running inside the enclave before sending anything, so "is this actually the code Venice published" is a solved problem. What's not yet solved is a formal third-party audit of that code's correctness. The GPU operator stops being a party that can peek. Venice's proxy still sees plaintext briefly, but the GPU host doesn't. The shift here is from policy to hardware. Trust didn't disappear; it moved targets. You're now trusting NVIDIA's confidential compute design, the attestation signing chain, and Venice's implementation. Robust against practical threats, though not bulletproof: TEE designs (Intel SGX, AMD SEV) have had side-channel vulnerabilities found repeatedly, and current designs aren't immune. For users who track that vulnerability research closely, Level 4 (Venice Private on a trusted operator's data center) may be the rational stopping point rather than Level 6, since trusting Venice's operational hygiene can feel more comfortable than trusting chip-vendor attestation chains. Apple's Private Cloud Compute is in roughly the same architectural family: private cloud inference with hardware-backed privacy and verifiability. The differences with Venice are real though. Apple uses Apple Silicon they control, runs only Apple Intelligence on it, and doesn't expose model selection. Venice uses external TEE partners, supports open-source models, and lets users pick a privacy tier per request. Metaphor: A courier service (Venice) delivers your memo to a consultant (the model) who works inside a sealed soundproof room (a TEE / hardware enclave on NVIDIA confidential-compute GPUs, operated by Venice's partners NEAR AI Cloud and Phala Network). The courier reads the memo on the way in, but the consultant inside cannot be observed by anyone, including the building owner (the GPU operator). The room is wiped after each session. Level 7: "Venice E2EE mode." TEE plus client-side encryption. The encryption setup happens between your client and the silicon enclave directly. Venice's proxy in the middle never has the key, so anything passing through it is ciphertext from your machine until the moment it's processed inside the silicon. Both the GPU operator and Venice itself are removed as parties that can peek; the only thing that ever processes plaintext is the model running inside the enclave, and it's ephemeral. This is the strongest privacy guarantee available on someone else's hardware, short of fully homomorphic encryption (which doesn't yet work for LLMs at usable speed). The Level 6 trust dependencies all carry over, plus one new one: the client-side encryption itself needs to be implemented correctly. Two functional trade-offs come with this tier specifically. Features that require Venice's infrastructure to read plaintext, like web search and persistent memory, are disabled. Model selection also narrows: exactly eleven models are deployed inside the TEE/E2EE infrastructure today: Venice Uncensored 1.2, GLM 5.1, GLM 4.7, GLM 4.7 Flash, Qwen3.5 122B A10B, Qwen 2.5 7B, Qwen3 30B A3B, Qwen3 VL 30B A3B, Gemma 3 27B, GPT OSS 20B, and GPT OSS 120B. Metaphor: Everything from Level 6 still applies: the consultant (the model) works inside a sealed soundproof room that no one outside can observe, and the room is wiped after each session. The new addition is that you put your memo in a locked box (client-side encryption) yourself before handing it to the courier (still Venice). The courier now carries an opaque box without seeing inside, so the only thing that ever sees your message is the consultant in the sealed room. The key point: Levels 0–2 are mostly policy and contract upgrades. Levels 3–4 change routing and model/vendor exposure. Levels 6–7 change the trust model more fundamentally by moving toward hardware-backed and encrypted inference. Venice's differentiation is that it spans Levels 3, 4, 6, and 7 inside a single product. The right level for any given user comes from their threat model. Picking based on which mechanism sounds most technically impressive misses the point. Levels 6 and 7 trade some frontier capability and add new trust dependencies. Even with those costs, this is the most meaningful privacy upgrade available on cloud inference today. That's how the architecture works. The harder question is who actually needs which level, and how big that audience is. Different threat models push different users onto different parts of the ladder, often by force rather than preference, and the resulting market is bigger than the technical pitch suggests. Below is the breakdown. User Categories Privacy posture isn't really an abstract preference. A meaningful share of Venice's audience landed there after content policy, compliance team, threat model, or principle pushed them off the default. Marketing has to do less work when users arrive looking for an alternative they couldn't keep using. Six segments worth mapping: Regulated and compliance-driven work. Finance teams handling MNPI, healthcare workers under HIPAA, lawyers with privileged communications, M&A and deal-flow professionals. Compliance teams generally don't permit Level 0. Many appear to settle at Level 2 because Anthropic and OpenAI's enterprise terms (no-train, short retention, contractual recourse) clear common compliance bars. A subset pushes to Level 6, often because they've been burned by policy changes elsewhere, or because the data they're handling would carry real cost if compelled disclosure happened. Anthropic has built what looks like a substantial enterprise business serving this segment, and the regulatory direction in healthcare and finance has been trending toward stricter privacy-preserving computation requirements over time. Venice's most apparent fit here today seems to be the individual practitioner buying Pro out of personal precaution, rather than the enterprise procurement motion. Enterprise procurement looks at more than the privacy architecture. Compliance teams want admin controls, audit logs, SOC2 reports, signed DPAs, real SLAs, and integration support before they sign. The cryptographic story matters but isn't sufficient. The procurement-driven enterprise market is contested by Apple PCC, Microsoft Azure Confidential Computing, and Phala or NEAR direct. Developers building on Venice's API. Venice's API has picked up traction across developer integrations like OpenRouter, Cursor, VSCode, Brave Leo, and Fleek. The most apparent use case here is developers building privacy-respecting AI features into their own products, where they want to offer "your data stays private" as a guarantee to their end users. Tier mapping likely varies by what the developer is building: Anonymous mode (Level 3) for cost-sensitive consumer features, Private mode (Level 4) for OSS-routing as a default, TEE or E2EE (Levels 6 to 7) for products marketed on architectural privacy specifically. One developer using Venice's API can serve many end users without each one buying a Venice subscription, which makes the unit economics potentially quite different from direct consumer subscription. High-stakes-personal use. Mental health and therapy queries people may not want sitting in an account history. Identity exploration around sexuality or gender the user may not be ready to disclose. Discussions about marriages, breakups, employment, or family dynamics where the queries themselves could be damaging if exposed. Many of these users likely sit at Level 1, thinking Incognito Chat hides them. The privacy-aware subset typically moves toward Level 6 once they understand it doesn't fully hide them from the lab. AI mental health appears to be a growing category, though scale and quality vary across clinical and consumer products. Hard to size from Venice's perspective because many users in this segment may not know to look for hardware-attested privacy until something embarrassing happens to them or someone they know. Adversarial environments. Journalists protecting sources, activists in jurisdictions where AI use is monitored, dissidents and political organizers, security researchers studying threat actors, lawyers representing whistleblowers. These users typically need Levels 6 and 7. Lower levels may not survive their threat model. Look at Proton: even with a privacy-first reputation and a Swiss legal home, it tends to comply with most legal requests it receives, often because Swiss law requires it. That's a failure mode policy-based privacy can hit at scale. Venice's TEE and E2EE architecture sits among the cloud setups where the provider isn't designed to hold the plaintext that would be needed to comply with that kind of compulsion. There's a limit to how far the architecture takes you, though. Levels 6 and 7 cut plaintext exposure, but they don't fix the rest of the picture. Account metadata, payment trails, what Venice logs about your usage, what your laptop has been doing, and what a court can compel out of you all stay on the user. For someone with a real adversarial threat model, this is one tool in a broader toolkit. Numerically the segment looks small. Willingness to pay for tooling that survives subpoena tends to be high. Crypto-native and privacy-cultural users. Web3 developers, sovereignty-minded technologists, people who run their own nodes and value hardware-attested guarantees on principle. This segment likely spans Levels 3 through 7 depending on personal threat model, with the principled subset often using 6 or 7 by default for sensitive queries. AI x crypto has emerged as a meaningful category in the broader crypto ecosystem, with infrastructure players like Bittensor establishing significant footprints. Industry surveys often report higher self-custody interest in emerging markets where centralized payment surveillance is a concern. Venice's posture aligns with this segment in ways closed-lab competitors haven't matched: VVV-denominated pricing, no-KYC, Erik Voorhees' reputation, and historical free Pro tiers for VVV and MOR holders that helped seed the cohort. Likely Venice's natural cultural base and a significant share of its earliest paid users. Adult content and other categories closed labs refuse outright. OpenAI, Anthropic, and Google generally refuse NSFW sexual content. The other categories that get tripped up at Level 0, things like mature creative writing, harm-reduction questions about drugs, and a long tail of stigmatized but legal topics, get handled differently across providers, sometimes with allowances. Users in these categories typically can't start at Level 0; the model usually refuses. Model selection alone tends to push them onto Levels 4 through 7, since that's typically where uncensored open-source variants are available. Most paid users likely settle at Level 4 for everyday use, with the privacy-acute subset pushing to 6 or 7. The category looks substantial: Character.AI and Replika both operate at meaningful consumer scale, and AI companion apps have grown into a notable subset of consumer AI. One reason these users may care about privacy more than the average chatbot user is the cost of exposure: a leaked profile of preferences could cost a marriage, a job, or a custody case. Plausibly Venice's largest by-volume audience today. What stands out across these is that few of them appear to sit at the top of the funnel. Most look shaped by being forced or pushed off the easy path, whether by content policy, compliance team, threat model, or principle. Privacy-first AI usually isn't a category people show up to at the front door; they often arrive at it after discovering they can't stay where they were. The same logic could explain two adjacent segments worth flagging without sizing them: international users whose jurisdictions may push them off centralized payment and AI surveillance, and the early personal-AI-agent cohort whose orchestration data could benefit from a privacy-respecting backend. Market Size Venice's eventual ceiling is set by the size of the addressable market, not by current execution. The right frame is share-of-inference: Venice sells AI inference, the relevant market is global spend on inference, and Venice's revenue is a slice of that pool. Independent estimates for the 2027 inference market converge around $140-160B globally, with Bain, IDC, and McKinsey projections roughly in that range. Even at Venice's projected (my projection, expanded on in the Valuation section) $400M annualized run rate at the end of 2027, Venice would represent less than 0.3% of that pool, a de minimis share by any reasonable market definition. For context, OpenAI's API business alone is estimated to capture single-digit percentages of inference spend today, and Anthropic's API is in a similar range. Venice's current position sits far below the share that even mid-sized inference platforms command. But Venice isn't competing for the whole pool. Venice's target is the privacy-segmented slice: users and enterprises that need anonymity, hardware-attested privacy, uncensored access, or jurisdictional choice in their inference. That subset is harder to size precisely, but the directional signal is strong. Several forces are expanding the privacy-segmented portion of inference: tightening data-residency regulations in Europe and parts of Asia, growing enterprise compliance friction with default closed-lab products, and the maturation of TEE-based privacy infrastructure. Enterprise surveys consistently flag rising concern about AI-driven data exposure. None of these forces are fast individually, but they compound. Even if privacy-segmented routes account for only 5-15% of the $140-160B 2027 inference market, that's a $7-23B segment. A low single-digit share gets Venice to several hundred million in revenue, comfortably above today's run rate with substantial headroom remaining. A mid single-digit share moves Venice into the billion-plus range. The bear case has three dimensions. First, the privacy-segmented cloud inference market fails to reach meaningful size because hyperscalers ship adequate privacy options inside their existing platforms. Apple PCC, Azure Confidential Computing, and AWS Bedrock confidential inference are all moving in this direction. Privacy still matters in this scenario, but it gets bundled into existing cloud and consumer platforms, and the standalone privacy-first market never grows large enough to support independent players at scale. Second, local inference becomes viable for mainstream users. Open-source model quality is already strong enough for most everyday workloads. The bottleneck is the setup friction and technical skill required to get a local model running. As that bottleneck eases through more polished out-of-the-box solutions, simpler installers, and integrations that handle the operational burden, a meaningful share of privacy-conscious users may opt to run inference locally rather than pay for any cloud service. That removes them from Venice's addressable market entirely. The timing of this concern depends on how quickly the consumer-friendly local stack matures. Third, even if the privacy market materializes at meaningful size, Venice still needs to win share against other privacy-native players such as Brave Leo, DuckDuckGo, Proton's Lumo, Maple, and Tinfoil, each of which is going after pieces of Venice's bundle from a different angle. The competitive landscape section addresses how Venice's combination of privacy depth, uncensored access, and crypto-native distribution compares to those specific threats. Competitive Landscape Venice's competitive set is broader than "other private AI apps." Different platforms compete for the same demand: privacy-aware consumers, developers wanting model choice, uncensored-content seekers, and crypto-native buyers. The section below covers five categories. The landscape is partial substitutes pulling on different pieces of Venice's wedge. Brave and DuckDuckGo are coming for distribution. OpenRouter is coming for the developer API. Tinfoil, NEAR, Phala, and Maple are coming for the privacy architecture itself. The frontier labs are coming from the enterprise side with good-enough privacy bolted onto better models. None of these products currently packages Venice's full bundle: private-by-default consumer AI, uncensored access, multi-model choice, crypto-native payments, and tokenized usage economics. Privacy levels worth distinguishing, weakest to strongest: No-training: provider commits not to train on your data (standard Anthropic and OpenAI API terms) Limited or zero retention: provider either retains prompts briefly for abuse monitoring or offers ZDR configurations where prompt and response content is not stored after processing (OpenAI ZDR, OpenRouter ZDR) Anonymous proxy: provider sees prompts but not identity (Venice Anonymous, Brave Leo, DuckDuckGo AI Chat) TEE / hardware-attested: prompts run inside enclaves the operator can't read (Venice TEE, Tinfoil, NEAR Private Chat, Apple PCC) E2EE into TEE: provider sees only ciphertext (Venice E2EE, Maple AI) Local: model runs on your own hardware (Ollama, LM Studio) Venice is one of the few consumer products spanning anonymous proxy, private chat, TEE, and E2EE modes in a single UX, with users picking the mode per request. Default AI platforms (OpenAI, Anthropic, Google, xAI) The frontier labs already offer real privacy for enterprise customers. OpenAI doesn't train on API or business data by default and offers ZDR configurations for eligible customers. Anthropic doesn't use commercial product inputs or outputs for training. Google Vertex AI offers enterprise-grade training restrictions. xAI also markets user privacy controls, though its posture should be treated separately from the more mature enterprise commitments of OpenAI, Anthropic, and Google. The enterprise and API privacy gap with Venice is narrower than many assume; the consumer anonymity gap remains much wider. Consumer ChatGPT, Claude, and Gemini all tie identity to prompts and retain conversation history server-side by default, with policies on training use varying by product and user setting. Venice goes after what the frontier labs won't do: anonymous access, uncensored models, and crypto-native payments. That's a smaller market than mainstream AI but a real one. The frontier labs serve the bulk of casual users. Venice serves the slice that wants out of the default. Segment by segment: Consumer chat: Venice has anonymity, less paternalistic content, crypto payments. Labs still win on capability and brand. Prosumer: Venice offers model choice and less lock-in. Labs win on coding integration, memory, and tooling. Enterprise: no Venice story today without SOC2, DPAs, admin controls, and audit logs. The labs and hyperscalers own this market. API: Venice has privacy depth and uncensored access. Labs have model quality and ecosystem. Privacy-native distribution surfaces (Brave, DuckDuckGo, Proton) Brave is the strongest consumer distribution play in privacy. Brave reports 115M+ monthly active users and 47M daily actives as of April 2026, with Leo Premium at $14.99/month plus a free tier. Leo is account-optional, stores history locally, and doesn't retain prompts on Brave's servers per Brave's stated policy. Brave is also beginning to move beyond proxy privacy toward verifiable privacy via NEAR AI's NVIDIA-backed TEEs, which reinforces that hardware-backed AI privacy is becoming a mainstream product feature. DuckDuckGo AI Chat is similar in posture: free, no account, anonymized proxy to a rotating set of third-party models from OpenAI, Anthropic, Meta, and others. DuckDuckGo says chats aren't stored or used for training. Duck.ai also now has paid tiers with more advanced models. Proton's Lumo is the third meaningful entrant in this bucket. Launched July 2025 and expanded with project-based encrypted workspaces in January 2026, Lumo offers zero-access encrypted AI assistance with no server-side logs and no training on user data. Lumo runs from Proton's European base, outside US jurisdiction, and is positioned for Proton's existing privacy-focused user base across email, VPN, and drive products. Compared to Venice, Lumo has narrower model selection with no frontier closed labs, no uncensored content, and no crypto-native distribution. But Proton's brand among privacy-conscious users is established in a way Venice's brand still has to earn outside its current niches Brave, DuckDuckGo, and Lumo are dangerous because they collapse the funnel. They don't need to persuade users to seek out private AI. They meet privacy-conscious users inside the browser, search flow, or email/VPN ecosystem already in use. For casual users, the privacy they offer plus a familiar brand may be enough. Venice differentiates on a different axis depending on which competitor I’m talking about: against Brave and DuckDuckGo, the privacy stack goes meaningfully deeper than proxy and the model catalog is wider; against Lumo, the differentiator is frontier closed-lab access via Anonymous mode, uncensored content, and crypto-native economics rather than depth of privacy itself. API routing and aggregation (OpenRouter, Together AI, Fireworks, Replicate) OpenRouter has emerged as a default routing layer for many developers. They raised $40M across combined seed and Series A from a16z, Menlo, and Sequoia in 2025 at approximately $550M, and are reportedly in talks to raise $120M at $1.3B led by CapitalG as of April 2026 on the back of ~$50M ARR and 150K+ monthly active developers. The product has the right surface, ZDR controls available globally and per-request, and developer mindshare from teams already integrated against it. OpenRouter also distributes Venice models, including Venice Uncensored, which makes it both a competitor and a distribution channel for Venice's API business. Venice's API differentiation is narrower but cleaner: privacy-first packaging, Venice-native uncensored models, crypto-native payment flows, and direct linkage into VVV and DIEM economics. Together AI, Fireworks, and Replicate compete on a different axis: cheap OSS inference for builders who don't care about privacy specifically. They're adjacent rather than directly competitive. Venice's API roadmap leans toward privacy and uncensored access. Continued investment in routing flexibility and developer experience will determine how much API share Venice captures relative to how fast the consumer subscription business grows. Confidential inference infrastructure (Tinfoil, NEAR AI Cloud, Phala Network, Maple) Several products now overlap with pieces of Venice's architecture. Tinfoil offers TEE-attested inference on confidential-compute GPUs with an OpenAI-compatible API, positioned at developer and infrastructure use cases. NEAR AI Cloud powers Venice's TEE mode and also ships NEAR Private Chat as its own consumer product. Phala Network powers Venice's E2EE infrastructure and OpenRouter's confidential routes. Maple is consumer-facing and privacy-native, with E2EE chat inside a secure enclave. Venice is deliberately building on specialized confidential-compute partners while owning the application layer, user relationship, brand, payments, and model packaging. Contractual privacy is becoming table stakes; verifiable privacy is becoming the next frontier. Venice's distinction is not that no one else has TEE or E2EE. It is that Venice packages multiple privacy modes, uncensored content, model access, crypto payments, and tokenized usage into one consumer and API product. Local and OS-level AI (Ollama, LM Studio, Apple Private Cloud Compute) Local AI is a real competitor on the horizon. Ollama and LM Studio already work well for technical users, and that audience continues to expand as consumer hardware accelerates. Open-source model quality is now strong enough for most everyday workloads. What keeps mainstream users on cloud services today is the setup friction and operational burden of running models locally. As that gap closes through more polished out-of-the-box solutions, simpler installers, and integrations that handle the operational burden, the share of privacy-conscious users who opt for local over any cloud service will grow. The timing is uncertain but could compress faster than typical long-horizon framing implies. Apple Private Cloud Compute is relevant strategically. PCC runs Apple Intelligence on Apple Silicon with hardware-backed privacy, normalizing the expectation that private AI is a platform feature. PCC is locked to Apple Intelligence on Apple devices, so it doesn't compete with Venice directly. It does educate consumers about what private AI should look like, which benefits the category Venice is in. Where Venice is actually different Three combinations are currently unique to Venice in market today: Multiple privacy modes selectable per request inside a single consumer product. Anonymous, Private, TEE, and E2EE all live in one app, and the user picks the mode at the prompt level. Several competitors ship pieces of this; Venice ships the full set together with the consumer UX layered on top. Strong privacy plus uncensored content access. Closed labs would have to abandon their corporate positioning to match this. None have shown willingness to do so. Enterprise-positioned privacy players face the same problem amplified by compliance requirements. Venice hosts Venice Uncensored 1.2 alongside frontier closed labs because Venice has fewer corporate constraints on content than the closed labs do, which lets it host uncensored variants the labs won't. Crypto-native distribution. VVV staking, DIEM mechanics, no-KYC onboarding, payment in crypto, and Erik Voorhees as founder reach an audience that closed labs and traditional privacy startups can't easily address. The customer acquisition cost basis is different from competitors buying mainstream consumer attention. Open questions on the competitive picture Five things to watch. The TEE infrastructure is rented, which means privacy alone won't be the long-term moat. Distribution against Brave and DuckDuckGo is a real gap and depends on whether deeper privacy and uncensored content pull users away from privacy-adjacent browsers. Enterprise procurement is open territory that requires SOC2, signed DPAs, admin controls, and audit logs to address. The consumer brand is concentrated in crypto and libertarian audiences, with mainstream awareness as the next leg of growth. And local AI maturation, particularly improvements in setup friction and consumer-friendly tooling, could compress the timeline on which Venice's addressable cloud market gets meaningfully smaller. The competitive thesis The shape of Venice's competition is the unbundling of its own wedge across multiple categories. Brave and DuckDuckGo can capture privacy-aware distribution. OpenRouter can capture developer routing. Tinfoil, NEAR, Phala, and Maple can commoditize confidential-compute primitives. OpenAI, Anthropic, Google, and xAI can offer enterprise-grade privacy around the strongest models. Privacy plumbing is going to commoditize. Most of the individual pieces of Venice's stack will become table stakes before long. The real bet is that Venice creates durable consumer and developer habits before that happens. That bundle is the core of Venice's positioning. Competitors can copy pieces of it, but copying the whole bundle would require each to stretch outside its core incentives and competencies. Closed labs would have to compromise their safety posture. Browsers and search engines would have to become AI-native. OpenRouter would have to own consumer UX and payments. Infrastructure providers would have to build consumer brands. Token Design Venice operates with a two-token model that separates protocol-level value capture from compute access. VVV is the protocol token tied to the success of the platform. The team has been progressively directing more value to VVV over time through emissions cuts and revenue-driven buy-and-burn mechanics. The goal is for the token to become deflationary over time. Staking VVV gives holders both yield and proportional API capacity. DIEM is a separate, more experimental token launched in August 2025. Each DIEM grants $1 of Venice API credit per day, indefinitely. DIEM is minted by locking staked VVV at an algorithmic rate, but once issued is freely tradeable, which lets users acquire predictable compute access without taking on raw VVV exposure. The two tokens answer different questions. VVV is a bet on Venice's growth and a way to participate in revenue capture. DIEM is a tokenized compute claim, more useful for actual API consumers than for speculators. VVV Current Supply Total supply is 79.93M VVV. 46.03M is circulating, with about 70% of that (32.19M) staked. 2.67M is still locked in team vesting. The remainder, roughly 31M, sits in Venice's company treasury, the Incentive Fund, and other non-distributed buckets outside the team block. Genesis Allocation Venice's launch documentation describes the following genesis allocation: There was no pre-sale. Burns Since Launch 99% of cumulative burns came from one-time events in March 2025. Approximately 32.51M VVV in the airdrop allocation went unclaimed and was permanently burned when the claim window closed, plus a separate ~1M team-related burn. Together these events removed roughly a third of the original supply. Recurring burns since November 2025 total only 195.26K VVV (about $3.1M at today's prices). The ongoing burn rate runs at roughly 37,752 VVV/month combined: ~31,636 from monthly discretionary buybacks using platform revenue, and ~6,116 from the programmatic per-subscription burn launched in April 2026. Burns aren't intended as a major source of demand for the token right now. The company is still young and is reinvesting cash to grow the business rather than scaling buybacks. The current burns function more as a signaling tool to the market that VVV is economically tied to the platform. They're also a useful way for observers to track subscriber growth, since each subscription tier triggers a specific dollar amount of VVV burned that's visible on-chain. Emissions Schedule Emissions have been stepped down six times since launch: January 27, 2025 (launch): 14M VVV/year August 20, 2025: cut to 10M/year (tied to the DIEM upgrade) October 23, 2025: cut to 8M/year February 10, 2026: cut to 6M/year May 1, 2026: cut to 5M/year (current) June 1, 2026: scheduled cut to 4M/year July 1, 2026: scheduled cut to 3M/year Vesting Team allocation vesting: 7.5M of the 10M team allocation streams linearly over 24 months from TGE. As of May 2026, roughly 4.83M has vested and 2.67M remains locked. The full team allocation completes vesting on January 27, 2027. Net Supply Pressure VVV is mildly inflationary today. Once the July 1 emissions cut to 3M/year takes effect, monthly emissions drop to ~250K VVV. At current burn rates of ~37,752 VVV/month, net new supply would be roughly 212K VVV/month, or about 3.2% annualized inflation against effective supply. The trajectory continues to improve from there. I expect emissions to keep declining past July. I also expect monthly burns to grow as subscription revenue scales, since the programmatic per-subscription burn mechanic ties burn volume directly to subscriber adds. Net deflation becomes quickly achievable as those trends compound. Utilities VVV has three utilities, all derived from staking. Venice has explicitly stated VVV is not a governance token, so there is no voting utility. Emissions yield. Stakers receive 80-100% of annual VVV emissions as yield, with Venice keeping the remainder on locked sVVV. Current staker APR is approximately 14.7% on the 5M/year emissions rate, dropping to roughly 9% after the July 1 cut. I don't view yield as a meaningful driver of investor behavior. People aren't buying VVV for the yield, and they aren't selling because the yield is coming down. It's something to do while holding the token, with the actual thesis driven by price appreciation tied to Venice's business growth. I’m constructive on emissions continuing to decline since they create new supply without driving incremental holder demand. Free Venice API access. Stakers can use Venice's API at zero marginal cost. Each staker's share of total API capacity is proportional to their share of staked VVV, measured in DIEM (where 1 DIEM = $1/day of credit). Before DIEM launched in August 2025, this share fluctuated daily as more people staked or unstaked. After DIEM, stakers who mint DIEM lock in a predictable per-day credit allocation. DIEM minting. Staked VVV can be locked to mint DIEM, the tradeable representation of Venice API capacity. Covered in the DIEM section below. Valuation Context Venice's token economics are trending in the right direction. The primary driver of VVV's valuation is revenue growth and the multiple the market applies to it. At $14 per token, VVV implies a market cap of approximately $660M and FDV of approximately $1.12B Per the Current State and Growth section, current total ARR is approximately $60M, growing at an annualized addition rate of approximately $200M and accelerating. On current ARR, VVV trades at roughly 11x revenue on market cap and 19x revenue on FDV. On 12-month forward ARR of approximately $260M ($60M current base plus $200M of annualized additions), VVV trades at roughly 2.5x revenue on market cap and 4.3x on FDV. Best comp: OpenRouter Among private inference platform peers, OpenRouter is the closest business-model analog to Venice. Both are asset-light businesses without their own GPU infrastructure, and both monetize via markup on underlying inference rather than by selling raw compute. Venice routes through NEAR AI Cloud, Phala, DeepInfra, and Parasail. OpenRouter routes through partner endpoints. ¹ Per The Information, OpenRouter is in talks to raise $120M at $1.3B led by CapitalG. Last closed valuation was approximately $550M at the $40M Seed plus Series A in June 2025. OpenRouter trades at 26x current ARR. One staleness consideration: OpenRouter's $50M ARR figure is from early 2026 per Sacra's research, and OpenRouter's reported growth trajectory ($5M to $50M over the eight months ending early 2026) suggests their current ARR by mid-2026 is likely materially higher. If OpenRouter is at $80-100M ARR today, the 26x multiple on the in-talks $1.3B valuation compresses to 13-16x. The directional case for Venice trading at a discount to OpenRouter holds, but the magnitude of that gap may be smaller than the 11x vs 26x framing implies. The reasons that justify that multiple (asset-light economics, smaller revenue base with substantial growth runway, aggregator value proposition) apply to Venice's business as well, with Venice's privacy positioning adding pricing power that OpenRouter doesn't have. But the two businesses aren't margin-identical. OpenRouter takes a ~5% fee on approximately $1B of annualized inference spend flowing through its platform. Its $50M revenue carries ~90%+ gross margins because OpenRouter doesn't pay for GPU compute; the underlying model providers do. Venice charges customers directly and bears the underlying inference costs (GPU compute for OSS model hosting and API fees for frontier closed-lab models), giving Venice meaningfully lower gross margins on its revenue (estimated 40-60%). Per-token economics also differ. Venice charges customers directly at retail-like pricing, and subscribers pay a fixed monthly fee regardless of usage. Both effects mean Venice captures meaningfully more revenue per token consumed than aggregators do. This is why Venice can have a comparable revenue base to OpenRouter despite operating at much lower absolute token volumes (~60-80B/day for Venice vs ~2.8T/day for OpenRouter). A margin-adjusted fair value framework therefore puts Venice's defensible multiple lower than OpenRouter's. Comparing on a gross profit basis: if Venice's gross margin is 50%, $60M of revenue translates to $30M of gross profit, and applying OpenRouter's 26x gross profit multiple to Venice yields approximately $780M of fair value. Venice's current market cap of $660M sits below that fair value figure, while FDV of $1.12B sits modestly above it. One caveat worth flagging is that VVV is a token, while the OpenRouter, Fireworks, and Together AI multiples reference equity. Investors in those private companies typically own securities with residual economic claims, governance and information rights, and in many cases liquidation preferences. VVV holders do not own equity in Venice, do not have a legal claim on company cash flows or exit proceeds, and cannot force revenue distribution. VVV derives its value from utility (staking, DIEM minting, and API access), plus revenue-linked buy-and-burn mechanics. Those buy-and-burn mechanics are not significant in absolute terms today, as discussed earlier, but they could become more material if subscription revenue scales and emissions continue falling. That distinction normally argues for a discount to equity-derived comps. A token can trade like a public proxy for a company's growth for long stretches, but it is not the same instrument as equity. In an equity sale, recapitalization, or restructuring, token holders may have no direct claim on the corporate value waterfall. There are multiple historical examples in crypto of tokens that initially traded as quasi-equity proxies, only for the economic value to accrue primarily to the company, equity holders, creditors, or insiders once conditions tightened. Venice is unusual in one important respect. Based on my understanding, Venice has not raised external venture capital. Erik Voorhees funded the company personally, and there is no publicly disclosed VC preference stack creating a competing equity outcome. That does not make VVV equity, and it does not eliminate the structural difference between token and shareholder claims. But it does reduce one of the common crypto failure modes where a project optimizes around an equity outcome while the token becomes economically stranded. In Venice's case, the token appears more central to the company's long-term value-capture strategy than it is in many VC-backed crypto projects. VVV is the liquid public asset tied to the platform, it is required for DIEM minting, it gates staking-based API capacity, and it is the asset Venice buys and burns as subscription revenue scales. That should argue for a smaller token discount than would apply to a project with a large preferred-equity stack and weak token mechanics. Still, some discount is warranted because VVV remains an indirect economic claim rather than ownership of Venice itself. The relevant analytical question is what percentage of Venice's underlying business value can be reflected in VVV's market value through burns, utility demand, DIEM, and market perception. Even after applying a meaningful token discount to the equity-comparable fair value, the case strengthens substantially on the forward trajectory. From the current $60M ARR base, the conservative $200M annualized addition rate adds approximately $317M of new ARR over the 19 months from now to end of 2027, reaching approximately $377M total ARR. Modest sustained acceleration (the latest week is pacing at $268M annualized assuming API tracks 1:1) would push end-of-2027 ARR to $400M+. At these forward levels, the multiple compression on current FDV is substantial. DIEM Overview DIEM launched on August 20, 2025 as a tradeable ERC-20 token representing perpetual tokenized inference. Each DIEM grants $1 of Venice API credit per day, indefinitely. Current DIEM supply is 38,416 tokens, with 29,131 staked. DIEM currently trades at approximately $1,325, implying a market cap of around $51M In practice, most users won't interact with the minting mechanic. The supply of DIEM is effectively capped at current levels. The exponential Mint Rate formula now requires locking roughly $9 of VVV for every $1 of DIEM minted at current prices, which makes new issuance economically restrictive. Net supply has stayed within a ~4% band of the 38,000 target over the past 30 days, with mints and burns roughly offsetting. Some new minting still happens at the margin, and existing minters can redeem (burn DIEM to unlock their sVVV), but for the vast majority of participants DIEM is just a token to buy or sell on the open market. The minting mechanic matters as context for understanding how supply formed and what backs the token, but most people only need to think about DIEM as a tradeable asset. The Mechanic (for context) You stake VVV. The staked VVV (sVVV) sits in the staking contract earning yield. You lock some or all of your sVVV to mint DIEM at the current Mint Rate. The Mint Rate is algorithmic and rises exponentially as DIEM supply approaches the target set by Venice (originally 38,000 DIEM). At current supply levels, the rate is approximately 757 sVVV per DIEM, up substantially from the base rate of 90 at launch. The formula creates natural scarcity as supply approaches target. Once minted, DIEM is freely tradeable on Aerodrome. To unlock your sVVV, you burn the same amount of DIEM you originally minted. If you sold the DIEM, you have to buy it back first. While your VVV is locked behind DIEM, you continue to earn 80% of staking yield. The other 20% flows to Venice. Utilities DIEM has three functional utilities: API access. Stake DIEM and consume up to $1/day of Venice API per DIEM held. Predictable, not capacity-fluctuating like raw VVV staking was before DIEM existed. Relevant to all DIEM holders. Tradeable cash-out instrument. VVV holders who have minted DIEM can sell it on the open market without selling their underlying VVV, which keeps earning yield. Relevant to existing minters. Required to unlock locked VVV. If you minted DIEM, you must burn an equivalent amount to recover the underlying VVV. Relevant only to existing minters. Valuing DIEM For an actual API user, DIEM valuation comes down to three components. The compute cash flow is fixed at $365 per DIEM per year. That is mechanically defined by Venice's design. Every DIEM holder receives the same $365 annually regardless of what they paid for the token. This is the underlying value DIEM represents. Opportunity cost is similar across investors. Whatever you could earn risk-free on capital (treasury yields around 5%) is what you give up by holding DIEM instead. Going-concern risk is where investor views diverge. The fixed $365/year only holds value if Venice continues to operate and honor the API credit. DIEM's price embeds the market's collective view on Venice's longevity. Investors who believe Venice will operate indefinitely require a small premium for that risk. Investors who believe Venice faces meaningful existential risk require a larger premium. Fair DIEM Price = $365 / (Risk-Free Rate + Going-Concern Risk Premium) Different views on Venice's longevity produce different fair prices for the same fixed cash flow. Working through it with a 5% risk-free rate: At today's DIEM price around $1,325, the market is collectively pricing in roughly a 22.5% going-concern premium (since $365 / $1,325 ≈ 27.5%, and 27.5% minus the 5% risk-free rate ≈ 22.5%). Investors who think Venice deserves a smaller premium will buy. Investors who think it deserves more will sell or pass. The opportunity cost component is essentially the same for everyone. The compute cash flow is fixed. Going-concern view is the only meaningful variable that drives price formation across investors. For users who actually consume compute at scale, the math typically favors DIEM at current prices as long as Venice continues to look durable. For pure speculators who don't use the API, the bet is purely on price appreciation tied to Venice's growth narrative. That's a different trade entirely. Venice's Cost from DIEM Venice mints some DIEM itself (10,000 at launch) and distributes portions to specific user cohorts, including historical free Pro tier promotions for VVV and MOR holders. Venice carries explicit costs from non-paying users who consume API capacity via DIEM rather than through Pro subscriptions or paid credits. Erik Voorhees has stated this is a small fraction of paid inference and revenue. The Bottom Line on VVV Venice is one of the more genuinely differentiated companies in crypto right now. The privacy-first AI bundle (Anonymous, Private, TEE, and E2EE selectable per request, alongside frontier closed labs and uncensored open-source models) is something no competitor packages today. The recent revenue trajectory suggests that bundle is finding paying users at a pace that's hard to ignore. At a $60M current ARR base, VVV trades at 11x revenue on market cap and 19x on FDV. The trajectory is what makes this compelling, more than the current multiple. Venice was adding sub ARR at roughly $2M/week through late April and stepped up to $2.6M/week by mid-May, implying an annualized run rate of new sub ARR additions of $134M, or $268M total with API tracking 1:1. Anchoring conservatively to $200M total annualized, 12-month forward ARR lands at approximately $260M, which compresses current multiples to 2.5x and 4.3x. If the trajectory holds, the forward case compounds quickly. Risks are real. Hyperscalers could ship adequate privacy as a feature and compress the standalone privacy-first market. Local inference could mature faster than expected and pull users out of cloud entirely. Privacy-native competitors (Brave, DuckDuckGo, Lumo, Maple, Tinfoil) could chip away at the bundle. The structural distinction between token and equity never fully disappears. Any of those could compress the upside. The central question is whether the addition rate sustains or accelerates from here. At $200M annualized today and pacing toward $268M at the latest week, even a modest continuation of the current trajectory puts Venice in a meaningfully different position 12-18 months out. That's the bet. Views expressed in this post are those of the individual author and are not the views of Delphi Ventures General Partner LLC (“Delphi Ventures”) or its respective affiliates. The post is not directed to any investors or potential investors, and does not constitute an offer to sell, or a solicitation of an offer to buy, any securities, and may not be used or relied upon in evaluating the merits of any investment. The author is a holder of the token(s) discussed and has a direct financial interest in their performance.