aero-allocator

MCP-Server, der die Nachfrage der nächsten Epoche für Aerodrome- (Base) oder Velodrome- (Optimism) Pools prognostiziert und daraus konkrete Anreiz-Allokationsempfehlungen ableitet – gebaut für die Ära der Predictive Allocation von Aerodrome (September 2026, verschoben vom ursprünglichen Juli-Ziel), in der Anreize der prognostizierten zukünftigen Nachfrage folgen statt den Abstimmungen der letzten Woche. Aerodrome ist die Standardeinstellung; siehe Multi-Protokoll zum Wechseln.

Jeder MCP-fähige Agent (Claude Code, Claude Desktop, Bankr-gehostete Agenten) kann ihn nutzen, um folgende Fragen zu beantworten:

• Welche Pools werden in der nächsten Epoche die meisten Gebühren generieren?

• Wo ist der Abstimmungsanteil falsch bepreist im Vergleich zur prognostizierten Nachfrage (die „Predictive Edge")?

• Wie sollte ich meine veAERO-Stimmen / mein Anreizbudget jetzt aufteilen?

Alle Daten kommen live von Base – Aerodrome-Sugar-Contracts für den Pool-Zustand und die Historie pro Epoche, DefiLlama für USD-Preise. Keine API-Schlüssel erforderlich.

Tools

Dieser Server hält niemals Schlüssel und signiert nichts. Die Ausführung ist Aufgabe des Host-Agenten, hinter expliziter Benutzerfreigabe.

Related MCP server: aero-vote-radar

Schnellstart

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

Multi-Protokoll (Aerodrome / Velodrome)

Aerodrome (Base) und Velodrome (Optimism) stammen aus derselben ve(3,3)-Linie – Aerodrome ist ein Velodrome-Fork, der das Sugar/Voter-Contract-Muster teilt –, sodass eine Engine beide abdeckt. Ein einzelner Serverprozess bedient ein Protokoll, das beim Start ausgewählt wird:

{
  "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 standardmäßig auf aerodrome (unverändertes Verhalten, wenn nicht gesetzt). Beide Einträge registrieren, um sie nebeneinander zu betreiben – jeder ist ein separater Prozess mit eigenem RPC-Client und eigenen Caches. Tool-Beschreibungen, ve-Token-Benennung (veAERO/veVELO) und Reward-Token-Benennung (AERO/VELO) wechseln automatisch mit dem konfigurierten Protokoll; predictive_allocation_status meldet korrekt, dass der Mechanismus bei Velodrome nicht anwendbar ist, da die Ankündigung von Dromos Labs Aerodrome-spezifisch ist.

RPC-Auswahl: RPC_URL (neu, funktioniert für beide Protokolle) gewinnt immer, wenn gesetzt; andernfalls wird BASE_RPC_URL aus Gründen der Abwärtskompatibilität berücksichtigt, wenn Aerodrome läuft; andernfalls fällt jedes Protokoll auf einen öffentlichen Standard zurück (base-rpc.publicnode.com / mainnet.optimism.io).

Dashboard

Eine „Predicted Hot Pools"-Web-UI befindet sich in web/ (Next.js, nutzt die Engine direkt) – derzeit nur Aerodrome/Base:

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

Öffne http://localhost:3000 – Hot-Pools-Tabelle (prognostizierte Gebühren, Edge, Konfidenz), plus interaktive Voter-ROI- (veAERO eingeben) und Protocol-Efficiency-Allokationspanels. Der erste Aufruf erstellt den Onchain-Snapshot (~1 Min.), danach wird gecacht.

Verbinde eine Wallet (injiziert oder Coinbase Wallet, Base-Chain), um die Voter-ROI-Allokation als echte Abstimmung abzugeben: Deine veAERO-NFTs werden automatisch über VeSugar erkannt (manuelle ID-Eingabe als Fallback) und der „Cast Vote"-Button sendet Voter.vote() mit den empfohlenen Gewichten – du signierst in deiner Wallet; die App hält niemals Schlüssel.

Bei Claude Code registrieren:

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

Oder in einer beliebigen MCP-Client-Konfiguration:

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

Beispiel-Agentenablauf:

„Prognostiziere die Nachfrage für die Top-Aerodrome-Pools, empfehle eine voter_roi-Allokation über 8 Pools, bereite dann die Vote-Calldata für meine veAERO #12345 vor und reiche sie mit meiner Base-Wallet ein."

So funktioniert die Prognose

Für jeden Kandidatenpool (Top N nach gestaketem TVL über einer TVL-Untergrenze):

1. Bis zu 8 wöchentliche Epochen Historie von RewardsSugar.epochsByAddress abrufen – Stimmen, Emissionen, Gebühren, Anreize pro Epoche – und alles in USD bepreisen.

2. Die laufende Epoche auf volle Länge extrapolieren, sobald >20 % verstrichen sind (das frischeste Nachfragesignal).

3. Gebühren der nächsten Epoche prognostizieren = EWMA (α=0,45) + ½ × linearer Trend, bei 0 gedeckelt. Konfidenzwerte aus Historientiefe und Varianz.

4. predictiveEdge = prognostizierter Gebühren-Nachfrageanteil − aktueller Abstimmungsanteil. Positive Edge → unterinzentivierter Pool: genau das, was ein Prediction-Market-Allokator belohnen sollte.

Zwei Allokationsziele:

• protocol_efficiency – Gewichte ∝ prognostizierter Nachfrageanteil. Das ist das Predictive-Allocation-Ideal; nützlich für Treasuries/Protokolle, die Anreize lenken, und zum Benchmarking des Live-Mechanismus, sobald er ausgeliefert ist.

• voter_roi – Maximierung deiner erwarteten Belohnung der nächsten Epoche für einen gegebenen veAERO-Betrag (votingPowerVe). Jeder Pool zahlt anteilig (R·v/(E+v)), also water-fillt der Optimierer die Stimmen, um die Grenzerträge anzugleichen – Staubpools mit hohem Headline-ROI, aber ohne Belohnungskapazität erhalten natürlich wenige oder keine Stimmen (plus eine harte $500-Kapazitätsuntergrenze). Die Ausgabe enthält die erwartete USD-Belohnung pro Pool nach Selbstverwässerung.

recommend_bribe_placement dreht dies für Teams/Protokolle um, die ein Bribe-Budget statt Stimmen ausgeben: Es führt denselben Water-Fill über die gesamte aktive Abstimmungsmacht des Marktes erneut aus, mit und ohne den Bribe, der zur Auszahlung eines Pools hinzugefügt wird, und meldet die Delta des Abstimmungsanteils. Stimmen water-fillen ∝ √Auszahlung, sodass ein Bribe-Dollar auf einem billigen Pool überproportional mehr zieht als auf einem bereits großen. Dies modelliert eine sofortige, reibungslose, marktweite Neuallokation, ist also eine theoretische Obergrenze, keine Prognose – nützlich zum Vergleichen von Kandidatenpools, nicht zur Vorhersage einer wörtlichen Stimmenzahl.

recommend_lp_deposit zielt auf ein drittes Publikum – LPs, die entscheiden, wo sie Liquidität einzahlen und staken – und rankt bewusst nicht nach predictedFeesUsd. Auf Aerodrome fließen Handelsgebühren (und Bribes) an veAERO-Wähler, nicht an Liquiditäts-Staker; Staker verdienen stattdessen AERO-Emissionen anteilig zum gestaketen TVL. Dieses Tool prognostiziert daher die Emissionen der nächsten Epoche aus der Emissionshistorie jedes Pools mit demselben EWMA+Trend-Modell, das predict_demand für Gebühren verwendet, und annualisiert das Ergebnis gegen das aktuelle gestakete TVL als predictedNextEpochAprPct. Es meldet auch currentEpochAprPct, das gar keine Prognose benötigt – die Emissionsrate der laufenden Epoche wurde bereits durch die Stimmen festgelegt, die vor ihrem Beginn abgegeben wurden, also wird sie direkt gelesen statt prognostiziert.

Prognosegenauigkeit

confidence für jede Prognose beginnt als Heuristik (Historientiefe + Varianz) und wird dann gegen die reale Backtest-Genauigkeit neu kalibriert, bevor sie eine Tool-Ausgabe erreicht – siehe Konfidenz- Kalibrierung unten. backtest_summary (Tool) und npm run backtest (Skript) legen die vollständige Validierung offen.

Methodik: Walk-Forward durch die abgeschlossene Epochenhistorie jedes Pools. An jeder historischen Epochengrenze wird diese Epoche nur mit den Epochen prognostiziert, die tatsächlich vorher verfügbar gewesen wären (begrenzt auf dasselbe nachlaufende Fenster, das predict_demand verwendet – der Backtest gibt dem Modell nie mehr Historie, als es live bekommt), und dann mit dem verglichen, was tatsächlich passiert ist. Fehler werden als MAE, RMSE und WAPE (Σ|Fehler| / ΣIst), robust gegenüber den nahezu-Null-Gebühren-Epochen, an denen MAPE scheitert, zusammen mit Skill vs. Baseline gemeldet – derselbe Vergleich gegen ein naives „nächste Epoche = letzte Epoche"-Modell, sodass eine negative Skill-Zahl bedeutet, dass die EWMA+Trend-Prognose ihre Komplexität gegenüber dem Nichtstun nicht rechtfertigt. Eine Konfidenz-Kalibrierungstabelle prüft, ob Prognosen mit höherer Konfidenz tatsächlich einen geringeren Fehler aufweisen. Eine bekannte Lücke: Dies spielt nur Epochengrenzen-Prognosen nach – es spielt nicht die Mitte-der-Epoche-Pace-Extrapolationsmischung nach, die für die laufende Live-Epoche verwendet wird.

Konfidenz-Kalibrierung

Die heuristische Konfidenz (depthScore × stabilityScore) ist eine Schätzung, wie vertrauenswürdig eine Prognose ist – sie hat nie ein reales Ergebnis gesehen. deriveConfidenceCalibration bucketed jeden Walk-Forward-Backtestpunkt nach seiner rohen heuristischen Konfidenz, berechnet den tatsächlich realisierten WAPE innerhalb jedes Buckets und konvertiert das in calibratedConfidence = 1/(1+wape) (dieselbe funktionale Form, die die Heuristik bereits für ihren eigenen Varianzterm verwendet). predict_demand, recommend_allocation und recommend_bribe_placement mappen dann jede Live-Prognose-Konfidenz über diese Kurve via applyConfidenceCalibration – ein Konfidenzbereich, den die Heuristik für solide hielt, der sich in der Praxis aber als verrauscht erwiesen hat, wird also herabgestuft und umgekehrt. Das ist über die Anzeige hinaus wichtig: Konfidenz gewichtet direkt die voter_roi-Belohnungsschätzung und begrenzt die Kandidatenpools von recommend_bribe_placement, sodass ein falsch kalibrierter Score beide still verzerren würde.

Buckets mit weniger als 8 Backtest-Stichproben werden verworfen statt vertraut, und jede Prognose, deren rohe Konfidenz in einen verworfenen (oder noch nicht berechneten) Bereich fällt, behält ihren heuristischen Score – Kalibrierung ist opportunistisch zusätzlich zur immer verfügbaren Heuristik, nie eine harte Abhängigkeit. Wenn in der letzten Stunde kein frisches backtest_summary gelaufen ist, rufen die relevanten Tools eines zusammen mit dem Markt-Snapshot ab (gleichzeitig, sodass es nicht zur Wartezeit beiträgt) und fallen auf die rohe Heuristik zurück, wenn dieser Abruf aus irgendeinem Grund fehlschlägt.

Führe npm run backtest für einen Konsolenbericht aus oder rufe backtest_summary von einem beliebigen verbundenen Agenten für Live-Zahlen auf (gecacht ~1h; AERO_BACKTEST_EPOCHS / AERO_BACKTEST_MAX_POOLS justieren Tiefe/Breite).

Predictive-Allocation-Adapter

Dromos Labs hat den Mechanismus angekündigt, aber noch keine Contracts/ABI veröffentlicht (Stand 2026-08-16; der Start wurde von Juli auf September 2026 verschoben). Alles Mechanismus-Spezifische liegt hinter einem Interface in src/adapters/predictive-allocation.ts und ist vollständig konfigurationsgesteuert – keine Codeänderungen am Starttag nötig, nur Env-Variablen setzen, sobald Dromos die Adresse und ABI veröffentlicht:

Mit allen vier gesetzt, erstellt prepare_submission echte Calldata; predictive_allocation_status meldet live: true. Bis dahin schlägt prepare_submission mit einer klaren „noch nicht veröffentlicht"-Fehlermeldung fehl und prepare_vote_calldata zielt auf den klassischen Voter.vote()-Ablauf, der heute funktioniert.

Konfiguration (env)

Verwendete Verträge

Beide aus velodrome-finance/sugar's deployments/{base,optimism}.env; Reward-Token-Adressen gegen DefiLlama + CoinGecko gegengeprüft.

Roadmap

• Predictive-Allocation-Adapter ist konfigurationsgesteuert und startbereit — das Anbinden der echten Verträge ist eine Env-Var-Änderung (prepare_submission)

• Soziale/Aufmerksamkeitssignale (Farcaster-Erwähnungen, Token-Listings) als Prognosefunktionen

• Backtest-Harness: vergangene Epochen abspielen, Prognose gegen realisierte Gebühren bewerten, Genauigkeit veröffentlichen (backtest_summary, npm run backtest)

• x402-monetarisierter gehosteter Endpunkt (Pay-per-Forecast in USDC über Bankr)

• „Predicted hot pools"-Dashboard (web/)

• Wallet-Verbindung + Ein-Klick-Abstimmung vom Dashboard (wagmi)

• Multi-Protokoll: Velodrome (Optimism) neben Aerodrome (Base), ausgewählt über AERO_PROTOCOL

• Multi-Protokoll-Unterstützung im Dashboard (web/) (derzeit nur Aerodrome/Base)

Haftungsausschluss

Prognosen sind statistische Extrapolationen der Onchain-Historie, keine Finanzberatung. Überprüfen Sie Calldata immer vor dem Signieren.