mirror of
https://github.com/status-im/EIPs.git
synced 2025-02-22 19:58:06 +00:00
* Try to clarify the meaning of EIP fields * Remove unhelpful extra comments in the template * Change EIP-1491 from CRLF to LF * Remove template comments from EIPs * Fix heading: Abstarct -> Abstract * Update EIP-2014 * Change author list of EIP-1
122 lines
6.0 KiB
Markdown
122 lines
6.0 KiB
Markdown
---
|
|
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/).
|