> For the complete documentation index, see [llms.txt](https://docs.otherside.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.otherside.xyz/odk-docs/odk-plugin/nfts-tokens.md).

# NFTs / Tokens

NOTE: The creator portal is in Alpha and only avaliable to specific developers, please talk to your Yuga representative if you have a need to access this.

The **ODK Token System** provides a unified way to track and synchronize player progress, rewards, achievements, and quests across the blockchain and experience.

Tokens can be used for **persistent state**, with each token type having a specific purpose and behavior.

***

### 🔍 What Is a Token?

In the context of ODK, a token is an on-chain data object that represents something the player owns.

Token are:

* **Minted and granted via the Creator Portal**
* **Stored in the player’s wallet**
* **Used to trigger or gate gameplay systems**
* **Synced in real-time between web, blockchain, and in-game logic**

All tokens follow a consistent format for their **Token ID**:

```
<ChainID>:<ContractAddress>:<TokenID>
```

Example:

```
33139:0x1122334455667788991122334455667788991100:3
```

| Component | Description                          |
| --------- | ------------------------------------ |
| `33139`   | Chain ID (e.g. APECHAIN)             |
| `0x...`   | Contract address for your experience |
| `3`       | Unique Token ID                      |

***

### 🧱 Supported Token Types

Each token is defined by its `type` field in metadata, which determines how it is handled in-game. This `type` is also used by the `TokenHandlers` map on the player wallet to route token logic.

| Type                  | Purpose                                                                                                   |
| --------------------- | --------------------------------------------------------------------------------------------------------- |
| `quest`               | Sequential multi-task experiences with reward support (See: [ODK Quests](/odk-docs/odk-plugin/quests.md)) |
| `achievement / badge` | Recognitions of completion, progress, or milestones                                                       |
| `image`               | Selfie/image tokens — used for storing screenshots or custom UGC                                          |
| `item`                | Inventory items (experimental or project-specific)                                                        |
| `custom`              | Any developer-defined use case (requires custom TokenHandler)                                             |

*Each type can have its own UI, reward logic, and flow triggers.*

***

### 🛠 Where Tokens Fit in Your Project

Tokens can:

* Start quest flows (by triggering `BP_ODK_TaskFlow`)
* Unlock achievements or badges
* Be displayed in user profiles or overlays
* Gate access to in-game systems or areas
* Be granted via Blueprint, server-side logic, or web interfaces

***

* 📜 [Quest Tokens](/odk-docs/odk-plugin/quests.md) – Multi-step task sequences with XP and rewards
* 🏆 Achievement Tokens – One-time accomplishments or stats
* 🎖️ Badge Tokens – Visual trophies or collectibles
* 🖼️ Image Tokens – Player-submitted images (e.g. selfies, UGC)
* ⚙️ Custom Token Types – Extending the system for new behaviors


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.otherside.xyz/odk-docs/odk-plugin/nfts-tokens.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.