Latest Radiant Node Release
1.3.0 Energy
Radiant Blockchain Wiki
Official Website
  • Radiant Blockchain
  • FAQs
  • Induction Proof System FAQs
  • Links
  • White Papers
    • Radiant: A Peer-to-Peer Digital Asset System
      • Radiant: un Système d'Actifs Numériques Pair-à-Pair
      • Radiant: 一种点对点数字资产系统
      • Radiant: un sistema de activos digitales electrónico peer-to-peer
      • रेडियंट: एक सहकर्मी से सहकर्मी डिजिटल संपत्ति प्रणाली
      • Radiant: Sistem Kasugihan Aset Digital Peer-to-Peer
      • Radiant: Sistem Aset Digital Peer-to-Peer
    • Radiant Blockchain System Design
  • Programming
    • Radiant Opcodes
    • Pay to Ref
    • Non-Fungible Tokens on Radiant
    • Token-Controlled Contracts on Radiant (Pay to Token)
    • Glyphs Protocol
    • RadiantScript
      • About RXD
      • Command Line Interface
      • Getting Started
      • Guides
        • Writing Covenants & Introspection
        • Syntax Highlighting
      • Language
        • Artifacts
        • Contract Structure
        • Examples
        • Global Functions & Operators
        • Global Variables
        • Language Grammar
        • Types
      • SDK
        • Examples
        • Contract Instantiation
        • Sending Transactions
      • Releases
        • Migration Notes
        • Release Notes
    • scryptlib
      • preimage
        • preimage - Chinese
      • rawstate
      • HashedMap
        • HashedMap - Chinese
      • Chained APIs
        • Chained APIs - Chinese
    • Scrypt Boilerplate
  • Guides
    • Docker
    • Electron Wallet
      • Restore
      • Create multisign
    • Radiant Node
    • Flux
Powered by GitBook
On this page
  • A simple NFT contract
  • Melting a token
  • Conclusion

Was this helpful?

Edit on GitHub
Export as PDF
  1. Programming

Non-Fungible Tokens on Radiant

PreviousPay to RefNextToken-Controlled Contracts on Radiant (Pay to Token)

Last updated 6 days ago

Was this helpful?

Radiant's singleton references are ideal for the creation of NFTs. A singleton ref is a type of reference which can only ever exist in a single UTXO. A transaction is invalid if a singleton ref is pushed to more than one output. References cannot change type, so a singleton ref must be created as a singleton. Therefore we can be sure that there has only ever been one instance of a singleton ref.

The opcode for pushing a singleton ref is OP_PUSHINPUTREFSINGLETON.

A simple NFT contract

We will define a contract for an immutable NFT by adding a singleton ref to a standard P2PKH script:

OP_PUSHINPUTREFSINGLETON <ref> OP_DROP
OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

Following Radiant's ref rules, the ref must match an outpoint or a ref of the same type in an input. If the ref matches an outpoint then this is the "mint" transaction. OP_PUSHINPUTREFSINGLETON leaves the ref on the stack, and since we don't need it later in the script it is immediately dropped.

DIAGRAM

Mint and transfer of an NFT, followed by an invalid transaction

As seen in the diagram above, an outpoint in the first transaction is used to create a singleton ref. The referenced output also contains an "immutable token payload" which can be stored as a push data. This is a simple way of associating data with our token, where the token data can be fetched from the referenced output. The payload could be an image or more complex data structure. Token UTXOs are kept light weight by not carrying the payload.

This token protocol can be used for a wide variety of use cases such as tickets, coupons and collectibles. Wallet integration is simple since the script only requires a singleton ref in addition to a standard P2PKH script.

Melting a token

Melting a token only requires that the token be spent and the singleton ref not pushed forward. Once the singleton does not exist in a UTXO it cannot be recreated.

Conclusion

Singleton refs are a simple yet effective way of creating an NFT protocol. We have demonstrated how a token protocol can be created with only a small change to a standard P2PKH script. In future articles we will explore how to extend this contract to support mutable data.