mcpField
Y
YieldSignal

YieldSignal

リモート
yieldsignal.vercel.app金融データ011 週間前に更新
リポジトリ公式サイト

YieldSignal について

YieldSignalは、ETHステーキングとBaseのレンディング市場を評価する自律エージェント向けに、リスク加重の利回りシグナルと分析を提供します。利回り、移動・維持の判断、インセンティブの持続性、退出可能性、金利感応度、ポートフォリオのエクスポージャー、シグナルの持続期間を扱い、x402で呼び出しごとに課金します。

主な機能

  1. 01ETHリキッドステーキング利回りの比較
  2. 02Base上のUSDC・WETHレンディング利回りの比較
  3. 03移動・維持の判断と純利益の評価
  4. 04インセンティブの持続性と出金能力の測定
  5. 05金利感応度とポートフォリオのエクスポージャー分析
  6. 06シグナルの持続期間の確認

活用シーン

  1. 01ETHの配分前にステーキング先を比較
  2. 02Baseプロトコル間のレンディング利回りを比較
  3. 03指定額のポジションを退出できるか評価
  4. 04再配分前に金利と共通リスクを確認

MCP 対応

YieldSignalは`/mcp`で、利回りシグナルと判断を取得する有料MCPツールを提供します。ツール呼び出しごとにx402で支払い、ツール一覧取得と初期化は無料です。

設定

リモートサーバーはインストール不要です。クライアントを選んで設定をコピーするか、ワンクリックで導入できます。

エンドポイントhttps://yieldsignal.vercel.app/mcp
インストールコマンドをコピー
Claude CodeTerminal
Cursor.cursor/mcp.json
VS Code.vscode/mcp.json
Claude Desktopclaude_desktop_config.json
Windsurf~/.codeium/windsurf/mcp_config.json

コマンドはターミナルで実行し、JSON は各クライアントの MCP 設定に貼り付けて再起動します。認可が必要なサーバーは初回接続時にログインを求めます。

ツール

7
パラメーター型必須説明
assetenumいいえ取得する利回りシグナル:Base 上の USDC/WETH レンディング APY、または Ethereum メインネット上の ETH_STAKING リキッドステーキング APY。デフォルトは USDC です。ETH_STAKING | USDC | WETH

詳細

YieldSignal

CI

自律型エージェント向けのリスク加重型利回りシグナルです。x402プロトコルを介して呼び出しごとに支払うため、API キーも登録も不要です。すべての製品ルートが有料です。シグナルは**$0.10**、分析(持続性/容量/感応度/エクスポージャー)は**$0.25**、判断は**$0.50**、持続期間は**$1.00**です。無料枠はなく、迂回パラメーターもありません。

  • ETH リキッドステーキング(Ethereum メインネット):Lido、Rocket Pool、Coinbase Wrapped Staked ETH、Frax Ether、Binance Staked ETH
  • USDC と WETH のレンディング(Base):Aave、Compound、Morpho、Moonwell、Euler、Fluid

7 つの製品を提供します。生のシグナル(現時点で最も高い利回りを得られるもの)、判断(現在の資金の配置を踏まえ、移動コストを考慮しても移動する価値があるかを示します。期待純利益と損益分岐までの日数を含む MOVE/HOLD)、持続性レポート(インセンティブが終了した場合に、その APY がどれだけ維持されるか)、容量レポート(その市場から実際に希望額を引き出せるか)、感応度レポート(借入金利が急上昇する屈曲点まで市場がどれだけ近いか)、エクスポージャーレポート(いくつの取引先に分散しているかにかかわらず、ポートフォリオのうち同じリスクにさらされている割合)、そして持続期間レポート(このサービスへの呼び出しの結果が、リーダーが入れ替わるまで実際にどれだけ持続するかを示します。このサービス独自のオンチェーン証明に基づいて測定するため、競合するフィードでは生成できません)。

稼働中: https://yieldsignal.vercel.app

GET https://yieldsignal.vercel.app/signal/eth-staking-yield
GET https://yieldsignal.vercel.app/signal/usdc-base-yield
GET https://yieldsignal.vercel.app/signal/weth-base-yield

GET https://yieldsignal.vercel.app/decision/eth-staking-yield?position=lido&amountUsd=25000&horizonDays=30

GET https://yieldsignal.vercel.app/durability/weth-base-yield
GET https://yieldsignal.vercel.app/capacity/usdc-base-yield?amountUsd=200000
GET https://yieldsignal.vercel.app/sensitivity/usdc-base-yield
GET https://yieldsignal.vercel.app/exposure/usdc-base-yield?positions=aave:200000,morpho:150000
GET https://yieldsignal.vercel.app/persistence/usdc-base-yield

資産を指定せずに /signal と /decision を呼び出すと、最も強い検証済み実績を持つ資産である ETH ステーキングのルートにリダイレクトされます。/signal/usdc のような短縮形式は、正規のパスにリダイレクトされます。

どの資産を信頼すべきですか?

私たちの言葉だけを信じる必要はありません。GET /accuracy.json は無料で、許容誤差内のヒット率と平均後悔値(bps)を資産ごとに返します。これらは公開オンチェーンのEAS実績から 1 対 1 で算出されます。執筆時点では、ステーキングのシグナルは USDC レンディングのシグナルよりはるかに良好です(Base の USDC は変動が速すぎるため、シグナルの正確さを保てません)。これが、ステーキングを主力製品としている理由です。数値はここで断言しているのではなく、チェーンデータから再計算されます。支払う前にご自身でご確認ください。

支払いをせずに呼び出すと、支払うべき正確な価格/資産/ネットワークを記載した 402 Payment Required が返されます。x402 対応クライアントならどれでも自動的に支払いを完了できます。たとえば、@x402/fetchを使う方法があります。

import { wrapFetchWithPayment } from "@x402/fetch";
import { CdpX402Client } from "@coinbase/cdp-sdk/x402"; // or any other x402 client/signer

const client = new CdpX402Client(); // needs CDP_API_KEY_ID/SECRET/WALLET_SECRET + a funded wallet
const fetchWithPayment = wrapFetchWithPayment(fetch, client);

const res = await fetchWithPayment("https://yieldsignal.vercel.app/signal/usdc-base-yield");
console.log(await res.json());
// { bestProtocol: "compound", gapBps: 57, rates: [...], asOf: "..." }
MCP

https://yieldsignal.vercel.app/mcp では、有料の MCP ツールとしても利用できます。get_yield_signal と get_yield_decision があり、どちらも任意の asset("ETH_STAKING"、"USDC"、"WETH"。既に公開済みのインテグレーションとの後方互換性のため、デフォルトは "USDC")を指定できます。多くの自律型エージェントフレームワークは、独自に実装した x402 HTTP クライアントではなく、MCP 経由でツールを検出して呼び出します。公式の@x402/mcpパッケージを使用しています。支払いはツール呼び出しごとに要求されます(tools/list と initialize は無料で、支払いが必要なのはツール呼び出しのみです)。公式レジストリではelizaOS プラグインも利用できます。

レスポンス形式

すべての利回りには、取得元を示すタグが付いています。onchain/api(Aave、Compound、Morpho — プロトコルから直接読み取り)または defillama(Moonwell、Euler、Fluid — DefiLlama yields API 経由)です。推定値や捏造した数値はありません。取得元でエラーが発生した場合や無効なデータが返された場合、その取得元のデータはレスポンスから除外され、推測で補われることはありません。

また、すべての利回りは、明示された単一の基準(apyBasis: "supply-apy-total-incl-rewards")で比較されます。これは、ベース金利とインセンティブを合わせたものです。生データの取得元によって「APY」の意味が異なるため、これは重要です。オンチェーンの liquidityRate/getSupplyRate はベース金利のみを示す一方で、DefiLlama の集計値と Morpho の netApy には、すでに報酬トークンが含まれています。これらを調整せずに横並びでランキングすると、異なるものを比較することになります。取得元が個別に示している場合、各利回りには apyBaseBps/apyRewardBps が記載され、rewardBasis にはインセンティブ要素の取得方法(reported、inferred、included-not-itemized、unavailable)が示されます。インセンティブをまったく確認できなかったプロトコルは incompleteRewardData に記載されます。その APY は下限値であり、確定的な評価ではありません。

{
  "asset": "USDC",
  "bestProtocol": "compound",
  "gapBps": 150,
  "rates": [
    { "protocol": "compound", "apyBps": 601, "apyBaseBps": 601, "apyRewardBps": 0, "rewardBasis": "reported", "tvlUsd": 8446455, "tvlBasis": "total-supplied", "weightedApyBps": 595, "source": "onchain", "asOf": "2026-07-30T..." },
    { "protocol": "moonwell", "apyBps": 434, "apyBaseBps": 403, "apyRewardBps": 31, "rewardBasis": "reported", "tvlUsd": 2643239, "tvlBasis": "aggregator-reported", "weightedApyBps": 382, "source": "defillama", "asOf": "..." }
  ],
  "omittedProtocols": ["euler"],
  "coverage": { "read": 5, "expected": 6 },
  "apyBasis": "supply-apy-total-incl-rewards",
  "incompleteRewardData": [],
  "asOf": "2026-07-30T..."
}
流動性の厚みと、利回りがキャンペーンによるものかどうか

各利回りには tvlUsd も含まれ、tvlBasis にその数値が示す内容が記載されます。プロトコル独自の帳簿(Aave totalAToken、Comet totalSupply、Morpho totalAssetsUsd)に由来する場合は total-supplied、利用可能な流動性を報告する DefiLlama に由来する場合は aggregator-reported です。これらは同じ数量ではなく、フィールドによってどちらの値かがわかります。流動性の厚みが重要なのは、薄い市場の最上位利回りが、大口取引で実際に得られる利回りとは限らないためです。執筆時点では、WETH のシグナルは、市場規模が $716k で利回りの 59% がインセンティブキャンペーンによる市場をトップとして示しています。

判断ルートは、両方の要素を考慮します。/decision/* は gainDependsOnIncentives と positionShareOfDestinationPct を返し、人間が読める reason にもその内容を記載します。また、保有ポジションが移動先に占める割合が大きい場合は、信頼度を下げます。実際のレスポンスの例:

MOVE、信頼度 medium — 「aave → euler に移動すると、リスク調整後利回りが +106bps になります……注:利得のすべては euler のインセンティブキャンペーン(291bps のうち 172bps)によるものです。キャンペーンが終了すれば、この利得はなくなります。注:お客様の $200,000 は、euler の $716,897 の市場の 27.9% に相当します。移動の目的である利回りは、参入することで薄まるほどの大きさです。」

利回りは本物ですか? — /durability/*

各プロトコルの APY を基本金利とインセンティブに分け、インセンティブ終了後の最低利回り、つまり報酬キャンペーンが終了した場合に維持できる利回りを報告します。2026-08-05 時点のライブデータでは、Base 上の WETH で euler が 299bps と最も高く、その 57.9% がインセンティブで、最低利回りは 126bps でした。一方、aave の 153bps はすべて基本金利でした。インセンティブを除くと順位は逆転します。シグナルエンドポイントだけを見ていた場合、euler を勧めていたでしょう。

誤警報を発生させないため、次の 2 つのルールを設けています。

  • 内訳が示されたソースのみを分解します。 rewardBasis: "included-not-itemized" または "unavailable" の場合、最低利回りは不明であり、そのプロトコルは undecomposable に記載されます。インセンティブがないものとして扱うことは決してありません。報告されたインセンティブがないことは、インセンティブが存在しない証拠にはなりません。
  • 首位のプロトコルが不透明な場合、順位について断定しません。 現在の最良プロトコルを分解できない場合、rankingChangesWithoutIncentives は false ではなく null になります。それでも bestVerifiableFloor、つまりインセンティブに依存しないことが証明された最高利回りが得られます。これはどちらの場合も、十分に測定された情報です。

貸付のみ(USDC/WETH)。 2026-08-05 にライブデータを確認したところ、DefiLlama 上では 5 つすべてのリキッドステーキングソースが apyReward: null を報告しており、呼び出しごとに分解できるものは 0/5 でした。そのため、ETH ステーキングの耐久性を確認するルートでは、「確証を得られない」ことに料金を課すことになります。ステーキング利回りがインセンティブなしである可能性はありますが、apyReward が欠けているだけでは証明になりません。これは、このサービスが貸付側の fluid/morpho についても行わない推論と同じです。

日付の予測は意図的に行いません。 「このキャンペーンはいつ終了するか」を調べる明白な情報源は Merkl の API(earliestCampaignEnd)です。2026-08-05 に api.merkl.xyz/v4/opportunities?chainId=8453&status=LIVE をライブで確認したところ、Aave、Compound、Euler、Fluid の LEND キャンペーンは 0 件で、Morpho/Moonwell は、このサービスが読み取るマーケットではない、厳選された MetaMorpho ボールトとしてのみ表示されました。status=PAST はタイムスタンプが null のため、更新履歴も測定できません。ボールトとの一致を推測して 6 つのプロトコルのうち 2 つを対象にしても、キャンペーンの多くは毎週更新され、自動延長されるため、確信があるように見えて実際には間違った数値を返すことになります。それは、このサービスが提供する価値とは正反対です。

実際に引き出せますか? — /capacity/*

利用率 99% の貸付マーケットは利回りが非常に高くても、出金できないことがあります。高い利率そのものが、その兆候です。tvlUsd ではこの 2 つを区別できません。1 億ドルが供給されていて 9,900 万ドルが借りられている場合と、1 億ドルが供給されていて 1,000 万ドルが借りられている場合とで、数値は同じです。

利用率と利用可能な流動性は、利率を取得する際の同じ呼び出しで、各プロトコル独自の帳簿から取得します(Aave:getReserveData のタプル、Compound:getUtilization() + totalSupply())。そのため、追加の RPC コストはかかりません。?amountUsd= を渡すと、各プロトコルについて、その金額を今すぐ引き出せるか(canExitNow)、カバー率、およびその金額がマーケットに占める割合が報告されます。

Morpho および DefiLlama を情報源とするプロトコルは、借入額と供給額を公開していないため、measured: false とされ、bestProtocolExecutable として返されることは決してありません。未測定は流動性があるという意味ではありません。米ドルの数値は USDC のみを対象とします。WETH 残高を換算するには、有料のレスポンス経路内で価格オラクルが必要になるためです。WETH についても、単位のない値である利用率は取得されます。

リプライシングまでどれくらいかかりますか? — /sensitivity/*

貸出金利は単なる数値ではなく、キンクがある利用率の関数です。キンクを下回ると金利はじわじわ上がり、上回ると急上昇します。2026-08-05 時点のライブデータをご覧ください:

             utilization   kink   headroom   borrow APY at 90% → 93%
compound USDC   89.82%      90%    0.18pp        4.08%  →  15.95%
aave     USDC   86.16%      90%    3.84pp        4.60%  →   7.79%

Compound の USDC マーケットは、転換点までわずか 0.18 ポイントでした。シグナルのエンドポイントだけを見ると、健全な 3.29% の供給 APY が表示されるだけで、そのことは何も分かりません。

キンクと両方の傾きは、各プロトコル独自の金利コントラクトから読み取ります。Compound では、再構築したカーブをコントラクト独自の純粋関数である getBorrowRate(u) と照合し、利用率 50/85/90/93/99% で wei 単位まで一致することを確認しています。Aave では、コントラクト自身が報告する上限(base + slope1 + slope2 == getMaxVariableBorrowRate)と照合してカーブの形状を確認しています。いずれかのチェックに失敗した場合、そのプロトコルは対象から外します。変更された数式から導いた数値を提供することはありません。

また、このルートは貸し手ではなく、借り手に向けて情報を提供する最初のルートでもあります。

Aave と Compound のみです。 Morpho の AdaptiveCurveIRM は、ライブで確認したところ、独立した3つの理由から対象外です。カーブ定数がオンチェーンで公開されていません(CURVE_STEEPNESS、TARGET_UTILIZATION、ADJUSTMENT_SPEED、INITIAL_RATE_AT_TARGET はすべて internal constant のため、使用するにはリポジトリからコピーした数値をハードコードする必要があります)。読み取り可能な rateAtTarget(id) は、静的なカーブではなく時間とともに変動する状態であるため、「利用率 95% の金利」に固定の答えはありません。また、このサービスが読み取るのはボールト(Gauntlet USDC Prime、5つの Blue マーケットにまたがる 4億2900万ドル、担保はそれぞれ異なります)であり、キュレーターが自由に再配分します。Moonwell、Euler、Fluid はカーブにアクセスできず、DefiLlama のデータを使用しています。これらはすべて measured: false として報告し、安定した値として扱うことはありません。

3つのラッパーに潜む1つのリスク — /exposure/*
GET /exposure/usdc-base-yield?positions=aave:200000,compound:50000,morpho:150000

市場にはイベント検知ツールがあふれています。デペッグアラート、ハックアラート、清算アラートなど、そのほとんどは無料です。しかし、実際に金銭的損失につながる問いに答えるものはありません。「自分はエクスポージャーを抱えているのか、抱えているとすればどの経路からなのか?」

Stream Financeの破綻では、約320のMetaMorphoボールトのうち、問題の資産を直接保有していたのはわずか1つ(70万ドルの不良債権)でした。それにもかかわらず、エクスポージャーが間接的に及んだことで、9,300万ドルの損失が2億8,500万ドルの連鎖的損失に膨らみました。この事象は数時間以内に公になりましたが、人々に損失をもたらしたのは、そこまで2ホップの距離にあると知らなかったことです。

上記のポートフォリオを対象に、2026-08-06に実際に取得したデータです。

$400k across 3 venues — $200k attributable

  collateral  cbBTC       81.0%   via compound+morpho   ← shared
  curator     0x9e33fa…   75.0%   via morpho
  collateral  WETH        13.4%   via compound+morpho   ← shared
  parameter   kink=9000  100.0%   via aave+compound     ← shared

  unattributed: aave $200k

3つの市場のうち、帰属可能な資本の81%が1つの担保に集中しています。kinkの行は別の事実を示しています。AaveとCompoundはどちらも利用率がちょうど90%に達すると金利が再設定されるため、資本を両者に分散しても、利用率ショックに対する保護にはまったくなりません。

帰属方法はプロトコルによって異なります。リスク構造が異なるためです。basisフィールドには、採用された方法が示されます。

  • Morpho(isolated-market) — 各Blueマーケットは単一の担保で隔離されているため、正確に帰属できます。
  • Compound(collateral-basket) — 定義済みの担保バスケットに対して1つのベース資産が設定され、実際に供給されている額(totalsCollateral × Comet独自の価格フィード)に基づいて加重されます。測定値:cbBTC 43.1%、WETH 37.4%、tBTC 7.8%、cbETH 6.9%、wstETH 4.8%。
  • Aave — 帰属不能として報告されます。これは調査不足のためではありません。v3の供給者はプール全体の担保セットにエクスポージャーを持ちます。1つの資産に帰属させるのは誤りです。また、すべての資産に分割して帰属させると、実際には存在しない分散があるかのように見えてしまいます。

割合は合計額ではなく、帰属可能な資本に対するものです。合計額に対する割合なら小さくなり、実態は可視性が低いだけなのに、集中度も低いかのように見えてしまいます。coverageには両方が示されます。

これは構造的な共通エクスポージャー、つまり「これらのポジションは同じものに依存している」という事実を測定するもので、統計的な相関ではありません。どの程度連動して価格が動くかを示すには、このサービスが持たない価格履歴が必要です。その主張は、より強く見せかけた、より根拠の弱いものになってしまいます。

再帰的な担保の検出は、意図的に行っていません。 Base上の稼働中Morphoマーケット77件をリアルタイムで調べたところ、循環依存はゼロで、担保とローン資産の両方になっている資産もゼロでした。さらに問題なのは、Streamを破綻させた再帰構造は貸付グラフ内ではなく、合成資産の発行にあったことです(借り入れたUSDCで資金調達したポジションを裏付けとするxUSD)。循環依存検出器は、破綻の間ずっと「問題なし」と報告していたでしょう。誤った安心感は、誤警報よりも有害です。

回答はどれくらい持続しますか? — /persistence/*
GET /persistence/usdc-base-yield

ここにあるほかのすべてのエンドポイントも、競合する利回りフィードも、答えるのは「今、最も高いリターンを得られるのはどこか」です。「それがどれくらい続くのか」に答えるものはありません。しかし、資金を移動する価値があるかどうかを決めるのは、この数字です。

このエンドポイントは、Base 上のこのサービス独自の毎時アテステーションを基に、持続期間を回答します。24 日間にわたる 439 件のアテステーションを見ると、3 つのアセットはまったく別の性質を持っています。

アセット首位の交代回数首位の継続時間の中央値ガス代を差し引く前に、1 万ドルあたり追いかける価値がある額
WETH レンディング0> 518h(下限値、右側打ち切り)$6.50
ETH リキッドステーキング1026h$0.018
USDC レンディング1672h$0.011

USDC の 167 回の切り替えの半分は、同じ 2 つのプロトコル間の往復です(compound <-> fluid)。このシグナルを文字どおりに追うと、エッジの価値を上回るガス代がかかります。そして、このエンドポイントが登場するまでは、カタログのどこにもそのことは示されていませんでした。

また、ほとんどの人が前提としている考えを、実証的に明らかにします。リードが大きくても、長続きするとは限りません。 完了した首位維持期間 177 件におけるスピアマン相関は -0.04 で、0-24bps と >=300bps の両方の区分で中央値は 2h です。差の大きさは信頼性を測る指標として使えません。このサービスに不都合な結果であっても、この数字を公開しているのはここだけです。

/decision/* ルートは、この情報を内部で利用します。期待利益は、指定された期間または測定されたリードの継続時間のうち、短い方を基準に予測されます。2h のエッジを 30 日間にわたって予測すれば、ガス代しか回収できない MOVE が推奨されてしまいます。

注釈ではなく、ペイロード内に明記された正直な制約事項です。観測間隔は 1h のため、それより短いリードは見えません。リードがまだ交代していないアセットでは、中央値ではなく下限値と打ち切りフラグを返します。また、すべての数値にはサンプル数が付随し、サンプルが少なすぎる場合は null になります。入力はすべて公開アテステーション UID です。base.easscan.org からレポート全体を再計算すれば、このサーバーを信頼しなくても同じ数値が得られます。

シグナルはどれくらい有効ですか?

GET /accuracy.json(無料)では、公開オンチェーンアテステーションから導出した、独立した 2 つの指標を確認できます。

  • score — 方向性の指標です。現時点の市場と照らして評価したとき、フラグが付けられたプロトコルが依然として首位(または 25bps 以内)だったかどうかを示します。
  • windowedScore — 各アテステーションをそれぞれの有効期間、つまりそのアセットに対する次のアテステーションに置き換えられるまでの期間について評価した値です。medianWindowHours は「どれくらいの頻度で再確認すべきか」への実用的な答えで、市場によって大きく異なります。2026-07-30 時点の記録では、ETH リキッドステーキングと WETH レンディングは 13h、Base 上の USDC レンディングは 1hです。USDC の入れ替わりが速いのは市場の特性であり、このエンドポイントが隠している欠陥ではありません。
実績の記録がシグナル以外にも広がりました

このサービスの主張はすべて、約束ではなく、検証可能であることです。そして2026-08-06までは、EASの記録が対象としていたのはシグナルのみでした。4つの分析プロダクトは、シグナルが築いた信頼性に頼って販売されていましたが、その信頼性には何も還元せず、評価を付けることもできませんでした。

SENSITIVITY_SCHEMAは、それを変える最初のものです。感応度を最初に選んだのには、明確な理由があります。後にその記録が実証的な問いに答えるのは、このプロダクトだけだからです。各読み取り時の利用率とキンクがオンチェーンに記録されれば、蓄積された履歴から、最終的に「キンクから0.5ポイント以内にあった市場は、どれくらいの頻度でキンクを超え、その速さはどれほどだったか?」に答えられるようになり、ヘッドルームの数値は単なる説明にとどまらなくなります。

アテステーションの対象は測定済みのエントリーのみです(未測定のエントリーをエンコードするとエラーになります)。また、記録されるのはキンクから5パーセントポイント以内の市場だけです。読み取りのたびにすべてをアテストすると、コストに上限がなくなります。また、利用率60%で停滞している市場からは、1か月後に新たに得られる情報はありません。

EAS_SENSITIVITY_SCHEMA_UIDによって制御されます。値が空の場合、トリガーは実行されません。これは、v2シグナル移行で使われた、設定を省略することで切り替えるのと同じ方式です。登録には実際のガス代がかかり、npm run register-schemaを使って型付きのCONFIRMを指定する必要があります。

検証可能性

すべてのオンチェーン成果物、それぞれを検証する正確なコマンド、そしてこのスタックでは解決できないことの率直な一覧を含む詳細な説明は、docs/verifiable-agent-trust.mdをご覧ください。

応答が改ざんまたは捏造されていないことを確認するには、独立した方法が2つあります。どちらも、確認時点でこのサーバーが稼働していると信頼する必要はありません。

  • 署名付き応答 — すべてのREST/MCP応答は、402の支払い要件で指定されているのと同じpayToアドレスによって署名されます(EIP-712型付きデータ)。構造体(asset、bestProtocol、weightedApyBps、gapBps、asOf、contentHash)は、以下のオンチェーンEASスキーマを反映し、応答全体に紐付けるcontentHash(応答本文そのもののkeccak256)が追加されています。RESTでは、X-Signal-Signature/X-Signal-Signer/X-Signal-Eip712-Payloadヘッダーを使います。MCPでは、独立したコンテンツブロックを使います。viemのverifyTypedDataで検証できます。または、yieldsignal-clientパッケージのgetSignalVerified()を呼び出せば、両方のチェックを実行できます。
  • オンチェーンアテステーション(EAS、Baseメインネット) — 「時刻Tに、プロトコルXがY bpsを支払い、次点よりZだけ上回っていた」という定期的な公開・恒久記録です。easscan.orgで、このサーバーをまったく信頼せずに個別に確認できます。アテスターのアドレスは、上記の署名付き応答と同じです。シグナルに大きな変化があった場合(最良のプロトコルが切り替わる、または差が25bps以上変動する)、あるいは古くなった場合(前回の記録から12時間以上経過)に自動的に公開されます。詳細はsrc/attestation/autoAttest.tsとPOST /internal/auto-attestをご覧ください(cronでトリガーされ、支払いのたびに実行されるわけではありません。毎回実行するとコストに上限がなくなるためです)。手動でオンデマンド公開するためのnpm run attestも引き続き利用できます。完全な履歴はGET /track-record(または/track-record.json)で確認できます。
  • エージェントの発見(ERC-8004、Baseメインネット) — GET /agent-card.jsonが登録ファイルです。agentId 59272はすでにIdentityRegistryでミント済みです。実際の購入者(サービス自身のものではないウォレット。コントラクトによって、所有者/オペレーターによる自己フィードバックはブロックされます)は、npm run give-feedbackを実行してReputationRegistryに検証可能なフィードバックを残せます。アドレスとABIはsrc/attestation/erc8004.tsにあります。

アーキテクチャ

YieldPilot(個人用の Aave/Morpho/Compound リバランサー)の姉妹プロジェクトですが、完全に独立しています。CDP の認証情報、受取ウォレット、実行時コードは共有しません。技術的な詳細と脅威モデルについては、CLAUDE.md と SECURITY.md を参照してください。

  • src/expressApp.ts — Express アプリと x402 決済ゲート(createX402Server、@x402/express)です。ローカル開発サーバー(src/server.ts)と Vercel サーバーレスエントリーポイント(api/index.ts)の両方で再利用されます。アセットごとに決済保護されたルートを 1 つずつ登録し(RESOURCE_PATHS)、未決済の /health 稼働確認エンドポイントも登録します。
  • src/signal/ — 純粋で決定論的な比較ロジックです(I/O なし、ユニットテスト済み)。
  • src/market-data/ — アセット(AssetId、USDC/WETH)を config/networks.ts の BASE_ASSETS 経由でパラメーター化した、2 層のデータ取得処理(直接読み取り+DefiLlama)です。
  • src/wallet/walletLock.ts — 受取ウォレットアドレスを固定します(サーバーレス環境では永続ディスクがないため、本番環境では EXPECTED_WALLET_ADDRESS を使用)。これにより、CDP 認証情報のローテーション時に、決済先が気付かないうちに変更されるのではなく、明確に検出されます。
  • src/mcp.ts — get_yield_signal MCP ツール(任意の asset パラメーター)です。@x402/mcp の createPaymentWrapper で呼び出しごとに決済を要求します(tools/list や initialize までペイウォールで保護してしまう、Express のルート全体を対象としたミドルウェアは使用しません)。
  • src/market-data/cache.ts — すべてのレート読み取り(直接読み取り+DefiLlama)に 30 秒の TTL を設定します。アセットごとにキャッシュインスタンスを 1 つ設けるため、有料呼び出しが同時に集中しても、公開 RPC/API エンドポイントに過剰なリクエストを送りません。
  • src/notify/paymentLog.ts — 決済が確定するたびに(REST と MCP の両方の決済サーバーで onAfterSettle を使用)、支払者/tx/ネットワーク/金額を記録し、所有者以外のウォレットからの決済(実際の販売)を通知します。
  • src/usage/ — 永続的なファネルカウンター(usageStore.ts+usageMiddleware.ts)です。GET /usage.json で参照できます(認証が必要です)。ルート/アセットごとに、提供した 402、決済試行、決済完了、失敗、404 の件数をカウントします。販売側の各段階(paid_attempt/served/settled/failed)は、1 日あたりのイベント予算の対象外です。クローラーのノイズが以前は正午前に予算を使い切り、「これは売れるのか?」という問いに答えるデータ行をちょうど消していました。プラットフォームの実行時ログには外部からアクセスできず、監査可能な唯一のシグナルがオンチェーン収益だったために追加されています。オンチェーン収益だけでは、「誰もアクセスしていない」のか「アクセスはあるが支払われていない」のかを区別できません。バックエンドには、REST API を持つ任意の Redis を使用できます。認証情報は環境変数名のサフィックスで検出されるため、Vercel ダッシュボード経由で接続されたストア(環境変数にプレフィックスが付けられて注入されます)も、コード変更なしで検出されます。ストアが設定されていない場合は、インスタンスごとのインメモリカウンターにフォールバックし、"durable": false を返します。
  • src/cli/withdraw.ts — 蓄積した USDC を所有者の個人ウォレットに送金します。手動で CONFIRM の指定が必須で、自動実行はされません。
  • src/wallet/signerAccount.ts — signMessage/signTypedData/sendTransaction を公開する、同じ受取ウォレットを解決します(createX402Server が公開するのはアドレスのみです)。レスポンスの署名と EAS アテステーションに使用します。
  • src/attestation/ — EAS スキーマ定義と calldata エンコード(純粋な処理で、ユニットテスト済み)、共有のトランザクション送信ロジックを担う publishAttestation.ts、EASScan の GraphQL クライアントとデコーダーを担う queryAttestations.ts、自動トリガーのための純粋な判定ロジックとオーケストレーションを担う autoAttest.ts、当時と現在の比較を担う trackRecord.ts、ERC-8004 のレジストリアドレスと ABI を担う erc8004.ts があります。
  • src/cli/registerSchema.ts/src/cli/attestSignal.ts/src/cli/registerAgent.ts/src/cli/giveFeedback.ts — それぞれ、スキーマの一度限りの登録、アテステーションごとの手動公開、ERC-8004 ID の一度限りの発行、購入者側からの評判フィードバックを行います。withdraw.ts と同じ CONFIRM パターンを使用します。giveFeedback.ts は wallet/signerAccount.ts とは意図的に異なるウォレットを解決する唯一のスクリプトです。コントラクトは、サービス自身のアドレスからのフィードバックを拒否します。

ローカル開発

npm install
npm test                # automated tests (market-data readers, signal logic, retry, wallet lock, usage funnel)
npm run signal            # live signal, real data, zero credentials needed (`npm run signal -- ETH_STAKING` / `-- WETH` for the other assets)
npm run dev               # local x402 server (reads X402_ENVIRONMENT from .env)
npm run test:paid         # spins up a test buyer wallet, funds it via the CDP faucet, pays for real (testnet only, REST endpoint)
npm run withdraw          # sweep accumulated USDC — asks for typed "CONFIRM"
npm run register-schema   # one-time EAS schema registration (mainnet, real gas) — asks for typed "CONFIRM"
npm run attest             # publish one on-chain attestation of the current signal (mainnet, real gas) — asks for typed "CONFIRM"
npm run register-agent    # one-time ERC-8004 identity mint (mainnet, real gas) — asks for typed "CONFIRM"
npm run give-feedback     # a REAL buyer leaves feedback on ReputationRegistry (mainnet, real gas) — asks for typed "CONFIRM". Fails with "Self-feedback not allowed" if run from the service's own wallet.

必要な変数については .env.example を参照してください。portal.cdp.coinbase.com で専用の CDP プロジェクトと認証情報を作成してください。ほかのプロジェクトのものは決して再利用しないでください。

ソース

github.com/Stakemate369/yieldsignal — オープンソースで、プッシュまたは PR のたびに CI で型チェックと全テストスイートが実行されます。

Spark、Seamless、Silo がプロトコル一覧にない理由

2026-07-16 に yields.llama.fi/pools を確認し、chain=Base と symbol=USDC で絞り込みました。Base 上で Spark にあるのは USDC ではなく USDS のプールのみです。Seamless と Silo には、現時点でインデックス登録済みの Base プールがありません。数値を捏造するのではなく、Base 上に実際の USDC マーケットができるまで、この 3 つは対象外にしています。詳しくは src/market-data/types.ts のコメントを参照してください。

WETH は含まれ、WBTC/cbBTC は含まれない理由

2026-07-17 に yields.llama.fi/pools をリアルタイムで確認しました。Base 上に正規の「WBTC」マーケットはなく、あるのは Coinbase の cbBTC(別の資産)のみです。また、マーケットが存在する場合でも、6 つすべてのプロトコルで供給 APY は約 0〜0.2%です。どのプロトコルもほぼ横並びでゼロ近辺にあるとき、「どれが最良か」はほとんど重要ではないため、売りにするには変動が小さすぎる指標です。一方、WETH には 6 つすべてのプロトコルで実際に異なる利回り(0.66%〜3.7%)があるため、代わりにこの資産を追加しました。

コメント

MCP は初めてですか?

プロトコルの概要から最初のサーバーの導入まで、よくある疑問にまとめて答えます。

AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。