VEN: Economics

Own a piece of an AI agent that actually earns. You buy a stake in an agent, and when that agent sells real products, you receive a pro-rata share of real revenue, paid in dollars, not a token.

Live: https://venai.app

This document describes how money works on VEN: the revenue streams, how a co-ownership stake is priced and bought, how product-sale revenue is split, the real-money ledger that records it, the payout rails that move money out, the demo play-money economy and why it is walled off, and the compliance posture that governs all of it.

As in the rest of the docs, each part separates what is built and running Today from Where we're going. One thing to state plainly up front, because it is the heart of the honesty of this model:

The full revenue-share engine, pricing, buying, splitting, ledgering, and paying out a stake, is live: real customers have bought real stakes with real money, and real sales distribute across cap tables today. The system was built gate-first (REAL_COOWNERSHIP_ENABLED) and opened deliberately; the kill-switch remains in place and tested, so the securities-sensitive surface can be shut off in one move if it ever needs to be.

Co-ownership is a direct legal revenue-share, recorded integer-exact in a ledger, a claim on real cash flow, not a tradeable coin, not an emission, not a bonding curve. VEN does have a token on Solana, but it is a separate layer (funded by a share of platform fees via buybacks, not emissions) and is not how co-ownership works, see §9.

0. The revenue streams (where money enters)

VEN earns from several distinct streams, kept strictly separate at the payment layer:

1. Brand-agent retainers [Today]: the primary commercial product. Businesses subscribe to a managed brand agent on published monthly tiers (Starter $900 · Growth $1,800 · Scale $3,000), billed by card as a standard subscription (one-time setup + monthly). Retainer revenue is flat subscription income. It does not flow through the per-sale split below, and a managed client's assets are excluded from every sales rail.
2. Product sales [Today]: 1-of-1 pieces sold by agents (card or USDC). These carry the 20% platform fee and distribute pro-rata across the agent's cap table (§3).
3. Agent services & licensing (x402) [Today]: pay-per-generation, per-agent paid services, and licensing of existing outputs, settled in USDC on Base or Solana and credited through the same revenue machinery.
4. Secondary-market fees [Today]: the platform fee on peer-to-peer stake resales (§2½).
5. Prepaid credits & demos [Today]: credit packs (card or USDC) that fund AI generation; brand demos draw purchased credits and auto-refund if no real AI output is produced.

Note that co-ownership is opt-in: the default brand-agent flow offers zero shares. An agent only has a cap table if its creator chooses to open one. Everything below describes the economics of agents that did.

1. What you actually own

A stake in a VEN agent is a percentage share of that agent's real product-sale revenue, net of the platform fee. It is a direct economic interest in cash flow, not a token whose price floats on sentiment.

Concretely, ownership is recorded in a cap table (ownership) per agent. Each row carries:

• the holder,
• the percentage owned, and
• a real flag that distinguishes real-money stakes (real=1) from play-money demo stakes (real=0).

Only real=1 stakes ever receive real payouts. That single flag is the wall between the two economies (see §6).

2. How a stake is priced and bought

Today (live, real stakes are bought with real money)

Stakes are sold from the agent's available pool. This is primary issuance. A buyer purchases a percentage of the agent at the agent's set price, on either rail:

• Card (Stripe): createShareCheckout opens a checkout; fulfillShareCheckout confirms payment. Routes: app/api/shares/[id], app/api/shares/stripe/fulfill.
• On-chain USDC: createShareIntent reserves the purchase; verifyShareIntent confirms the on-chain payment (lib/server/payments.ts). Same receive-only verification model as product sales: Solana and Base, no custody, no keys.

The purchase is recorded in share_purchases, tagged purpose='shares' on its payment intent so it can never be confused with a product sale or a credit top-up.

Settlement is rail-agnostic, exactly-once, and crash-safe (settleSharePurchase, lib/server/shares.ts). It is decomposed so it converges correctly even without a long transaction:

1. Claim the purchase via a settled_at conditional update (so it settles once, even under retries).
2. Grant ownership idempotently with a deterministic primary key (own_<purchaseId>, real=1).
3. Debit the agent's available pool and credit the seller in a single CTE.

If the same percentage is oversold by a race, the settlement honors the paid buyer and logs the conflict for reconciliation, a paid buyer is never left empty-handed. On-chain share payments are additionally self-healed by the cron (reconcileShareIntents, 48h window) to catch reference-less sends, late confirmations, and confirmed-but-uncredited payments.

2½. Secondary market: bet on the future of an agent

Beyond primary issuance, VEN runs a peer-to-peer secondary market (live at /secondary) where co-owners resell part of a held stake to one another. This is what lets you bet on the future of an agent:

• Buy early. Buy a stake early in agents you believe will grow, before demand catches up to the price.
• Earn while you hold. For as long as you hold the stake, you receive your pro-rata share of that agent's real product-sale revenue (§3), settled into the same ledger as every other co-owner.
• Sell higher later. List your stake for resale at a price you set; if the agent's demand or revenue has grown, a later buyer may pay more than you did. The upside, and the downside, is yours.

How a resale settles (lib/server/secondary.ts, settleStakeTrade). A holder lists a percentage of their stake at an asking price, and can reprice it, or field bids (a bid is accepted no-custody: acceptance converts it into a reserved listing that settles through the same rails). A buyer pays on either rail: card (Stripe) or on-chain USDC. On settlement, the ownership percentage moves seller→buyer as a pool-neutral pair of ownership adjustment rows, and the seller is credited the proceeds net the platform fee into the revenue_ledger, reusing the exact exactly-once, crash-safe machinery as a primary sale, with no new money-out path (the seller withdraws via the existing payout rails). Because revenue distribution reads the live cap table, all future revenue automatically follows the new owner with no extra bookkeeping. If two buyers race for the same listing, a single-winner claim settles one and refunds the other.

This is experimental and securities-sensitive. A revenue-share interest that can be resold for profit carries its own regulatory weight, so the secondary market is gated server-side (SECONDARY_MARKET_ENABLED), shows a risk disclaimer on every surface, and is operated under the same legal responsibility as primary co-ownership. Demo/play-money accounts cannot trade real stakes. Consult your own legal advisor before trading.

Where we're going

Deepening the secondary market within the same legal wrapper: KYC and transfer-restriction tooling as volume grows, plus richer price discovery on top of the live bids/depth/history surfaces.

3. How revenue is split

Today (live)

When an agent sells a one-of-one product for real money, the gross is split across the cap table by distributeProductRevenue (lib/server/revenue.ts). The rules:

• Platform fee first. The platform takes PLATFORM_FEE_PCT (20%) of gross.
• Pro-rata to the cap table. The remainder is split across the owner plus all real=1 co-owners, in proportion to their ownership percentage.
• Integer micro-USD math. Everything is computed in integer micro-USD (1 USD = 1,000,000 µUSD). Each share is floored, and the sub-cent dust remainder is assigned to the agent owner, so the split never loses a fraction of a cent and never mints one. The books always balance to the gross.
• Real money only. Only real revenue distributes: a live Stripe sale (livemode) or a settled on-chain USDC sale (tx_signature). Play-money (real=0) stakes are excluded entirely.
• Exactly-once. Distribution is claimed with a distributed_at guard plus the UNIQUE idx_revledger_once index, so a sale is split exactly once even if the settlement path runs twice.

The result of a split is a set of credits in the revenue_ledger.

4. The real-money ledger

Today

The revenue_ledger is the single source of truth for real money owed and paid. Properties:

• Integer micro-USD throughout. No floats. Every entry is exact.
• Append-only and idempotent. The UNIQUE idx_revledger_once index plus the distributed_at claim mean a given sale produces exactly one set of ledger entries, ever.
• Real only. Play money never enters the ledger. It is walled off at write time by the real flag and the livemode/tx_signature gates.

A co-owner's balance is simply the sum of their ledger credits, minus what has been paid out. Payouts draw against this balance.

5. Payout rails (real money out)

Two rails are built (lib/server/payouts.ts), both reserve-first and reversible on failure:

Today

• Bank, via Stripe Connect Express. A creator onboards through a Connect link; the system checks live eligibility and transfers funds, handling FX when the platform balance is in a non-USD currency (PAYOUT_FX_USD_<CCY>). This rail is live, connected creators exist and have been paid through it, and remains behind its STRIPE_CONNECT_ENABLED switch so it can be shut off in one move.
• Solana USDC, operator-settled. The app records a pending payout and debits the ledger; the operator then sends USDC from their own wallet and marks it paid with the transaction. This preserves the no-keys, no-custody posture. The app never sends on-chain itself. Available to any creator who sets a Solana address.

Hybrid routing at sale time. When a sale settles, resolvePayoutRoute (lib/server/sales.ts) decides how the creator's cut is paid:

• DIRECT: a connected, non-operator creator with no real co-owners is paid instantly via a Stripe destination charge, with the platform fee taken as an application_fee. The money never pools.
• POOLED: everything else accrues to the revenue_ledger and is withdrawn later via the rails above.

The router fail-safes to POOLED on any doubt, so money is never sent down the wrong path.

Accounting hygiene. Reserve-first with payout_reversal on failure; a MIN_PAYOUT_USD floor (default $10); whole-cent payouts with sub-cent dust left in the balance rather than rounded away.

Where we're going

Broadening payout currencies/regions as creator demand grows.

6. The demo economy: and why it's walled off

Today

Alongside the real economy, VEN runs a fully simulated Demo Mode so people can explore co-ownership without spending a cent. It is recognized by account (demo accounts, e.g. demo@forge.app) and is play money end to end:

• Play-money co-ownership (investInAgent): only demo buyers, only demo agents (never the flagship), debiting a play-money walletBalance and writing ownership rows with real=0.
• Simulated earnings + APR: deterministic, seeded figures credited to the play-money wallet, shown only for demo accounts.
• Play-money wallet: walletBalance, withdraw, transactions, demo-only; real accounts see $0 here.

Why the wall exists, and how it's enforced

Mixing play money and real money is how trust dies. The separation is structural, not a UI convention:

• ownership.real: revenue distribution excludes real=0, so a play-money stake cannot receive a real payout. Ever.
• payment_intents.purpose (credits | product | shares): a payment for one purpose cannot grant another.
• livemode / tx_signature: only genuinely real sales distribute revenue; the public proof-of-work feed reads only real signals.

Real accounts therefore see honest zeros for every simulated figure, and only ever see real product-sale revenue. Demo Mode is a frictionless on-ramp, not a mirror that inflates the real ledger.

7. A worked example

Take an agent, call it Aria, with a simple cap table, and one real sale.

Cap table (all real=1):

A buyer pays for a one-of-one piece: $9.00 (the default product price), settled on-chain in USDC.

Step 1: Platform fee (20%).

gross           = $9.000000   (9,000,000 µUSD)
platform fee    = 20% × gross = $1.800000   (1,800,000 µUSD)
distributable   = $7.200000   (7,200,000 µUSD)

Step 2: Pro-rata split of the $7.20 distributable, in micro-USD, floored.

Co-owner A (25%):  0.25 × 7,200,000 = 1,800,000 µUSD = $1.80
Co-owner B (15%):  0.15 × 7,200,000 = 1,080,000 µUSD = $1.08
Owner      (60%):  0.60 × 7,200,000 = 4,320,000 µUSD = $4.32
                                       ---------
                          sum of shares = 7,200,000 µUSD   (balances exactly)

In this clean example the percentages divide evenly, so there is no remainder. When a split does not divide evenly, each share is floored to the µUSD and the leftover dust (a few millionths of a dollar) is assigned to the owner, so the parts always sum back to exactly $7.20, never $7.199999, never $7.200001.

Step 3: Ledger + payout. Three credits are written to revenue_ledger (exactly once). Co-owners A and B draw their balances when they clear the MIN_PAYOUT_USD floor, via bank (Connect) or operator-settled Solana USDC. If the owner is a connected, non-operator creator with no real co-owners, their cut could instead be paid instantly via a DIRECT Stripe destination charge at sale time, but here, because real co-owners exist, the sale is POOLED and everyone is paid from the ledger.

The check that makes it honest: $1.80 (fee) + $4.32 + $1.80 + $1.08 = $9.00. Every cent of the sale is accounted for, with no float drift, because the entire computation is integer micro-USD.

8. Compliance posture

The economics are designed around a single hard constraint: a revenue-share sold with an expectation of profit from the issuer's efforts is a security, and VEN's model is exactly that. The structural choices follow from taking that seriously rather than routing around it.

Today

• Kill-switch, retained. Public co-ownership purchases were built gate-first behind REAL_COOWNERSHIP_ENABLED and opened deliberately. The switch remains live and tested: if it is ever flipped off, the buy-shares route (app/api/bazaar/[id]/buy-shares/route.ts) immediately returns 503: "Co-ownership purchases aren't open yet." The most securities-sensitive surface on the platform can be shut down in one move, without a deploy.
• Ownership is cash flow, not a token. Co-ownership is a direct legal revenue-share recorded in revenue_ledger. There is no per-agent coin, no emissions, and no bonding curve behind ownership. VEN's token (§9) sits outside this: it is funded by a share of real platform fees (buybacks), not emissions, and is never the ownership instrument. Keeping ownership a ledgered revenue-share removes an entire category of securities and market-manipulation exposure that token-as-ownership models carry.
• No custody, receive-only. The platform holds no private keys and makes no outbound on-chain sends; USDC payouts are operator-settled from the operator's own wallet. The platform verifies the public chain rather than touching customer funds.
• Walled demo economy. Exploration happens in clearly-disclaimed play money, structurally isolated from the real ledger (§6), so no one can mistake a simulated APR for a real return.
• Public proof-of-work. Real sales carry public verify links (solscan/basescan); the /live feed reads only real signals. Claims are falsifiable.

Where we're going

Hardening the legal wrapper as volume grows, KYC and transfer-restriction tooling for the secondary market (§2½), and region-aware compliance for primary co-ownership, all inside the same gate-first architecture.

9. The VEN token

VEN has a token on Solana. It is deliberately separate from co-ownership and from the entire sale / payment / payout structure described above. Nothing about how creators or co-owners earn depends on it.

Today

• Fee-funded buybacks. A portion of the platform's real fee revenue (the same platform fee taken on sales) is used to buy the token back on the open market. Its value is therefore tied to actual platform activity, real cash flow, rather than emissions, inflation, or a bonding curve. This is the "revenue → buyback" leg that token-first models promise but rarely turn.
• Not the ownership instrument. Co-owning an agent is a claim on that agent's revenue (a ledgered revenue-share); holding the token is a separate, optional claim on the platform's overall growth. You never need the token to deploy, co-own, earn, or get paid.
• No emissions. Token value comes from buybacks funded by real fees, not from minting or inflation schedules.

Where we're going

• Token-holder benefits. Utility for holders, for example, discounts on the platform fee and other perks, may be introduced over time. Any such benefits stay anchored to real platform economics, never to emissions.

For the system that generates the revenue this model distributes, the autonomy loop, the channel model, the AI funding chain, and the exactly-once/crash-safe machinery, see architecture.md.