Fee-to-compute: can an agent pay its own inference bill?

Direct answer Fee-to-compute is the idea that an agent's trading fees should pay its own inference bill — the agent as a small company that covers its costs. It is the most economically coherent story in this sector, and it is a cycle we can only partly walk, because walking it requires knowing which addresses belong to the runtime and no operator has published that set. This page renders the gap rather than filling it.

A hosted agent runtime tries to be the place the agent lives: a wallet, a compute bill, and distribution in one product. The pitch that makes it more than hosting is the loop — the agent trades or sells something, fees accrue to a recipient, and that recipient pays for the inference the agent needs to keep working.

If that loop closes, an agent is a business. If it does not, an agent is a subsidised demo. That is a real, checkable distinction, and it is exactly the kind of thing a public ledger should be able to settle.

The loop, as a graph

Wallet        --PAYS-->        DEX / router        (a fee is generated)
              <--COLLECTS_FEE--  feeRecipient
feeRecipient  --PAYS-->        Seller              (inference, hosted API, x402)

Four node types — Agent, Wallet, FeeRecipient, Seller — and three edges. Our graph already models every one of them; nothing new needs to be invented to hold this. The object model →

The view, no longer empty

This block sat blank for months with the blocker printed underneath it. On 12 September 2026 the operator answered the question in public and pointed at its own launch registry. The registry needs no key, and every row in it names a fee recipient. Here is what walking it produces.

The launches · read from the operator's own registry

Launches indexed—

Of those, on Base—

Distinct fee recipients—

Distinct deployers—

Fee recipients with more than one launch—

Definitions: bankr.launches.v1, bankr.recipients.v1, bankr.deployers.v1

As of —. Full document at /api/partners.

The fee side · their numbers, cited not measured

Launches asked about—

Of those, with any fee record—

With no fee record at all—

Share of asked launches with a fee record—

… on Base—

… on Robinhood Chain—

Lifetime fees — their figure—

Creator share — their figure—

Platform share — their figure—

Definitions: bankr.withfees.v1, bankr.feerate.v1, bankr.totalfees.v1, bankr.creatorfees.v1, bankr.platformfees.v1

Most launches never earn a fee at all. Most tokens with no fee record genuinely earned nothing — but not all. Bankr’s batch endpoint sometimes leaves out a token that its own per-token endpoint shows did earn, on both chains and for new and older launches alike. So the counts and totals on this page are under-counts, and we re-measure how often that happens, by chain and by launch age, on every run rather than trusting one test. The share also varies several-fold between launch weeks, so read it as a description of the window we have indexed, not a property of Bankr launches. Correction, 14 September 2026: this paragraph previously called the rate a floor, on the theory that a newest-first walk skews young. Older launches turned out to earn fees less often, not more, and that claim is withdrawn. A version live briefly the same day also called the missing records a Robinhood-only problem; checking both chains across launch ages showed it is not. Fees are also extremely concentrated — a single token has accounted for roughly a third of everything cited here — so the total is not a typical launch multiplied by a count, and an average across this set would describe no real launch.

Those three dollar figures are the operator's own computation, read from the operator's own endpoint. We did not reproduce the fee accounting from chain data, so we do not present them as ours. Every one of them carries _cited in its metric name so the label travels with the number when somebody quotes it. Measured, cited, live — what each word means here →

The compute side · ours, and the only half nobody else can check

Fee recipients on Base—

… bound to an identity in this graph—

… that are themselves named sellers—

… observed paying anyone at all—

Payments to a named compute seller—

Wallets our payment scan covers—

Definitions: bankr.payingrecipients.v1, bankr.tosellers.v1, bankr.bound.v1

What the zeroes mean, and what they do not

The two populations do not intersect. Not one fee recipient on Base is a wallet bound to a registered agent identity in this graph, appears in our named-seller set, or has been paid for work on the job rail. That overlap is zero, and it is the finding: the token-launch economy and the registered-agent economy are, at this moment, separate economies.

A zero in the paying rows means unmeasured, not disproven. Our payment scan follows wallets bound to identities in this graph — the last row above is its exact width — and a fee recipient outside that set cannot appear as a payer no matter what it does with its money. Reading those rows as "fee recipients never buy compute" would be the same species of error as the near-miss below: a number that is technically correct and rhetorically false. The loop is not closed here, and it is not broken either. It is not yet observable, and the honest thing is to publish the width of the window alongside what we saw through it.

The thing that would change this is not a better query. It is a fee recipient registering an identity, or a named seller taking a payment from one. The day that happens, these rows move on their own.

The near-miss that set this rule

We were close to publishing tens of thousands of token launches attributed to a named runtime. The trail was convincing: one launch controller, one address taking a cut of every single launch, a hit rate of 100%.

A 100% hit rate is not a fingerprint. It is a definition restating itself. Both addresses belonged to the underlying launch protocol, which lists that runtime as one integrator among several — so what we had actually measured was “launches that went through the launcher,” dressed up as a claim about one company.

Nothing about that error would have been visible to a reader. The number would have been large, specific, and wrong, and it would have been quoted back at us for a year. It is the reason a volume claim stays a dated quote here until a wallet set exists. Every claim we make, with its addresses →

How a runtime's numbers are treated until then

A volume claim is a quote with a date on it, attributed to whoever made it, never rendered as a measured tile.
Public on-chain data and public documentation only. No private endpoints, no write keys, no credentials of any kind in the graph.
An integrator is not an operator. Activity through a shared protocol is not attributable to one of its integrators without an address set.
Launches are not agents. Most of what any launch layer produces is neither an agent nor a business, and we count it as neither.

What the set does and does not buy us

Having the registry settles attribution. It does not settle everything the empty state was waiting on, and it is worth being precise about which half moved.

Settled: which launches are theirs. Read from their registry, not inferred from a fingerprint they themselves declined to vouch for.
Settled: the fee side, as a citation. Their endpoint computes it, we read and attribute it.
Still open: the platform volume quote. A registry of launches is not an address set for the platform's trading volume. That claim stays a dated quote. Every claim we make, with its addresses →
Still open: the loop itself. It needs a fee recipient inside our payment scan. None is, yet.
Deliberately absent: market cap and 24h volume. The same rows carry both and we store neither. A token's market cap is a crowd's opinion, never capital at work.
Unchanged: none of this touches our own totals. No launch becomes an actor, no fee becomes spending. This page adds nothing to the site's headline. What does count, and at which level →

The other shape: self-custody and a human gate

Not every runtime wants to hold the key. The opposite institutional shape signs locally, keeps the key off the provider's infrastructure entirely, and puts an approval gate in front of spending.

Our schema models that as a policy of kind human_gate, sitting beside EIP-7702 delegation rather than inside it. It is a different answer to the same question — who can move this money, and under what constraint — and a graph that only understood delegated keys would be unable to see it at all. The delegation half →

Questions people actually ask

What does fee-to-compute mean?

It is the idea that an agent's trading or product fees should pay its own inference bill, making the agent a small business that covers its costs rather than a subsidised demo. As a graph it is a cycle: a wallet pays a router and generates a fee, a fee recipient collects it, and that recipient pays a compute seller. If the cycle closes, the economics are real.

Why do you not publish agent runtime trading volumes?

Because attributing volume to a named operator requires knowing which addresses belong to them, and no public constituent address set exists. We do not scrape private APIs, we hold no write keys, and we will not guess at addresses. Until a set is published, a volume claim stays a dated quote attributed to whoever made it, never a measured tile.

What was the attribution near-miss?

We were close to publishing tens of thousands of token launches attributed to one named runtime. The evidence looked strong — one launch controller, one address taking a cut of every launch, a 100% hit rate. But a 100% hit rate is a definition restating itself: both addresses belonged to the underlying launch protocol, which lists that runtime as just one integrator. We had measured the launcher, not the company.

Does the fee-to-compute loop close?

Not yet, and the honest answer is that it is unmeasured rather than disproven. We have the operator's own launch registry and their own fee figures, so the income half is covered. The compute half needs a fee recipient that our payment scan can see, and our payment scan follows wallets bound to identities in this graph. Right now not one Bankr fee recipient on Base is such a wallet. The overlap between the two populations is zero — which is itself a real finding about how separate the token-launch economy and the registered-agent economy currently are — but it means a payment a fee recipient made would be invisible to us either way. We publish the width of our scan next to the zero so nobody reads it as the stronger claim.

Are the fee dollar figures yours or Bankr's?

Bankr's. They come from an unauthenticated endpoint the operator publishes, which computes total, platform and creator fees per token. We read it, attribute it, and carry a _cited suffix in the metric name so the attribution travels with the number if it gets quoted somewhere else. We did not reproduce the fee accounting from chain data, so calling it measured would be a lie of one word.

Why use their registry instead of an on-chain fingerprint?

Because they told us the fingerprint was not safe, and they were right. Asked whether a Uniswap v4 hook, a beneficiary address and a token-address suffix would identify their launches, Bankr said they could not confirm it gives a clean match with no false positives from other integrators of the same launch protocol. That is precisely the error we nearly published ourselves. A registry the operator maintains needs no inference at all.

What would a loop ratio above one mean?

That more is being spent on compute than the fees we could observe. It does not mean the model is broken — it means our view of the income side is incomplete, or there is other revenue we cannot see. The honest name for it is unexplained spend, and it is a measurement problem before it is anything else.

How do you model a runtime that never holds the key?

As a policy of kind human_gate, sitting beside EIP-7702 delegation rather than inside it. Some runtimes sign locally, keep the key off the provider's infrastructure and put an approval gate in front of spending. That is a different answer to the same question of who can move money and under what constraint, and a graph that only understood delegated keys would not be able to see it at all.

An agent that pays its own bills is a business. Now we can check.