Real work, verified.

EDEN is a tokenized, non-dilutive venture platform for AI startups, where launching is one track/feature among several: any AI/agentic company — compute, models, agents, DePIN, or apps — can launch a token paired against ETH, a stablecoin, or any tokenized stock on Robinhood Chain, streams real yield to its holders from day one (denominated in whatever it's paired against), earns ongoing protocol-level rewards only once it proves real usage, and feeds an ecosystem-wide buyback engine with a rising, real-collateral-backed NAV floor. Small backers are structurally favored over whales throughout.

It is not a trading-bot casino wearing infrastructure language, and not a copy of any single precedent. It is built by taking the one mechanism each precedent does best, and explicitly designing out the failure mode that sank the rest of that precedent's model.

Real AI economics run in a stack. Each track is its own launch category with its own definition of verifiable output — a support agent is never measured like a GPU provider, and an inference host is never measured like the model it serves.

The tracks mirror how the real AI economy stacks from silicon to product — compute → inference → models → data → agents → DePIN → commerce → apps, plus research — and the taxonomy extends without touching the math: a new track is a new adapter family plus a published weight vector, zero mechanism changes. Training-as-a-service runs as an adapter under compute; robotics/embodied-AI fleets run as one adapter family under DePIN, alongside wireless/sensor, energy and mapping networks — DePIN is the track, robotics is one category inside it, not a synonym for it. Agentic Commerce & Payments is its own track: an agent settling a transaction bears payment-specific risk (chargebacks, disputes, settlement failure) that neither the agent nor app track measures.

• —Instant and permissionless. Any creator, any layer. Supply mints to the curve — no presale. A team allocation is allowed at launch, with one hard condition: a minimum of 20% of it is vesting-locked at the contract level (§11). Creators upload their own coin icon and set a description at launch.
• —Dev-buy vesting is mandatory, not optional. A creator's opening buy on their own curve must acquire at least 5% of supply, and a minimum of 20% of that buy locks into its own vesting contract — the creator picks the schedule (linear, cliff, or cliff-then-linear; 20–100% locked, 180 days to 4 years) at launch, then it's immutable. This closes the gap the team-allocation lock doesn't cover: a creator's own opening purchase, which would otherwise land fully liquid and sellable in the same second the curve opens.
• —Pairing asset is the creator's choice, fixed at launch: ETH as the neutral default, a stablecoin for calm settlement, or a tokenized stock as a real-world benchmark. The pairing choice doubles as the project's public performance benchmark — a trading agent paired against a semiconductor stock is scored against it.
• —Snipe protection. Opening buy tax starts at 99% and decays to zero over seconds — bot-sniping the first block is unprofitable while ordinary buyers enter almost immediately.
• —Launch burn. Creating a token requires burning a fixed amount of the root token, atomically in the launch transaction. Real anti-spam cost, and permanent deflationary pressure that fires regardless of whether the project ever proves usage.
• —Graduation. When the curve sells out, it automatically builds a locked liquidity pool seeded from what the curve collected. No migration step, nothing for a creator to get wrong, and anyone can trigger it if it stalls.
• —Liquidity keeps deepening after graduation. A bounded slice of every post-graduation trading fee routes into a per-launch vault that periodically grows that same permanently-locked pool — never withdraws from it, no admin key can reverse it. The root token gets the identical treatment on its own pool, funded from a carve of the protocol's existing fee cut rather than a new, larger one. Volume compounds into deeper markets instead of just generating a fee that leaves the pool unchanged. Launches can additionally lock a second pool paired against the EDEN index token itself, so a trade between two unrelated launches can route through that shared index depth instead of needing a dedicated, thinly-traded pair for every combination — the same growth mechanism compounds fees into that pool too.
• —Pre-verification during bonding. Attestation sources are declared at launch, so the oracle can start scoring before graduation. Dry-run scores publish on the token page while the curve fills — an already-real business bonds with a live verified score instead of as a blind ticket, and clearing the gate before sell-out starts the creator fee ramp and holder fee routing at the instant of graduation (§06). The curve itself never changes: same shape, same snipe tax, same gauntlet for everyone.
• —Zero custody. Every transaction is signed by the user's own wallet. The platform holds nothing.
• —Access gating happens at the asset level, not the person level. The platform gates which assets are eligible to pair against; trading a launched token requires only holding the pairing asset. Tokenized-equity assets are available only where and as permitted — see §12.

The only question the gate asks: does the claimed real-world output reconcile with data re-pulled directly from the project's own systems — its helpdesk, its CRM, its GitHub and CI, its brokerage feed, its payment processor? A metric that fails re-fetch is zeroed before it ever reaches the scoring math.

On-chain commitment. Scoring math runs off-chain; each epoch commits a signed Merkle root of every (project, score) pair to an on-chain registry. Anyone verifies any single project's score with a Merkle proof — public, tamper-evident grades without publishing private business data. Signer trust is staged: single signer → committee → staked attesters slashable if a signed root contradicts re-fetched source data.

Human input decays at the extremes. A human score can nudge the systematic score, but its weight follows $w(s) = 4\,s\,(1-s)$ (γ = 1, fixed on-chain) evaluated at the project's attested systematic score — the registry proves the oracle's Merkle leaf itself, so no scorer can pick s. Maximal in the ambiguous middle, zero at both ends. A token with no attested score yet records human scores (and validator-emissions eligibility) with zero weight.

There are no protocol-wide ROOT emissions — for any reason. No pool releases ROOT on a timer, no schedule halves, no track partition splits a shared pot. Every reward is paid out of a single project's own trading fees, so a project only ever earns from the activity its own token generates.

• —Creator fee ramp. The creator's share of that token's fee rises with its score to 50 % at score 100 (CreatorRouting). It starts at 30 % for a project that is verified by Eden or has an attested data score, and at 10 % (10 % → 50 %) for an unverified project with no data — an unscored project sits at that floor, and because no-data scores are capped at 50 such a creator tops out at 30 % until verified or data-backed.
• —Scorer rewards (paid in the pair asset). A slice of every fee feeds that token's ROOT-buyback lane. Half of the lane stays in the token's pair asset (ETH, USDG or the RWA it trades against) and pays the validators who scored that token (ValidatorEmissions, 7-day cycles, weight √stake × thesis quality, at most 5 % of the cycle pool per validator) — validators are never paid in ROOT, so rewards create no ROOT sell pressure. The other half buys ROOT: half of that becomes permanently locked ROOT/ETH liquidity, half is burned. Anything the scorer pool leaves unpaid buys ROOT and is burned.

Every graduated project is re-scored continuously. A project that stops delivering slides back to its creator floor (30 %, or 10 % if it is unverified with no data), and its validators stop earning because nobody can post a quality proof for work that is not there.

Every trade pays a fee, split between protocol, creator, and — for projects with an attested score — a holder distribution pool. Where enabled, the protocol routes a share of a project's trading fees to its holders automatically, denominated in the pairing asset, proportional to holdings, with no claim step.

To be precise about what this is: these are protocol-defined fee distributions — a routing rule over trading fees the protocol itself generates. They are not dividends, not a share of any company's revenue or profits, and not interest. Whether any distribution occurs, and its size, depends entirely on protocol activity. It can be zero.

Holder routing follows the attested score, not a badge. A project's holder distribution switches on once its score appears in a FINAL attested root (the distributor checks the Merkle proof on-chain). The Eden “Verified” badge is a display flag only — it never gates routing, the creator ramp or validator payouts.

Small positions are structurally favored: reward weighting within a project's backer pool is concave in position size, and positions above a threshold contribute a skim redistributed to smaller positions in the same pool. Large capital still participates — it just doesn't capture the whole curve. (Exact parameters are published per epoch; see §04 for how scoring feeds this.)

Three burn rails reduce one root supply. Two are structural — they fire on participation alone, with zero dependency on trading volume:

• —Launch burns — every new token launch burns root supply atomically (§03).
• —Validation burns — registering as an active backer of a specific project (beyond passively holding or trading it) means locking a validating stake plus a one-time root-token burn, atomically (§17). Passive trading never requires a burn — this is a conviction filter, not a tax on speculation. Slashed unverified claims are burned through the same rail.
• —Buyback burns — funded from three fee sources: launch fees, trading fees, and treasury yield. Executed as scheduled, publicized burn events with a public ticker, not invisible continuous buys. Never funded from any cut of a project's own business revenue — the protocol deliberately takes no share of the real-world value a project proves (see §13).
• —Validator-emissions remainder — whatever a token's validator pool leaves unpaid at cycle close (the 5 % cap, low-quality theses, copies) is burned through the same vault.

Every fee event splits two ways: part funds the leaf project's holder distribution pool, part flows up to the root token's buyback engine. One successful project compounds both its own holders' distributions and the ecosystem's root asset simultaneously.

A portion of protocol revenue accumulates in a treasury. The book is split across four allocations, rebalanced per epoch:

The index also has its own direct fee lane. Separately from the treasury rebalance target above, a flat 20% of every fee event — launch fees, curve-stage trading, and post-graduation trading alike — routes straight to the index vault as a first-class destination, alongside the protocol, holder-share, and root-buyback cuts. The ~26% figure is the portfolio target the per-epoch rebalancer steers toward; this 20% lane is the flow mechanism that funds it. Under high-volatility regimes the routed inflow still lands in the vault — it just rests in its stablecoin leg until the deployment throttle below allows conversion into equity.

The NAV floor, framed precisely. The floor reserve is designed so the root token's reference value rises with accumulated real collateral and burns. The rail is redemption-only: below NAV, a small set of whitelisted authorized participants can burn root and receive reserve assets at NAV — instant, mechanical, always available. There is no corresponding creation function: no AP, and no one else, can mint fresh root against the reserve at any price. That means the floor protects the downside only — nothing in the protocol pushes the price back down if root trades above NAV, and any premium the market pays is retained by design. Retail users trade tokens on the open market and never interact with restricted assets directly. The floor is a treasury-management design target, not a promise: no value, price, or exit is guaranteed.

The index allocation compounds into a long-only basket of tokenized AI-economy equities — energy and compute infrastructure (Bloom Energy, CoreWeave, Nebius), silicon (AMD, Intel, NVIDIA), and the application and rail layer (Tesla, Robinhood) — weighted and published per name, with a defined share of treasury fee inflow routed to each. Weights are research-set, not sentiment-set: current supply and demand data taken directly from manufacturers and providers, market-trend analysis, and related signals. Allocations are reviewed per epoch and subject to change.

The thesis: some protocols hedge away direction to harvest a spread. EDEN runs the opposite book — long only, no shorts, no leverage, just long different assets. Every launch on the curve is a bet that AI does real work; the treasury makes the same bet, so it compounds with the industry its projects are built on.

The deployment curve manages the long-only risk — governed by the index's own signal. Deployment of fee inflow into the index is a function of the index's own 30-day realized volatility: fully deployed in calm regimes, concave pullback into stablecoin reserves as vol rises. While the index's trailing 28-day drawdown exceeds its trigger, deployment is halved on top of the curve. The deployed asset's own risk governs its sizing — never a proxy asset's. In weak-liquidity, drawdown regimes the treasury holds cash instead of buying into weakness; when vol settles, reserves redeploy. Parameters (vol floor, ceiling, minimum deployment, drawdown trigger) are published; the live curve is interactive on the Index page.

In volatile markets, the index is what keeps a bid under the root token. Drawdowns are the root token's worst hour: fee revenue collapses with volume, so a purely fee-funded buyback goes silent exactly when sentiment is selling. The index inverts that. Its yield keeps root buybacks funded through the drawdown, independent of trading activity. The throttle's pullback doubles as accumulation — inflow parked in stablecoin during high-vol regimes is dry powder building on the liquid-reserves allocation, so the treasury enters the worst markets with a growing cash position for buybacks and floor defense. And the index's assets remain part of the redeemable NAV behind the floor, so panic selling of the root has a hard stop at redemption value. Buyback pressure and floor coverage are relatively strongest at exactly the point where fee-velocity platforms historically died.

Market hours are handled explicitly. Tokenized equities carry reference prices that freeze on nights, weekends, and halts while curves trade continuously. While a reference price is stale, NAV-floor redemptions pause and floor-adjacent quotes widen — curve trading never pauses. Over closures, floor coverage is computed against a volatility-buffered value of the equity sleeve, not a raw last close, and the coverage ratio is published every epoch. A wrapper that depegs from its reference on its own venue, or whose issuer freezes transfers, moves its pair to restricted: no new launches against it, existing curves unaffected, treasury marks that sleeve conservatively.

A dedicated slice of the treasury funds non-dilutive builder grants — no equity, no token dilution, no revenue-share obligation attached. Because they're funded from the treasury allocation rather than trading activity, grants can be paid even in a quiet market — exactly when a real builder needs non-speculative support most.

The verification gate is a real cost — it takes work to prove real usage. The payoff for clearing it is stacked, and each piece answers a different objection a skeptical builder would raise:

Team lockups are a platform floor, not a courtesy. A default launch allows a team allocation — it's a standard launch parameter, not an exception. The condition: any team or insider allocation, at the root level or on any leaf project, must lock a minimum of 20% for a vesting period, enforced at the contract level. No admin key can shorten it.

Five subsystems. Two fork proven live launch infrastructure; three are new builds where the differentiation actually lives.

Creator → [Launch Engine] → Leaf Token (bonding curve) → Graduation → locked AMM pool
                                          │
                               [Fee Router: launch/trade fees]
                                          │
              ┌───────────────────────────┴───────────────────────────┐
    [Holder Fee-Share Pool]                              [Root Buyback Engine]
     per leaf token, paid in                              protocol-wide, funds
     the token's pairing asset                            NAV floor + root burns
              ▲                                                       ▲
              └────────── [Scoring / Attestation Oracle] ─────────────┘
                             gates eligibility for both
                                          ▲
                   client-system webhooks + independent re-fetch
                (helpdesk, CRM, GitHub/CI, brokerage, payments)

Both burns are atomic, by design. The launch burn executes as a sub-call inside createLaunch() — never a separate transaction, which would reopen a front-running/griefing window. Same rule for the validator burns inside stakeAndRegister() (ROOT stake pull + ROOT burn + validator flag) and registerForProject() (ROOT burn + per-project flag): each succeeds or reverts as a unit. Holding or trading a token never triggers a burn — "holds tokens" and "is a registered backer" are tracked as distinct states everywhere in the reward logic.

Section 04 gives the shape; this is the exact per-epoch computation. Attestation adapters — one per category (support, sales, dev, trading, content, compute) — translate client-system events into signed, standardized payloads. Validators independently re-fetch the source data via a secondary API pull (never just trusting the pushed webhook) and co-sign. Components that fail reconciliation are zeroed before the pipeline runs.

# 1. Winsorized cohort normalization — clip to cohort p5/p95, scale to [0,1]
q5, q95 = percentile(cohort_features[:, i], [5, 95])
f[i]    = (clip(x[i], q5, q95) - q5) / (q95 - q5 + EPS)

# 2. Published, version-pinned weight vector (sums to 1)
raw = Σ weight[i]·f[i]  −  Σ penalty[p]·f[p]
#   e.g. agents: 0.34·resolvedWork + 0.24·qualitySignal
#              + 0.18·benchmarkRelative + 0.16·throughputTrend
#              − 0.08·disputeRate

# 3. Eligibility gate — hard floor, no partial credit
if output < MIN_OUTPUT or age < MIN_EPOCHS or unverified: raw = 0

# 4. Temporal EMA — sustaining a score requires sustaining verified output
score_t = α·raw + (1−α)·score_prev            # α ≈ 0.4

# 5. Bounded-influence cap — no project exceeds ~15% of epoch mass
score_t = min(score_t, CAP · Σ all_scores_t)

# 6. Fixed-point conversion for on-chain use
score_wad = round(score_t · 1e18)

On-chain commitment. The chain holds the part that matters: the commitment. Scoring computes off-chain by necessity — re-fetching a helpdesk's tickets or an inference host's metering logs isn't something the EVM can do — and by design: the same division of labor rollups use, heavy computation where it's cheap, settlement where tampering is impossible. Each epoch builds a Merkle tree over (project, score) leaves, signs the root (EIP-712), and submits it to the attestation registry, which checks exactly three invariants: valid signature, strictly increasing epoch, non-expired root. From that moment the scores are immutable and load-bearing — every payout reads them through the registry, and any consumer verifies any single score with a Merkle proof in O(1) gas regardless of cohort size. Signer trust hardens in stages — single signer → m-of-n committee → staked attesters slashable when a signed root contradicts re-fetched data — and the read interface never changes across stages.

Hard exclusion, enforced in review. score() never accepts token price, volume, holder count, or liquidity depth as an input at any stage. A future change adding one of these is a spec violation, not a tuning choice.

individual_share = √(individual_stake) / Σ √(all_stakes_in_pool)

# threshold skim on outsized positions:
if individual_stake > pool_percentile(P90):
    skim = individual_reward · skim_rate
    → redistributed pro-rata to positions below the threshold
    → a portion feeds the root buyback engine ("the Coffer")

One reward shape everywhere a pool is split between backers (the validator pool of each token uses √stake weighting, multiplied by the quality of the validator's thesis). A large backer of a strong project still earns more in absolute terms; the curve only compresses yield-per-dollar toward smaller positions. The concavity exponent is a published, tunable parameter (√ = k 0.5 baseline).

Other emissions-based networks conflate two roles into one word, “validator”: the entity that scores quality and the entity that registers stake to participate. EDEN deliberately splits them. Scoring is done by the oracle layer against external ground truth (§04, §15) — validators there re-fetch source data and co-sign attestations, and are slashable if a signed root contradicts reality. Backing is separate: anyone who wants to actively back a specific project — beyond passively holding or trading its token — registers a validating stake.

Registration is two burns, one stake: the wallet first becomes a validator globally — 2,500 ROOT staked and $100 of ROOT burned inside stakeAndRegister() — then, per project, burns $100 of ROOT per project (oracle-priced; the project's own token is never touched) inside registerForProject() (§14) to become its validating staker. Unstaking the ROOT drops every project registration at once. Burns are conviction filters, never refunded, and never a tax on speculation — passive trading requires neither. The ROOT stake is the position the concave share is computed over (§16): it sizes the payout, while the burns buy eligibility only. A registered backer is never a scorer — the oracle has already decided, from outside data, whether the project is real; the backer is registering capital behind that verdict.

The consequence chain is direct: a validator's payout comes only from the fees of the token it scored, through $V_{j,c}$. If the project trades, its lane fills and its validators are paid in its pair asset; if it goes quiet, there is nothing to pay. Backing a dead project costs the burn and pays zero.

sources: LaunchFee | TradingFee | TreasuryYield
# TreasuryYield accrues on a keeper schedule, independent of
# user activity — the always-on fuel source

protocol_cut   = amount · protocol_bps[source]
holder_cut     = amount · holder_bps[launchId]   # once the score is in a FINAL root
grants_cut     = amount · grants_bps[source]     # treasury grants program
buyback_cut    = remainder                       # → that token's ROOT lane

→ FeeEscrow.credit(protocol, protocol_cut)
→ HolderDistributor[launchId].credit(holder_cut)   # concave push
→ grants sink.credit(grants_cut)
→ RootBuybackVault.credit(buyback_cut)             # 50 % scorers (quote asset) / 25 % ROOT LP / 25 % ROOT burn

Never taken: a cut of a project's own revenue. A hard boundary, not a policy: it would tax the exact business value the verification gate exists to reward, and a fee computed as a percentage of a specific business's revenue reads materially closer to a revenue-share arrangement than a fee on protocol activity. Projects are rewarded through their own creator fee ramp and treasury grants — never from a cut of their own revenue. The platform monetizes launching and trading, not the work itself.

The treasury module is isolated on purpose — separate deployment, separate audit track, independently shippable. Bugs in an AP redemption path have reserve-asset implications nothing else in the system has, so the core launch engine must remain fully functional if that module ships later. Retail paths and the AP path never share a function: redeem() is callable only by the allowlist (§08), and no UI path suggests otherwise. There is no create() — the module has no path that mints root against the reserve, at any price, for anyone.

Buybacks execute on a schedule, not continuously — a keeper triggers the burn on a fixed cadence, every burn emits an indexed event, and the public ticker sums launch burns, validation burns, and buyback burns as distinct categories over one shared supply.

Every mechanism above was re-reviewed adversarially — assume every actor is rational and hostile, find the cheapest attack, then either price it or close it. Remediations came out of that pass; each is specified in full in the hardening spec. The load-bearing ones:

• —Nothing here is an offer or solicitation to buy or sell any security or other financial instrument, and nothing here is investment, legal, accounting, or tax advice.
• —Holder distributions are protocol fee routing, not dividends. They are a share of trading fees the protocol generates, not a claim on any company's revenue, profits, or assets. The protocol deliberately takes no cut of any project's real-world business revenue.
• —Utility framing by layer: compute- and model-layer tokens are access/utility instruments — staking confers queue priority and subsidized access, not an earnings claim.
• —Tokenized equities are restricted assets. They are eligible pairing and reserve assets only where and as permitted. Retail users never redeem against the reserve directly — that function is limited to whitelisted authorized participants, and it runs one way only: redemption, never creation.
• —The v1 score oracle is a single signer. Each epoch's score root is signed by one Eden key and then sits through a bonded challenge window before anything reads it. Moving to an m-of-n committee and staked attesters is planned, not live.
• —“Verified” is a manual review by Eden and a display flag only. It never changes a score, holder routing or validator payouts; its one economic effect is the creator floor — a verified project starts at 30 % of fees instead of 10 % (LAUNCH_NUMBERS 2D.6). It does not expire; Eden revokes it manually.
• —ROOT supply is fixed at 1,000,000,000. Genesis mints it once and renounces the minter in the same broadcast, so nobody — not Eden, not the Safe — can mint more; burns only reduce it (LAUNCH_NUMBERS 7.12). ROOT's genesis split: LP seed 15 % · Treasury 30 % · Team 20 % (3-month cliff, then 16 equal quarterly releases to month 48) · Incubation (Eden incubation multisig) 20 % · Community incentives 15 %. There is no emissions allocation.
• —Creators may hold up to 80 % of their own token. The bonding curve (phantom : threshold = 1.25 : 5) sells exactly 80 % of supply; a creator who buys the whole curve through the dev-buy ends up holding that 80 %. Check the creator's locked and liquid balances on the token page before you buy.
• —No guarantees. Tokens can lose all value. Floors, scores, creator fee shares, validator payouts, grants, and distributions are protocol design targets, can change, and may be zero. Transactions are signed by your own wallet and may be irreversible. The platform takes no custody at any point.
• —Certain features are under active design review — including authorized-participant structure, distribution framing and multi-asset pairing scope — and are presented here as proposed mechanics under consideration, not final commitments.