Fuelbot Fuelbot: metered autonomous agents funded by trading fees
A design for an AI agent whose only budget is the creator fees its token generates, with every unit of work receipted and every unit of value accounted for.
Abstract
Fuelbot is an autonomous software agent whose entire compute budget comes from the creator fees of its token, $FUELBOT. A component called the Meter turns incoming fees into a spendable budget, prices every model call as it happens, and halts the agent when the budget runs out. Every unit of work produces a commit and a receipt. From Phase 02, every fee received and every lamport spent is recorded in a hash-chained ledger that anyone can verify from a browser. This paper describes the design, the safety model, the role of the token, the roadmap and the risks.
01Motivation
Tokens are attention markets. Most sell a roadmap of future utility that rarely ships, and most "AI agent" tokens produce little beyond social posts, with treasuries that holders cannot inspect.
Creator fees changed the raw material. On launchpads such as pump.fun, every trade pays a small fee to the token's creator: a continuous, on-chain revenue stream tied directly to trading activity. The 2026 wave of fee-routing platforms showed real demand for giving those fees a visible purpose.
Fuelbot's thesis: bind an agent's work directly, and verifiably, to the fees its token generates. No volume, no compute. Volume becomes visible work: commits, receipts and a ledger anyone can audit.
02System overview
The system has four parts: the fee wallet (a public address that receives creator fees), the Meter (accounting and limits), the Agent (a language model with a minimal tool set, working inside a sandboxed repository) and the receipts (the public record of work and cost). A read-only dashboard exposes all of it.
03The Meter
The Meter guarantees one invariant: the agent can never spend more than its token has earned.
cost(call) = (tokensin · pin + tokensout · pout) / PSOL
| Parameter | Meaning |
|---|---|
r | Spend ratio: the share of fees that may become compute. Published at launch. |
min_task | Sleep threshold. Below it the agent does not start a task. |
max_task | Hard cap per task, whatever the balance. |
PSOL | SOL/USD from the most liquid SOL/stablecoin pair, cached for up to five minutes. Without a price, nothing runs. |
Controls
- Pre-call estimate. Before each model call the Meter projects its cost (at least 1.3× the previous call, since context only grows) and stops if the task cap would be exceeded.
- Cumulative accounting. A task stopped by its cap keeps its partial work and is retried up to three times; every attempt's cost stays on the books.
- Fee detection. Inflows to the fee wallet after the start time are read from chain; each inflow's transaction signature is its receipt. Funds that were in the wallet before launch never count as fees.
04The Agent
The agent is a language model in a loop with exactly five tools: list_files, read_file, write_file, delete_file and finish. It takes the next task from a public queue, works on it, and calls finish with a summary and a commit message.
Sandbox
- All file access is confined to one git repository. Absolute paths,
.., symbolic links and the.gitdirectory are refused. - Nothing the agent writes is executed on the host. Git runs with fixed arguments and no shell.
- The agent never holds keys and cannot move funds; the fee wallet is read by its public address only.
Output
Each finished task yields a commit, a public summary, token counts, cost in SOL and USD, and a post draft for X. A turn limit and the Meter bound every run.
05Receipts & the Ledger
Receipts describe work. The ledger makes the accounting tamper-evident: every fee in and every compute spend becomes an entry that commits to the one before it.
hn = SHA-256( hn−1 ‖ "\n" ‖ en ), h0 = 064
Verification needs only the public entries: start from h0, recompute each hash, compare it with the published one, and check that balances add up. The dashboard will ship a one-click in-browser verifier. Periodically anchoring the head hash on-chain is under research.
06Token & fee flow
- $FUELBOT launches on Solana via pump.fun. Its creator fees are Fuelbot's only fuel.
- The split between compute and the team is published at launch and enforced by the spend ratio
r. - There are no allocations promised to holders and no revenue share. Holders get a say in what is built (Section 7) and a public record of every fee and every spend.
07Governance
The core team sets the mission, so the product stays coherent. Within it, anyone can propose a task and holders vote on what the agent works on next. Voting weight is capped per wallet to limit the influence of the largest holders. The winning task enters the queue; the Meter decides when it can run.
08Roadmap
| Phase | Scope | Status |
|---|---|---|
| 01 · Ignition | Agent engine and sandbox, the Meter, per-task receipts, live dashboard | Live |
| 02 · Ledger | Hash-chained ledger, in-browser verifier, public code explorer | In development |
| 03 · Pit crew | Holder task voting; trader tools built by the agent | Coming soon |
| 04 · Fleet | Fuelbot Launchpad: a metered agent, tank and ledger for any coin | Coming soon |
Phases after 01 describe intent, not commitments; scope and timing may change.
09Risks & disclosures
- Model risk. The agent can write incorrect or incomplete code. Its output is public so it can be reviewed.
- Budget risk. Compute can cost more than fees bring in; the agent then sleeps.
- Dependency risk. The system relies on a model provider, Solana RPC, price feeds and the launchpad.
- Market risk. $FUELBOT is a memecoin with no intrinsic value. Its price can go to zero.
- No promises. This document is not an offer, not investment advice and not a promise of returns. Features not marked Live may change or not ship.