NFTokens often entail unique and identifiable data, this is commonly referred to as Metadata. This data storage allows NFTokens to be clearly distinguished and displayed, in an interoperable manner, throughout various platforms.
OCM follows a widely agreed standard for metadata representation, and details are given below. Pleas ensure all relevant data is formatted as explained below, this will allow seamless and efficient listing and trading throughout platforms.
OCM supports the XLS-20 standard for NFTokens on the XRPL. More details can be found here.
This standard does not store metadata on the XRPL network. Instead, issuers are required to host the metadata elsewhere, and use a Unique Resource Identifier (URI), to point to the details surrounding the NFToken.
This URI should typically direct users to a hosted JSON file, that contains all the relevant metadata for the NFToken. Details on NFTokens and URIs, within the XRPL, can be found here.
It is vital that the token is minted purposely, as the data cannot be altered on the XRPL (other than being burnt). The following describes how the metadata should be displayed and hosted.
| Field | JSON Format | Options | Description |
|---|---|---|---|
| name | String | True | The name of the asset that the NFToken represents/is. This should be a short phrase that is easy to read, and understandable by users. |
| description | String | True | A description of the purpose of the NFToken and/or the project it represents. This should be a quick summary that provides context to the purpose of the asset. This should be a moderately lengthened paragraph, but one that is concise and direct. |
| image | String | True | This is the URL link (please see below for more details), to the visual representation of the asset. File types include, '.png', '.jpg', '.jpeg', '.gif', '.mp4', '.webm', '.ogg'. |
| external_url | String | True | This should be a ‘https’ formatted URL, that points to an external website giving more details on the NFToken. Examples include project websites, further readings, and blogs. |
| attributes | Array | True | This will be an array of objects, that contains the unique attributes of the NFToken, to be displayed. Each object in the array contains 2 fields. 1. “trait_type”, refers to the name of the trait. 2. “value”, refers to the value of the trait. Both values can exist as either a String, or a Number. These should be clear and concise descriptors of the unique characteristics of the NFToken. The exact contents are not strict, and can be modified to suit your use-case (but the JSON naming convention must remain constant). |
| collection | Object | True | This object represents the group (or groups) that the NFToken belongs to. It contains 2 fields. 1. “family”, refers to the wider group/collection the NFToken represents. 2. “name”, refers to the subgroup within the family the NFToken represents. Both values should exist as a string. They should be concise phrases, identical to other NFTokens of the same category. |
| edition | Number | True | This is a number that represents what edition/release number the NFToken represents. It should be a whole, positive number. |
| date | Number | True | This should be a UNIX timestamp (in milliseconds), representing the minting date, or the date the NFToken Image/Details were developed. It refers to the number of milliseconds that have passed since Unix Epoch (January 1st, 1970) |
| compiler | String | True | This should be a simple string, referring to the compiler/artist that generated the artwork. |
Please note, that while all fields are optional. Failure to include relevant details may result in a misrepresentation of your NFTokens. As per all JSON files, ensure the formatting (capitalisations and spelling) are correct.
The following content is applicable to URLs that exist in both the URI of the NFToken, and the metadata endpoint.
OCM supports 2 URL formats: "https" protocol and IPFS protocol.
Any data that does not exist on the IPFS system, should be displayed using “https” standards (i.e. “https://onchainmarketplace.net/”). This hosting type is applicable to those that wish to be able to alter/modify metadata representations, after NFToken minting, or to any issuers that need to maintain control of endpoints. Please note, OCM will update/retrieve any “https” linked data once every 24hrs
For immutable and permanent data hosting, the IPFS protocol may be used. Data should be represented as per the official recommendation for best practises, found here. This means all IPFS stored data should be displayed as ipfs://
Minting NFTokens on the XRPL is a simple, and cost-effective, process. Official documentation can be found here.
A free Desktop Application has been supplied by OCM, to allow developers to mint NFTokens with ease and in a trustless manner. This process requires no coding knowledge and streamlines the OCM listing process. There is no obligation to list or utilise OCM after using the free application. This can be found at the bottom of the site here.
There are many methods to upload and host metadata immutably on IPFS. Developers can refer to the official documentation here.
Pinata, is also an affordable and simple platform that can streamline this process with no coding knowledge required. Their services are recommended for those who aren't confident following the official documentations.