Alert Source Discuss
🚧 Stagnant Standards Track: ERC

ERC-1523: 作为 ERC-721 非同质化通证的保险单标准

Authors Christoph Mussenbrock (@christoph2806)
Created 2018-10-10
Discussion Link https://github.com/ethereum/EIPs/issues/1523
Requires EIP-721

简述

一个基于 ERC 721 的保险单标准接口。

摘要

以下标准允许在智能合约中实现保险单的标准 API。 保险单是具有某些独特方面的金融资产,因为它们与客户、特定风险相关联,或者具有其他独特的属性,例如保费、期限、承保人、保险商等。 然而,在许多潜在的应用中,保险单可以被交易、转移或者以其他方式被视为一种资产。 ERC 721 标准已经提供了标准和技术手段来处理作为特定类别的非同质化通证的保单。 在本提案中,我们定义了一个最小的元数据结构,其中包含对最大可能类别的保单通用的属性。

动机

对于去中心化的保险协议,保险单标准对于所涉及的服务和应用程序的互操作性至关重要。 它允许保单以统一和灵活的方式被辛迪加、经纪人和保险公司等许多独立参与者捆绑、证券化和交易。

规范

本文档中的关键词“必须(MUST)”,“禁止(MUST NOT)”,“需要(REQUIRED)”,“应当(SHALL)”,“不应当(SHALL NOT)”,“应该(SHOULD)”,“不应该(SHOULD NOT)”,“推荐(RECOMMENDED)”,“可以(MAY)”和“可选(OPTIONAL)”应按照 RFC 2119 中的描述进行解释。

符合 ERC-1523 的保险单是一种非同质化通证,它必须遵守 ERC-721 通证标准,并且必须实现 ERC721Metadata 和 ERC721Enumerable 接口

/// @title ERC-1523 保险单标准
///  注意:此接口的 ERC-165 标识符为 0x5a04be32
interface ERC1523 /* is ERC721, ERC721Metadata, ERC721Enumerable */ {

}

实现者可以为 namesymbol 选择值。

对于 ERC-1523 智能合约,推荐使用保单元数据扩展。 这允许查询您的智能合约以获取保单元数据。

/// @title ERC-1523 保险单标准,可选的保单元数据扩展
/// @dev See ...
///  注意:此接口的 ERC-165 标识符为 0x5a04be32
interface ERC1523PolicyMetadata /* is ERC1523 */ {

    /// @notice 给定属性的元数据字符串。
    /// 属性通过其属性路径的哈希值来标识。
    /// 例如,ERC721 元数据 JSON 模式中的属性“name”具有路径 /properties/name
    /// 并且属性路径哈希是此属性路径的 keccak256()。
    /// 这允许有效地寻址任意属性,因为属性集可能是无限的。
    /// @dev 如果 `_propertyPathHash` 不是有效的属性路径哈希,则抛出异常。
    function policyMetadata(uint256 _tokenId, bytes32 _propertyPathHash) external view returns (string _property);

}

类似于 “ERC721 Metadata JSON Schema”,tokenURI 必须指向具有以下属性的 JSON 文件:

{
    "title": "Asset Metadata",
    "type": "object",
    "properties": {
        "name": {
            "type": "string",
            "description": "Identifies the asset to which this NFT represents",
        },
        "description": {
            "type": "string",
            "description": "Describes the asset to which this NFT represents",
        },
        \[additional parameters according to the following table\]
    }
}

元数据 JSON 模式的附加参数

Parameter Type Mandatory Description
carrier string yes 描述承担主要风险的承运人
risk string yes 描述风险
status string yes 描述保单的状态,例如已申请、已承保、已过期
parameters string no 描述表征风险的更多参数
terms string no 描述适用于此保单的法律条款和条件
premium string no 保费的字符串表示形式,可以包含货币单位
sum_insured string no 保险金额的字符串表示形式,可以包含货币单位

强制性参数必须包含在元数据 JSON 中。其他参数可以包含。但是,建议的可选参数应该用于预期目的,因此,例如,如果保费金额将包含在元数据中,则参数名称应该是“premium”。 所有参数可以是纯文本,或者可以是指向包含相应信息的资源的 URI,并且可以受到身份验证机制的保护。

理由

保险单构成了金融资产的重要类别,很自然地将这些资产表示为符合已建立的 ERC-721 标准的一类非同质化通证。 我们为唯一地定义保险单所需的随附元数据结构提出了一个标准。标准化是关键,因为我们期望去中心化保险得到广泛采用,并且建立统一的标准对于实现可组合性和通用工具集的创建至关重要。 因此,我们为描述保险单的不同参数提出了标准化的命名方案。我们提出了三个必须包含在每个 NFT 中的强制性参数,以及可以使用的其他参数,我们仅对这些参数的命名约定进行标准化。

强制参数

虽然保单可以具有多种可能的属性,但常见的是保单由某个实体发行,该实体基本上是负责支付索赔的实体。 其次,保险单通常与特定风险相关。有些风险是独一无二的,但在某些情况下,许多保单共享相同的风险 (例如,同一航班的所有航班延误保单)。 通常,保单与风险的关系是多对一的关系,特殊情况是一对一的关系。 第三,保单具有不同状态的生命周期。因此,NFT 我们认为这四个属性对于描述保单是必要的。对于许多应用程序来说,这些属性甚至可能就足够了。

可选参数

大多数保单需要更多参数来表征风险和其他特征,如保费、期限等。命名约定在上面的表格中列出。 但是,任何实现可以选择实现更多属性。

链上与链下元数据

对于某些应用程序来说,将元数据存储在可以通过 tokenURI 资源定位符寻址的链下存储库或数据库中就足够了。 对于更高级的应用程序,可能希望在链上提供元数据。 因此,我们要求 tokenURI 必须指向具有上述结构的 JSON,而 policyMetadata 函数的实现是可选的。

向后兼容性

测试用例

实现

版权

版权和相关权利通过 CC0 放弃。

Citation

Please cite this document as:

Christoph Mussenbrock (@christoph2806), "ERC-1523: 作为 ERC-721 非同质化通证的保险单标准 [DRAFT]," Ethereum Improvement Proposals, no. 1523, October 2018. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-1523.