Filecoin NV29「Solstice」とは？Fil+廃止・報酬変更と必要な対応

Filecoinのネットワークアップグレード「NV29（Solstice）」は、2026年10月19日21時59分30秒（日本時間）、epoch 6470279で実施予定です。中心となるFIP-0118は、Filecoin Plus（Fil+）のDataCap制度を廃止し、ブロック報酬の一部を有料サービスの需要に連動させます。epoch（エポック）とは、Filecoinでチェーンの進行位置を表す単位です。

FIL保有者と取引所利用者が確認すべきこと

一般のFIL保有者と、ノードを運用する事業者では必要な対応が異なります。ウォレットにFILを保有しているだけの人が、運用者向けのクライアント更新を行う必要はありません。一方で、アップグレードを口実にした偽の交換案内や、シードフレーズの入力要求には注意してください。

自己管理ウォレットでトークン交換は不要

公式のネットワーク更新案内には、一般の自己管理ウォレット保有者がFILを別のトークンへ交換する手続きは示されていません。ハードフォークという言葉から、新旧コインの交換が必要だと連想しがちですが、今回はネットワークルールと報酬制度の更新です。

利用者は、ウォレット提供元の公式サイトやアプリ内告知で対応状況を確認し、必要な場合のみ正規の更新を適用します。自己管理の基本は暗号資産ウォレットの種類と選び方でも確認できます。秘密鍵やシードフレーズをサポート担当者へ送ることはありません。「期限までに交換しないと資産が消える」と急がせる案内は、公式情報と照合してください。

取引所の入出金停止と取引継続は別

取引所は、アップグレード中に誤ったチェーンへ入金を反映しないよう、FILの入出金を一時停止することがあります。入力・出力を止めても、取引所内の現物取引まで必ず止まるとは限りません。入出金、売買、積立、貸暗号資産などは別機能なので、告知の対象範囲を読み分けましょう。

調査対象では、Binanceが10月19日11時59分UTCからFILの入出金を一時停止し、取引は継続すると告知しています。これは一社の対応例であり、すべての取引所に同じ時刻や方針が適用されるわけではありません。日本国内を含め、自分が利用する事業者の公式告知を個別に確認してください。

再開時刻は各社の公式案内で確認

入出金の再開は、予定時刻の経過だけでなく、ネットワークが安定し、取引所が安全性を確認できたかで決まります。終了予定が書かれていても延長される可能性があるため、停止直前の送金は避け、宛先、ネットワーク、最低入金額、必要な確認数を再確認しましょう。手順は暗号資産を安全に送金する方法も参考になります。

また、アップグレード直後にSNS上の「再開済み」という投稿だけを信じないでください。ログイン画面の表示、取引所のステータスページ、公式サポートの告知を優先します。送金を再開するときは、可能なら少額で宛先を確認してから本送金を行う方法もあります。

Filecoin NV29「Solstice」は2026年10月19日に実施予定

NV29は、Filecoinメインネットの29番目のネットワークバージョンです。「Solstice」という名称が付き、ネットワーク全体が同じルールへ切り替わるハードフォークとして実施されます。予定時刻は2026年10月19日12時59分30秒UTC、日本時間では同日21時59分30秒で、チェーン上の切り替え条件はepoch 6470279への到達です。

実施時刻とメンテナンス予定

公式のネットワーク更新案内は、Lotus、Forest、Venus、Curio、Boostの対応先を示しています。公式ステータスページでは12時59分から13時59分UTCをメンテナンス枠として掲示していますが、これは必ず1時間で全サービスが平常化するという保証ではありません。チェーンが進み、各事業者が安定性を確認するまで、入出金などを長めに止める場合があります。

一般利用者は予定時刻の直前に慌てて送金するより、利用中の取引所やカストディの告知を先に確認するのが安全です。運用者はepoch基準で作業計画を立て、移行前後の同期状態、チェーンヘッド、ブロック生成、メッセージ処理を監視する必要があります。

アップグレードの対象はFIP-0118

NV29の制度変更の中心は、Accepted状態のFIP-0118「Deprecate Fil+ and Fund Services via Block-Reward Split」です。大きく分けると、①DataCapの発行・割当を用いたFil+を廃止する、②新規セクターを一律10倍QAPで評価する、③ブロック報酬を合意報酬とサービス報酬などへ分ける、④条件を満たさず獲得されないサービス枠をバーンする、という変更です。

「報酬が変わる」という一言だけでは、SPの取り分が一律に増減するように聞こえます。しかし実際には、合意維持に対する経路とサービス需要に対する経路が分けられ、サービス側は条件次第で配分されない仕組みです。初期比率と将来の上限も別なので、以下で一つずつ整理します。

Solsticeが目指すのは容量供給からサービス需要への転換

Solsticeの狙いは、保存容量を増やすこと自体への支援から、実際に料金を支払う顧客と継続的なサービス利用を生む活動へ、インセンティブの軸を移すことです。Filecoinがストレージネットワークとして成熟するには、容量の数字だけでなく、データを預けたい利用者、サービスを販売する事業者、支払いが継続する市場が必要だという考え方が背景にあります。

従来の容量拡大モデルが抱えた課題

Fil+では、認証されたクライアントへDataCapを割り当て、そのDataCapを使った検証済み取引を高い品質として評価してきました。この仕組みは、価値のあるデータを呼び込む目的を持つ一方、人による審査や割当が必要です。FIP-0118の議論では、ゲートキーピング、運営コスト、不正利用の余地、そしてDataCapを獲得する行動と実際の有料需要が必ずしも一致しない点が課題として扱われました。

ここで重要なのは、Fil+が「失敗だった」と単純化しないことです。過去の容量拡大を支えた制度を、ネットワークの現在の段階に合わせて置き換える提案です。旧制度の役割と、新制度が解決しようとする問題を分けて理解すると、変更の意味が見えやすくなります。

有料サービスを生む活動へ報酬を移す狙い

新しい設計では、顧客獲得や有料サービスの提供につながる活動へ報酬の一部を振り向けます。容量を封入しただけでサービス報酬を得られるわけではなく、Filecoin Payによる有料決済量など、需要を示す条件が関わります。供給側の設備投資だけでなく、販売、顧客対応、プロダクト開発、継続利用の形成も評価対象へ近づける考え方です。

ただし、需要重視へ変わることが、直ちにネットワーク利用やFIL価格の上昇を意味するわけではありません。顧客が実際に支払うか、サービスが継続するか、ガバナンスが適切に運用されるかは別の問題です。本記事では制度の仕組みを説明しますが、将来の市場成果を断定する材料にはしません。

Fil+廃止でDataCapとセクター品質はどう変わるか

Fil+廃止の影響を理解するには、「データの保存」と「セクターの品質評価」を分ける必要があります。既に保存されたデータや過去の取引履歴が、アップグレードと同時に消えるわけではありません。変わるのは、DataCapを用いて検証済み取引を特別扱いし、QAPへ反映する制度です。

DataCap発行・割当モデルの終了

FIP-0118は、DataCapの新規発行と割当を廃止し、Verified RegistryやDataCap actorに依存していた流れを切り離します。これまでDataCap申請、クライアント認証、割当確認、検証済み取引の作成を前提にしていた業務は、そのまま続けられるとは限りません。画面上の項目が不要になるだけでなく、自動化スクリプト、API呼び出し、データベース項目、運用手順書まで影響範囲に含まれます。

DataCap残高を「資産」のように捉えていると誤解が生じます。DataCapはFILとは異なり、一般の暗号資産として自由に売買するものではありません。したがって、廃止に伴ってFILへ交換されるという話でもありません。

全新規セクターが一律10倍QAPに

有効化後に作られる新規セクターは、保存内容やDataCapの有無にかかわらず、一律で10倍のQAPを受けます。QAPはQuality-Adjusted Power、つまり品質調整済みパワーの略です。Filecoinでは単純な物理容量だけでなく、プロトコル上の重みを加味してストレージパワーを扱います。従来は検証済み取引かどうかで差がありましたが、その入口が統一されます。

一律10倍という表現は「FIL報酬が全員10倍になる」という意味ではありません。ネットワーク参加者の評価基準が同時に変わるため、個別SPの相対的な取り分は、他の参加者のパワー、稼働状況、担保、合意参加など多くの要因に左右されます。QAP倍率を収益倍率として読み替えないことが重要です。

既存セクターはクライアント別手順の確認が必要

既存の有効セクターについても、品質を更新する手段が仕様に用意されています。ただし「アップグレード時にすべてが自動で同じ状態になる」と決めつけず、利用するクライアントの手順、セクターの状態、操作条件を確認する必要があります。大量のセクターを運用するSPは、本番で一括操作する前に対象の抽出方法、実行時間、失敗時の再試行、監視項目を確認してください。

報酬は合意枠とサービス枠に分かれ、未獲得分はバーン

Solstice後はブロック報酬をまず「合意報酬」と「サービス報酬」の枠に分けます。バーンは当初から並列に配分される第三の報酬ではなく、サービス枠のうち獲得条件を満たさなかった分の行き先です。原資が増えると断定する変更ではなく、合意を維持するSPへの経路を残しつつ、需要創出に使える枠を設ける変更です。

初期配分は合意報酬95％・サービス報酬5％

初期パラメータは合意側95％、サービス側5％です。つまり開始時点で報酬の半分が直ちにサービス側へ移るわけではありません。まず小さい比率から始まり、制度上の条件と時間に従って変化し得ます。記事やSNSで「最大50％」だけを見た場合は、初期値と上限を混同していないか確認してください。

合意側は条件付きで最大50％まで低下

合意側の比率は、設計上、段階的に最大50％まで下がり得ます。ただし、これはSolstice開始と同時に50％になるという意味ではなく、需要条件や四半期単位の判定を伴う上限です。サービス需要が育たなければ想定通りに移行しない可能性があり、移行速度も単純な日付だけでは決まりません。

SPが収益計画を作る際は、最大値だけを採用した単一シナリオでは不十分です。初期配分が続く場合、サービス比率が段階的に上がる場合、需要条件を満たさずバーンが増える場合を分け、公式パラメータの変更を追跡する必要があります。これは投資収益の予測ではなく、制度依存リスクを把握するための運用上の考え方です。

獲得されないサービス枠はバーン

サービス枠は、設定されたからといって必ず事業者へ配られるわけではありません。条件を満たして獲得されなかった分はバーンされます。ここでのバーンは、その分が通常の報酬として参加者へ配られず、流通へ出ない処理です。需要が弱いときにも自動的に誰かへ配るのではなく、報酬と実需を結び付けるための仕組みといえます。

バーンがあるから価格が上がる、あるいは供給が減るから必ず価値が上がる、と結論付けることはできません。市場価格は需要、流動性、規制、ネットワーク利用、投資家心理など多くの要因で動きます。制度上の流通経路の変化と、価格予測は切り分けてください。

サービス報酬は有料需要と四半期ゲートで決まる

サービス報酬は、容量を提供した事実だけで自動的に確定するものではありません。FIP-0118では、Filecoin Payの有料決済量など、実際のサービス需要を表す条件と四半期ゲートが重要になります。これにより、見かけ上の容量ではなく、顧客が対価を支払う活動へ報酬を近づけようとしています。

報酬条件になる有料決済とサービス需要

有料決済は、無料配布や自己取引とは異なり、顧客がサービスに価値を認めて支払ったことを示す手掛かりになります。しかし、決済量だけでサービス品質のすべてを測れるわけではありません。顧客維持、データの可用性、価格設定、関連主体の独立性など、数値の背景も重要です。

事業者にとっては、ストレージを用意する能力に加え、顧客へサービスを届け、契約を維持し、決済を正しく記録する能力がより重要になります。逆に一般保有者は、サービス報酬の話を「FILを持つだけで追加報酬がもらえる制度」と誤解しないよう注意が必要です。

四半期ゲートが配分比率を左右する

四半期ゲートは、一定期間ごとに需要条件の達成状況を確認し、報酬配分の進行を制御する仕組みです。短期的な一度の決済だけで恒久的に比率が変わるのではなく、定期的な判定を設けることで、実需要の継続を確認する意図があります。

このため、公開される数字を見るときは、対象期間、集計方法、達成基準、判定後に適用される比率をセットで確認する必要があります。シミュレーターは仕組みの理解には役立ちますが、入力した仮定どおりの結果を保証するものではありません。実際の配分は最終仕様、オンチェーン状態、公式な判定を優先してください。

SWA・SRAが担う報酬管理とガバナンスの注意点

Solsticeの運用には、L1のbuiltin actorだけでなく、FEVM上の契約とガバナンスが関わります。代表的な構成要素がSWA、SRA、Orchestratorです。コードによる自動処理だけで完結するのではなく、登録や権限管理、報告、変更手続きも制度の信頼性を左右します。

SWA・SRAとOrchestratorの役割

SWA・SRA・Orchestratorの関係は、入力、判断、出力の順に見ると整理できます。

1. 入力：プログラム登録情報、サービスの重み、有料需要を示す報告値を扱う
2. 判断：Orchestratorと権限を持つガバナンス主体が登録・変更を管理し、四半期ゲートの条件を評価する
3. 出力：SWAがサービスの重みを反映し、SRAが条件に応じた報酬配分を管理する。獲得されなかったサービス枠はバーンへ回る

つまり、需要を測る情報、登録や変更を判断する主体、配分を実行する契約が分かれています。名称だけでなく、どの段階の誤りが重みや配分へ波及するかを見ることが重要です。

マルチシグと7日保留による権限管理

ガバナンス文書では、SWAとSRAの二層構造、マルチシグ、7日の保留期間などが規定されています。マルチシグは、重要操作を一つの鍵だけで実行しないための仕組みです。保留期間は変更を即座に確定させず、確認や対応の時間を確保する狙いがあります。

ただし、すべての操作が同じ保留期間を持つとは限りません。登録変更など即時反映される操作もあるため、「マルチシグと保留があるから無条件に安全」とは言えません。誰が署名者か、何人の承認が必要か、緊急時の手順は何か、オンチェーンで変更を追跡できるかが重要です。

登録判断や操作順序に残るリスク

ガバナンスには、マルチシグ鍵の侵害、関係者の談合、不適切な登録判断、報告値の操作などのリスクが残ります。また、同一epoch内で重み変更と四半期ゲートの処理順が重なる場合の中間状態についても、開発過程で問題が記録されました。仕様側で運用順序が明確化されても、稼働直後は実装と手順の両方を監視する必要があります。

この種の問題は、コードのバグだけに限定されません。正しいコードでも、権限者が誤った対象を登録したり、手順の順番を間違えたりすれば影響が出ます。透明な変更履歴、複数人の承認、監視、異常時の停止・復旧手順を組み合わせることが大切です。

ノード・ストレージ事業者の移行チェックリスト

運用者にとってNV29は、情報収集だけで終わるアップデートではありません。対応クライアントへの更新、依存コンポーネントの整合、Fil+関連処理の撤去または変更、監視項目の更新、移行後の確認までが一つの作業です。以下は調査資料に基づく確認項目ですが、実環境の構成に合わせて公式リリースノートを必ず照合してください。

Lotus v1.37.0などNV29対応版へ更新

Lotus利用者は、NV29対応の必須リリースであるv1.37.0へ移行します。リリースにはactors v19.0.1、移行epoch、API・CLIの非互換変更が含まれます。Forestはv0.37.0、Curioはv1.29.0がNV29対応版として示され、Venusにも対応変更が取り込まれています。複数コンポーネントを組み合わせる環境では、一つだけを更新して完了としないでください。

• 実行中バイナリのバージョンを記録する
• ノード、マイナー、セクター管理、取引処理の対応表を作る
• 設定ファイルとデータのバックアップ、復旧手順を確認する
• テスト環境または段階的な手順で起動・同期・API疎通を確認する
• epoch 6470279の前後でチェーン追随とログを監視する

更新前には、公式のチェックサムや署名、配布元を確認します。障害が起きたときに旧バイナリへ戻せばよいとは限りません。ネットワークルールが切り替わった後に非対応版を起動すると、正しいチェーンへ追随できないおそれがあるためです。ロールバック条件はソフトのリリースノートと運用手順に従ってください。

DataCap前提の取引・CLI・APIを点検

Fil+関連のCLIやAPIには廃止・変更があります。運用スクリプトにコマンド名が埋め込まれている場合、手作業では正常に見えても、定期ジョブだけが失敗する可能性があります。DataCap残高の照会、検証済みクライアントの判定、verified dealの作成、割当処理、エラーコードを利用している箇所を検索してください。

Boost側でもDataCap廃止に伴う取引処理や互換性の対応が追跡されています。チェーンノードが同期しているだけでは、取引受付から公開、封入、証明までの業務が正常とは限りません。API利用者、顧客向け画面、請求処理にも影響がないか、端から端まで確認します。

セクター操作と監視メトリクスの非互換を確認

Lotus v1.37.0では、Fil+関連だけでなく、セクター操作、API、CLI、F3を含む監視メトリクスの変更も確認対象です。ダッシュボードが緑色でも、メトリクス名の変更によって値を取得できず、古い値が残っているだけという場合があります。収集エージェント、Prometheusのクエリ、アラート条件、可視化パネルまで点検してください。

運用者が最低限見る対象は、チェーンヘッド（ノードが認識する最新ブロック列）の進行、ピア接続、同期遅延、メッセージプール（未処理メッセージの待機領域）、ブロック生成、sector proving（保存データを保持していることを示す証明処理）、APIエラー、プロセス再起動、ディスク・メモリ・CPUです。さらに、報酬actor（チェーン上で報酬ロジックを実行する組み込み機能）の状態と期待値を照合します。F3はファイナリティ確定を高速化する仕組みで、関連メトリクスの名称変更も監視設定へ反映してください。

移行後は公式ステータスと最終仕様を優先

FIP-0118は、初期提案からレビューと実装を経て細部が更新されています。古い解説記事、草案時の図、SNSの要約には、現在と異なる比率や処理が含まれる可能性があります。判断の優先順位は、最終FIP、対応クライアントのリリースノート、公式ネットワーク更新、公式ステータス、実際のオンチェーン状態です。

稼働直後は、既知の問題、追加リリース、緊急手順が更新される可能性があります。担当者を決めて監視し、変更が出たときの連絡先と判断権限を明確にしてください。異常を見つけた場合は、推測で状態を書き換える前にログ、epoch、バージョン、再現条件を保存し、公式の運用チャネルへ報告できる形にします。

情報を共有するときは、「予定」「実施済み」「安定確認済み」を分けて記録します。たとえば予定epochへ到達したこと、ノードが新ルールで同期したこと、取引受付や入出金まで復旧したことは、それぞれ異なる状態です。画面のスクリーンショットだけでなく、確認時刻、参照した公式URL、対象ネットワーク、利用中のソフトウェア版を残すと、担当者間の認識違いを減らせます。

障害対応では、チェーン自体の問題、特定クライアントの問題、自社環境の問題を切り分けます。複数の公式情報と自ノードの状態を照合し、原因が分からない段階で設定やデータを連続して変更しないことも大切です。変更を行う場合は、実施者、時刻、変更内容、結果を記録し、一つずつ影響を確認してください。

まとめ：Solsticeは制度変更として確認する

Filecoin NV29「Solstice」は、2026年10月19日21時59分30秒（日本時間）、epoch 6470279で実施予定です。FIP-0118によりFil+のDataCap発行・割当モデルを廃止し、新規セクターを一律10倍QAPとしたうえで、ブロック報酬の一部を有料サービス需要へ結び付けます。

初期配分は合意側95％、サービス側5％です。合意側は条件付きで最大50％まで低下し得ますが、開始時に一気に変わるわけではありません。また、サービス枠は必ず配られるのではなく、需要条件を満たさず獲得されない部分はバーンされます。この区別が、Solsticeを正確に理解する中心です。

一般のFIL保有者にはトークン交換は示されていません。取引所利用者は入出金停止と再開を各社の公式告知で確認します。ノードとSPの運用者は対応版へ更新し、DataCap前提の処理、API・CLI、セクター操作、監視メトリクスを点検してください。制度の変更を価格上昇や収益増加の保証と捉えず、最終仕様と稼働状況を継続して確認することが大切です。