HomeEIPsNewsletter
EIPsERC-1523
ERC-1523

Standard for Insurance Policies as ERC-721 Non Fungible Tokens

StagnantStandards Track: ERC
Created: 2018-10-10
Requires: EIP-721
Christoph Mussenbrock (@christoph2806)
DiscussionsOriginal linkEdit
1 min read

The ERC-1523 proposal outlines a standard interface for representing insurance policies as ERC-721 non-fungible tokens within smart contracts. It defines a minimum metadata structure with common properties for policies and recommends the use of a policy metadata extension. The proposal aims to enable interoperability and flexibility in trading, bundling, and securitizing insurance policies by various independent actors.

Video
Anyone may contribute to propose contents.
Go propose
Original

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:

/// @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.

/// @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:

{ "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\] } }

Additional parameters for the metadata JSON Schema

ParameterTypeMandatoryDescription
carrierstringyesDescribes the carrier which takes the primary risk
riskstringyesDescribes the risk
statusstringyesDescribes the status of the policy, e.g. applied for, underwritten, expired
parametersstringnoDescribes further parameters characterizing the risk
termsstringnoDescribes legal terms & conditions which apply for this policy
premiumstringnoA string representation of the premium, MAY contain currency denominator
sum_insuredstringnoA string representation of the sum insured, MAY contain currency denominator

Parameters which are mandatory MUST be included in the metadata JSON. Other parameters MAY be included. However, the proposed optional parameters SHOULD be used for the intended purpose, so e.g. if the premium amount would be included in the metadata, the parameter name SHOULD be "premium". All parameters MAY be plain text or MAY also be URIs pointing to resources which contain the respective information, and which MAY be protected by an authentication mechanism.

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. Standardization is key because we expect decentralized insurance to receive widespread adoption and it is crucial to establish a unified standard to enable composability and the creation of universal toolsets. We therefore propose a standardized naming scheme for the different parameters describing an insurance policy. We propose three mandatory parameters which need to be included in every NFT and further parameters which MAY be used, and for which we only standardize the naming conventions.

Mandatory parameters

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, a policy has a lifecycle of different statuses. Therefore the NFT We believe that those four properties are necessary to describe a policy. For many applications, those properties may be even sufficient.

Optional parameters

Most policies need more parameters to characterize the risk and other features, like premium, period etc. The naming conventions are listed in the above table. 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 and related rights waived via CC0.

Further reading
Anyone may contribute to propose contents.
Go propose
Adopted by projects
Anyone may contribute to propose contents.
Go propose

Not miss a beat of EIPs' update?

Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.

View all
Serve Ethereum Builders, Scale the Community.
Resources
GitHub
Supported by