Skip to content
AURA

AURA

Autonomous Utility Revenue Agent - Based

Created on 20th February 2026

AURA

AURA

Autonomous Utility Revenue Agent - Based

The problem AURA solves

Most AI agents are expensive pets — they often burn through any funds you provide and stop working when the money runs out.

AURA tries to fix that. It's my first attempt at an AI agent that earns its own living.

Here's how it works: AURA keeps its idle USDC earning yield in Aave while simultaneously selling DeFi analysis to anyone willing to pay a few cents per question. With it's two income streams, passive yield and pay-per-use fees no human should need to refill the wallet.

The payments side is powered by x402, a newly rejuvenated HTTP protocol relic where a server responds with 402 Payment Required and the client pays in USDC before getting their answer. There's no account to create, no API key to manage — you just sign a gasless authorization and the money moves. It's what buying a coffee would look like if coffee shops ran on Base.

Every five minutes, the agent wakes up, checks its balances, decides whether to deposit or hold, and logs what it decided to 0G Storage (or Upstash KV as a fallback) so there's an immutable record. A live dashboard tracks whether revenue is actually beating costs — right now it shows "DEFICIT", because yield alone isn't enough and you need real query traffic to close the gap. The dashboard will also show you how many x402 fees or how much liquidity you need to be self-sustaining.

Challenges I ran into

The ERC-8021 builder code was silently doing nothing.

The Base bounty requires a builder code appended to every transaction. The code looked correct,

ox/erc8021

was imported,

Attribution.toDataSuffix

was called but the

dataSuffix

was being passed to

createWalletClient

, but viem simply ignores it. Every transaction had been going out clean, with no builder code attached. Caught it during a type-check pass, refactored to pass

dataSuffix

on each individual

writeContract

call instead, and verified on Basescan.

x402 couldn't run inside Vercel's Edge Runtime.

When attempting to test my x402 prompt requests I kept seeing 500 status codes returned. Originally I wanted to use the

/api/analyze

route with

@x402/next

. But With claude's help we found that Vercel's Edge Runtime doesn't support the Node.js crypto APIs that

@x402/evm

depends on, so the middleware silently failed. The fix was to strip

middleware.ts

to a pass-through and move the x402 payment gate directly into the route handler using a

withX402

wrapper. Less elegant, but it works.

x402 kept returning 402 even after a valid payment.

After getting the middleware issue sorted, the test client was still hitting 402s every run. The server was receiving the payment authorization but rejecting it due to

invalid_payload

. After checking and deconstructing the payload we found that the culprit was wallet config: the buyer wallet and the agent wallet (the payment recipient) were the same address. The facilitator rejects self-payments. Once the test client was switched to a separate funded wallet, the flow completed cleanly — payment authorized, 200 returned, USDC credited.

Dynamic pricing required reading the request body twice.

To price a query before running inference, the

dynamicPrice

function needed to read the request body to measure query length. The route handler also needed to read the body to get the query text. An HTTP request body is a stream which you can only consume once. Solved with a

WeakMap<NextRequest, ...>

cache: the pricing function reads and caches, the handler reads from cache.

The dashboard showed an empty decision log for 25 ticks.

The agent was faithfully logging decisions every tick — but to a KV key called

aura:zg:logs

. The

/api/stats

route was only reading

aura:state

, which has a separate

decisionLog: []

field that never got populated. Two hours of agent reasoning sitting in KV, invisible to the dashboard. One extra

readDecisionLogs()

call in the stats route fixed it.

Under priced x402 due to unmodeled inference overhead

Initial estimatePrice() only counted system prompt + raw query tokens — ignoring the actual cost structure of a multi-step tool-calling Sonnet request
Three hidden token sources were eating the margin silently:
Tool schema injection (~400 tok/request) — both getDeFiYields and getAuraStatus schemas are serialized into every API call regardless of whether tools are used
Multi-step context growth — with maxSteps: 5, each subsequent step re-sends the full prior context; a single tool call roughly 1.7× the input token count
Tool result payload — a DeFiLlama response at topN=10 adds ~500 tokens of JSON the model must process before generating its answer
Result: production margins of 0.67× (loss) and 1.03× (breakeven) — the agent was subsidizing every analysis request with its own Aave yield reserves
Fix: re-calibrated the estimator to model all three overhead sources (TOOL_DEFINITION_TOKENS, MULTISTEP_FACTOR, TOOL_RESULT_TOKENS), raised the output token estimate (450 + chars/8 vs. old 300 + chars/12), bumped PRICE_FLOOR from $0.02 → $0.03, and halved the default topN on the tool — projecting 2.2×–3× sustainable margins across all query lengths

Use of AI tools and agents

AURA runs two Claude models with distinct roles:

Claude Haiku powers the autonomous agent loop (every 5 min on Railway, timing can be adjusted). It's cheap enough (~$0.002/tick) that yield can realistically cover its cost. Each tick it calls tools to check balances, deposit/withdraw from Aave, and log its reasoning to 0G Storage — no human involved.

Claude Sonnet handles the paid

/api/analyze

endpoint, gated by x402. Clients pay micro-USDC per query and get higher-quality DeFi analysis in return. The price is estimated dynamically per query so the inference never runs at a loss.

Haiku manages the treasury. Sonnet earns from it. The dashboard tracks whether revenue from both Aave yield and Sonnet fees is beating Haiku's inference costs — a live proof-of-concept that an AI agent can cover its own bills.


Claude Code (Anthropic's CLI agent) was used throughout the 45-hour solo build. Three practices kept it from causing the usual AI-assisted mistakes:

  • Plan before edit — Claude would research, propose an approach, and wait for sign-off before touching any file. This caught a near-miss ERC-8021 bug that would have silently voided the Base bounty.
  • Skills — Domain knowledge (USDC decimals, verified contract addresses, gas costs) was loaded via skills from ethskills.com rather than letting the model guess.
  • MCP servers — Used for live access to protocol specs during development, keeping context current rather than relying on training data.

The output is a

CLAUDE.md

in the repo that encodes all critical facts — so any agent (or developer) resuming the project starts from verified ground truth.

Tracks Applied (3)

Futurllama

AURA is an AI agent that earns its own compute costs — a working proof that autonomous agents can be economically self-s...Read More

Best DeFAI Application

DeFi workflow — Aave V3 lending (supply/withdraw USDC) is a core DeFi primitive, running live on Base mainnet AI does mo...Read More
0g Labs

0g Labs

Base Self-Sustaining Autonomous Agents

Self-sustaining — The whole project is built around proving an agent can cover its own costs. Dual revenue (Aave yield +...Read More
Base

Base

Cheer Project

Cheering for a project means supporting a project you like with as little as 0.0025 ETH. Right now, you can Cheer using ETH on Arbitrum, Optimism and Base.

Discussion

Builders also viewed

See more projects on Devfolio