XChain Platform Token Information Standard (TIS)
The Token Information Standard (TIS) defines standardized formats to associate information like images, audio, video, and files with a token.
JSON Specifications
v1.0.0
JSON Field Definitions
| Field | Type | Description |
|---|---|---|
| tick | String | The TICK of the token |
| description | String | A longish description about this token. 2048 characters max. |
| website | String | A link to the website for the token. 100 characters max. |
| name | String | The full name of the token |
| html | String | HTML code providing additional information or functionality |
| owner | Object | Information about the owner of this token |
| contacts | Array | Information about how to contact the owner of this token |
| categories | Array | Information on what type of categories this token falls into |
| social | Array | Social media accounts related to this token |
| images | Array | One or more images used to represent the token |
| audio | Array | One or more audio files related to the token |
| video | Array | One or more video files related to the token |
| files | Array | One or more files related to the token |
| packs | Object | Display metadata for token-gated content packs. Map of pack id → { name, description }. |
| dns | Array | One or more DNS records related to the token. |
File Entry Fields
Entries inside the files, audio, video, and images arrays can carry the following fields:
| Field | Type | Description |
|---|---|---|
| data | String | URL to the file (off-chain). Used for non-gated content. |
| data_ref | String | Reference to an on-chain FILE action by ACTION_INDEX: action:<index> (same chain as the token) or action:<COIN>:<index> (sibling chain — base coin ticker BTC/LTC/DOGE, network tier implied by the token’s network, same convention as LINK’s COIN1/COIN2). Lets cheap chains carry the bytes for tokens on expensive ones — e.g. a BTC token whose artwork FILE lives on DOGE. When both data and data_ref are present, clients prefer data_ref. |
| name | String | Filename |
| type | String | MIME type |
| title | String | Display title |
| locked | Boolean | true if the file is encrypted and gated. Clients use this to render locked/unlocked states without first fetching the FILE action. |
| pack_id | String | (Optional) Pack identifier grouping files that share an unlock key. References the top-level packs map for display name and description. Does not need to be present for unlocking to work — the protocol groups by KEY_HASH directly. |
NFT Usage
Tokens following the NFT Standard use TIS as their display
layer: the protocol records which files a token’s owner has officially attached (via
FILE + LINK), but attaches no display
semantics to them — the token’s TIS document decides what clients render and how.
Recommendations for NFT issuers:
- Declare intent with a category entry so clients can distinguish a collectible from an integer-unit currency that happens to share the same field values:
"categories": [ { "type": "main", "data": "NFT" } ]
- Use
data_reffor on-chain content. Pointingimages/audio/video/filesentries at on-chainFILEactions ("data_ref": "action:<index>") gives the display assets the same permanence as the token itself. Off-chaindataURLs remain valid for creators who prefer them. For tokens on expensive chains, upload the bytes on a cheap sibling chain and reference them cross-chain ("data_ref": "action:DOGE:<index>"). - For a fully on-chain token, upload the TIS JSON itself as a
FILEaction and setDESCRIPTION=action:<index>(the On-Chain Format below). With the document and itsdata_refmedia all on-chain, every byte a client needs to render the token is recoverable from a full chain parse — no hosting, no hostnames. - For immutable presentation, host the TIS JSON content-addressed (
ipfs:/ord:/ar:or URL;HASHforms below) and setLOCK_DESCRIPTION=1on the token so the pointer can never change. (The on-chainaction:<index>form is inherently content-immutable — locking the description makes the pointer immutable too.)
Clients classify a token as NFT-pattern by chain state (DECIMALS=0 +
LOCK_MAX_SUPPLY=1 — the canonical rule is defined in the
NFT Standard) and treat the TIS
category as the issuer’s stated intent.
Supported Token Description Formats
Below are a number of token description formats which should be recognized by XChain block explorers.
IMAGE Format
| Format | https://domain.com/imagename.jpg |
| Note | URL must end in gif, jpg, or png |
| Example | https://xchain.io/img/xchain-color-500.png |
JSON Format
| Format | https://domain.com/info.json |
| Note | URL to a JSON file ending in .json |
| Example | j-dog.net/json/JDOG.json |
JSON Format with Hash
| Format | https://domain.com/info.json;HASH |
| HASH | 64-character sha256 hash |
| Note | URL to a JSON file ending in .json |
| Example | j-dog.net/json/JDOG.json;96fc96754c913f60e9d7a0be07d76ffbcdc53338295cbd69595e69cf49616c3b |
On-Chain Format (action index)
| Format | action:INDEX or action:COIN:INDEX |
| INDEX | ACTION_INDEX of a FILE action whose raw bytes are a TIS JSON document (declared MIME type application/json) |
| COIN | (optional) base coin ticker (BTC/LTC/DOGE) when the FILE lives on a sibling chain; omitted = same chain as the token. The network tier (mainnet/testnet/regtest) is implied by the token's network — same convention as LINK's COIN1/COIN2. Lets cheap chains carry the document for tokens on expensive ones. |
| Note | The fully on-chain form: the TIS document itself lives on a chain, so the token's display metadata has the same permanence as the token. Combine with data_ref entries inside the document for on-chain media (also same- or sibling-chain), and LOCK_DESCRIPTION=1 for an immutable pointer. Same casing/format as data_ref, one level up. Clients resolve the bytes the same way they resolve data_ref (e.g. the explorer's /{COIN}/api/file/{INDEX}/raw). |
| Example | action:12345 · action:DOGE:12345 |
IMGUR Format
| Format | imgur/IMAGENAME;TITLE |
| IMAGENAME | Filename of the image on imgur.com |
| TITLE | Title of the image/artwork |
| Note | In the URL https://i.imgur.com/yTS3gEv.png the IMAGENAME is yTS3gEv.png |
| Example | imgur/yTS3gEv.png;XChain |
SOUNDCLOUD Format
| Format | soundcloud/CODE;TITLE |
| CODE | Unique code for the audio on soundcloud.com |
| TITLE | the title of the song/artwork |
| Note | In the URL https://api.soundcloud.com/tracks/924613324 the CODE is 924613324 |
| Example | soundcloud/924613324;Back in Blood |
YOUTUBE Format
| Format | youtube/CODE;TITLE |
| CODE | Unique code for the video on youtube.com |
| TITLE | the title of the video/artwork |
| Note | In the URL https://www.youtube.com/watch?v=FenVJ_cyE5M the CODE is FenVJ_cyE5M |
| Example | youtube/FenVJ_cyE5M;Can't Suck Dick! |
IPFS Format
| Format | ipfs:CODE |
| CODE | Unique IPFS CID that points to a JSON file |
| Note | The ipfs format only works with JSON files |
| Example | IPFS:QmdnznjxzrjmLGpwjiDrgfdAu5r7VB4tWWWVtNRtqYqACq |
Ordinals Inscription Format
| Format | ord:CODE |
| CODE | Inscription Reveal Transaction ID (standard 64 character hex string or converted to Base64) |
| Note | The ord format works with inscribed JSON files and inscribed images (png, jpeg and gif only) |
| Example | ORD:1d36aa544a20be86dca452e3abe464d33dd8567392dee8e333f72519e97af679 or ORD:HTaqVEogvobcpFLjq+Rk0z3YVnOS3ujjM/clGel69nk= |
Arweave Format
| Format | ar:HASH |
| HASH | Arweave transaction hash that points to a JSON file |
| Note | The ar format only works with JSON files. The hash is resolved via the public Arweave gateway at https://arweave.net/HASH |
| Example | AR:jGxVm7yghVDfv39tJds8kRFFrIsGTsg3h-JgXHx_inw |
Copyright © 2025–2026 Dankest, LLC
Based on XChain Platform by Dankest, LLC – https://dankest.llc
Licensed under the GNU Affero General Public License v3.0 (AGPL-3.0-or-later) with a commercial license available for proprietary use.
You may use, modify, and distribute this material under the terms of the License. See LICENSE and NOTICE for full terms. See the licensing overview.