# [ERC1523] 保険証券をNFTにする仕組みを理解しよう！

> ERC1523は、スマートコントラクト上で保険証券（保険契約）を扱うための標準的なAPIを提案しています。保険証券は、加入者、対象となるリスク、保険料、契約期間、保険会社、引受人などの要素により一意性を持つ金融資産です。

- URL: https://cardene.dev/articles/83fa7c68be5ea877017f
- 公開日: 2025-06-05
- 更新日: 2025-06-05
- トピック: Blockchain
- タグ: ethereum, solidity, smartcontract, ブロックチェーン

## はじめに

『DApps開発入門』という本や色々記事を書いているかるでねです。

https://amzn.asia/d/gxvJ0Pw

今回は、保険証券を**ERC721**形式のNFTとして表現するための標準インターフェースとメタデータ構造を提案している**ERC1523**についてまとめていきます！

:::message
以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。
:::

https://eips.ethereum.org/EIPS/eip-1523

他にも様々なEIPについてまとめています。

https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4

## 概要

**ERC1523**は、スマートコントラクト上で保険証券（保険契約）を扱うための標準的なAPIを提案しています。
保険証券は、加入者、対象となるリスク、保険料、契約期間、保険会社、引受人などの要素により一意性を持つ金融資産です。
これらは従来の金融資産とは異なる特性を持ちますが、取引や譲渡などが可能な資産としての側面もあります。
**ERC721**（NFT）標準は、このような非代替性を持つ資産の管理に適しており、**ERC1523**ではこれをベースにして保険証券に共通する最小限のメタデータ構造を定義しています。

## 動機

分散型保険プロトコルを実現するためには、保険証券の共通仕様が不可欠です。
標準が定義されることで、保険契約をパッケージ化したり、証券化したり、取引所で流通させたりといったユースケースが、シンジケート（共同保険団体）、ブローカー、保険会社など、独立した複数の関係者によって柔軟かつ一貫性をもって実現できます。
これにより、保険契約の相互運用性が高まり、保険分野における分散型アプリケーションの発展が進みます。

## 仕様

**ERC1523**は、保険証券（保険契約）をブロックチェーン上でトークンとして表現し、**ERC721**の標準に準拠させることで非代替性トークン（NFT）として扱えるようにするための仕様です。

この仕様では、**ERC721**とその拡張である**ERC721Metadata**および**ERC721Enumerable**インターフェースに準拠する必要があります。
これにより、保険証券を一意なトークンとして識別・転送・参照できるようになります。

また、保険証券に関する追加情報を効率的に取得するための「**ポリシーメタデータ拡張**」も用意されており、`tokenURI`が指し示すJSONファイルに、保険固有の属性情報を含めることが推奨されています。

ポリシーのメタデータは、以下のような構成のJSONで表現されます。

```json
{
  "title": "Asset Metadata",
  "type": "object",
  "properties": {
    "name": { "type": "string", "description": "NFTが表現する資産の名称" },
    "description": { "type": "string", "description": "NFTが表現する資産の説明" },
    "carrier": { "type": "string", "description": "主たるリスクを引き受ける保険会社" },
    "risk": { "type": "string", "description": "保険が対象とするリスク" },
    "status": { "type": "string", "description": "申請中、引き受け済み、失効などの状態" },
    "parameters": { "type": "string", "description": "リスクを特徴づける追加パラメータ" },
    "terms": { "type": "string", "description": "契約条件や適用される規約" },
    "premium": { "type": "string", "description": "保険料。通貨単位を含んでもよい" },
    "sum_insured": { "type": "string", "description": "補償額。通貨単位を含んでもよい" }
  }
}
```

### `ERC1523`

保険証券をNFTとして扱うための標準インターフェース。
このインターフェースは、**ERC721**、**ERC721Metadata**、**ERC721Enumerable**に準拠する保険証券用のコントラクトに求められる最低要件を示します。
これにより、第三者による保険トークンの扱いや相互運用性が可能になります。

```javascript
/// @title ERC-1523 Insurance Policy Standard
///  Note: the ERC-165 identifier for this interface is 0x5a04be32
interface ERC1523 /* is ERC721, ERC721Metadata, ERC721Enumerable */ {

}
```

### `ERC1523PolicyMetadata`

ポリシーのメタデータを取得するための関数を提供する拡張インターフェース。


```javascript
/// @title ERC-1523 Insurance Policy Standard, optional policy metadata extension
/// @dev See ...
///  Note: the ERC-165 identifier for this interface is 0x5a04be32
interface ERC1523PolicyMetadata /* is ERC1523 */ {

    /// @notice Metadata string for a given property.
    /// Properties are identified via hash of their property path.
    /// e.g. the property "name" in the ERC721 Metadata JSON Schema has the path /properties/name
    /// and the property path hash is the keccak256() of this property path. 
    /// this allows for efficient addressing of arbitrary properties, as the set of properties is potentially unlimited.
    /// @dev Throws if `_propertyPathHash` is not a valid property path hash. 
    function policyMetadata(uint256 _tokenId, bytes32 _propertyPathHash) external view returns (string _property);

}
```

#### `policyMetadata`

任意の保険証券（トークンID）に対して、特定のプロパティ情報をハッシュで指定して取得する関数。
これにより、柔軟かつ拡張性のあるメタデータ管理が可能になります。

**引数**

* `_tokenId`
    * メタデータを取得する対象の保険証券（NFT）のID。
* `_propertyPathHash`
    * 取得したいプロパティのパスを`keccak256`でハッシュ化した値（例：`/properties/name` など）。

**戻り値**

* `_property`
    * 対象のプロパティに対応する文字列情報（例："Expired" や "0.1 ETH" など）。

## 補足

### 必須パラメータの意義

保険証券はさまざまな情報を含みますが、最小限の情報として次の3つのパラメータが必要です。

* **carrier**（引受者）
  保険金を支払う責任を持つ主体（保険会社や引受人）。

* **risk**（リスク）
  保険が対象とする具体的なリスク。例えば、あるフライトの遅延保険など、同じリスクを共有する複数のポリシーが存在し得ます。

* **status**（ステータス）
  保険契約の状態。例：申請中、引き受け済み、失効など。これにより契約のライフサイクルを表現できます。

これらの情報は、保険証券としての基本的な性質を特定し、NFTとしての一意性を保証するために不可欠です。

### 任意パラメータの拡張性

実際の保険証券では、プレミアム（保険料）や契約期間、補償額、契約条件など、より詳細な情報が必要になる場合がほとんどです。
これらの情報は**任意**として定義されており、標準では命名規則だけが提案されています。

これにより、開発者やプロトコルはユースケースに応じて柔軟にデータ構造を拡張できます。

### オンチェーンとオフチェーンのメタデータ管理

多くのアプリケーションでは、`tokenURI` を用いてオフチェーンのリソース（たとえばIPFSやHTTPSサーバー）に格納されたJSONファイルからメタデータを取得することで十分です。

一方で、より高度なユースケース（オンチェーン照会や即時検証など）に対応するため、オンチェーンでのメタデータアクセスも想定されています。
これに対応するのが、`policyMetadata` 関数です。
ただし、この関数の実装は**任意**であり、プロジェクトの設計方針に応じて選択できます。

## 引用

Christoph Mussenbrock (@christoph2806), "ERC-1523: Standard for Insurance Policies as ERC-721 Non Fungible Tokens [DRAFT]," Ethereum Improvement Proposals, no. 1523, October 2018. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-1523.

## 最後に

今回は「保険証券を**ERC721**形式のNFTとして表現するための標準インターフェースとメタデータ構造を提案している**ERC1523**」についてまとめてきました！
いかがだったでしょうか？

質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！

[Twitter @cardene777](https://twitter.com/cardene777)

他の媒体でも情報発信しているのでぜひ他も見ていってください！

https://chaldene.net/

https://zenn.dev/heku

https://cardene.substack.com/

https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58

https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4