ERC-6596 Cultural and Historical Asset Token (CHAT) metadata (Cultural and Historical Asset Token)
Review · Names & metadata · created 2023-02-28
Defines a common metadata format for recording the provenance and historical context of cultural and historical assets, such as artworks, artifacts, and rare collectibles, when they are minted as NFTs. This makes it easier to search for and connect scattered collections.
Why it is needed
The default metadata of the existing NFT standard (ERC-721) covers only basics like name, description, and image. For culturally and historically significant assets such as paintings or artifacts, provenance history, such as who created the piece, what materials and techniques were used, and whose hands it passed through before reaching its current owner, underpins its value, but there is no common format for recording this. As a result, each issuer builds its own metadata structure, making it difficult to consistently search for or connect tokenized assets on the blockchain. The original text cites incidents of museums losing artifacts and data breaches to argue that, instead of relying on trust-based record-keeping, tamper-proof records need to be kept on the blockchain. It also points out that without a structure compatible with the many metadata standards already used in the art and culture field, it is difficult for museums and institutions to adopt blockchain.
In depth
An off-chain extension of ERC-721/1155 metadata
This standard does not create a new on-chain interface. Instead, it extends ERC-721's Metadata JSON Schema and ERC-1155's Metadata URI JSON Schema with 48 attributes. Compliant contracts implement the corresponding metadata schema, and token metadata must follow the HistoricalAssetMetadata TypeScript interface. The off-chain JSON extension approach was chosen because existing NFT contracts can adopt it without upgrades or migrations and can continue using contract code that has already been audited and verified, reducing the risk of adopting a new standard. It is fully backward compatible with existing ERC-721 and ERC-1155.
HistoricalAssetMetadata structure
There are five top-level fields: name (token name), description (a full description containing cultural and historical context), image (a cover image URI with an image/* MIME type), attributes (an array of CHATAttribute), and attributesExt (an array of ExtendedCHATAttribute), all of which are optional. If a field has multiple values, the attribute object can be repeated. In the example metadata for "The Great Wave off Kanagawa," Subject Matter and Provenance are repeated multiple times in this way.
attributes: core attributes for display and search
attributes contains the core attributes that NFT galleries and marketplaces display and search directly. These include creator information (Creator Name, Creator Bio), production information (Publication / Creation Date in ISO 8601 format, Materials and Technology, Edition, Series name), physical information (Dimensions Unit along with height/width/depth, Inscriptions / Marks), ownership and provenance (Current Owner, Provenance, Acquisition Date, Credit Line), rights (Copyright Holder, Copyright / Restrictions), location (Asset Creation Geo referencing ISO 3166-2, Asset Creation Coordinates), related information (Relevant Date, Relevant Geo, Relevant Person, Relevant Entity), language (Asset Language referencing ISO 639), and whether the asset is physical (Is Physical Asset, boolean). Most value types are string, while dimensions and file size are number.
attributesExt: in-depth data that is not displayed
attributesExt is an extended set of attributes that holds in-depth information but is not meant to be displayed or searched in galleries or marketplaces. It consists of six fields: Asset Full Text (the full text of the asset), Exhibition / Loan History, Copyright Document (a URI to the copyright agreement document), Provenance Document (a URI to existing provenance records), Asset URL (a URI to a high-quality file), and Copyright Document of Underlying Asset (a URI to the legal document defining the token owner's rights). Separating these from the core attributes is intended to keep the general user interface uncluttered while still giving researchers and historians access to richer records.
Interoperability with existing cultural and artistic standards
Several metadata standards already exist in the art and culture field. This standard aims for a structure suited to blockchain preservation while remaining interoperable with existing standards and complying with the Open Archives Initiative (OAI) and International Image Interoperability Framework (IIIF) protocols. It also enables integration for search and discovery without consolidating ownership in one place. The original text cites, as an example, artifacts from Silk Road sites being linked to Buddhist paintings, sculptures, and texts scattered across museums in multiple countries. The metadata format is compatible with ERC-721 and OpenSea-style metadata.
Authenticity verification is out of scope; currently in Review status
How to verify that claims written in a metadata JSON file are true is out of scope for this standard, and an appropriate protocol is left to be proposed in a future EIP. This proposal is also currently in Review status, so its contents may still change.
Things to watch out for
- Caution against SSRF via URI fields: Metadata files must be treated as externally provided data. In particular, when handling URI fields, care must be taken that a malicious issuer cannot exploit the backend to cause Server-Side Request Forgery (SSRF), tricking the server into making requests to internal resources.
- Character escaping to prevent XSS: Frontends and clients are recommended to escape all control characters that could be exploited for cross-site scripting (XSS).
- Managing resource allocation to prevent DoS and buffer overflows: Mishandling variable-length data such as strings, arrays, or JSON objects can cause buffer overflows and leave a system vulnerable to denial-of-service (DoS) attacks or security bypasses triggered through exceptions. Processing systems must manage resource allocation carefully.
- Stored on decentralized storage: Metadata JSON files and the digital material representing a token's underlying asset must be stored on a decentralized storage network to preserve integrity and ensure availability for long-term preservation.
- Does not guarantee the authenticity of metadata content: Verifying the truth of claims recorded in a metadata file is out of scope for this standard. Defining an appropriate verification protocol is left to a future EIP.