We have just released our roadmap for 2024, and we are thrilled about what's in store. Our primary objective with this short-term roadmap is to commit to delivering specific functionalities within a relatively short period of time. 

One of the developments we are most excited about is the integration of ordinals into Qtum. 

Qtum has always supported established token standards like ERC-721 and ERC-1155 on the smart contract EVM layer, allowing users to mint NFTs. But we also want to make room for the new and embrace the new Ordinals protocol on Qtum.

Our blockchain is based on Bitcoin Core and Ethereum, which means we support the latest Bitcoin Improvement Proposals. One of these BIP’s included the Taproot activation, which Qtum integrated in late 2021. This allows Qtum to make use of the Ordinals protocol.

In early 2024, we'll introduce a set of tools that will help facilitate a Qtum implementation of BRC-20 tokens and Ordinals. This is already working in a testnet environment using the "QORD" wallet. 

We plan to release an indexer, blockchain explorer, and web-based frontend that will make it easier for users to inscribe Ordinals. We're also working with a third-party partner to introduce a more user-friendly wallet to interface with the indexer and block explorer.

What Are Ordinals? 

We all know about NFTs, and some wonder why we need Ordinals. But first, let’s explore what they are. 

Ordinals are a novel concept in the cryptocurrency space that facilitates the unique identification of individual satoshis, which are the smallest units of Bitcoin and QTUM. 

This unique identification is achieved by assigning a sequential number, called an ordinal number, to each satoshi in the order of their creation through mining. This transforms each satoshi from a fungible to a non-fungible or at least distinguishable unit.

The introduction of ordinals effectively enables each satoshi to carry distinct characteristics, similar to how serial numbers differentiate individual banknotes. However, unlike banknotes, which are physical and thus naturally distinct, satoshis are digital and were designed to be indistinguishable from one another. Ordinals disrupt this fungibility by attaching a unique ordinal number to each satoshi.

Technically, this approach does not alter the fundamental properties of Bitcoin and Qtum or require protocol changes. Instead, it utilizes existing transaction metadata fields to embed ordinal information. This process relies on the blockchain's inherent immutability and the chronological ordering of blocks to establish a verifiable sequence of satoshi creation.

How are Ordinals different from traditional NFTs? 

Non-Fungible Tokens (NFTs) have gained widespread attention for their ability to represent unique digital assets on blockchain networks. An NFT is a special type of token that is distinct from others due to its unique attributes and metadata. This uniqueness allows for the ownership and transfer of digital art, collectibles, and other one-of-a-kind digital items.

Ordinals differ from NFTs in several key aspects. Firstly, NFTs typically exist on separate layers or smart contract platforms built on top of a blockchain, whereas ordinals are intrinsic to the blockchain itself, marking the native currency units. 

Secondly, while NFTs are distinct tokens within a broader ecosystem (e.g., ERC-721 or ERC-1155 tokens on Ethereum), ordinals turn the smallest units of the cryptocurrency (e.g., satoshis on Bitcoin) into uniquely identifiable units. This intrinsic identification does not rely on external smart contracts or tokens.

This is achieved by using the taproot upgrade, which introduced new ways to embed data in transactions through Tapscript. The transaction outputs (vouts) containing the inscribed satoshis use Taproot to enable the inclusion of arbitrary data, like text and images, without compromising privacy or scalability.

NFTs on the Ethereum network usually only contain metadata or a URL pointer to off-chain data, while Ordinals store content on the blockchain through inscriptions. 

This makes Ordinals more decentralized and censorship-resistant than NFTs on a smart contract, depending on how they are deployed. If the smart contract is hacked, or the contract has ways for the developer to change variables later, it could be considered centralized. If the off-chain data is altered, there could be risks. Ordinals are a more permanent solution that cannot be altered when inscribed.

For example, you may own an Ape NFT. You can trace it and put a price on it. Even if someone screenshots it, you have proof you own it. But here comes the tricky part: the actual picture of the Ape is not stored in the blockchain; it is stored off-chain, and it could stop existing at any given moment.

When it comes to off-chain storage of NFTs, the NFT's smart contract has information that points to where the actual NFT JPEG image is stored. Usually, the NFT image and its metadata are stored as a hash. This hash points to a hosting provider, which is usually centralized, like Google or Amazon. These providers run servers that store the NFT's data. 

Although it is unlikely, these servers could shut down at any time, resulting in the loss of your NFT image viewing ability, and you would be left with a simple hash in a smart contract. 

NFT owners would have to revisit the smart contract and change the URL once they migrate to a new server in order for their NFT to be easily viewable again. 

With Ordinals, it is simply stored natively on the blockchain via inscription and viewed with any indexer. This is a great selling point because you don’t have to rely as much on an external provider as anyone can deploy an indexer.

Latest development update: 

Done: 

The first version of the Indexer API has been implemented in the test environment and currently provides two interfaces.

Working on:

1. The Index data source parses events from its own on-chain by hand and switches to reading events from the Trust Source ORD.

2. Reference to librc20 to maintain two different balance types: Transferable Balance and Available Balance.

3. Event processing and verification logic goes through the BRC20 specifications to ensure compliance. 

We hope the Qtum community is as excited as the team, this is only the first step of an evolved Qtum ecosystem that will allow developers to build and make the most of our tools. We’ll keep you updated on the progress.

Join the Qtum Community

If you haven't already, we invite you to become a part of our community. Stay updated with the latest developments, participate in discussions, and contribute to the growth of the Qtum ecosystem. Here are some places to connect with us:

Qtum Discord

Qtum Twitter