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

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

Related MCP server: MAIN MCP

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 your expected next-epoch reward for a given veAERO amount (votingPowerVe). Each pool pays pro-rata (R·v/(E+v)), so the optimizer water-fills votes to equalize marginal returns — dust pools with high headline ROI but no reward capacity naturally get few or no votes (plus a hard $500 capacity floor). Output includes the expected USD reward per pool after self-dilution.

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)

Contracts used (Base, 8453)

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.