Join the Radiant Community on Discord
The fuel of the Radiant Network is RXD
Native Asset Indexing
Induction Proofs
Trustless interaction
Ultra Fast Transactions
1,000+ TPS
Low fees to do more
Build on Radiant today
Smart Contracts
Creator and dev friendly
Future-Proof Design
Highly Scalable
Grows with demand
Solves the high costs, instability, and limited scaling of existing blockchains
Radiant RXD
21 billion coins
Total maximum supply
Photons
100 million
Sub units per RXD coin
PoW Consensus
Layer 1 blockchain
UTXO + Account based
Induction Proofs
Onchain indexing
Native validation of assets
Low fees. High tps
1,000+ TX per sec
Designed for 500k+ TPS
Block Time
5 mins (300 secs)
Instant with 0-confs
Mining Algorithm
SHA512/256d
GPU/FPGA/ASIC
Smart Contracts
Turing Complete
Extensive Opcodes
Highly Scalable
System design
Multiple Node types
Block Size
256mb initial
Designed to achieve 10gb
Genesis Block
20 June 2022
Fair launch. No pre-mine
Halving Schedule
Every 2 years
50k RXD per block start
Access the power of Radiant
Cold hardware wallet for RXD
Desktop wallet v0.1.4 for RXD
Manage Glyph Radiant Tokens
Mine Glyph Radiant Tokens
0.1 RXD per IP to get you started
Browser Extension - Alpha
Explore by Transactions
Explore by Blocks
Buy and trade RXD
RXD/USDT
RXD/USDT
RXD/USDT
RXD/USDT
RXD/USDT
RXD/USDT
Dive into how Radiant works
Radiant Blockchain Whitepaper
Radiant System Design Paper
Run a Radiant Full Node
Run and host an ElectrumX Server
Build with Radiant Opcodes
Radiant JavaScript Library
Rust/WASM Library
Pools and software
Technical Wiki
Live metrics of RXD
RXD market stats
RXD market stats
RXD market stats
RXD market stats
RXD mining stats
RXD mining stats
RXD mining stats
RXD mining stats
What's coming in the future?
Radiant P2P Naming System
Trade Glyph tokens with RXD
Trade Glyph tokens with RXD
Radiant is a peer-to-peer programmable digital asset system, derived from a fork of the Bitcoin Cash (BCH) genesis block. It introduces new Opcodes that enable Turing completeness and mathematical induction proofs, effectively addressing the "back to genesis" problem. This innovative design combines the performance and parallelism advantages of an Unspent Transaction Output (UTXO) blockchain with the contract capabilities found in Ethereum-based blockchains, specifically the Ethereum Virtual Machine (EVM).
Radiant stands out for several reasons:
Radiant was launched as a 100% PoW blockchain, ready for use, without any involvement of investors, ICOs, premining, or coin allocations. Mining guides and instructions, including how to mine with rented hash power, were publicly released by Atoshi, Radiant's developer, ensuring that everyone had equal access to RXD coins from day one.
BTC civil wars divided blockchain enthusiasts into small-block and big-block proponents. In BTC, small-blocks won and big-block proponents forked it to create BCH. BCH still ended deviating from what BTC was supposed to be based on what is stated in the Bitcoin Whitepaper.
Another fork (BSV) was made, aiming to make it as close as possible to the original BTC proposed by Satoshi Nakamoto. This version of Bitcoin is still far from perfect as it has to rely on third party indexers to function properly. Additionally, its associations with an individual who claims to be Satoshi Nakamoto who has initiated legal actions against some blockchain projects, raised concerns about potential legal challenges.
This made BCH a more favorable choice for Radiant's development.
SHA512256d is a hashing algorithm that takes a SHA512 hash and truncates it to SHA256. Although SHA256 is already secure enough, SHA512256d was chosen to ensure a secure and battle-tested blockchain compatible with ASIC machines. This choice levels the playing field, fostering a truly decentralized, massively scalable, cost-efficient blockchain where no ASIC capable of mining RXD currently exists.
Radiant was specifically designed to transition from GPU mining to ASIC mining for enhanced scalability and efficiency. The chosen SHA512/256d algorithm simplifies ASIC manufacturing.
Radiant now has ASIC miners publically available on the market as of September 5th 2024. The first manufacturer to announce a Radiant compatible SHA512/256d ASIC miner was DragonBall Miner, with the A11 Dual ASIC Miner.
ICERIVER was the second manufacturer to release an ASIC miner for Radiant, with the ICERIVER RXD RX0.
A 5-minute block time offers faster transaction confirmations compared to Bitcoin (BTC) while maintaining stability and security by minimizing orphan blocks. With block sizes of up to 256MB and the potential for even larger blocks, selecting the right block time is essential. In Radiant, the block time, thanks to its features, does not directly limit transactions per second or transaction speed.
Radiant has a total maximum supply of 21 billion RXD, with a Proof of Work emission schedule emitting block rewards to miners every 5 minutes (300 seconds), with block rewards halving every 2 years.
Beginning with its Genesis Block on the 20th of June 2022, Radiant's initial block reward was 50,000 RXD per block, and Radiant's first halving event occurred on the 19th April 2024, halving to 25,000 RXD.
The next halving event for Radiant will occur around the middle of April 2026, reducing the block rewards to 12,500 RXD per block.
With the current block size of 256MB, Radiant is capable of doing 1,000+ TPS (Transaction Per Second). If needed, miners can optimize in the future to scale linearly. For example, with 3GB blocks, 20,000+ TPS can be achieved.
Radiant's tokenomics, with a 21 billion coin supply and 8 decimal places (100 million photons per RXD coin), positions it well for tokenizing digital and real-world assets while ensuring ample availability of RXD for both micro and macro transactions. The block time, block reward, and bi-yearly halvings serve as incentives attractive to miners and investors alike.
In blockchain terms, the "back-to-genesis" problem refers to the ability to validate that all coins, transactions, and digital assets can be traced back to the genesis block. Radiant successfully solves this problem, enabling it to operate as a truly decentralized and permissionless digital asset system without relying on external third-party indexers.
Turing completeness, in the context of a programming language, signifies that there are no limits to the types of computations that can be performed. Radiant's Turing completeness allows for highly flexible smart contract capabilities similar to those of Ethereum but without the scalability issues and high gas costs. This feature makes Radiant a unique and groundbreaking blockchain, capable of supporting a wide range of cryptocurrency and blockchain technology use cases.
How is Radiant protected against attacks that harness turing completeness if it doesn't have a gas system like ETH?
Radiant, while Turing complete, does not incorporate loops. Loops must be unrolled to the maximum number of iterations required. This design simplifies and secures script execution, allowing fees to be calculated per byte. This discourages malicious actors from creating overly complex or inefficient scripts, as they would incur higher fees.
A 0-conf transaction is one broadcasted to the blockchain but not yet included in a block (i.e., 5 minutes have not passed). These transactions are useful and safe for microtransactions. Thanks to induction proofs, recipients of 0-conf transactions can be confident that the sender indeed owns the funds being transferred. However, there is a minor risk of double-spending in such transactions.
For small transactions, the potential reward for attempting a double-spending attack is typically much lower than the cost of acquiring mining hardware, electricity, and competing with the network's hash rate. In practice, it's not economically rational for an attacker to invest significant resources in double-spending small transactions.
For larger transactions, it's advisable to wait for inclusion in a block, which provides increasing security with each additional block confirmation.
Radiant does not have RBF implemented. Radiant's decision to exclude Replace-by-Fee is a strategic choice that enhances transaction security, reduces double spend risks, and simplifies the user experience.
By prioritizing transaction finality and promoting responsible fee management, Radiant fosters a more secure and reliable blockchain environment.
This approach aligns with its commitment to maintaining a robust, miner-driven network that users can trust for fast, low cost, and dependable transactions.
In the world of blockchains, transaction security and network reliability are paramount. One feature that often sparks debate is Replace-by-Fee (RBF) vs, First In First Out (FIFO). While some blockchains implement RBF to allow users to replace a pending transaction with a new one that includes a higher fee, Radiant has opted not to include this feature.
Here's why this decision benefits the Radiant network and its users:
By not supporting RBF, Radiant ensures a higher degree of transaction finality once a transaction is broadcast to the network. This means that once a transaction is sent, it's committed to the network's mempool, reducing the risk of the transaction being replaced or tampered with. This provides more confidence to recipients, particularly in situations where quick transaction acknowledgment is essential.
RBF can be exploited for double spend attacks, especially in low-confirmation transactions. For instance, a user could broadcast a low-fee transaction to one party, then replace it with a higher-fee transaction to a different party, attempting to defraud the first recipient. To mitigate these risks, many businesses and users wait for several confirmations before considering a transaction final, especially for larger amounts. Radiant's decision to exclude RBF minimizes this risk, making it safer for merchants and users to accept zero or low-confirmation transactions without the fear of an attack.
Excluding RBF simplifies the transaction process for users and developers. With RBF, users have to be cautious about transaction replaceability, potentially leading to confusion or errors. Radiant's straightforward approach means that once a transaction is sent, users can have confidence that it won't be replaced, leading to a more predictable transaction experience.
Without RBF, users are encouraged to consider transaction fees carefully before broadcasting. This helps prevent network congestion caused by users continually adjusting fees to prioritize their transactions. It fosters a more balanced network usage where users evaluate the urgency of their transactions in relation to current network conditions, promoting a healthier fee market. Miners can still choose to process higher fee transactions at will, but the volume and speed of putting more transactions in a block is more valuable and hence important in a scalable network.
Radiant's Proof of Work consensus mechanism relies on the security provided by miners who validate and add transactions to the blockchain. By not having RBF, Radiant reinforces the trust in its PoW system, ensuring that transactions are treated as irreversible once included in a block. This aligns with the core principles of PoW, where the longest chain and the work behind it determine the network's state.
Bitcoin originally operated on a First-In-First-Out (FIFO) basis for transaction processing within the mempool. This means that transactions were typically processed in the order they were received by the network, regardless of the transaction fee. Miners would include the earliest transactions in the next block, provided they met the standard criteria for validity and size. Networks like Radiant that focus on true scalability by having adequate block space and faster block production will not suffer the same fate as size constrained and artificially limited networks. So the need for something like RBF is negated.
Radiant employs a Split Node System to accommodate its big-block design and scalability needs. Nodes in Radiant can operate in three different ways:
Radiant was bootstrapped and introduced to the world by an individual or group of individuals using the pseudonym "Atoshi." Similar to the anonymous creation of Bitcoin by Satoshi Nakamoto, Atoshi delivered a fully functional product without making any promises or guarantees, allowing the community to shape its future.
A step-by-step guide on how to mine RXD with an ASIC miner.
Radiant's initial GPU mining guide when it was first launched can be found on GitHub.
Check the Radiant Node deployment guides
Is there any reward for running a Radiant Node?
No, Radiant is a 100% PoW Blockchain. The only way to get RXD is through mining.
You can access your RXD through:
Software
Hardware
The current toolbox available to help developers build on Radiant is:
Radiant was created by a starting group of miners to begin bootstrapping the blockchain at 2022-06-20 02:42 UTC. All coins were mined from block height 0 with Proof-of-Work.
There is no initial allocation to the project. All coins were mined independently to set the Radiant Blockchain in motion and are owned by no single entity.
Release changes at block height 62000:
OP_STATESEPARATOR
and related Opcodes to segregate scripts and stateRelease changes at block height 214555:
List of new Opcodes:
<value> OP_PUSH_TX_STATE
Additional bug fixes and improvements:
OP_DISALLOWPUSHINPUTREF
is treated correctly
The induction proof system is a method used in the Radiant blockchain to ensure the authenticity and traceability of digital assets. It verifies that each transaction is linked back to a valid genesis transaction, preventing forgery and ensuring that all assets are genuine.
The induction proof system works by including references to parent and grandparent transactions in each new transaction. These references create a chain of trust, where each transaction can be verified against its predecessors, all the way back to the original genesis transaction.
The induction proof system is important because it provides a secure and efficient way to validate digital assets without relying on trusted third parties. It ensures that all assets on the Radiant blockchain are genuine and prevents double-spending and forgery.
Unique identifiers are like serial numbers for digital assets. They help track the asset's journey from the genesis transaction through all subsequent transactions. Each transaction output has a unique identifier, ensuring that the asset's lineage can be verified.
The Radiant blockchain uses a compressed transaction hash algorithm to summarize transaction contents into a fixed-size data structure. This prevents the exponential growth in transaction size that would occur if full copies of parent transactions were included in each new transaction.
A genesis transaction is the original creation of a digital asset on the Radiant blockchain. It serves as the starting point for the asset's lineage and is referenced in all subsequent transactions to verify authenticity.
To validate a transaction, you need to check the references to its parent and grandparent transactions. By verifying these references, you can ensure that the transaction is genuine and traceable back to the genesis transaction.
Opcodes are programming instructions used in the Radiant blockchain to manage and validate transaction
references. Examples include OP_PUSHINPUTREF
, OP_REQUIREINPUTREF
, and
OP_DISALLOWPUSHINPUTREF
. These Opcodes help enforce rules and ensure the authenticity of
transactions.
Yes, the induction proof system can be used to create and validate smart contracts on the Radiant blockchain. By ensuring the authenticity and traceability of transaction outputs, it supports the creation of complex contracts and digital assets.
The induction proof system enhances security by creating a chain of trust for each transaction. This makes it nearly impossible to forge or duplicate assets, as each transaction must be verified against its predecessors.
Practical applications of the induction proof system include digital asset management, creation of fungible and non-fungible tokens (NFTs), and implementation of complex smart contracts. It ensures the authenticity and traceability of these assets, making them secure and reliable.
The Radiant blockchain's use of the induction proof system and compressed transaction hashes allows for efficient and secure transaction validation. This provides a significant advantage over other blockchains that may rely on trusted third parties or less efficient validation methods.
Pay to ref is a powerful new script built using Radiant's unique induction proof system. This script provides a way of composing contracts from multiple outputs, introducing efficiencies and flexibility previously very difficult on UTXO based blockchains.
OP_REFTYPE_UTXO OP_0 OP_NUMNOTEQUAL
The above script uses OP_REFTYPE_UTXO
to take a given ref from the stack and return the
type of any ref found in the transaction's inputs. If the returned value is not equal to zero then we
know the ref has been found in the inputs. We can check for any ref type or a specific type.
OP_REFTYPE_UTXO
returns one of the following:
This script can be used to break a contract up into multiple parts. For example a complex NFT contract, split into a token contract and ownership contract:
UTXO for contract functions
// Contract functions
// function 1...
// function 2...
OP_PUSHINPUTREFSINGLETON <ref1> OP_DROP
<ref2> OP_REFTYPE_UTXO OP_2 OP_NUMEQUAL
UTXO for token ownership/control
OP_PUSHINPUTREFSINGLETON <ref2> OP_DROP
OP_DUP OP_HASH160 <pubKeyHash OP_EQUALVERIFY OP_CHECKSIG
The above contract is composed of two outputs. A singleton ref has been assigned to each output. The first UTXO can only be spent if the second "control" UTXO is also an input.
We can now handle token transfers using only the P2PKH output and not have to touch the rest of the contract. Since the token contract doesn't contain the P2PKH script, only a pay to ref, it is automatically carried forward with the transfer. For wallets to support transfers of this token, they only need to handle a simple singleton + P2PKH script and not be concerned with custom functionality or parsing custom contract templates.
Diagram: Transferring control of a token contract
The two singletons are best created as a contiguous set, so if any script needs to read from another part of the contract, it can check for the existence of a ref within its own set to verify the authenticity of the input. This also makes it easy for wallets to find all parts of the contract.
In this example we have only used two outputs, but this can be extended to compose contracts from three or more outputs.
Another powerful use case is to extend a contract's functionality by permitting the UTXO to be spent alongside one of a range of refs. These contract extensions can be defined at a later date, providing a way of upgrading contracts or adding new functionality.
The developer must plan this in advance, by keeping some refs in reserve, coded into the contract so they can be deployed and distributed to users later.
For example, a contract that allows locking conditions to be delegated to an input containing any ref from a specific transaction hash. The ref index is provided as a parameter in the unlocking script:
<extensionTxId> OP_SWAP OP_CAT OP_REFTYPE_UTXO OP_0 OP_NUMNOTEQUAL
The above script takes a ref index from the unlocking script, appends to the transaction ID to construct the ref and checks if the ref exists in an input.
Care must be taken to ensure the user remains in control of their coins and complete control is not given over to the developer. Requiring the owner's signature will ensure the developer cannot spend the coins.
The Radiant blockchain introduces a set of opcodes that significantly improves on the capability of the Bitcoin technology it's based on. All these opcodes are outlined below:
OP_STATESEPARATOR
. Useful for storing state data that can be changed by the contract.
OP_STATESEPARATOR
. If no state separator is present, the code script is the entire
script.
codeScriptHash
: The double SHA-256 of the code script.SHA-512/256 is the hash function used by Radiant's proof of work algorithm. It is available in script as single and double hash functions. These can be used to validate Radiant block headers in script.
Opcode | Hex | Input | Output | Description |
---|---|---|---|---|
OP_SHA512_256 |
ce | bytes | hash | SHA-512/256 |
OP_HASH512_256 |
cf | bytes | hash | Double SHA-512/256 |
Opcode | Hex | Input | Output | Description |
---|---|---|---|---|
OP_PUSHINPUTREF |
d0 | ref | ref | Propagates a ref to an output. A ref of normal type must exist in an input or an input must have an outpoint matching the ref. Ref will be left on the stack. |
OP_PUSHINPUTREFSINGLETON |
d8 | ref | ref | Propagates a singleton ref to an output. A ref of singleton type must exist in an input or an input must have an outpoint matching the ref. Ref will be left on the stack. |
OP_REQUIREINPUTREF |
d1 | ref | ref | A ref of normal type must exist in an input. Ref is not propagated. Ref will be left on the stack. |
OP_DISALLOWPUSHINPUTREF |
d2 | ref | ref | Requires a ref to not exist in any input. Leaves the ref on the stack. |
OP_DISALLOWPUSHINPUTREFSIBLING |
d3 | ref | ref | Requires a ref to not exist in any input sibling. Leaves the ref on the stack. |
OP_REFTYPE_UTXO |
d9 | ref | type | Get the type of a ref from transaction inputs. Returns 0 (not found), 1 (normal type) or 2 (singleton type). |
OP_REFTYPE_OUTPUT |
da | ref | type | Get the type of a ref from transaction outputs. Returns 0 (not found), 1 (normal type) or 2 (singleton type). |
OP_REFHASHDATASUMMARY_UTXO |
d4 | inputIndex | summary | For the input of the given index returns a hash256 of
<nValue><hash256(scriptPubKey)><numRefs><hash(sortedMap(pushRefs))>
|
OP_REFHASHDATASUMMARY_OUTPUT |
d6 | outputIndex | summary | For the output of the given index returns a hash256 of
<nValue><hash256(scriptPubKey)><numRefs><hash(sortedMap(pushRefs))>
|
OP_REFDATASUMMARY_UTXO |
e1 | inputIndex | summary | Return refs used within an input. Pushes a vector of the form
<ref1><ref2><ref3>... . If an input UTXO does not contain at least
one reference, then the 36 byte zeroes are pushed.
|
OP_REFDATASUMMARY_OUTPUT |
e2 | outputIndex | summary | Return refs used within an output. Pushes a vector of the form
<ref1><ref2><ref3>... . If an input UTXO does not contain at least
one reference, then the 36 byte zeroes are pushed.
|
Opcode | Hex | Input | Output | Description |
---|---|---|---|---|
OP_STATESEPARATOR |
bd | Separates the state script from the code script. Only one can exist in a script and it must not exist within an OP_IF. No OP_RETURN can exist in the script when used. | ||
OP_STATESEPARATORINDEX_UTXO |
be | inputIndex | separatorIndex | Returns the byte index of the state separator for an input. Returns zero if no separator exists. |
OP_STATESEPARATORINDEX_OUTPUT |
bf | outputIndex | separatorIndex | Returns the byte index of the state separator for an output. Returns zero if no separator exists. |
OP_CODESCRIPTBYTECODE_UTXO |
e9 | inputIndex | bytecode | Returns the code script bytecode for an input. |
OP_CODESCRIPTBYTECODE_OUTPUT |
ea | outputIndex | bytecode | Returns the code script bytecode for an output. |
OP_STATESCRIPTBYTECODE_UTXO |
eb | inputIndex | bytecode | Returns the state script bytecode for an output. Does not include the OP_STATESEPARATOR. |
OP_STATESCRIPTBYTECODE_OUTPUT |
ec | outputIndex | bytecode | Returns the state script bytecode for an output. Does not include the OP_STATESEPARATOR. |
These opcodes provide a set queries on inputs and outputs by ref, ref hash and code script hash. Counts and sums can be performed over many outputs with a single opcode, meaning an unrolled loop in the script is not required.
Opcode | Hex | Input | Output | Description |
---|---|---|---|---|
OP_REFHASHVALUESUM_UTXOS |
d5 | refHash | photons | Returns the total sum of photons for inputs that match a 32 byte hash of the sorted set of ref asset ids. |
OP_REFHASHVALUESUM_OUTPUTS |
d7 | refHash | photons | Returns the total sum of photons for outputs that match a 32 byte hash of the sorted set of ref asset ids. |
OP_REFVALUESUM_UTXOS |
db | ref | photons | Returns the total sum of photons for inputs that contain a ref. |
OP_REFVALUESUM_OUTPUTS |
dc | ref | photons | Returns the total sum of photons for outputs that contain a ref. |
OP_REFOUTPUTCOUNT_UTXOS |
dd | ref | count | Returns the count of inputs that contain a ref. |
OP_REFOUTPUTCOUNT_OUTPUTS |
de | ref | count | Returns the count of outputs that contain a ref. |
OP_REFOUTPUTCOUNTZEROVALUED_UTXOS |
df | ref | count | Returns the count of inputs that contain a ref and contain zero photons. |
OP_REFOUTPUTCOUNTZEROVALUED_OUTPUTS |
e0 | ref | count | Returns the count of inputs that contain a ref and contain zero photons. |
OP_CODESCRIPTHASHVALUESUM_UTXOS |
e3 | codeScriptHash | photons | Returns the total sum of photons for inputs that have a
codeScriptHash
|
OP_CODESCRIPTHASHVALUESUM_OUTPUTS |
e4 | codeScriptHash | photons | Returns the total sum of photons for outputs that have a
codeScriptHash
|
OP_CODESCRIPTHASHOUTPUTCOUNT_UTXOS |
e5 | codeScriptHash | count | Returns the count of inputs that have a
codeScriptHash
|
OP_CODESCRIPTHASHOUTPUTCOUNT_OUTPUTS |
e6 | codeScriptHash | count | Returns the count of outputs that have a
codeScriptHash
|
OP_CODESCRIPTHASHZEROVALUEDOUTPUTCOUNT_UTXOS |
e7 | codeScriptHash | count | Returns the count of inputs that have a
codeScriptHash and contain zero photons.
|
OP_CODESCRIPTHASHZEROVALUEDOUTPUTCOUNT_OUTPUTS |
e8 | codeScriptHash | count | Returns the count of outputs that have a
codeScriptHash and contain zero photons.
|
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
.
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 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.
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.
Token-controlled contracts revolutionize contract composition and management on Radiant, facilitating the separation of contracts into multiple UTXOs, each with distinct functionalities. With token ownership housed in its UTXO and additional UTXOs for data storage and specialized functionalities, developers can seamlessly integrate custom functionalities with standard token scripts, extending contract capabilities effortlessly.
OP_REFTYPE_UTXO OP_0 OP_NUMNOTEQUAL
Token Input
A standard singleton + P2PKH token script:
OP_PUSHINPUTREFSINGLETON <tokenRef> OP_DROP <p2pkh>
Token Output
The token output features a state script binding it to the contract input using
OP_REQUIREINPUTREF
, followed by the contract's script signature hash:
OP_REQUIREINPUTREF <contractRef>
<contractScriptSigHash> OP_2DROP // Hash256 of contract's script sig
OP_STATESEPARATOR
OP_PUSHINPUTREFSINGLETON <tokenRef> OP_DROP <p2pkh> // Standard token script
Script Sig
<hashIndex> // Position of ref + hash in token output
<refIndex> // Index of ref in token output data summary
<outputIndex> // Output index of token
Script Pub Key
// Contract ref
OP_PUSHINPUTREFSINGLETON <contractRef> OP_DROP
// Check token ref exists in the token output
OP_DUP OP_ROT OP_REFDATASUMMARY_OUTPUT OP_SWAP 36 OP_MUL OP_SPLIT OP_NIP 32 OP_SPLIT OP_DROP <tokenRef> OP_DUP OP_ROT OP_EQUALVERIFY
// Get ref + hash in token output script
OP_ROT OP_STATESCRIPTBYTECODE_OUTPUT OP_SWAP OP_SPLIT OP_NIP 69 OP_SPLIT OP_DROP
// Compare ref + hash in token output to ref + hash of this script's unlocking code
OP_SWAP 32 OP_INPUTINDEX OP_INPUTBYTECODE OP_HASH256 OP_CAT OP_CAT OP_EQUALVERIFY
// Propagate the contract
OP_INPUTINDEX OP_CODESCRIPTBYTECODE_UTXO OP_HASH256 OP_CODESCRIPTHASHOUTPUTCOUNT_OUTPUTS 1 OP_NUMEQUALVERIFY
//
// Contract code...
//
This script empowers complex contracts composed of multiple UTXOs, each with unique responsibilities. Token scripts maintain standard scripts easily understood by wallets but can be associated with custom contracts. Pay to token contracts can be deployed at any time to expand token functionality.
Token-controlled contracts pave the way for more flexible and manageable blockchain contracts, fostering innovation and scalability in decentralized applications.
The blockchain and cryptocurrency world is always evolving, with new innovations that have the potential to be game-changers. One of the latest and most promising developments is happening with smart contracts on the Radiant blockchain.
If you're not already familiar, smart contracts are essentially computer programs that automatically execute transactions and state changes on the blockchain based on predefined rules and conditions. They allow developers to create decentralized applications (dapps) and automate processes with code instead of requiring intermediaries.
However, despite their promise, existing smart contract platforms like Ethereum have faced major limitations around scalability, costs, and design constraints. Radiant aims to completely revolutionize smart contracts by introducing powerful new ways to construct, manage, and upgrade decentralized programs.
At the core of Radiant's innovation are two major new techniques called "Pay to Token" and "Pay to Ref" enabled by its novel use of crypto induction proofs and referencing schemes. These allow:
This contrasts with current approaches that tend to create monolithic, inflexible smart contract blobs that are hard to manage and extend.
With Pay to Token, developers can have a primary token contract controlling ownership, while custom logic for things like an NFT renderer or staking mechanism exist in separate contracts that are cryptographically bound to the token. This modularity makes the system much more flexible and scalable.
Pay to Ref goes even further, allowing composition of multi-component contracts that securely interact and validate each other's state using induction proofs. This could enable constructing extremely sophisticated blockchain applications from interlocking pieces
What's most exciting for crypto enthusiasts is that Radiant represents a fundamental innovation that could unlock an entirely new design space for decentralized applications and business models. By getting involved early as a user, developer, or investor in the Radiant ecosystem, there could be significant "first mover" benefits:
Of course, the usual risks around new and unproven technologies still apply. But for those willing to take the plunge, getting embedded in Radiant could be akin to being an early Bitcoin or Ethereum adopter before their ultimate breakthroughs.
By overhauling smart contract design from first principles, Radiant has discovered a key to blockchain scalability and programmability.
2nd RXD halving from 25k to 12.5k per block is estimated for early-mid April 2026
Radiant began in 2022 with 50,000 RXD emitted per block, halving every 2 years, with a maximum supply of 21 billion RXD.