ERC-7578 Real-world asset redemption NFT standard (Physical Asset Redemption)

Final · NFTs & multi-token · created 2023-08-01

An ERC-721 extension that places key information such as the issuer, legal owner, storage location and contract terms in a standard format on NFTs backed by real-world assets, so that holders can verify authenticity and prepare for physical redemption.

Why it is needed

Until now, NFTs (unique tokens on a blockchain) have mainly been used to represent ownership of digital assets. But as the trend of tokenizing real-world assets grows, there is no way to tell from the token alone whether the physical asset is genuine, who the legal owner is, where and in what condition it is stored, or which contracts and laws apply when redemption is demanded. There is also no guarantee that the issuer is the legal owner of the physical asset, so holders have to investigate counterparty risk and legal risk separately. This lack of standardized information and the opacity of the parties involved create unnecessary barriers for those who want to use real-world asset NFTs. The original text points out that this could hinder mass adoption. This standard has each token carry specified information, which makes authenticity checks and physical redemption easier and makes the issuer responsible for providing accurate information.

What to implement

In depth

The six fields of the Properties struct

Each token carries six pieces of information, represented by the Properties struct. tokenIssuer is the network or entity that mints the token, assetHolder is the legal owner of the physical asset, storageLocation is the place where the physical asset is kept, terms is an IPFS link to the contract or terms of service, jurisdiction is the governing law and jurisdiction set out in terms, and declaredValue is the asset value declared at the time of minting. declaredValue is an Amount struct made up of a currency (currency, string) and a value (value, uint256). All fields are strings, so a party can be identified not only by name but also by a unique identification number issued by a service provider or by a network ID.

The effect each field aims for

Disclosing tokenIssuer gives holders a reference point for doing due diligence on the issuer and assessing its credibility, and it holds issuers accountable, which drives standardization of minting practices. assetHolder is disclosed separately because one cannot assume the issuer is the legal owner of the physical asset, and it lets holders weigh legal counterparty risk. storageLocation lets holders assess the risk that storage conditions pose to value, and it becomes a second point of contact for enforcing redemption. terms and jurisdiction help assess legal risk and enforceability. declaredValue serves as a reference and classification for ancillary services such as insurance. The original text states explicitly that this value does not necessarily mean market value.

Lifecycle rules for minting and burning

When a token is minted, its properties SHOULD already be initialized. The PropertiesSet event is emitted when properties are set, and the PropertiesRemoved event is emitted when they are removed. When a token with valid properties is burned, its properties MUST be removed. The Rationale of the original text explains that if properties are not initialized before minting, there is a risk that the provenance of the asset the token represents cannot be proven.

Behavior of getPropertiesOf

getPropertiesOf(uint256 tokenId) MUST return the unique properties of the token. A comment states explicitly that it does not revert even if the token does not exist. If the token has been burned or its properties were never set, it SHOULD return an empty Properties struct. Callers must handle the possibility that an empty struct is returned.

terms as an IPFS link

The terms parameter SHOULD be an HTTP link to a document stored on IPFS. IPFS is a distributed storage method in which the address changes when the content changes, so holders can verify that the document has not been tampered with. The intent of the original text is that the more an actual legal document such as a contract or terms of service is included as a link, the better holders can assess the legal risk of enforcing redemption.

Why there is no contract-level validation

There is no contract-level validation of property values. The original text takes the position that the accuracy of the recorded data is the responsibility of the token issuer, and explains that this builds trust in the issuer and in the token itself. In other words, the chain does not guarantee whether the data is true or false. Instead, the structure makes the issuer identifiable and holds them accountable.

Key mechanisms of the reference implementation

The reference implementation based on OpenZeppelin ERC-721 v5 overrides the _update function to enforce the lifecycle. If the recipient is the zero address (burn), it deletes the properties with _removePropertiesOf, and if the sender is the zero address (mint), it reverts with the PropertiesUninitialized error when _properties[tokenId].tokenIssuer is empty. _setPropertiesOf, which writes properties, is an internal function. It warns that it should be called only from a trusted EOA, an approved contract, or a function whose access is restricted by role-based access control (RBAC). This standard is compatible with ERC-721, requires ERC-165 and ERC-721, and its status is finalized as Final.

Things to watch out for

Original ERC · ← ERCs