aero-allocator

MCP 服务器，用于预测 Aerodrome（Base）或 Velodrome（Optimism）池的下一周期需求，并将其转化为具体的激励分配建议——专为 Aerodrome 的预测性分配时代（2026 年 9 月，从原定的 7 月目标推迟）而构建，在该时代，激励将跟随预测的未来需求，而非上周的投票。Aerodrome 为默认协议；参见多协议进行切换。

任何支持 MCP 的代理（Claude Code、Claude Desktop、Bankr 托管的代理）都可以使用它来回答：

• 哪些池将在下一周期产生最多的费用？

• 投票份额在哪些地方与预测需求定价错位（即“预测优势”）？

• 我现在应该如何分配我的 veAERO 投票 / 激励预算？

所有数据均实时来自 Base——Aerodrome Sugar 合约提供池状态和逐周期历史，DefiLlama 提供 USD 定价。无需 API 密钥。

工具

此服务器绝不持有密钥或签署任何东西。 执行是宿主代理的工作，且需在用户明确批准之后进行。

Related MCP server: aero-vote-radar

快速开始

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

多协议（Aerodrome / Velodrome）

Aerodrome（Base）和 Velodrome（Optimism）同属 ve(3,3) 血统——Aerodrome 是 Velodrome 的分叉，共享 Sugar/Voter 合约模式——因此一个引擎即可覆盖两者。单个服务器进程服务一种协议，在启动时选择：

{
  "mcpServers": {
    "aero-allocator": {
      "command": "npx",
      "args": ["tsx", "/path/to/aero-allocator/src/index.ts"],
      "env": { "AERO_PROTOCOL": "aerodrome" }
    },
    "velo-allocator": {
      "command": "npx",
      "args": ["tsx", "/path/to/aero-allocator/src/index.ts"],
      "env": { "AERO_PROTOCOL": "velodrome" }
    }
  }
}

AERO_PROTOCOL 默认为 aerodrome（未设置时行为不变）。注册两个条目即可并行运行——每个都是独立的进程，拥有自己的 RPC 客户端和缓存。工具描述、ve 代币命名（veAERO/veVELO）和奖励代币命名（AERO/VELO）都会根据配置的协议自动切换；predictive_allocation_status 在运行 Velodrome 时正确报告该机制不适用，因为 Dromos Labs 的公告仅针对 Aerodrome。

RPC 选择：RPC_URL（新增，适用于任一协议）一旦设置则始终优先；否则在运行 Aerodrome 时，为向后兼容会优先使用 BASE_RPC_URL；否则每个协议回退到公共默认值（base-rpc.publicnode.com / mainnet.optimism.io）。

仪表板

“预测热门池”Web UI 位于 web/（Next.js，直接复用引擎）——目前仅支持 Aerodrome/Base：

npm run build                 # engine dist/ used by the web app
cd web && npm install && npm run dev

打开 http://localhost:3000——热门池表格（预测费用、优势、置信度），以及交互式 Voter ROI（输入你的 veAERO）和协议效率分配面板。首次加载会构建 链上快照（约 1 分钟），之后缓存。

连接钱包（注入式或 Coinbase Wallet，Base 链）即可将 Voter ROI 分配作为真实投票投出：你的 veAERO NFT 通过 VeSugar 自动检测（手动输入 ID 作为回退）， “投出投票”按钮以推荐权重提交 Voter.vote()——你在钱包中签名；应用绝不持有密钥。

使用 Claude Code 注册：

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

或在任何 MCP 客户端配置中：

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

示例代理流程：

“预测顶级 Aerodrome 池的需求，推荐一个跨 8 个池的 voter_roi 分配，然后为我的 veAERO #12345 准备投票 calldata，并用我的 Base 钱包提交。”

预测的工作原理

对于每个候选池（按质押 TVL 排名前 N，且高于 TVL 下限）：

1. 从 RewardsSugar.epochsByAddress 拉取最多 8 个每周周期的历史——投票、排放量、费用、每周期激励——并将所有内容以 USD 计价。

2. 当进行中的周期已过去超过 20% 时，将其外推至完整长度（最新的需求信号）。

3. 预测下一周期费用 = EWMA（α=0.45）+ ½ × 线性趋势，下限为 0。置信度得分来自历史深度和方差。

4. predictiveEdge = 预测费用需求占比 − 当前投票占比。正优势 → 激励不足的池：这正是预测市场分配器应奖励的对象。

两种分配目标：

• protocol_efficiency — 权重 ∝ 预测需求占比。这是预测性分配的理想状态；适用于指导激励的国库/协议，以及在该机制上线后对其进行基准测试。

• voter_roi — 在给定 veAERO 数量（votingPowerVe）下最大化你的预期下一周期奖励。每个池按比例支付（R·v/(E+v)），因此优化器会水灌投票以均衡边际回报——具有高名义 ROI 但奖励容量不足的零散池自然获得很少或零投票（外加 $500 的硬性容量下限）。输出包括每个池在自我稀释后的预期 USD 奖励。

recommend_bribe_placement 为花费贿赂预算的团队/协议（而非投票者）反转了这一逻辑：它在市场整个活跃投票权上重新运行相同的水灌算法，分别计算有和没有将贿赂添加到某个池的支付中的情况，并报告投票份额变化。投票按 ∝ √支付水灌，因此一美元贿赂在廉价池上比在已大型池上能拉动更多份额。这模拟了即时、无摩擦、全市场的重新分配，因此这是一个理论上限，而非预测——适用于比较候选池，而非预测字面投票数。

recommend_lp_deposit 面向第三类受众——决定在何处存入和质押流动性的 LP——并且刻意不按 predictedFeesUsd 排名。在 Aerodrome 上，交易费用（和贿赂）归属于 veAERO 投票者，而非流动性质押者；质押者则按质押 TVL 比例获得 AERO 排放。因此该工具使用与 predict_demand 相同的 EWMA+趋势模型，从每个池的排放历史预测下一周期排放量，并将结果按当前质押 TVL 年化，得到 predictedNextEpochAprPct。它还报告 currentEpochAprPct，这完全不需要预测——当前周期的排放率在周期开始前就已由投票固定，因此直接读取而非预测。

预测准确性

每个预测上的 confidence 最初是启发式（历史深度 + 方差），然后在到达任何工具输出之前，根据真实回测准确性重新校准——见 置信度校准 下文。backtest_summary（工具）和 npm run backtest（脚本）提供完整验证。

方法：对每个池的已完成周期历史进行前向遍历。在每个历史周期边界，仅使用当时实际可用的周期（上限为 predict_demand 使用的相同滑动窗口——回测绝不会给模型比实时更多的历史）来预测该周期，然后与实际结果进行比较。误差以 MAE、RMSE 和 WAPE（Σ|误差| / Σ实际值，对 MAPE 无法处理的近零费用周期具有鲁棒性）报告，同时报告相对基线的技能——与朴素“预测下一周期 = 上一周期”模型的相同比较，因此负技能值意味着 EWMA+趋势预测在复杂度上并未优于什么都不做。置信度校准表检查更高置信度的预测是否确实具有更低误差。一个已知缺口：此回测仅重放周期边界预测——它不重放用于实时进行中周期的周期中速度外推混合。

置信度校准

启发式置信度（depthScore × stabilityScore）是对预测可信度的猜测——它从未见过真实结果。deriveConfidenceCalibration 将每个前向回测点按其原始启发式置信度分桶，计算每个桶内实际实现的 WAPE，并将其转换为 calibratedConfidence = 1/(1+wape)（与启发式自身方差项使用的函数形式相同）。predict_demand、recommend_allocation 和 recommend_bribe_placement 随后通过 applyConfidenceCalibration 将每个实时预测的置信度重新映射到该曲线上——因此，启发式认为看起来可靠但实际噪声较大的置信度范围会被下调，反之亦然。这不仅仅影响显示：置信度直接加权 voter_roi 的奖励估计，并门控 recommend_bribe_placement 的候选池，因此校准不当的分数会悄悄使两者产生偏差。

样本少于 8 个回测点的桶会被丢弃而非信任，任何原始置信度落在被丢弃（或尚未计算）范围内的预测都会保留其启发式分数——校准是在始终可用的启发式之上的机会性增强，而非硬性依赖。如果过去一小时内尚未运行过新的 backtest_summary，相关工具会与市场快照同时获取一个（并发，因此不会增加等待时间），并在获取失败时回退到原始启发式。

运行 npm run backtest 获取控制台报告，或从任何连接的代理调用 backtest_summary 获取实时数据（缓存约 1 小时；AERO_BACKTEST_EPOCHS / AERO_BACKTEST_MAX_POOLS 调整深度/广度）。

预测性分配适配器

Dromos Labs 已宣布该机制，但尚未发布合约/ABI（截至 2026-08-16；启动已从 7 月推迟到 2026 年 9 月）。所有机制特定内容都位于 src/adapters/predictive-allocation.ts 的一个接口后面，并且完全由配置驱动——启动日无需代码更改，只需在 Dromos 发布地址和 ABI 后设置环境变量即可。

设置全部四个后，prepare_submission 会构建真实的 calldata；predictive_allocation_status 报告 live: true。在此之前，prepare_submission 会以明确的"尚未发布"错误失败，而 prepare_vote_calldata 则针对经典的 Voter.vote() 流程，该流程目前可用。

配置（环境变量）

使用的合约

均来自 velodrome-finance/sugar 的 deployments/{base,optimism}.env；奖励代币地址已与 DefiLlama + CoinGecko 交叉核对。

路线图

• 预测分配适配器已配置驱动并准备就绪 — 连接真实合约只需更改环境变量（prepare_submission）

• 社交/关注度信号（Farcaster 提及、代币上线）作为预测特征

• 回测工具：重放历史周期，对比预测与实际费用评分，发布准确率（backtest_summary、npm run backtest）

• x402 变现托管端点（通过 Bankr 以 USDC 按次付费预测）

• "预测热门池"仪表盘（web/）

• 钱包连接 + 从仪表盘一键投票（wagmi）

• 多协议：Velodrome（Optimism）与 Aerodrome（Base）并行，通过 AERO_PROTOCOL 选择

• 仪表盘（web/）多协议支持（目前仅 Aerodrome/Base）

免责声明

预测是基于链上历史的统计外推，不构成财务建议。签署前请务必审查 calldata。