The ecosystem

FRODO is designed to turn creator fees and inference revenue into compute. Long's launch flow sends trading fees from the token to one receiver. What that receiver does next is project operations, not an automatic protocol split.

Read the chips. LIVE is in the shipped code and traceable to a line. DESIGNED is specified and not built. PLANNED is direction with no spec yet. Two of the five gates below are live. The rest is the programme, honestly labelled.

#The loop

Where the fee goes at launch PLANNED — Long's creation flow selects one fee receiver. It does not publish a guaranteed fee percentage or a built-in holder split. FRODO can direct received fees to compute, but that is project operation after receipt.

Where inference revenue goes DESIGNED — split between buying the next tranche of GPU hours and buying back $FRODO to burn. More usage means more burn and more capacity at the same time, which is the only reason the two halves of this are in the same document.

#Disclosure, and it matters

Long's fee receiver is one destination. It is not an automatic holder distribution. The deployed contracts must confirm the rate and split; any later routing by this project must be implemented and disclosed separately. Nothing here promises income.

#The gates

Access opens in stages. What each stage opens is settled; the market cap that triggers it is not published here. The thresholds live in public/token-config.json, the meter on the site reads them from there, and nothing past the key mint has been announced at all.

The first two rows are not aspirational — they are enforced. unlockReached (unlock.js:19-39) re-derives the mint gate from chain state on every single mint, and there is no HTTP override. A client that simply claims the gate has passed is not evidence of anything.

_{The mint gate has a dependency that is easy to miss: the launch pairs against ETH, not a USD stablecoin, so a dollar basis must be supplied. Left unset, the meter honestly reports it has no dollar basis rather than inventing one — and no key can be minted. See GO-LIVE.md.}

#What the key is worth

Every key today gets the same ceiling: 20 requests a minute, 500 a day. That is a launch default, and it quietly throws away the whole thesis — a token that buys compute should buy you more compute when you hold more of it.

The design is one sentence: your daily allowance is a function of what your wallet holds, re-read from chain state, and it refreshes every epoch.

Why an allowance and not credits. Prepaid credits make you a customer who has already paid and is now watching a balance drain. An allowance makes you an owner: it refreshes whether you used it or not, it does not dilute as the network grows, and selling your position is the only thing that reduces it. That is a different relationship with the asset, and it is the one the fee flow actually supports.

Where this plugs in DESIGNED — the mint path already proves wallet ownership and reads chain state on every issuance (unlock.js:19-39), and quotas are already counted per key record (keys.js:141-161). A tier is a field on a record we already write, checked against counters that already run. See the build.

_{No thresholds are published here, for the same reason the gate figures are not: announcing a number turns a design into a promise about a market. The shape is the commitment; the arithmetic lands with the launch.}

#Free inference for Robinhood Chain DESIGNED

A protocol on Robinhood Chain has users who need inference and no reason to run a gateway. We have a gateway, an allowlist, and a fee stream that pays for capacity.

The mechanism is the one that already exists: a protocol key is a frodo_sk_ key with a pooled budget instead of a personal one, and the same allowlist, quota and cost clamps apply to it unchanged. Nothing new has to be invented — only funded.

The condition is the whole design. Free inference is paid for by the fee flow, and the fee flow scales with the market. If the market fades, the budgets shrink; if it grows, they grow. Nobody is being paid out of the next buyer, and no promise is made that outlives the thing paying for it.

Everybody winning is the precondition, not the reward.

_{Partner protocols are named by category on purpose. No Robinhood Chain protocol has agreed to anything, and printing real names here would fabricate an endorsement. Pons is the one real name used anywhere in these docs, because the token genuinely launches on it.}

#Compared with OpenRouter

Same protocol. Different economics. Both expose an OpenAI-compatible endpoint and a key, and any editor that takes one takes the other.

If you want the widest catalogue and clean per-token billing, use OpenRouter — that is what it is built for, and this is not a catalogue play. What is different here is who pays. On OpenRouter, access is purchased per user. Here it is endowed by an asset: hold the token, mint a key, and the inference is paid for by the market that made the token worth holding.

That is the only claim on this page, and it is a structural one, not a performance one.

#Next

• Routing — what actually enforces the gates above
• Compute — what the fees buy
• Endpoint catalog — the key, the endpoint, the editors