How It Works

This page follows a dollar through the system: from a trade, into the fee stream, into the reserve, and back out as redeemed machine time.

   Trade on the Uniswap V4 pool (Robinhood Chain, live from block zero)
        |  3.35% trade fee in ETH; 0.35% platform + referral, 3.00% to this project
        v
   Fee hook (accrues our 3.00%) --> FeeRouter.sweep()  <- public, anyone may call
        |                                |
        |          2/3 (2.00% of volume) |  1/3 (1.00% of volume)
        v                                v
   RESERVE (ETH -> USDC, published     TEAM TREASURY
   address + /api/stats)               (funds operations)
        |
        v
   two paths to a holder:
   |- Drip: weekly credits paid from current inflows,
   |  never from the reserve balance itself
   |- Burn-to-runtime: tokens burned to the dead address,
   |  credited as Workbench credits
        |
        v
   Work gets done (jobs, agents, chat). Consumption realizes
   our margin, which flows back into the reserve.

The fee stream#

The token launches through the degen.zone direct launcher on Robinhood Chain. The pool is a Uniswap V4 pool, tradeable from the launch block; there is no bonding curve, no graduation step, and no threshold to reach. The launcher and hook enforce the economics; none of this is our promise:

• 3.35% trade fee on every trade, charged in ETH regardless of direction. 0.30% goes to the platform and 0.05% to referrals; 3.00% of trading volume reaches this project. The rate is written once at launch and can never be changed afterward, by us or by degen.zone. There is no function for it.
• The fee accrues in the launch venue's hook contract. Collection is a public crank: sweep() on our FeeRouter can be called by anyone, with no signature, no API, and no permission from anyone. Whoever calls it, the ETH can only go to the two fixed addresses in the fixed ratio.
• The FeeRouter splits what it collects: two thirds to the reserve, one third to the team treasury (2.00% and 1.00% of trade volume). The split and both addresses are immutable, with no owner, no pause, and no upgrade path. Rounding dust always favors the reserve.
• Fixed supply of 1,000,000,000 tokens, 100% of it placed as pool liquidity in the launch transaction, whose LP position is burned to the dead address in that same transaction. No team allocation is possible, no mint, no freeze, no admin role. This is launcher-enforced, not policy.

One third of the fee stream funds operations. Stated plainly: for every $100 traded, $2 goes to the reserve and $1 pays for running this. That is new relative to the original design, where a team allocation was impossible and operations were unfunded; it is revenue-based rather than dilutive. There is no premine and there are no team tokens; the team's income exists only if the token actually trades. Unlike the earlier plan, this share is fixed in the contract rather than steered by a formula; the trade-off is discussed in The Numbers.

The one declared exception to "no team tokens": a pre-announced dev buy of at most 3% of supply. On this venue it executes inside the launch transaction itself as a real market purchase on the fresh pool, paying the same 3.35% fee as anyone (the venue caps such buys at 20% of supply; our declared cap is 3%). The purchased tokens are locked in an on-chain timelock with a 180-day cliff and 360-day linear release. The lock contract has no revoke, no early exit, and its release function is permissionless: anyone can enforce the schedule.

The reserve#

Trading fees, converted to USDC, accumulate in a published reserve address on Base. The reserve holds stablecoins, deliberately without any yield position, plus a small prepaid working buffer at the model providers. What it holds and why is on The Reserve.

The headline figure is always net backing: reserve minus open liabilities (unclaimed drip, unspent credits), divided by circulating supply. We never quote a gross number as backing.

From reserve to work#

Two paths, both specified in full on Redemption:

1. Drip (hold). Each week, a fraction of that week's inflows, at most 25%, is distributed as Workbench credits to holders above a minimum time-weighted balance. It is paid from inflows only. If inflows are zero, the drip is zero. It can never draw down the reserve balance.
2. Burn-to-runtime (redeem). Burning tokens through the BurnRedeemer contract sends them irrevocably to the dead address and creates an on-chain claim. The claim is credited as Workbench credits at the published rate: current net backing per token, times a coverage-dependent factor between 0.85 and 0.98. Credits are non-transferable, cannot be cashed out, and do not expire.

When credits are spent on jobs, the work is done at published Workbench rates. Our realized margin on that consumption, roughly 10% in the expected v0 mix (ASSUMPTION, to be measured in operation), flows back into the reserve.

The loop, corrected#

The intended loop is: capital trades the token, fees build the reserve, the reserve backs redeemable runtime, runtime does work, useful work attracts demand. Stated that way, one correction is required, and we make it ourselves rather than let a reader find it:

The reserve does not accumulate computing capacity. It accumulates stablecoins. This is deliberate. Prepaid compute would freeze today's providers and today's capability level, and typically expires within 12 months. The amount of redeemable work still grows, for two reasons: inflows grow the reserve, and the cost of a constant capability level in AI inference has been falling by roughly 50 to 200 times per year (Epoch AI data; see the inference economics notes in our research). A dollar next year does not buy more tokens of the same model, because nominal per-model prices are sticky. It buys substantially more capable tokens. Capacity grows because machines get cheaper per unit of capability, not because we stockpile credits.

Two properties, stated precisely#

Both are proven or precisely bounded in The Numbers:

1. Net backing per token is monotonically non-decreasing under all protocol operations. The drip is paid from inflows, never from the reserve balance. Burns reduce supply by more than they add liabilities (the credit factor is at most 1). Consumption realizes margin. Backing per token can fall only through losses on the reserve's assets or operational failure, never through the mechanism itself.
2. The absolute reserve can still shrink. Redemptions are served from it, capped at roughly 1% of the net reserve per day. That is the intended meaning of a redemption: claims are honored, and the remaining holders are left with more backing per token, not less. Both figures, absolute reserve and per-token backing, are published side by side on the reserve page so nobody mistakes one for the other.

Neither property says anything about the market price of the token. The market price is set by the market. See Risks, which treats that distinction as seriously as it deserves.