こんにちは、よだかです。
今回は、CurveのcrvUSDで使われているPegKeeperという仕組みを調べました。
出発点にあった問いは比較的単純です。
PegKeeperが動ける状態を事前に見つけて、自分で
update()を実行すれば、呼び出し報酬を取れるのではないか。
調べ始めた時点では、かなり単純なKeeper botの候補として見ていました。
最終的には、
報酬はある。
ガス代を引いても残る。
しかも事前に見える。
それでも、個人botterとしては追わない。
という判断になりました。
理由は、観測した大きな報酬の勝者では、PegKeeperから得られる経済価値の大部分に相当する額が、ブロックへの取り込み競争に使われていたためです。
今回は、そこまでを順番に書きます。
1. PegKeeperとは何か
crvUSDは、Curveが発行する米ドル連動型の暗号資産です。
当然、市場価格は常に完全な1ドルになるわけではありません。
crvUSDを含むCurveプールの中で、crvUSDが不足したり過剰になったりすると、価格にも偏りが生まれます。
PegKeeperは、この偏りを調整する仕組みです。
たとえばcrvUSDがプール内で不足している場合、PegKeeperはcrvUSDを片側流動性としてプールへ追加します。
逆にcrvUSDが過剰なら、保有しているLPトークンを使ってプールからcrvUSDを引き抜きます。
かなり単純化すると、
crvUSDが不足
→ crvUSDを追加する
→ 均衡方向へ戻す
または、
crvUSDが過剰
→ crvUSDを引き抜く
→ 均衡方向へ戻す
という仕組みです。
ただし、条件が成立したら自動的に処理が走るわけではありません。
誰かがPegKeeperの update() を呼ぶ必要があります。
この呼び出しは誰でも実行できます。
そして、価格調整によってPegKeeper側に利益が発生すると、その一部が呼び出した側へLPトークンとして支払われます。
つまり、
条件を監視する
→ 利益が出るときだけupdate()を呼ぶ
→ 報酬を受け取る
というbotを作れる可能性があります。
【crvUSDの偏り → PegKeeperの調整 → caller reward、という基本構造】
2. 最初の標本では、報酬はかなり薄く見えた
まず、現在のPegKeeper V2の構造と実際の取引を確認しました。
Ethereum上では、USDC、USDT、PYUSD、frxUSD向けの4つが現在も経済的に有効です。
GHO向けPegKeeperも登録自体は残っていますが、現在は供給上限と負債がともに0で、実質的に休止しています。
最初の調査では、各PegKeeperについて直近の成功した処理を3件程度ずつ取りました。
合計16件です。
この範囲だけを見ると、呼び出し報酬はかなり薄く見えました。
ガス代などを引いた値は中央値で数セント程度。
確認できた最大値も1ドル未満です。
さらに、すでに少数の実行者が繰り返し処理していました。
この段階では、
既存botが数セント単位まで回収しているなら、ここから先を掘る価値は低いのではないか。
と考えました。
ただし、この16件は「各PegKeeperの直近3件程度」という取り方です。
報酬の分布を見るための標本ではありません。
ここでそのまま切ると、
普段は数セントでも、ごく一部に大きな報酬が存在する
という可能性を見落とします。
そこで、最後の確認として30日間へ広げました。
3. 30日分を見ると、判断が一度逆転した
2026年8月24日から9月23日までの30日間について、現在有効な4つのPegKeeperを調べました。
確認できたのは、
- 報酬を伴う経済的な処理：305件
- transaction数：283件
- crvUSDを引き抜く処理：235件
- crvUSDを追加する処理：70件
です。
ここは表現に注意が必要です。
305件は「成功した update() 呼び出しの総数」ではありません。
update() は、時間条件などによって何も処理せず0を返してもtransaction自体は成功できます。
今回数えたのは、
実際にcrvUSDの追加・引き抜きが行われ、報酬LPの移転まで発生した経済的な処理
です。
そして、この305件をその時点のLP価値でドル換算して並べました。
報酬上位10件は、
- 最小：約30.33ドル
- 最大：約76.96ドル
- 中央値：約45.30ドル
でした。
最初に見ていた「数セント」の世界とはかなり違います。
【最初の16件では薄く見えた → 30日305件では30〜77ドルのtailが見つかった、という調査の変化】
ここで、
PegKeeperの報酬は小さすぎるから終了
という最初の判断は撤回しました。
4. Ethereumでも、ガス代は問題ではなかった
次に確認したのはガス代です。
Ethereum L1なので、報酬が数十ドルあったとしてもtransaction costで消える可能性があります。
そこで上位10件について、実際のreceiptから使用ガス量と実効ガス価格を取り、当時のETH価格でドル換算しました。
結果として、上位10件はすべてガス代を引いた後も大幅にプラスでした。
上位10件合計では、
報酬：約484.89ドル
ガス代：約7.89ドル
報酬 − ガス代：約477.00ドル
でした。
中央値でもガス代は約0.23ドルです。
つまり、少なくとも大きな報酬が発生した事例では、
Ethereumだからガス代で消える
という説明は成立しませんでした。
ここまで来ると、条件はかなり良く見えます。
報酬がある。
発生回数もある。
数十ドル級のtailもある。
ガス代を引いても残る。
前回、GHOの価格調整機構を使った裁定を調べたときも、「理論上の余剰があること」と「最終的に自分へ残ること」は分けて考えました。
関連記事：🛠️開発記録#575(2026/9/20) 見えた、取れそう、それでも取らない｜GHO裁定を実装しなかった理由
今回も、この時点ではまだ「取れる」とは判断していません。
5. 大きな報酬は、誰が取っていたのか
30日間で報酬を受け取ったアドレスは16個でした。
ただし、かなり偏っています。
報酬額で見ると、
- 上位1アドレス：約22.6%
- 上位3アドレス：約53.7%
- 上位5アドレス：約78.0%
を取得していました。
さらに、報酬上位10件を取得したのは5アドレスだけです。
そのうち3アドレスが8件を取得しています。
一方で、最も多く処理していたアドレスは30日で121件を実行しているにもかかわらず、報酬Top10には1件も入っていませんでした。
この結果を見ると、
実行可能なら広く拾う高頻度keeper
と、
大きな報酬を選択的に取りに来る実行者
が分かれている可能性があります。
また、305件中、通常のEOAから報酬を受け取っていたのは1件だけでした。
残り304件はcontractまたはEIP-7702のdelegated accountです。
少なくとも、人が画面を見ながら手動で押しているような市場ではありません。
ただし、ここで集計している「caller」は報酬LPを受け取ったbeneficiary addressです。
同じ経済主体が複数アドレスを使っている可能性はあるため、16アドレス＝16人・16botという意味ではありません。
6. 次に、「そもそも事前に見えるのか」を調べた
報酬が大きくても、それが同じブロックの途中で突然生まれるなら、通常の状態監視botでは取れない可能性があります。
そこでTop10について、
実行transactionが入る前の状態から、その機会を見つけられたのか
を再構築しました。
結果は、
10件中10件がブロックへ入る前から検知可能
でした。
ただし、2種類あります。
2件は、一つ前のブロックが確定した時点ですでに報酬が発生していました。
残り8件は、その時点では報酬が0でした。
しかし、親ブロックの状態をそのまま使い、Ethereumの次の候補slotである12秒後の時刻を与えてシミュレーションすると、8件すべてが利益の出る状態になりました。
実際に完成した未来のブロック時刻を後から使ったわけではありません。
12秒後でも24秒後でも同じ報酬額になりました。
つまり、単純に最新ブロックだけをpollingすると2/10しか見えませんが、
次のslotでPegKeeperがどうなるか
まで計算すれば10/10を事前に検知できたことになります。
【親ブロック → 次slotシミュレーション → profitable → update、という事前検知の流れ】
2件では、同じブロック内の先行swapによって報酬がさらに増えていました。
ただし、そのswapが入る前からガス代を十分上回る報酬が存在しています。
つまり、
block内の取引が機会を新しく作った
のではなく、
すでに存在していた機会をさらに大きくした
という形でした。
これで「見えるか」という問いはかなり解決しました。
以前の清算研究でも、
見えるか
→ 予測できるか
→ 取れるか
→ 儲かるか
を分離して考えてきました。
関連記事：🛠️開発記録#572(2026/9/17) 清算エッジ探索をどうフェーズシフトするか？
今回のPegKeeperでは、「見えるか」と「事前に判断できるか」についてはかなり強いところまで進みました。
問題はその先でした。
7. 最後に、報酬がどこへ消えているのかを追った
ここまでの結果だけなら、bot実装へ進んでもよさそうに見えます。
- 数十ドルの報酬がある
- ガス代を引いても残る
- 公開状態から事前検知できる
- 実際に繰り返し取得しているbotもいる
そこで最後に、
勝者は、その数十ドルを最終的にどれだけ自分の利益として残しているのか
を調べました。
ここで判断が決まりました。
Top10の10transactionについて、報酬LPを受け取った後の資産移動、ETHへの換金、ガス代、ブロックの実際のfee recipientへの直接ETH支払いまで再構築しました。
10件中9件では、受け取ったreward LPを同じtransactionの中ですべてETHまで換金していました。
残り1件はLPを保持しています。
さらに2件では、同じtransaction内で複数のPegKeeper報酬をまとめて取得していました。
その分まで含めると、Top10 winner transactionにおけるPegKeeper由来の経済価値は約503.75ドルでした。
そこから、
- actual fee recipientへの直接ETH支払い：約489.31ドル
- ガス代：約7.89ドル
が出ていました。
最終的にactor側へ残ったPnLは、
約6.54ドル
でした。
比率で見ると、
- direct fee-recipient payment：約97.1%
- ガス代：約1.6%
- 最終的に残ったmargin：約1.3%
です。
【約503.75ドル → 約489.31ドル direct payment → 約7.89ドル gas → 約6.54ドル margin、という価値の流れ】
比較する分母を変えても、direct paymentに相当する割合は約94.8〜97.1%でした。
方向は変わりません。
8. 別の裁定利益で支払っていたわけでもなかった
ここで一つ疑いました。
PegKeeper以外の裁定利益が同じtransaction内にあり、その利益を使って大きな支払いをしているだけではないか。
もしそうなら、
PegKeeper rewardのほとんどが競争で消えている
とは言えません。
そこでTop10についてtransaction内部の資産移動を分解しました。
結果として、
- 別の裁定利益
- flash loan由来の利益
- 清算利益
- 別protocolの報酬
- 想定外のERC20流入
は確認されませんでした。
同じブロック内の別transactionからの補填も確認できませんでした。
9件のcashout transactionでは、
rewardを換金して得たETH ＋ ごく小さいmsg.value
＝ fee recipientへの直接支払い ＋ 最終的な払い戻し
がwei単位で一致しました。
残る1件ではreward LPを保持したまま、以前から持っていたETHで直接支払いをしています。
経済的には受け取ったLPがその支出を補っています。
つまり、Top10の勝者について見る限り、
PegKeeperから得られる価値そのものを原資として、ブロックへの取り込み競争をしていた
という説明が最も整合的でした。
ただし、ここも断定範囲には注意します。
オンチェーンで確認できる事実は、
actual block fee recipientへの直接ETH支払い
です。
これがblock inclusionのための入札だったという解釈はかなり強く支持されます。
一方で、private relayやbundleを使っていたことまで証明したわけではありません。
9. 報酬がなかったのではなく、競争で残らなかった
今回の結果を整理すると、
PegKeeperに利益がなかった
わけではありません。
むしろ途中までは、かなり条件が揃っていました。
報酬は存在する
↓
大きなtailもある
↓
ガス代を引いても残る
↓
公開状態から事前検知できる
↓
実際にbotが繰り返し取得している
↓
しかし勝者の最終marginは非常に薄い
という順番です。
問題は価格予測ではありませんでした。
観測速度の問題でもありません。
ガス代でもありません。
最後に残ったのは、
同じ機会を見ている参加者同士で、誰がそのtransactionをブロックへ入れられるか
という実行競争でした。
前回のGHO裁定でも、市場に存在する余剰と、競争後に自分へ残る利益は違うという結果が出ていました。
今回は、それがさらに直接的な形で見えています。
PegKeeperの報酬そのものは数十ドルあります。
しかし、Top10 winnerではその大部分に相当する価値がfee recipientへの直接支払いへ移っていました。
10. 結論を出す前に、調査方法そのものも監査した
今回はcloseする前に、分析方法そのものも独立に再監査しました。
結論は、
方法論監査：限定付きで合格
最終結論：限定付きで支持
closeout前の追加研究：不要
でした。
監査ではいくつか修正点も見つかっています。
一つは、先ほど触れた305件の定義です。
これは成功した update() 呼び出しの全件数ではなく、報酬を伴う経済的action eventの件数です。
もう一つは、最初のTop10抽出です。
当初はLPの数量で順位付けしていました。
異なるpoolを横断して比較する方法としては不適切なので、全305件を過去時点のドル価値へ変換してから再ランキングしました。
結果としてTop10も順位も変わりませんでした。
また、報酬を受け取ったaddressと実際の経済主体は同一とは限りません。
今回の集中度はaddress単位の結果です。
そして約489ドルの直接支払いについても、
private bundleを使った
とは断定していません。
確認したのは、実際のblock fee recipientへの直接ETH支払いです。
最後に、約95〜97%という数字も30日305件全体の話ではありません。
これは、
報酬Top10を実際に取得したwinner transaction
に条件付けた結果です。
この限定を入れた上でも、今回の判断は変わりませんでした。
11. 今回はここで閉じる
PegKeeper caller rewardについては、ここでactive researchを終了します。
理由は、
エッジが存在しないから
ではありません。
また、
技術的に検知できないから
でもありません。
むしろ、
grossの機会は存在し、事前にも見える。しかし、観測した大きな報酬の勝者では、その価値の大部分に相当する額がblock inclusion競争へ移っていた。
という理由です。
個人botterとしてここから先へ進むなら、研究対象はPegKeeperそのものではなく、
- builderへの送信
- transaction inclusion
- 入札設計
- private orderflow
- 複数戦略を束ねたsearcher economics
といった実行層へ移っていきます。
そこまで含めて競争することはできます。
ただ、現在の自分がPegKeeper単体のためにそこへ追加の時間を使う理由は弱いと判断しました。
もう一つ考えていた、PegKeeperが起こす価格変化そのものを裁定する枝も、今回は進めません。
これまで確認した範囲では、同一transaction内での価格遷移裁定も、PegKeeper直後の同一poolでのbackrunも確認できず、PegKeeperによる価格変化も最大約0.307bpsでした。
存在しないと証明したわけではありません。
ただ、新しいシミュレーターや経路探索を作るだけの事前証拠が足りません。
そのため、こちらは否定ではなく凍結とします。
12. 「見える」と「取れる」の間に、実行競争がある
最近の研究では、
見えるか
取れるか
最終的に利益が残るか
を分けて考えることが増えています。
今回のPegKeeperでは、この分解がかなりはっきり出ました。
「見えるか？」については、かなり強くYESでした。
「grossの利益があるか？」もYESです。
それでも、自分に残る利益は別でした。
これまでにも、追加研究を続ければ未解決の問いをさらに減らせる一方で、それが次の意思決定を変えるとは限らないという問題を何度か扱ってきました。
関連記事：🛠️開発記録#570(2026/9/14) 追加研究の限界価値を考える回：市場横断観測機の作成を通して
今回も、まだ分かっていないことは残っています。
成功したものの何も起こらなかった update() の総数。
実際にどのprivate delivery経路を使っていたのか。
複数addressの背後にいる経済主体。
競争に負けたtransactionや未採用bid。
PegKeeperの価格遷移を使った別の裁定経路。
これらは未解です。
ただし、
未解であることと、そこへ次の研究時間を使うことは別
です。
今回のcloseout判断を変えるために、これらをすべて解決する必要はないと判断しました。
【「見える → gross利益 → gas後利益 → 事前検知 → inclusion競争 → 個人botterではDROP」という最終探索フロー】
今回は、
見えなかったから切った
のではありません。
かなりよく見えました。
報酬もありました。
事前にも見えました。
その先まで追った結果、
利益のある場所と、自分に利益が残る場所は同じではない
ことが改めて確認できました。
PegKeeper V2のcaller reward探索は、ここで一区切りにします。
次の候補へ進みます。
それでは、また。
一次情報・公式資料
本記事で扱ったcrvUSD PegKeeper（現在の名称はPeg Stabilization Reserve / PSR）の仕組みについては、以下のCurve公式情報・実装を参照しています。
- Curve公式：Peg Stabilization Reserve（PSR）
Ethereum上で稼働するPSRの現行状態を確認できます。
Curve公式 PSRページ - Curve公式GitHub：PegKeeperV2.vy
update()、crvUSDの追加・引き抜き、caller rewardなど、今回調査したPegKeeper V2本体の実装です。
PegKeeperV2.vy（Curve公式GitHub） - Curve公式GitHub：PegKeeperRegulator.vy
PegKeeperがcrvUSDを追加・引き抜きできる条件を制御するRegulatorの実装です。
PegKeeperRegulator.vy（Curve公式GitHub）