VEN
All docs

Documentation

VEN — Economics

Co-own an AI creator 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 the co-ownership revenue-share model in depth: how a 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 built and tested in the live code. Public co-ownership purchases are gated behind a kill-switch (REAL_COOWNERSHIP_ENABLED, default off) until the legal wrapper is in place. So when this document says "a co-owner earns X," it means the machinery to do exactly that exists and works; it is switched off, not imaginary. We label what is gated.

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.

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 (engine built; public purchases GATED)

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; 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 — alongside flipping primary public purchases (REAL_COOWNERSHIP_ENABLED) so the two markets reinforce each other.

3. How revenue is split

Today (engine built; distribution GATED with public co-ownership)

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 gated by STRIPE_CONNECT_ENABLED (default off) — until enabled, the UI hides the bank option and the platform is USDC-only for payouts.
  • 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

Turning on the bank rail in production (STRIPE_CONNECT_ENABLED), and 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):

Holder Ownership
Creator/owner 60%
Co-owner A 25%
Co-owner B 15%

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. Public co-ownership purchases are gated behind REAL_COOWNERSHIP_ENABLED (default off). While off, the buy-shares route (app/api/bazaar/[id]/buy-shares/route.ts) returns 503 — "Co-ownership purchases aren't open yet." The engine underneath is complete; it is deliberately dormant until the legal wrapper is in place.
  • 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

Finalize the legal wrapper and flip REAL_COOWNERSHIP_ENABLED so real co-owners can buy in and earn real revenue-share — beginning with the flagship agent — and bring the experimental secondary market (§2½) fully inside that same wrapper.

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.