Scoring and rewards math

How Eden measures a project, commits the result on-chain, and turns it into payouts. Every section starts with what the rule does in plain English; the formula underneath is the precise version, for anyone who wants to check it.

For each stage there is a short argument for why it cannot be gamed and why it is good for honest participants, and an honest note on what it does not prove where that matters.

#1. Notation

WAD arithmetic: all scores, weights and shares are integers scaled by $10^{18}$; divisions round down unless stated otherwise.

#2. The systematic score

In plain English. Once a week, for every live project, Eden checks the numbers it reports against the project's own systems, compares each number with the other projects in the same track, combines them with published weights, drops projects that produce too little, and smooths the result over time. The output is a grade from 0 to 100 that means the same thing for every project, whatever else is in its track.

The pipeline is deterministic: two runs of the same model version over the same verified inputs produce the same Merkle root bit for bit.

#2.1 Verified inputs

In plain English. A number only counts if the project's own system vouches for it, and, where Eden can fetch it independently, the two agree. A number that fails is thrown out and counts against the project.

1. It must carry a valid signed attestation from the registered source key, and
2. where an independent re-fetch exists, the claim must reconcile with it, and the re-fetched value is the one used:

A claim that fails either check is dropped (contributes nothing) and counts against the project:

Token price, trading volume, holder counts and liquidity are never inputs.

What it does not prove. A signature proves who reported a number; a re-fetch proves the source returned it. Neither proves the activity was economically real: a helpdesk can hold tickets a project opened itself, and a payment processor can record payments between related parties. Eden limits this in three ways:

• Forgery-cost tiers. Every metric is tiered by how expensive it is to fake. Money-verified metrics (revenue, settled volume) anchor each track; counterparty-verified metrics are capped at 0.25 each; metrics that only the project's own systems can see are capped at 0.15 combined and can never qualify a project on their own.
• Adapter checks. Each data source has its own reconciliation and anomaly rules (refunds, self-dealing, duplicate work).
• The challenge window. Every published result can be disputed before anything reads it (§3.3).

Treat the score as Eden's verified assessment of real output, not as an audit opinion on the business.

#2.2 Normalisation within the track

In plain English. Each number is compared with the rest of the track and turned into a value from 0 to 1. The top and bottom 5 % are clipped, so one giant (or one faker) can't stretch the scale and flatten everyone else, and inflating a number past the top of the track earns nothing extra. Small tracks, where one project could set the scale by itself, are measured against fixed published ranges instead.

For a cohort of at least $N_{min}=20$ projects, each feature is clipped at its 5th and 95th percentiles and scaled to $[0,1]$. Percentiles are nearest-rank on the sorted cohort column: $P_p=x_{(\lceil pn/100\rceil )}$.

${\underline{r}}_i,{\overline{r}}_i$ are reference bounds: fixed per track and metric, published with the weight vector and pinned to the same model version, so they cannot move during an epoch.

Example. A cohort of 20 agents reports resolved work $\{3,5,6,8,9,10,11,12,12,14,15,16,18,19,20,22,24,25,28,400\}$. Nearest rank gives $P_5=3$ (1st value) and $P_{95}=28$ (19th value). The outlier at 400 is clipped to 28 and scores $1.0$, exactly what 28 scores. A project at 14 scores $(14-3)/25=0.44$.

Why it cannot be gamed. Above the upper bound, more of a metric adds exactly nothing. With $n\ge 20$, the upper bound is at most the second-highest value, so the project at the top can never set its own ceiling; below 20, nobody in the cohort sets the bounds at all. Why it is good. Heavy-tailed metrics become comparable, and one giant cannot push every honest mid-sized project to the bottom of the range. What it does not do. Clipping limits outliers. It does not detect fake data; that is §2.1's job.

#2.3 Weighted score

In plain English. The normalised numbers are combined with published weights that always add up to 1, so a project that tops every metric in its track scores 1. A small deduction is then taken for claims that failed verification.

So ${\text{raw}}_j\in [0,1]$. Each track has its own weight vector, tiered by forgery cost (§2.1). For the agent track:

The penalty is a deduction, not a weight: a project with perfect features and no failed claims scores 1; one with perfect features and every claim failed would score 0.92 before the gate, except that it has no verified features left to score.

Why it cannot be gamed. The weights are public constants pinned to a model version; no participant supplies them and nothing is learned from submissions. A change of weights is a new version and applies only to future epochs. Why it is good. A project can forecast its own score from its own operations.

#2.4 Eligibility gate

In plain English. A project that produced too little this week, or is too new, gets a zero for this week.

$\text{MIN\_RAW}$ is a per-track merit floor (for example $0.02$ for agents and research, $0.10$ for apps); $\text{MIN\_OUTPUT}$ is a floor on absolute verified output.

The gate zeroes this week's input, not the published score. A project that fails the gate keeps 60 % of last week's score and loses another 40 % each further week it fails (§2.5). Every payout reads the published score, so the effect is a fast, predictable fade rather than a cliff: from 100 to 60, 36, 22, 13…

Why it cannot be gamed. The gate reads only verified output. Capital, liquidity and wash volume are not inputs, so they cannot buy a project over the floor. Why it is good. One bad week, a data outage for example, does not wipe out a project that has been delivering for months, while a project that stops delivering loses most of its score within a month.

#2.5 Smoothing over time

In plain English. The published score is 40 % this week and 60 % the past. A single great week can lift a score by at most 40 points; staying at the top takes weeks of sustained output.

where $s_{t-1}(j)$ is the project's published score of the previous epoch ($0$ for a new project). Unrolled, $s_t=\alpha {\sum }_{\tau \ge 0}(1-\alpha {)}^{\tau }g({\text{raw}}_{t-\tau })$: memory of about $1/\alpha =2.5$ epochs. Because every term is in $[0,1]$, so is $s_t$.

Example. A one-epoch spike to $1.0$ followed by zeros publishes $0.40,0.24,0.144,\dots$. A project steadily at $0.6$ climbs $0.24,0.384,0.470,0.522,0.553,0.572\to 0.6$.

Why it cannot be gamed. A manufactured spike earns only $\alpha$ of itself and decays geometrically. Sustaining an inflated score requires sustaining verified output, which is the work itself. Why it is good. Honest projects get a stable score that absorbs normal week-to-week variance.

#2.6 The score is absolute

In plain English. Scores are grades, not shares. There is no fixed pot of score to split, so one project doing well never pushes another down, and every project can reach 100.

Earlier designs turned scores into capped shares of a weekly emission pool. That pool is gone, and so is the share cap: applied to a grade, it would have held every project at 15 or below. What a single project can take is bounded where money actually moves: its creator's share has a fixed ceiling (§7), each scorer is capped at 5 % of a token's reward stream (§5.3), and human scores move a project by at most 20 % (§4.2).

#2.7 Fixed point

Scores feed the creator's fee share (§7), human-score weights (§4) and grant eligibility. There is no protocol-wide emission pool: no score is ever converted into newly issued tokens.

#3. The commitment

In plain English. Every day's scores and thesis grades are sealed into one fingerprint (a Merkle root), signed by Eden, and posted on-chain with a bond. For 72 hours anyone can challenge it. Only after that can any contract read a score, and anyone can check any single score against the fingerprint.

#3.1 Merkle root

Every epoch's scores, thesis-quality grades and pre-data human scores are leaves of one tree. Leaves are double-hashed ABI encodings; pairs are hashed commutatively (sorted), the OpenZeppelin convention:

$T_q$, $T_h$ are fixed domain tags (so a quality or human leaf can never collide with a score leaf), $h_k$ the thesis hash, $v_k$ the originality verdict, $h_k^{match}$ the thesis it matched. The epoch is bound by the root being stored per epoch.

#3.2 Signature

The root is signed with EIP-712 (domain: name, version, chain id, registry address):

$R_{in}$ is a Merkle root over per-project input commitments: for a project whose inputs are private it is a salted hash, so the oracle is bound to a fixed input set without publishing it.

#3.3 On-chain acceptance and the challenge window

The registry accepts a root only if the signature recovers to the authorised signer, the epoch is the next one, the expiry has not passed, and the proposer escrows a bond. The root is then pending for $T_c=72$ h. During that window anyone may challenge it with an equal bond; an adjudicator resolves it (upheld: the bond goes to the challenger and a corrected root may be submitted; rejected: the bond goes to the proposer and a fresh window starts). Only final roots can be read:

Verification costs $O(\log n)$ hashes and no per-project storage.

Why it cannot be gamed. Changing any one leaf changes the root and breaks the signature; replay and reordering fail the epoch check; stale roots fail the expiry check; and a wrong root can be disputed before anything reads it. Why it is good. One signed root a day serves any number of projects, and any third party can check any single score.

#3.4 Trust model

At launch one accountable signer signs, bonded and challengeable. The planned path is an m-of-n signer committee, then staked attesters who can be slashed when a signed root contradicts the re-fetched data. The read interface does not change between stages, so hardening trust never touches the payout path.

#4. Human scores

In plain English. Anyone can become a scorer by staking ROOT, and every score burns ROOT and must come with a written thesis that cites its sources. An AI grader checks the sources really say what the thesis claims. Scores with good theses can move a project's data-driven score by up to 20 % either way. They count most in the ambiguous middle of the scale and not at all at 0 or 100. Before a project has any data, human scores can lift it step by step up to 50.

#4.1 Thesis quality

$G$ is computed by code. $R\in [0,1]$ is the mean of three rubric criteria (relevance, specificity, consistency of the score with the thesis), taken as the median of three model samples; any result at or above $0.8$ is re-graded by an independent verifier and the lower value kept. Copy detection runs in submission order and sets the multiplier $c\in \{1(\text{original}),1(\text{similar}),0.5(\text{derivative}),0(\text{copy})\}$. A thesis that tries to instruct the grader scores $0$. Grades are leaves in the epoch root (§3.1) and an adjudicator can override any grade on-chain; the override wins.

#4.2 Projects with an attested systematic score

With ${\delta }_k$ the move scorer $k$ proposes (their submitted score minus $s_{sys}$), and only theses with $q_k\ge 0.3$ counting:

The normaliser is $\sum q_k{c}_k$, not $\sum w_k$, so the envelope is not divided away: $\Delta =4s_{sys}(1-s_{sys})\times$ the quality-weighted mean of the proposed moves.

Example. $s_{sys}=0.60$, so the envelope is $0.96$. Three scores: $(q,c,\delta )=(0.8,1,+0.10)$, $(0.5,0.5,-0.04)$ and $(0.2,1,+0.30)$. The third is below the quality floor and does not count. $\Delta =0.96\cdot (0.08-0.01)/1.05=0.064$, so $s=0.60\times 1.064=0.638$.

Why it cannot be gamed. $w(0)=w(1)=0$: a systematic zero stays zero and a top score cannot be pushed further. The move is bounded by $\pm \text{BAND}$ of $s_{sys}$ however many wallets submit. Each scorer can submit at most once every 14 days across all projects, every submission burns ROOT, and a copied or ungrounded thesis carries no weight. Why it is good. Human judgment counts most where the data is most ambiguous (the middle of the scale) and not at all where the data is decisive.

#4.3 Projects with no data yet

The score starts at $0$ and the submissions are replayed in order. For each counting submission ($q_k{c}_k>0$) with target $y_k$:

(points on the $0$–$100$ scale). A non-counting submission does not use up the first slot. A project verified by Eden's manual review keeps the same steps with a cap of $100$. The first attested systematic score ends this mode permanently.

Example. Scores of 80 ($q=0.9$), 60 ($q=1$), 10 ($q=0.5$) move the project $0\to 18\to 23\to 20.5$.

#4.4 Adjudicators

Adjudicators can (1) uphold a challenge against a root, (2) override a thesis grade or originality verdict, and (3) set or revoke the manual "Verified" badge. Verified never changes a score; it only lifts the pre-data cap (§4.3) and the creator's starting floor (§7). Adjudicators are never signers.

#5. Scorer rewards

In plain English. Each token's scorers are paid from that token's own fees, in its pair asset (ETH, a stablecoin or the stock it trades against), never in ROOT. Rewards stream every second for 30 days after a score and can be withdrawn any time. Every scorer stakes the same amount, so pay is set by the quality of the thesis. No scorer can take more than 5 % of a token's stream. Anything not paid out is used to buy ROOT and burn it.

#5.1 Funding and the drip

A share ${\varphi }_{scorer}$ of each fee on token $j$ funds that token's pool. Each funding $a$ is released linearly over $d=7$ days. With $U$ the undripped balance and $T_f$ the end of the current drip:

So a large fee spike cannot be captured by whoever scores that afternoon.

#5.2 Positions and weight

A score opens a position that starts earning when its quality grade is proven on-chain against a final root, and ends at

A re-score replaces the position (new grade, new window); a request to unstake ends every position of the scorer in the same transaction. One open position per scorer per token. The weight is

Every scorer stakes the same $\sigma =2,500$ ROOT; there is no top-up. $\sqrt{\sigma }$ is therefore a common constant, and only ratios matter, so a scorer's share is set by thesis quality alone: ${\omega }_k/W=q_k^{\text{eff}}/{\sum }_m{q}_m^{\text{eff}}$. The contract keeps the $\sqrt{\text{stake}}$ form so a variable stake could be introduced later through governance without changing the accumulator; at launch it has no effect.

#5.3 The cap and the conservative denominator

Let $W={\sum }_k{\omega }_k$ over earning positions and ${\omega }_{max}={\max }_k{\omega }_k$. Exact per-scorer capping of a shared stream is non-linear, so the contract divides by

Since $D\ge W$ and $D\ge {\omega }_{max}/c\ge {\omega }_k/c$:

No scorer ever exceeds the cap and the pool is never overpaid. It is exact when the cap does not bind, exact for the heaviest scorer when it does, and exact for equal weights; lighter scorers in a capped pool earn $c{\omega }_k/{\omega }_{max}$ — less than an exact water-filling would pay. That is the documented price of a constant-gas accumulator. ${\omega }_{max}$ is tracked in logarithmic weight classes ($2^{1/1024}$ wide) and can only be stale on the high side, which lowers payouts, never raises them.

Example. Three scorers with theses graded $q=0.8$, $0.6$ and $0.9$ (all stake 2,500 ROOT, so $\sqrt{\sigma }=50$): $\omega =40,30,45$, $W=115$, ${\omega }_{max}/c=900=D$. The best thesis earns $45/900=5\%$ of the pool rate, the others $4.44\%$ and $3.33\%$; $12.8\%$ is paid and the rest is burned. An exact capped split would pay all three the full 5 % ($15\%$ in total). With 20 or more scorers of equal quality, $W\ge {\omega }_{max}/c$ and the whole stream is paid; with fewer, some of every drip always burns.

What the cap is, and is not. It guarantees no scorer ever takes more than 5 % and the pool is never overpaid. It is not an exact proportional split: in a thin pool, lighter scorers are paid less than an exact capped allocation would give them, and the remainder is burned. That is the price of paying everyone in constant gas per transaction.

#5.4 Accumulator

Every event that changes $W$ or $D$ (a proof, an expiry, a re-score, an unstake, a cap change) first advances the token to that instant, so $W$ and $D$ are constant on every segment $[t_0,t_1)$. Per segment and pair asset, with $\text{ACC}=10^{18}$:

(with no earning weight the whole $R$ is returned). Scorer $k$ is owed $\lfloor {\omega }_k(A-A_k^{snap})/\text{ACC}\rfloor$ for the time its weight was in $W$.

#5.5 Unearned rewards and solvency

Everything not paid — cap excess, positions below the quality floor, time with no earning scorer, rounding — is returned in the pair asset to the ROOT buyback, bought as ROOT and burned. Per token and pair asset the contract keeps

which is checked by a fuzzed invariant test.

Why it cannot be gamed. A lump of fees is dripped, so nobody can time a big sweep. A scorer's share is capped. Payouts go only to the scorer's own wallet. Running several wallets is covered in §6.1. Why it is good. Scorers are paid for the effort and evidence of a thesis, in a real asset, continuously; there is no ROOT reward to dump.

#6. The per-score burn and the ROOT price

In plain English. Every score burns $100 of ROOT, and becoming a scorer costs a 2,500 ROOT stake plus a one-time $100 burn. The ROOT price for these burns is read from ROOT's own trading pool, averaged over time, and multiplied by Chainlink's ETH/USD price. No Eden key posts a price.

#6.1 Running several wallets

Because every scorer stakes the same amount and weight is set by thesis quality, splitting a stake across wallets is not possible: each wallet needs its own full 2,500 ROOT stake. The question is whether one person running $m$ separately staked wallets on the same token can earn more than they spend. Each extra wallet:

1. locks another 2,500 ROOT for as long as it scores, returned only after a 7-day cooldown;
2. burns $100 of ROOT once to register and $100 on every score and re-score;
3. must submit its own thesis, which is graded independently. Copies of an earlier thesis earn nothing, derivative work earns half, and a thesis below quality 0.3 earns nothing;
4. may score only once every 14 days, across all projects;
5. earns at most 5 % of the token's stream.

So $m$ wallets earn at most $\min (m\cdot 5\%,\text{their quality share})$ of one token's stream, and each one has to pay for itself: a wallet whose expected 30-day reward on a token is below the $100 burn loses money on every score. On a thin token that is most wallets; on a busy token it is profitable only for wallets that write genuinely original, well-sourced theses, which is the work the reward exists to pay for.

What is not claimed. This makes extra wallets expensive and caps their share; it does not make them impossible. Eden does not verify scorer identities.

Planned: a burn that scales with reward. The registry can also charge $B_j^{usd}=\max (\$100,\lceil 0.415\cdot {\hat{R}}_j\rceil )$ per score, where ${\hat{R}}_j$ is a per-token reward estimate published by governance. At launch no estimate is published, so every score burns a flat $100; the scaling floor is for tokens whose rewards grow large.

#6.2 Price

The burn is charged in ROOT at a keeper-free price read from ROOT's own pool:

The mean tick is rounded toward the lower ROOT price; the pool hook truncates each recorded tick move to 9,116 ticks per elapsed second; the anchor window shortens to the pool's age when it is younger than 4 h. The price fails closed (no burn, no score) when Chainlink is older than 25 h, the window is not covered, or the amount is out of bounds.

Why the minimum. A lower ROOT price burns more ROOT and raises the buyback's minimum-out floor, so the minimum of the two windows is the protocol-favourable side for every consumer. Pushing the price up to make burns cheaper must be held for hours to move the 4-hour anchor; pushing it down only makes the payer's own transaction revert against their cap.

#7. Creator share — the score ramp

In plain English. A creator's share of their token's fees starts at a floor and rises in a straight line with the score, reaching the ceiling at 100. It follows every newly published score (daily) and moves both ways. Whatever the creator has not earned goes to the other lanes.

The creator's share of their token's fee is linear in the latest final score $S\in [0,100]$:

$f_{backed}$, $f_{unverified}$ and the ceiling $\bar{c}$ are published in Tokenomics. The share is recomputed each epoch and moves both ways; there is no grace period and no decay clock. The unearned part $(\bar{c}-\text{creator}(S))$ is redirected to the other lanes, never kept. Of the creator's payout, a fixed share ${\varphi }_{LP}$ becomes permanently locked liquidity (§9) and a launch-time share goes to the creator's own token buyback.

#8. Holder payouts

In plain English. Every day holders are paid in proportion to their balance at a fixed past block. Buying after the snapshot earns nothing for that day. Claims open 24 hours later and stay open for 90 days.

Each epoch, for token $j$ and pair asset $a$, balances are snapshotted at a past block $b$, excluding pool, curve, locker, hook, escrows, vesting locks, vaults, the distributor, $0x0$ and $0x\text{dEaD}$. With $T$ the amount allocated from the holder pot ($\le$ available):

The root is claimable after a 24-hour review delay and for 90 days; a leaf pays once, only to its account (or a recipient that account signs for). After 90 days the unclaimed remainder rolls into the next round.

Why it cannot be gamed. A buy after the snapshot, or a transfer to a fresh wallet, earns nothing for that epoch; the leaf is bound to this distributor, chain, token, asset and epoch. Why it is good. Holders are paid in a real asset whatever the project's score; the holder lane is never throttled.

#9. Bonding curve, graduation and liquidity growth

In plain English. Every launch sells 80 % of its supply on a curve whose price rises with each buy, then moves to a Uniswap pool at exactly the curve's last price, with liquidity that can never be withdrawn. The full walkthrough is on Bonding curve and Graduation.

#9.1 Curve

A constant-product curve with a virtual quote reserve $\Phi$ that is never held. With total supply $S$, real quote raised $Q$ and token reserve $Y$:

($\tau$ is the trading fee, taken from the quote leg before the swap; ${\tau }_{snipe}(t)=0.99\cdot \max (0,1-t/15\text{s})$ is the opening anti-snipe tax, decaying linearly to 0 over the first 15 s). Graduation happens at exactly $Q=G$; the crossing buy is clamped to the sellable remainder and the excess refunded. Eden uses $G=4\Phi$ for every pair (1.25 ETH : 5 ETH, or $3,125 : $12,500):

#9.2 Graduation

The Uniswap v4 pool is seeded at the curve's last price with the quote raised and the matching token amount, ${\sqrt{P}}_{X96}=\sqrt{{\text{amount}}_1/{\text{amount}}_0}\cdot 2^{96}$:

The position and the remaining 4 % are locked forever. Every launch on a given pair graduates with the same amounts and the same opening price.

#9.3 Liquidity growth

A share ${\varphi }_{LP}$ of each creator payout is held for the token's pool (escrowed on the curve, added at graduation). Each sweep spends half the accrued quote buying the token in its own pool and adds both legs as a new full-range position owned by the launch locker — it can grow, never be withdrawn. Half of the ROOT bought by the buyback is treated the same way in ROOT's own pool (sell half for ETH, add both legs, locked in the genesis liquidity contract); the other half is burned.

#10. What changed from the earlier math

#11. Where it runs

Parameter values are the mainnet launch configuration. Values marked as published by governance change only through the 48-hour timelock. Nothing here is investment advice.