diff --git a/EIPS/eip-1523.md b/EIPS/eip-1523.md new file mode 100644 index 00000000..31c2fef0 --- /dev/null +++ b/EIPS/eip-1523.md @@ -0,0 +1,129 @@ +--- +eip: 1523 +title: Standard for Insurance Policies as ERC-721 Non Fungible Tokens +author: Christoph Mussenbrock (@christoph2806) +discussions-to: https://github.com/ethereum/EIPs/issues/1523 +status: Draft +type: Standards Track +category: ERC +created: 2018-10-10 +requires: 721 +--- + +## Simple Summary + +A standard interface for insurance policies, based on ERC 721. + +## Abstract + +The following standard allows for the implementation of a standard API for insurance policies within smart contracts. +Insurance policies are financial assets which are unique in some aspects, as they are connected to a customer, a specific risk, or have other unique properties like premium, period, carrier, underwriter etc. +Nevertheless, there are many potential applications where insurance policies can be traded, transferred or otherwise treated as an asset. +The ERC 721 standard already provides the standard and technical means to handle policies as a specific class of non fungible tokens. +insurance In this proposal, we define a minimum metadata structure with properties which are common to the greatest possible class of policies. + +## Motivation + +For a decentralized insurance protocol, a standard for insurance policies is crucial for interoperability of the involved services and application. +It allows policies to be bundled, securitized, traded in a uniform and flexible way by many independent actors like syndicates, brokers, and insurance companies. + +## Specification + +The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. + +An ERC-1523 compliant insurance policy is a non-fungible token which **MUST adhere to the ERC-721 token standard** and **MUST implement theERC721Metadata and the ERC721Enumerable interface**: + +```solidity +/// @title ERC-1523 Insurance Policy Standard +/// Note: the ERC-165 identifier for this interface is 0x5a04be32 +interface ERC1523 /* is ERC721, ERC721Metadata, ERC721Enumerable */ { + +} +``` + +The implementor MAY choose values for the ```name``` and ```symbol```. + +The **policy metadata extension** is **RECOMMENDED** for ERC-1523 smart contracts. +This allows your smart contract to be interrogated for policy metadata. + +```solidity +/// @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); + +} +``` + +In analogy to the “ERC721 Metadata JSON Schema”, the tokenURI **MUST** point to a JSON file with the following properties: +```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", + }, + "carrier": { + "type": "string", + "description": "Describes the carrier which takes the primary risk", + }, + "risk": { + "type": "string", + "description": "Describes the risk", + }, + "parameters": { + "type": "string", + "description": "Describes further parameters characterizing the risk", + }, + "status": { + "type": "string", + "description": "Defines the status of the policy, e.g. Applied, Underwritten, Claimed, Paid out, etc." + } + } +} +``` + +## Rationale + +Insurance policies form an important class of financial assets, and it is natural to express those assets as a class of non-fungible tokens which adhere to the established ERC-721 standard. +We propose a standard for the accompanying metadata structures which are needed to uniquely define an insurance policy. +While policies can have a multitude of possible properties, it is common that policies are issued by some entity, which is basically the entity responsible for paying out claims. +Second, an insurance policy is typically related to a specific risk. Some risks are unique, but there are cases where many policies share the same risk +(e.g. all flight delay policies for the same flight). +In general, the relation of policies to risks is a many-to-one relation with the special case of a one-to-one relation. +Third, most policies need more parameters to characterize the risk and other features, like premium, period etc. +Forth, a policy has a lifecycle of different statuses. +We believe that those four properties are necessary to describe a policy. For many applications, those properties may be even sufficient. +However, any implementation **MAY** chose to implement more properties. + +### On-chain vs. off-chain metadata +For some applications it will be sufficient to store the metadata in an off-chain repository or database which can be addressed by the tokenURI resource locator. +For more advanced applications, it can be desirable to have metadata available on-chain. +Therefore, we require that the ```tokenURI``` **MUST** point to a JSON with the above structure, while the implementation of the ```policyMetadata``` function is **OPTIONAL**. + + +## Backwards Compatibility + + +## Test Cases + + +## Implementation + + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).