Firelightが800万ドル調達、XRPからBTC・XLMへ拡大

Firelight Protocolは、DeFiのスマートコントラクト事故などに備えるオンチェーン保護プロトコルです。800万ドルの資金調達を実施し、XRPだけでなくビットコイン（BTC）やStellarのXLMを保護資本として活用する構想を進めています。

狙いは、DeFiを利用するフィンテック企業や投資家に、透明な補償条件と迅速な支払い手続きを提供することです。同時に、資本提供者には保護料を原資とする収益機会を設けます。

Firelightが800万ドルを調達

Firelight Protocolは2026年9月、Gumi Cryptos Capitalが主導するシードラウンドで800万ドルを調達したと発表しました。Maven 11、Metalayer、Joint Effects、Tribe Capitalも参加しています。

調達資金は、プロトコル開発、DeFi保護商品の拡充、提携先の開拓に充てられる予定です。Firelightは機関向けDeFiインフラを手掛けるSentoraから生まれたプロジェクトで、Anthony DeMartino氏とJesus Rodriguez氏が共同創業者を務めています。

Firelightが注目するのは、フィンテック企業やネオバンク、決済事業者が、ステーブルコインやオンチェーン・ボールトを利用した利回り商品を顧客へ提供する場面です。こうした商品では、基盤となるプロトコルに脆弱性があると、顧客資産が直接影響を受ける可能性があります。

Firelightの公式発表によると、DeFiに預けられた資産はおよそ800億ドルである一方、オンチェーン保護の対象となっている割合はごくわずかです。同社はこの隔たりを、機関投資家や一般金融サービスによるDeFi採用を妨げる要因と位置付けています。

DeFi保護をオンチェーンで提供する仕組み

Firelightは、資本提供者がノンカストディアル型のボールトへ暗号資産を預け、その資産をDeFi保護市場の裏付けに利用するモデルを採用します。対象プロトコルやボールトの補償範囲、価格、容量などの条件はオンチェーンに登録されます。

フィンテック企業やボールト運営者が保護料を支払うと、その一部が資本提供者へ分配されます。ただし、これは無条件に得られる利回りではありません。補償対象となる事故が発生すれば、預けられた担保が請求の支払いに使われる可能性があります。

公式サイトが示す対象事象には、スマートコントラクトの脆弱性、オラクル障害、ガバナンス攻撃、清算機構の不具合による不良債権、仕組み上の問題によるデペッグ、償還障害などがあります。実際の補償可否は、各保護市場で事前に定められた条件に基づいて判断されます。

Firelightはこの仕組みを一般的な保険商品ではなく、定義されたオンチェーン事故に対応する「cover」と位置付けています。利用者は、保護対象、免責条件、支払い上限、適用地域などを個別に確認する必要があります。

XRPとstXRPが果たす役割

FirelightはXRPを起点にプロトコルを構築しました。XRPはFlare NetworkのFAssetsを通じてFXRPとしてオンチェーン化され、Firelightのボールトへ預けられます。預金者には、預けたFXRPを表すERC-20形式のリキッドステーキングトークン「stXRP」が発行されます。

ボールトはERC-4626規格を採用し、資産の預け入れ、引き出し、トークン発行を管理します。stXRPは預けた資産の受取証として機能し、Flare上のDEXや流動性プールなど、対応するDeFiサービスで利用できます。

ただし、Firelightのフェーズによってリスクと権利は異なります。公式利用規約では、初期フェーズのstXRPはFXRPの預け入れを示す技術的な受取トークンであり、利益分配権やガバナンス権を付与するものではないと説明されています。

保護機能が本格稼働する段階では、ステークされた資本が実際の補償原資になります。請求が成立した場合に担保が削減されるスラッシングリスクも生じるため、単純なXRP運用商品として捉えるべきではありません。

BTCとXLMへ拡大する理由

Firelightは、保護市場を支える資産をXRPからBTCやXLMへ拡大する方針です。候補となるのは、流動性が高く、独自のネイティブ利回りを持たない資産です。保有者は資産を保護資本として提供し、その対価として保護料を受け取れる可能性があります。

BTCについては、FirelightとLombardが具体的な協業を進めています。検討されているのは、LombardのBitcoin Smart Account利用者向けにFirelightの保護を組み込んだDeFiボールトと、BTCを担保として保護能力を供給するFirelight側のボールトです。LombardはLBTCやBTC.bも展開しています。

複数資産への拡大には、補償資本を分散する意味もあります。保護対象となるDeFiプロトコルの資産と異なる性質を持つ担保を用いれば、単一エコシステムへの依存を抑えられる可能性があります。ただし、BTCやXLMへの対応は段階的な計画であり、利用開始時期や具体的条件は正式な提供開始後に確認する必要があります。

独立コンソーシアムが請求を審査

Firelightの特徴は、補償判断をプロジェクト内部だけで完結させない点です。請求審査にはGFX Labs、Hypernative、Credora、Native、Cyfrinで構成されるFirelight Risk Consortiumが参加します。

Cyfrinはスマートコントラクト監査、Hypernativeは脅威検知、CredoraはDeFiリスク評価、GFX Labsはガバナンスとプロトコル設計、Nativeは保険仲介とオンチェーン・リスク移転の知見を提供します。

対象事故が確認されると、オンチェーン・レジストリから有効な保護ポジションを特定し、セキュリティ企業が事故報告を作成します。コンソーシアムは事故の発生、損失規模、契約条件への該当性を検証し、結果をオンチェーンで証明する設計です。

CoinDeskの報道によれば、Firelightは審査判断を3〜4日、請求開始から担保処分と支払いまでを10日未満で完了することを目標としています。これは運転資金や顧客資産を扱うフィンテック企業にとって重要ですが、現時点では目標値であり、実際の処理時間を保証するものではありません。

利用前に確認したいリスク

Firelightを利用する際は、「保護があるから安全」と短絡的に判断しないことが重要です。まず、対象のスマートコントラクト、事故原因、資産、期間が補償条件に含まれるかを確認します。市場価格の下落、秘密鍵の紛失、利用者の操作ミスなどは、通常のプロトコル事故とは扱いが異なる可能性があります。

資本提供者は、保護料だけでなく最大損失を確認する必要があります。請求成立時にはXRPやBTCなどの担保が支払いに充てられるため、得られる手数料と引き受けるリスクは表裏一体です。stXRPなどの受取トークンをDEXで運用する場合は、流動性、価格乖離、追加プロトコルのスマートコントラクトリスクも加わります。

また、Firelightは監査実績としてOpenZeppelin、Coinspect、0xMacroを挙げ、Immunefiのバグ報奨金制度も案内しています。しかし、監査は将来の事故を完全に防ぐ保証ではありません。コントラクトアドレス、監査対象バージョン、管理権限、出金条件を公式資料で照合し、少額から利用を検討するのが現実的です。