主页EIPs
EIPsERC-7578
ERC-7578

Physical Asset Redemption

Provides the holder of physical asset backed NFTs readily available real-world information on the underlying physical asset.
DraftStandards Track: ERC
创建时间: 2023-08-01
关联 EIP: EIP-165, EIP-721
Lee Vidor (@V1d0r) <vidor@emergentx.org>, David Tan <david@emergentx.org>, Lee Smith <lee@emergentx.org>
社区讨论原文链接编辑
1 分钟了解
欢迎补充好内容
去提交
相关视频
欢迎补充好内容
去提交
正文

Abstract

This proposal is an extension of ERC-721 and implements additional functionality and information pertaining to the NFT’s underlying physical asset by capturing information that enables the holder of physical asset backed NFTs to verify authenticity and facilitate redemption of the underlying physical assets. This proposal is primarily aimed at providing transparency by disclosing details of involved parties and provides opportunity to define and make readily available relevant legal relationship between NFT holder and the owner/holder of the respective underlying physical asset. This proposal makes the token issuer accountable to embed accurate information on a set of standardized information about the underlying physical asset and the involved key parties.

Motivation

The first wave of NFT use cases encompass predominately the representation of ownership of digital assets. In view of the anticipated trend to tokenize any real-world asset, it is to be expected that the use cases of NFTs will rapidly grow and expand around physical assets. The absence of an embedded standardized set of information pertaining to the underlying physical asset together with lack of transparency of involved key parties, creates an unnecessary hurdle for NFT holders and potential users which might, as a result, hinder mass adoption of NFTs that are used as ownership representation of a specific physical asset.

Addressing the lack of readily available information and paving the way for mass adoption for a tokenized economy, this proposal requires that each minted token includes a defined number of predefined variables enabling verification of authenticity and facilitating redemption of the underlying physical asset.

  • [TOKEN ISSUER] Identification of individual or entity minting the NFT (Issuer): [NAME], [UNIQUE IDENTIFICATION NUMBER] OR [NETWORK IDENTIFICATION]
    The token issuer is the key person connecting the physical asset and the digital representation. By identifying and disclosing the token issuer, a reference point is made instantly available to the NFT holder which allows them to conduct a due diligence on the NFT issuer and assessment of the NFT issuer’s trustworthiness. At the same time, it creates accountability for the token issuer which leads to overall improvement and standardisation of the NFT minting process. Token issuers will compete for best practices and recognition to gain advantages over competitors. A reputable NFT issuer will e.g. keep information on the legal owner of the physical asset prior to the minting of the underlying physical asset to satisfy any AML and KYC concerns. Ideally the NFT issuer is identified by a name but may also be identifiable via unique identification number or network ID that is issued by a service provider who stores relevant information on the NFT issuer.

  • [LEGAL OWNER OF UNDERLYING PHYSICAL ASSET] Identification of legal owner of underlying physical asset: [NAME], [UNIQUE IDENTIFICATION NUMBER] OR [NETWORK ID]
    In view of a redemption of the underlying physical asset and enforcing of legal rights, it is (from a legal perspective) essential for the NFT holder to identify the legal owner of the underlying physical asset. It allows the NFT holder to consider the legal counterparty risk. It cannot be assumed that the NFT issuer is the legal owner of the underlying physical asset, therefore it is vital for the NFT holder to have instant access to this additional information. Same as with the NFT issuer’s identity, the legal owner is ideally identified by a name but may also be identifiable via unique identification number or network ID that is issued by a service provider who stores relevant information on the legal owner.

  • [STORAGE LOCATION] Identification of storage location of underlying physical asset: [PHYSICAL ADDRESS OR JURISDICTION]
    Certain physical assets require specific storage conditions. A digital representation of an inappropriately stored physical asset may impact the value of the NFT significantly. Disclosing the storage location and making it directly accessible to the NFT holder, allows them to evaluate the storage risk of the underlying physical asset. In addition, it provides the NFT holder with a second point of contact for the enforcement of the redemption of the underlying physical asset.

  • [LEGAL CONTRACT] Type of legal relationship: [WITH LINK TO DOCUMENT IPSF]
    The disclosure and accessibility of the legal basis of the relationship between NFT holder and legal owner of the underlying physical asset promotes token issuers to stipulate and define the legal rights of the involved key parties. It furthermore allows the NFT Holder to conduct a legal risk and enforcement assessment. Ideally, the information is provided by embedding a link to the actual legal documentation such as an agreement or terms. The more information is accessible via the NFT, the better the NFT holder can assess the legal risks associated with enforcement of the redemption of the underlying physical asset.

  • [APPLICABLE LAW] Governing Law and Jurisdiction: [JURISDICTION]
    The applicable law is an extension of the legal contract disclosure and makes instantly available to the NFT holder or smart contract under what jurisdiction an enforcement would be governed without the need to review the details legal contract. This allows for an instant assessment of jurisdiction risk.

  • [DECLARED VALUE] Value of the underlying asset: [VALUE]
    Certain auxiliary services such as insurance are tied to a value of the NFT and underlying physical asset. By defining a declared value, NFTs are able to be categorised in certain ways while the declared value provides an indication regarding the underlying asset’s value. The declared value of the underlying physical asset does not necessarily represent the market value.

Specification

The keywords "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.

Properties MUST be set before a token can be minted.

The tokenId MUST be greater than 0.

The terms parameter MUST be a link to a document that is stored on IPFS.

When a token has no properties set mint reverts.

When a token has a valid properties, if the token burns, the properties MUST be deleted.

Contract Interface

pragma solidity ^0.8.21; /** * @notice Struct encapsulating fields required to by the ERC-7578 standard to represent the physical asset * @param tokenIssuer The network or entity minting the token * @param assetHolder The legal owner of the physical asset * @param storedLocation The physical storage location * @param terms Link to IPFS contract, agreement or terms * @param jurisdiction The legal justification set out in the terms * @param declaredValue The declared value at time of token minting */ struct Properties { string tokenIssuer; string assetHolder; string storedLocation; string terms; string jurisdiction; Amount declaredValue; } /** * @notice Struct encapsulating fields describing the declared value of the physical asset * @param currency The currency of the amount * @param value The value of the amount */ struct Amount { string currency; uint256 value; } /** * @notice Required interface of an ERC-7578 compliant contract */ interface IERC7578 { /** * @notice Emitted when the properties of the `tokenId` token are set * * @param tokenId The ID of the token * @param properties The properties of the token */ event PropertiesSet(uint256 indexed tokenId, Properties properties); /** * @notice Emitted when the properties of the `tokenId` token are removed * * @param tokenId The ID of the token * @param properties The properties of the token */ event PropertiesRemoved(uint256 indexed tokenId, Properties properties); /** * @notice Retrieves all the properties of the `tokenId` token * @dev Does NOT revert if token doesn't exist * @param tokenId The token ID of the minted token */ function getProperties(uint256 tokenId) external view returns (Properties memory properties); /** * @notice Sets the properties of the `tokenId` token * * IMPORTANT: Properties required to be set when minting a token * * @param tokenId The ID of the token * @param properties The properties of the token */ function setProperties(uint256 tokenId, Properties calldata properties) external; }

The setProperties(uint256 tokenId, Properties calldata properties) function is called before minting a token.

The getProperties(uint256 tokenId) function MUST return the unique properties for a token.

When properties are set, the PropertiesSet(uint256 indexed tokenId, Properties properties) event is emitted.

When properties are removed, the PropertiesRemoved(uint256 indexed tokenId, Properties properties) event is emitted.

Rationale

The tokenId must be greater than 0 so the properties can be checked before minting.

The _update function is overridden to check if the properties are set before minting and removed after burning.

The terms parameter is a HTTP link to a document that is stored on IPFS. This is to ensure that the document is immutable and can be verified by the NFT holder.

Contract level validation is not used on the properties as we believe the accuracy of the data declared is the responsibility of the token issuer. This builds trust in the token issuer and the token itself.

Backwards Compatibility

This standard is compatible with ERC-721.

Reference Implementation

An example of an ERC-721 that includes this proposal using the OpenZeppelin ERC-721 v5 library:

pragma solidity ^0.8.21; import { ERC721 } from "@openzeppelin/contracts-v5/token/ERC721/ERC721.sol"; import { IERC7578, Properties, Amount } from "./interfaces/IERC7578.sol"; /** * @title ERC7578 * @author DESAT * @notice Implementation of the ERC-7578: Physical Asset Redemption standard **/ contract ERC7578 is IERC7578, ERC721 { /** * @notice Thrown when the properties of a token are not initialized */ error PropertiesUninitialized(); /** * @notice Retrieves the properties of the `tokenId` token */ mapping(uint256 tokenId => Properties) private _properties; /** * @notice Initializes the [ERC-721](./eip-721.md) dependency contract by setting a `name` and a `symbol` to the token collection */ constructor(string memory _name, string memory _symbol) ERC721(_name, _symbol) {} /** * @inheritdoc IERC7578 */ function setProperties(uint256 tokenId, Properties calldata properties) public { _properties[tokenId] = Properties({ tokenIssuer: properties.tokenIssuer, assetHolder: properties.assetHolder, storedLocation: properties.storedLocation, terms: properties.terms, jurisdiction: properties.jurisdiction, declaredValue: Amount({ currency: properties.declaredValue.currency, value: properties.declaredValue.value }) }); emit PropertiesSet(tokenId, _properties[tokenId]); } /** * @inheritdoc IERC7578 */ function getProperties(uint256 tokenId) public view override returns (Properties memory properties) { properties = _properties[tokenId]; } /** * @notice Removes the properties of the `tokenId` token * @param tokenId The ID of the token from which to remove the properties */ function _removeProperties(uint256 tokenId) internal { delete _properties[tokenId]; emit PropertiesRemoved(tokenId, _properties[tokenId]); } /** * @notice Override of the {_update} function to remove the properties of the `tokenId` token or * to check if they are set before minting * @param tokenId The ID of the token being minted or burned */ function _update(address to, uint256 tokenId, address auth) internal virtual override returns (address) { address from = _ownerOf(tokenId); if (to == address(0)) { _removeProperties(tokenId); } else if (from == address(0)) { if (bytes(_properties[tokenId].tokenIssuer).length == 0) revert PropertiesUninitialized(); } return super._update(to, tokenId, auth); } }

Security Considerations

For further discussion.

Copyright and related rights waived via CC0.

扩展阅读
欢迎补充好内容
去提交
相关项目
欢迎补充好内容
去提交

不想错过最新的 EIP 动态?

订阅 EIPs Fun 周刊以跟进相关更新,建⽴你与 EIP 之间的连接 ,更好地建设以太坊。

详情
支持以太坊贡献者,推动生态建设
资源
GitHub
支持社区