ステークプールの報酬と手数料をめぐる設計変更が、Cardano の週次開発レポート（8 月 7 日付）に 2 行だけ書かれています。CIP-50（プレッジのレバレッジに応じた報酬）が実装され、CIP-23 の下ごしらえとして minPoolMargin というプロトコルパラメータが Dijkstra 期の台帳に追加された、という報告です。
片方はプールが受け取れる報酬に上限を置く仕組み、もう片方はプールが取る可変手数料に下限を置く仕組みです。どちらも、委任先を選ぶ側と運用する側の双方に効きます。ただし、これは「決まった」という話ではありません。台帳のコードに入ったという段階と、実際に効き始める段階のあいだには距離があります。その距離を含めて、順に見ていきます。
■ CIP-50 が置こうとしている上限——プレッジの何倍までなら満額なのか
CIP-50 の正式名称は「Pledge Leverage-Based Staking Rewards」で、状態は Proposed（提案中）です。
導入されるのは L という新しいパラメータで、CIP はこれを「報酬が頭打ちになるまでの、プレッジに対する総ステークの最大比率」と定義しています。報酬計算に使われる有効ステークの式は次の形になります。
σ’ = min(σ, L · p, z₀)
σ がプールの総ステーク（プレッジ + 委任分）、p がプレッジ、z₀ が飽和点（流通 ADA ÷ k）です。つまりプールには上限が二重にかかることになります。従来からある飽和点による上限と、プレッジの L 倍という上限です。プレッジが小さいプールは、飽和点に届く前にレバレッジ側の上限に当たります。
なぜこれが必要とされているのか。CIP が挙げているのは、実際の分散度が k = 500 という設定ほどには進んでいないという認識です。エポック 560 時点で「473 のプールがプレッジをゼロにしたまま、2,740,223,943 ADA の委任分を集めている」と CIP は記しています。単一の主体が数十のプールを運用することで、実効的な独立運用者は 500 ではなく 25 程度にとどまっている、という見立てです。
既存パラメータで対処できない理由も書かれています。プレッジ影響度 a₀ を上げれば小規模プールが不利になり、k だけを上げれば大規模プールの分割を促しかねない。だから、レバレッジそのものを直接制約する別の仕組みが要る——というのが提案の筋です。
L の値域は 1 から 10,000 とされていますが、いくつに置くかは決まっていません。式が入っただけで、効き方は数値で決まります。
■ minPoolMargin が置く床——minPoolCost とは別の、二本目の下限
もう一方の CIP-23 は「Fair Min Fees」、こちらも状態は Proposed です。
追加される minPoolMargin は、CIP の言葉では「ステークプールが設定できる可変手数料（マージン）の下限」です。仕様としては、プールの登録証明書・更新証明書が margin >= minPoolMargin を満たすことを求めます。既に登録済みのプールについては、マージンが新しい下限を下回っている場合、報酬計算の時点でプロトコル側の minPoolMargin がプールの登録値を上書きする、と書かれています。
重要なのは、これが既存の固定手数料の下限（minPoolCost）とは独立しているという点です。固定費の下限を変えるものではなく、可変手数料の側にもう一本、別の下限を立てる設計になっています。
提案文書は、既存のプール証明書を壊さないために初期値をゼロに置くとしています。つまり導入した瞬間には誰の設定も変わりません。動くのは、値をゼロ以外に決めたときです。
動機として書かれているのは、固定手数料が小規模プールの委任者に不釣り合いな負担をかけているという問題意識です。同じ論点は、いま進行中の minPoolCost を 170 ada から 75 ada へ下げる提案でも扱われています（Weekly Brief #18）。ただし両者は別のものです。片方は既にあるパラメータの値をガバナンス投票で動かす話、もう片方は新しいパラメータそのものを台帳に足す話です。手数料の床は、いま一本ではなく二本立てで議論されていると読むのが正確です。
■ 「台帳コードに入る」と「有効になる」の距離
ここを混同すると、記事の意味が反転します。
週次レポートが報告しているのは、Dijkstra 期の台帳実装への反映です。CIP-50 は実装され、CIP-23 は minPoolMargin の追加という下ごしらえの段階にあります。両 CIP とも、状態は Proposed のままです。
実際に効き始めるには、少なくとも二つの段階が残っています。ひとつはハードフォークによる有効化。もうひとつはパラメータ値の決定です。L をいくつにするか、minPoolMargin をゼロから動かすのか——ここが決まらない限り、式は入っていても挙動は変わりません。
言い換えると、今回の 2 行は「議論の対象が、文書の上から実装の上へ移った」という報告です。決着ではありませんが、決着したときに何が起きるかを事前に読める状態にはなりました。プレッジをどれだけ入れているか、マージンをどう設定しているか——その二つが、これまでとは違う重みを持つ可能性が出てきたということです。
同じレポートの台帳節には、Leios 対応でプールパラメータのプレースホルダを実際の BLS 鍵へ置き換えたこと、Praos と Leios のブロックヘッダ直列化を往復検証するテスト群を追加したこと、Dijkstra の入れ子トランザクションで払い戻しの仕組みを実装したこと、ブロック内のスクリプトキャッシュとスクリプトハッシュのメモ化を入れたことなども並んでいます。CIP の 2 行は、その中に混ざって置かれていました。
■ 次に見るもの
ふたつあります。
ひとつは、パラメータ値がどこで議論されるかです。L も minPoolMargin も、値が決まらなければ実質的な変更は起きません。値の議論がどの場に立つのか——ガバナンスの提案として出てくるのか、その前に技術的な検討の場を挟むのか。minPoolCost の提案がたどっている経路が、そのまま参考になります。
もうひとつは、Dijkstra ハードフォークの時期です。台帳への実装は Dijkstra 期を対象にしています。同じレポートでは van Rossem ハードフォークのベンチマーク完了も報告されており、順序としてはその先です。時期が見えてきた段階で、この 2 つのパラメータは「いつか」の話から「いつ」の話に変わります。
一次ソース / 関連リンク
- Cardano 週次開発レポート（2026 年 8 月 7 日付・Essential Cardano）
https://www.essentialcardano.io/development-update/weekly-development-report-as-of-2026-08-07 - CIP-0050: Pledge Leverage-Based Staking Rewards（Status: Proposed）
https://github.com/cardano-foundation/CIPs/tree/master/CIP-0050 - CIP-0023: Fair Min Fees（Status: Proposed）
https://github.com/cardano-foundation/CIPs/tree/master/CIP-0023 - 既報：Weekly Brief #18（minPoolCost 提案の投票状況）
https://sipo.tokyo/weekly-brief-18/