aero-allocator

MCP server that forecasts next-epoch demand for Aerodrome pools on Base and turns it into concrete incentive-allocation recommendations — built for Aerodrome's Predictive Allocation era (July 2026), where incentives follow predicted future demand instead of last week's votes.

Any MCP-capable agent (Claude Code, Claude Desktop, Bankr-hosted agents) can use it to answer:

• Which pools will generate the most fees next epoch?
• Where is vote share mispriced vs predicted demand (the "predictive edge")?
• How should I split my veAERO votes / incentive budget right now?

All data comes live from Base — Aerodrome Sugar contracts for pool state and per-epoch history, DefiLlama for USD pricing. No API keys required.

Tools

Tool	What it does
scan_pools	Gauge-enabled pools with live TVL, staked TVL, fee tier
pool_history	Per-epoch votes, emissions, fees (USD), bribes (USD) for one pool
predict_demand	Next-epoch fee forecast per pool + predictiveEdgePct (predicted demand share − current vote share)
recommend_allocation	Weighted allocation: protocol_efficiency (∝ predicted demand) or voter_roi (max reward per vote, 25% concentration cap)
prepare_vote_calldata	Unsigned Voter.vote() calldata from an allocation — submit via your own wallet layer (e.g. Base MCP send_calls)
predictive_allocation_status	Whether direct Predictive Allocation submission is wired up yet

This server never holds keys or signs anything. Execution is the host agent's job, behind explicit user approval.

Quick start

npm install
npm run smoke        # live end-to-end test against Base mainnet
npm run build

Register with Claude Code:

claude mcp add aero-allocator -- npx tsx /path/to/aero-allocator/src/index.ts

Or in any MCP client config:

{
  "mcpServers": {
    "aero-allocator": {
      "command": "npx",
      "args": ["tsx", "/path/to/aero-allocator/src/index.ts"],
      "env": { "BASE_RPC_URL": "https://mainnet.base.org" }
    }
  }
}

Example agent flow:

"Predict demand for the top Aerodrome pools, recommend a voter_roi allocation across 8 pools, then prepare the vote calldata for my veAERO #12345 and submit it with my Base wallet."

How the forecast works

For each candidate pool (top N by staked TVL above a TVL floor):

1. Pull up to 8 weekly epochs of history from RewardsSugar.epochsByAddress — votes, emissions, fees, incentives per epoch — and price everything in USD.
2. Extrapolate the in-progress epoch to full length once >20% has elapsed (the freshest demand signal).
3. Forecast next-epoch fees = EWMA (α=0.45) + ½ × linear trend, floored at 0. Confidence scores from history depth and variance.
4. predictiveEdge = predicted fee-demand share − current vote share. Positive edge → under-incentivized pool: exactly what a prediction-market allocator should reward.

Two allocation objectives:

• protocol_efficiency — weights ∝ predicted demand share. This is the Predictive Allocation ideal; useful for treasuries/protocols directing incentives and for benchmarking the live mechanism once it ships.
• voter_roi — maximize expected (fees + bribes) per vote, confidence-shrunk and edge-boosted, capped at 25% per pool so your own votes don't dilute the return.

Predictive Allocation adapter

Dromos Labs announced the mechanism but hasn't published contracts/ABI yet (as of 2026-07-06). Everything mechanism-specific lives behind one interface in src/adapters/predictive-allocation.ts — on launch day, wire the addresses/ABI there and prepare_submission goes live. Until then prepare_vote_calldata targets the classic Voter.vote() flow, which works today.

Configuration (env)

Var	Default
BASE_RPC_URL	https://mainnet.base.org	Use a dedicated RPC for faster snapshots
AERO_MIN_TVL_USD	50000	Candidate pool TVL floor
AERO_MAX_CANDIDATES	60	Pools receiving full epoch-history analysis

Contracts used (Base, 8453)

LpSugar v3	0x69dD9db6d8f8E7d83887A704f447b1a584b599A1
RewardsSugar	0x1b121EfDaF4ABb8785a315C51D29BCE0552A7678
Voter	0x16613524e02ad97eDfeF371bC883F2F5d6C480A5

Roadmap

• [ ] Predictive Allocation live adapter (day-one, when contracts publish)
• [ ] Social/attention signals (Farcaster mentions, token listings) as forecast features
• [ ] Backtest harness: replay past epochs, score forecast vs realized fees, publish accuracy
• [ ] x402-monetized hosted endpoint (pay-per-forecast in USDC via Bankr)
• [ ] "Predicted hot pools" dashboard (Next.js + wagmi)

Disclaimer

Forecasts are statistical extrapolations of onchain history, not financial advice. Always review calldata before signing.