aero-allocator

Aerodrome(Base) 또는 Velodrome(Optimism) 풀의 다음 에포크 수요를 예측하고 이를 구체적인 인센티브 할당 추천으로 전환하는 MCP 서버입니다. Aerodrome의 예측 할당(Predictive Allocation) 시대(2026년 9월, 원래 7월 목표에서 연기됨)를 위해 구축되었으며, 인센티브가 지난주 투표가 아닌 예측된 미래 수요를 따르는 시대입니다. Aerodrome이 기본값이며, 전환하려면 멀티 프로토콜을 참조하세요.

MCP를 지원하는 모든 에이전트(Claude Code, Claude Desktop, Bankr 호스팅 에이전트)는 이를 사용하여 다음을 답할 수 있습니다:

• 다음 에포크에 가장 많은 수수료를 생성할 풀은 무엇인가?

• 예측 수요 대비 투표 점유율이 잘못 평가된( "예측 엣지") 곳은 어디인가?

• 지금 내 veAERO 투표 / 인센티브 예산을 어떻게 분할해야 하나?

모든 데이터는 Base에서 실시간으로 제공됩니다 — 풀 상태 및 에포크별 기록은 Aerodrome Sugar 컨트랙트, USD 가격은 DefiLlama에서 가져옵니다. 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은 Sugar/Voter 컨트랙트 패턴을 공유하는 Velodrome 포크이므로 하나의 엔진이 둘 다 처리합니다. 단일 서버 프로세스는 하나의 프로토콜만 제공하며, 시작 시 선택됩니다:

{
  "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)으로 폴백합니다.

대시보드

"예측된 인기 풀" 웹 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 입력) 및 Protocol Efficiency 할당 패널. 첫 로드 시 온체인 스냅샷을 구축합니다(~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 — 가중치 ∝ 예측 수요 점유율. 이는 Predictive Allocation의 이상적 목표입니다. 재무부/프로토콜이 인센티브를 지시하고, 메커니즘이 출시되면 라이브 메커니즘을 벤치마킹하는 데 유용합니다.

• 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가 질식하는 거의 0에 가까운 수수료 에포크에 강건함)로 보고되며, 기준선 대비 스킬 — "다음 에포크 = 마지막 에포크"를 예측하는 순진한 모델과의 동일한 비교 — 도 함께 보고됩니다. 따라서 음수 스킬 수치는 EWMA+추세 예측이 아무것도 하지 않는 것보다 복잡성을 정당화하지 못한다는 의미입니다. 신뢰도 보정 테이블은 더 높은 신뢰도의 예측이 실제로 더 낮은 오류를 갖는지 확인합니다. 알려진 한 가지 격차: 이는 에포크 경계 예측만 재생합니다 — 라이브 진행 중 에포크에 사용되는 중간 에포크 속도 외삽 혼합은 재생하지 않습니다.

신뢰도 보정

휴리스틱 신뢰도(depthScore × stabilityScore)는 예측이 얼마나 신뢰할 수 있는지에 대한 추측입니다 — 실제 결과를 본 적이 없습니다. deriveConfidenceCalibration은 모든 워크포워드 백테스트 포인트를 원시 휴리스틱 신뢰도로 버킷화하고, 각 버킷 내에서 실현된 실제 WAPE를 계산한 다음 calibratedConfidence = 1/(1+wape)로 변환합니다(휴리스틱이 자체 분산 항에 이미 사용하는 것과 동일한 함수 형태). 그런 다음 predict_demand, recommend_allocation 및 recommend_bribe_placement는 applyConfidenceCalibration을 통해 모든 라이브 예측의 신뢰도를 이 곡선에 재매핑합니다 — 휴리스틱이 견고해 보였지만 실제로는 시끄러웠던 신뢰도 범위는 낮게 표시되고, 그 반대도 마찬가지입니다. 이는 표시 이상으로 중요합니다: 신뢰도는 voter_roi 보상 추정치를 직접 가중하고 recommend_bribe_placement의 후보 풀을 게이트하므로, 잘못 보정된 점수는 둘 다 조용히 편향시킬 수 있습니다.

샘플이 8개 미만인 버킷은 신뢰하지 않고 버려집니다. 원시 신뢰도가 버려진(또는 아직 계산되지 않은) 범위에 속하는 예측은 휴리스틱 점수를 유지합니다 — 보정은 항상 사용 가능한 휴리스틱 위에 기회적으로 적용되며, 절대 하드 의존성이 아닙니다. 지난 1시간 동안 새 backtest_summary가 실행되지 않은 경우 관련 도구는 시장 스냅샷과 함께 하나를 가져오고(동시에, 대기 시간에 추가되지 않음) 어떤 이유로든 해당 가져오기가 실패하면 원시 휴리스틱으로 폴백합니다.

콘솔 보고서는 npm run backtest로 실행하거나, 연결된 에이전트에서 backtest_summary를 호출하여 실시간 숫자를 얻을 수 있습니다(~1시간 캐시, AERO_BACKTEST_EPOCHS / AERO_BACKTEST_MAX_POOLS로 깊이/폭 조정).

Predictive Allocation 어댑터

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() 흐름을 대상으로 합니다.

구성 (env)

사용되는 컨트랙트

둘 다 velodrome-finance/sugar의 deployments/{base,optimism}.env에서 가져옴; 보상 토큰 주소는 DefiLlama + CoinGecko와 교차 검증됨.

로드맵

• Predictive Allocation 어댑터는 구성 기반이며 출시 준비 완료 — 실제 컨트랙트 연결은 환경 변수 변경으로 가능(prepare_submission)

• 소셜/관심 신호(Farcaster 언급, 토큰 상장)를 예측 기능으로

• 백테스트 하네스: 과거 에포크 재생, 예측 대비 실현 수수료 점수화, 정확도 게시(backtest_summary, npm run backtest)

• x402 수익화 호스팅 엔드포인트(Bankr를 통한 USDC 예측당 결제)

• "예측 인기 풀" 대시보드(web/)

• 대시보드에서 지갑 연결 + 원클릭 투표(wagmi)

• 멀티 프로토콜: Aerodrome(Base)과 함께 Velodrome(Optimism), AERO_PROTOCOL로 선택

• 대시보드(web/) 멀티 프로토콜 지원(현재 Aerodrome/Base만)

면책 조항

예측은 온체인 기록의 통계적 외삽이며, 재정적 조언이 아닙니다. 서명 전에 항상 calldata를 검토하세요.