0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【保険×Web3 #2】DeFi 保険・再保険を、もう一層厚くするために — 私が超過額損害再保険を選んだ理由

0
Posted at

保険 × Web3 #2.png

web3 に相互扶助思想を持ち込む

著者:cmalu ractu(シュマル・ラクトゥ:小さなウサギ)


目次


本稿の位置付け

#1 で提示した、既存 DeFi 保険プロバイダの支払い能力を支える超過額損害再保険層(相互扶助構造)を Solidity で実装するプロトコル「Campanella」シリーズの第 2 回。

本稿では、Campanella の設計判断、特に「なぜ超過額損害再保険 (Excess of Loss、以下 XL) に特化するのか」を整理する。

なお、note 全文版(現状把握パートを大幅に拡充)は別途公開している。

想定読者

  • DeFi 保険・再保険の技術背景に関心のある engineer / builder
  • 暗号経済学・mechanism design × 保険の交差点に立つ研究者
  • Web3 audit を学習中の方
  • 国際的な reinsurance × DeFi 関心層

「Attachment Point」「Layer」「Quota Share」「XL」「ERC-4626」が初出でも引かない読者層を念頭に書いている。


本稿が応える問い

本シリーズと Campanella プロトコルは、研究目的で公開した設計・実装に対する反応と実装可能性を見て、将来的に商用化の選択肢を検討する段階方針を採る。本稿が答えるべき 4 つの問いを明示する。

1. 需要 — 誰が困っているか

  • DeFi 保険を信用しきれない一般ユーザー(プロバイダの支払能力が見えないため)
  • 保険を購入したい DeFi プロトコル(既存 prov の引受能力上限で買えない)
  • 自社の集中リスクを reinsurance に出したい既存 DeFi 保険プロバイダ
指標 数値
DeFi insurance セクター TVL $123.5M
DeFi 全体 TVL に占める比率 0.14%(DeFi 資産の 99% 以上が無保険)
DeFi 全体 TVL(2026 年 4 月) $86B〜$170B 帯
Nexus Mutual TVL(Symbiotic 統合後) $425M、業界 76% シェア

出典:coinlaw.io / DefiLlama / CoinDesk

ロジック:再保険が原保険の信用力を支える → DeFi 保険の信頼性向上 → 加入者層拡大 → 「Web3 に安心して資金が入る」状態 → DeFi 実用化加速

2. 市場規模

指標 数値 出典
Decentralized insurance 市場 $3.5B (2025) → $16.94B (2029)、CAGR 48.4% Market-sizing 各社
Crypto insurance 市場 $9.49B (2025) → $13.75B (2026) Grand View Research
Crypto insurance gap $3.31 trillion 規模 Risk & Insurance
Cyber XL reinsurance demand(参考) $9B by 2030(現状から約 2 倍) Gallagher Re

Campanella の SAM 推計:2029 年 DeFi 保険市場の再保険層 $3.4B〜$6.8B、うち XL 層 $1B〜$3.4B(業界横断比較からの仮定的推計)。

3. 伝統再保険業界の課題 → DeFi 再保険の応答

TradFi の課題 DeFi 再保険の応答
新領域 capacity 不足(Cyber XL demand 倍増予測) LP の global pool、ERC-4626 で capital elasticity 確保
集中リスクの不透明(global protection gap $1.83T) on-chain で資本・payout が完全透明
idle 資本の非効率 restaking で underwriting capital が yield も生成(Nexus + Symbiotic で capacity 約 40% 拡大)
新リスク対応速度(数年単位) smart contract で rapid prototyping

Munich Re が Chainproof(Bermuda 拠点・Quantstamp パートナー)を後援している事実は、TradFi 側が DeFi 再保険を「補完的に価値ある」と認識している証拠。DeFi 再保険は TradFi の置換ではなく、crypto-native リスクを DeFi 経済圏内で引き受ける補完層

4. 段階方針 — 研究公開から商用化検討へ

  • 第 1 段階(〜2026 年内):本シリーズ #2〜#8、Solidity 実装の GitHub オープンソース公開、Sepolia testnet MVP。研究目的の公開
  • 第 2 段階(2026 末〜2027):公開後の反応・実装可能性の評価。既存プレイヤーとの対話・PoC、チーム組成の検討(Solidity 開発・保険業界知見・regulatory 対応)
  • 第 3 段階(2027 年以降):反応次第で 商用化の選択肢を検討(独立商用化/既存プレイヤー協業/OSS 提供のいずれか)

利回り獲得・トークン投機を目的としない。「Web3 に安心して資金が入る」インフラに資する設計言語の研究公開が当面の目的

対話・参加歓迎:Solidity / Web3 開発者・保険業界実務者・regulatory 専門家・LP 候補
連絡:X @lo_cmalu_ractu DM / GitHub Issues(公開後)


Part 1. 既存層の全体像(要約)

主要 DeFi 保険プロバイダ(2026-05 時点)

プロバイダ 主な引受範囲 特徴
Nexus Mutual smart contract / custody / depeg / slashing 業界最古参・Lloyd's syndicate 型・2025-11 Symbiotic 統合で reinsurance layer 化
Sherlock 監査済プロトコルの Shield audit-to-protection 一体型
InsurAce smart contract / depeg / CEX failure マルチチェーン
Unslashed 複合カバー(bucket model) $700M+ 容量・DAO + Kleros
Subsea (旧 Risk Harbor) yield / stablecoin パラメトリック・45 秒支払
Etherisc 天候・depeg・気候 GIF / 現実世界保険連携
InsureDAO smart contract 日本人チーム (Kohshi Shiba CEO) ・会長 岩瀬大輔(実業家・元ライフネット生命保険社長)・ReportingDAO subDAO governance

業界全体:DeFi TVL 約 $200B(約 31 兆円) / 保険セクター TVL は DeFi 全体の 2% 未満

DeFi / クリプト再保険層は三系統

系統 内容 代表
A 系統 DeFi ネイティブ Nexus Mutual + Symbiotic(2025-11、yield-generating reinsurance layer)
B 系統 規制対応型クリプトネイティブ Nayms / OnRe(Bermuda)、Ensuro、Chainproof(Munich Re 後援)
C 系統 伝統的キャリアの DeFi 拡張 Munich Re(DeFi Protect)、Lloyd's、Allianz、AON

A は DeFi 経済圏に閉じた設計、B・C は TradFi 構造を起点とする設計


Part 2. なぜ「超過額損害再保険 (XL)」に着目するか

XL とは

事前定義された Attachment Point を超える損失部分を再保険でカバーする型。

$10M xs $5M  →  Attachment $5M、Limit $10M
用語 意味
Attachment Point 発動閾値
Limit カバー上限
Layer Attachment 〜 Attachment+Limit の帯

Lloyd's syndicate モデルの中核を成す再保険型で、100 年以上の歴史を持つ。

主要再保険型との比較

DeFi 例
Quota Share Nexus Mutual syndicate
Industry Loss Warranty (ILW) Nayms / OnRe
パラメトリック Subsea / Etherisc
Cat Bond Ensuro 一部
Excess of Loss (XL) Campanella の対象

XL を選ぶ 8 つの理由

  1. tail event との適合性:XL は tail event のために設計された型。DeFi の漸進的 depeg / カスケード清算 / 相関リスク / 流動性枯渇に構造的フィット
  2. 既存層の未充足部品を埋める:XL 特化型 DeFi 再保険プロトコルは、現時点で公開されていない。伝統再保険で Quota Share と XL が併買される別部品であり続けた通り、tail event を守る部品は他の型で代替できない(再保険予算内で選択が競合しうる点は note 全文版で詳述)
  3. 資本効率:LP 資本が tail event 時のみ使われる構造のため、idle 時の低リスク運用が可能
  4. コード化適合性:トリガーが「cumulativeLoss > attachmentPoint」という明示条件で記述可能。主観的事故認定を排除
  5. 業界共通語彙:東京海上・MS&AD・Sompo など日本の主要再保険会社で標準語彙
  6. Lloyd's 系譜接続:Lloyd's (1688) → Nexus Mutual (2019) → Nexus + Symbiotic (2025-11) → Campanella (2026) の歴史的系譜
  7. 相互扶助との同型:「平時は各自、危機は共に」を保険商品化したのが XL
  8. 筆者の現実的フィット:業界共通語彙確立済 + 単一プール XL は実装スコープ的に着手可能

Campanella の差別軸(vs A 系統 Nexus + Symbiotic)

観点 Nexus + Symbiotic Campanella
再保険型 Quota Share 近似 XL 特化
資本性格 restaking ベース利回り生成型 相互扶助プール危機担保型
最適化目標 キャピタル効率 + 利回り 反脆弱性 + 集合的吸収
位置付け スケーラブルインフラ商品 研究目的概念実装

プロトコルの最小コア — 4 関門

Campanella の中核は、ERC-4626 標準の保管庫(Vault)と 4 つの関門から構成される:

関門 役割
起動 (Trigger) オラクルが危機を検知 → 請求発行・検証期間開始
検証 commit K-of-N オラクルが verdict を hash で提出(中身は隠す)
検証 reveal commit 期間終了後、オラクルが verdict を明かす
引出 (Pull) 被害者が Merkle 証明で資金を pull 取得

コアは 4 関門 + Vault で完結する。複雑性は周辺領域(オラクル網・被害者特定・料率モデル・lockup・ガバナンス)に追い出し、記事 #4-#8 で段階公開する。

検証期間 8 時間と透明性

検証期間は commit 期間 6h + reveal 期間 2h = 計 8h

  • commit 期間:verdict の hash のみ on-chain、中身は隠れる
  • reveal 期間:各オラクルが verdict を明かす
  • 集計後:賛成 ≥ K で支払予約確定、被害者が pull で引出

公開 / 隠す方針:

情報 commit 期間 reveal 期間以降
起動時刻 / severity / 金額 / 進捗カウンタ ✅ 公開 ✅ 公開
各オラクルの verdict ❌ 隠す ✅ 公開
identity-verdict 紐付け ❌ 隠す ✅ 公開

中身を隠し、進捗を見せる」commit-reveal 構造により、frontrun / オラクル同調圧力 / 閾値ギリギリ調整攻撃を構造的に排除しつつ、被保険者・被害者にプロセスの可視性を提供する。

既存 DeFi 保険・再保険との位置取り:

Subsea       : 45 秒(完全自動・透明性は trigger のみ)
Campanella   : 8 時間(多重 attestation・透明性は全段階) ← ここ
Unslashed    : 5 日標準
Nexus Mutual : 2-6 日
伝統再保険    : 数ヶ月

Subsea ほど速くなく、Nexus / Unslashed ほど遅くもない。意図的な中庸である(理由は Part 5 で詳述)。


Part 3. 設計の三つの転換

XL を採用する以上、既存層とは意図的に異なる方向を採る。

  1. 個別契約 → 集合的吸収:LP 残高を ERC-4626 vault パターンでプール持ち分(shares)として保持。プールが薄まれば全 LP の価値も比例して薄まる
  2. 利回り中心 → 危機前提:APY 競争を最適化目標から外す。tail event 時の機能を最優先
  3. 平時最適化 → 反脆弱性:ナシーム・ニコラス・タレブ『反脆弱性』(2012) における antifragile(衝撃で強くなる)を目標として加える

これらは Web3 のコミュニティ思想(DAO / 公共財ファンディング / 共同所有プール)と本質的に同型である。
相互扶助は Web3 にとって外来の思想ではなく、既にコミュニティ思想として根を張っているものを、保険プロトコル層で明示的に設計言語化する試みである。


Part 4. 一般 Solidity パターンによる素描

以下は Campanella 固有の実装ではなく、XL 再保険を Solidity で表現するときの一般パターンである。具体的な Campanella 実装は #3 で示す。

4-1. ERC-4626 Vault の基本シェイプ

EIP-4626 は、Tokenized Vault の標準インターフェース。

interface IERC4626 is IERC20 {
    function asset() external view returns (address);
    function totalAssets() external view returns (uint256);

    function deposit(uint256 assets, address receiver)
        external returns (uint256 shares);
    function withdraw(uint256 assets, address receiver, address owner)
        external returns (uint256 shares);

    function convertToShares(uint256 assets) external view returns (uint256);
    function convertToAssets(uint256 shares) external view returns (uint256);
}

LP の価値は持ち分(shares)として保持され、固定額ではなくプール状態に比例する。

4-2. プール状態に連動した持ち分価値

function convertToAssets(uint256 shares) public view returns (uint256) {
    uint256 supply = totalSupply();
    return supply == 0
        ? shares
        : (shares * totalAssets()) / supply;
}

プールが豊かなら持ち分の価値が上がり、薄まれば比例して薄まる。集合的吸収の実装コア。

4-3. XL トリガー条件の概念例

// XL の発動条件は単純な比較式で書ける
struct XLLayer {
    uint256 attachmentPoint;  // 発動閾値
    uint256 limit;            // カバー上限
    uint256 cumulativeLoss;   // 累積損失
}

function _calcPayout(XLLayer memory layer)
    internal pure returns (uint256 payout)
{
    if (layer.cumulativeLoss <= layer.attachmentPoint) {
        return 0;
    }
    uint256 excess = layer.cumulativeLoss - layer.attachmentPoint;
    payout = excess > layer.limit ? layer.limit : excess;
}

主観的事故認定を経ず、閾値超過の機械的判定だけで発動する。

4-4. tail event 時の引き出し制御

modifier whenNotInCrisis() {
    require(!isCrisisMode, "Withdrawals deferred during crisis");
    _;
}

function withdraw(uint256 assets, address receiver, address owner)
    external whenNotInCrisis returns (uint256 shares)
{
    // ...
}

危機時の「先逃げ」を構造的に不可能にすることで、損失の集合的吸収を保証する。


上記コードはすべて一般パターンであり、Campanella 固有の実装ではない。
AI(Claude)が補助して書かれている。筆者は当該部分の完全な正確性・適切性・解釈の網羅性を保証せず、当該部分から発生する一切の責任を負わない


Part 5. 速さで競争する道もあった — しかし、敢えてしない

DeFi 保険・再保険の領域には極限まで速い支払の系譜がある。最速は Subsea(旧 Risk Harbor)の 45 秒 / 3 ブロック。完全パラメトリック型で、オラクル signal が閾値を越えた瞬間に自動支払。

設計の途中、Campanella もこの方向に寄せる選択肢を真剣に検討した:

速度 仕組み
単一 oracle + 即時実行 45 秒 Subsea 型クローン
Optimistic settlement 45 秒で支払 + 6h challenge 期間 UMA / Optimistic rollup と同思想

特に Optimistic settlement は魅力的だった。被害者は即座に受領、challenge 期間で誤りを差し戻し可能。Subsea と並ぶ速度を獲得しつつ、人間判断の余地も残せる。

しかし最終的に Campanella は 「複数 oracle の独立判断を待つ。8 時間の検証期間(commit 6h + reveal 2h)」 設計を選んだ。理由は四点:

  1. tail event の特性:誤発動コスト > 遅延コスト。プール全体を毀損する事象では、速さより正確さが価値を持つ
  2. 速度競争の本質:Subsea が 45 秒を達成できるのは事象が機械的に明白だから(depeg は数値判定可)。XL の対象は集合的・連鎖的・解釈の余地ある事象が中心
  3. 訴求の方向選択:「速さ」ではなく「集合的吸収の信頼性」に軸を置く
  4. 既存層との位置取り:Subsea の速度を目指さず、Nexus / Unslashed の遅さも避ける。意図的な中庸

速さで競争する道もあったが、敢えてしない」というのが、本プロトコルの設計哲学である。誤発動の影響が大きい tail event 領域では、速さよりも正確さが価値を持つ。Lloyd's of London の 340 年が積み重ねてきた知見も、同じ方向を指している。


次回予告

#3 では Solidity による実装詳細に降りる。

  • ERC-4626 を XL 再保険プールの文脈でどう拡張するか
  • Attachment Point 自動判定の設計
  • 反脆弱な構造の関数設計への埋込

AI 使用開示

思想・アイディア・校閲・校正:cmalu ractu(シュマル・ラクトゥ:小さなウサギ)
文章生成:Claude(Anthropic)

コードと著者に関する執筆分担

パート 上流工程(思想・設計) 下流工程(基本コード) 検証(レビュー)
一般 Solidity 例 筆者 AI(Claude) 筆者
Campanella 概念図・プロトコル設計 筆者 (#3 にて実装予定) 筆者

筆者による検証は研究目的のレビューであり、筆者は AI(Claude)が生成・補助したコードや記述について、その完全な正確性・適切性・解釈の網羅性を保証するものではなく、当該部分から発生する一切の責任を負わない。読者からの指摘は歓迎し、改訂は明示的に行う。


関連リンク

  • X@lo_cmalu_ractu
  • note 全文版:別途公開(現状把握パートを大幅拡充)
  • Mirror.xyz 英語版:後日公開予定

主要出典

DeFi 保険・再保険プロバイダNexus Mutual / Sherlock / InsurAce / Unslashed / Subsea Protocol / Etherisc / InsureDAO (Medium)

Nexus + Symbiotic 統合 (2025-11)CoinDesk

Nayms / Ensuro / ChainproofNayms Medium / ensuro.co / Munich Re DeFi Protect

業界統計:DefiLlama Insurance Category / OpenCover / Three Sigma DeFi Insurance Guide

書籍:Nassim Nicholas Taleb, Antifragile: Things That Gain from Disorder, Random House, 2012


0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?