1. Freedom of Individual Agency

All individuals have the right to communicate, transact, and interact freely in a decentralized, permissionless manner without interference and censorship from centralized authorities.

2. Self-Custody and Ownership

Every participant retains full control over their digital assets, data, and private information. No entity can seize or alter an individual’s property without their explicit consent.

3. Privacy as a Choice

Participants have the option to protect their personal information, activities, and financial interactions. This is achieved through encryption and other cryptographic methods, allowing individuals to maintain control over how much of their identity is revealed.

4. Transparency and Accountability via Code

X1 advocates for open-source, verifiable smart contracts and cryptographic protocols where trust is embedded in technology rather than fallible human intermediaries.

5. Evolution Through Innovation

X1 is committed to the continuous evolution of cryptographic methods, decentralized technology, and blockchain innovations, adapting to new challenges and fostering a future where freedom, privacy, and decentralization thrive.

X1 blockchain is a high performance, high throughput, monolithic L1 with a mission to provide a decentralised, censorship-resistant multi-purpose infrastructure that empowers the freedom to transact with minimal technical and economic limitations.

X1 exponentially improves the economic model of Solana to scale capacity even further.

On X1, validators are not required to pay for votes. The zero-cost vote mechanism significantly lowers the barriers for new validators to join and participate in the consensus process. Consequently, running a validator becomes significantly more affordable, with costs limited to approximately 5 USD per day.

For just $5 a day, a validator can participate in the chain’s consensus and earn rewards, making X1 the lowest cost validator participation network.

On the other hand, validators have various ways to generate rewards through voting rewards, commissions from delegators, block rewards, and an incentivized bootstrap bonus program. Set up your own validator in just a few minutes.

X1 utilises congestion-reflective dynamic base fees. Base fees are not fixed, but rather calculated based on the reflection of the block space demand in terms of the computational resources the blockchain is currently experiencing. This model, akin to EIP-1559 on Ethereum, prevents the underpricing of transactions and spam, ensuring that transactions are fairly priced.

X1 blockchain is fully compatible with the Solana Virtual Machine (SVM), allowing to seamlessly deploy decentralised applications.

X1 launched mainnet on October 6th, 2025, and already has over 1,000 validators participating. To watch their live performance, visit .

X1 Blockchain will have zero-cost votes and congestion-reflective dynamic base fees implemented from mainnet launch.

Other scaling and performance improvements are listed and described in the technical roadmap and includes:

• SVM capacity scaling

• Homomorphic encryption

• Performance based leader selection

Update Binary (if new version)

cd ~/tachyon
git fetch origin
git checkout dyn_fees_v2.2
git pull
cargo build --release
~/tachyon/target/release/tachyon-validator --version

Wait for Safe Restart Window

tachyon-validator --ledger ~/ledger wait-for-restart-window --min-idle-time 10

Stop

Start

Verify

Keep your node up to date periodically and update packages:

sudo apt update

sudo apt upgrade

Make sure you don't run out of space

See server information, available space.

If low on space take action.

Minimum XNT requirements

There is no strict minimum amount of XNT required to run a validator on X1.

Hardware Recommendations

What is homomorphic encryption?

Homomorphic encryption is a type of encryption that allows computations to be performed on encrypted data without needing to decrypt it first. The result of these computations, when decrypted, matches the outcome of performing the same operations on the original unencrypted data. This property enables processing and analyzing data while preserving its confidentiality.

Homomorphic encryption is important because it allows computations to be performed on encrypted data without needing to decrypt it first. This capability is significant for several reasons:

1. Privacy Preservation: With homomorphic encryption, sensitive data can remain encrypted even while being processed. This is crucial in scenarios like cloud computing, where users might need to outsource computation to a third party but want to ensure that their data remains confidential.

Register validator with name, website and icon

See list of registered validators:

Set to you identity.json keypair:

Publish your validator information:

Note "-k" at the end which points to your identify.json including its path. This links your validator identity to the information you are providing. Your icon needs to be hosted.

Example:

Stake

Transfer XNT to stake account:

Do delegate stake operation:

Check condition of a stake:

Vote costs on Solana present significant challenges to decentralization. At todays price of 250 USD/SOL, validators must pay approximately $8,600/month to participate in consensus, with 94% of this cost coming from voting fees. These fees create a high barrier to entry, discouraging smaller validators while disproportionately benefiting larger ones. Validators bear these costs to support the network, while top leaders profit from vote fees and block rewards, exacerbating centralization.

Arguments for vote fees include covering compute resources (2,100 CUs per vote) and deterring spam. However, these justifications are flawed. Votes are net-positive for the network, enhancing resilience and security. Taxing them discourages participation, ultimately weakening the system. As for spam, weighted votes require stake to count, making spam voting ineffective. Malicious actors could already spam at low cost, and true consensus attacks would still require 33% of the total stake, an unattainable threshold for most.

On the , a substantial cluster of nodes has demonstrated that removing vote costs is not only possible but also beneficial. Without these fees, validator costs drop significantly, enabling higher scalability and profitability. This approach lowers barriers to entry, encouraging more validators to join and strengthening decentralization. Removing vote costs aligns with the principle that anything above zero is a tax on network participants, in this case, validators.

Concerns about full blocks pushing out votes, seen during PoW on Solana, are also addressed. X1 implements congestion-reflective dynamic base fees, ensuring blocks are never full and eliminating the risk of votes being displaced. Even in rare cases where votes are delayed, the network remains secure, with consensus only postponed by one block.

1. Download wallet extension

1. Copy private key

Go to folder in terminal where you have keypair

1. Add new Solana wallet>import private key

2. In wallet change to developer mode and X1 testnet: https://rpc.testnet.x1.xyz

RPC endpoints

X1 testnet

Transaction pricing on the X1 Blockchain includes base fees and priority fees.

Unlike Ethereum's single-thread execution, X1—similar to Solana—leverages the server's expanded capacity through parallelism, allowing transactions to be executed across multiple threads. Priority fees act as a voluntary tip to validators set by users, facilitating prioritization within the local fee market threads.

Solana’s transaction fee model

Solana's transaction fee market is primarily driven by local fee markets that prioritize transactions within individual blocks. The base fee for transaction signatures on Solana is statically set at a fixed rate of 5,000 lamports. This fixed fee structure is inadequate for applying sufficient economic back pressure during periods of high network demand. As a result, the network is more vulnerable to spam transactions, which can reduce overall network efficiency and degrade the quality of service. Solana does not employ a global block Compute Unit (CU) accounting mechanism. Without this, transaction fees do not dynamically adjust based on the overall demand on the network's computational resources. During peak periods, the lack of a global adjustment mechanism can lead to network congestion and performance bottlenecks, as low-priority transactions continue to compete for compute resources without any economic disincentive.

X1 fee model; congestion-reflective dynamic base fees

The X1 Blockchain dynamically adjusts base fees based on global compute-unit (CU) congestion across its threads. The transaction fee structure accounts for the computational resources consumed by transactions, which are constrained by a block size of 48M CU per block. Transactions that require higher CUs incur proportionally higher fees. As thread capacity becomes more utilized and blocks fill up, a multiplier is applied to transaction pricing, making them progressively more expensive.

This dynamic fee scaling mechanism on the X1 Blockchain is designed to create economic back pressure that aligns transaction prioritization with available network capacity. As the network load increases, the corresponding rise in transaction fees discourages non-essential transactions (including bots and spam), reducing the likelihood of network congestion. This strategy optimizes resource allocation and ensures sustained high performance under varying network conditions.

Fee comparisson

Ethereum utilizes a single-threaded execution model with global base fees, which leads to high transaction costs during periods of network congestion.

Solana, on the other hand, features multithreaded execution that supports local fee markets, generally resulting in lower transaction costs. However, its base fee pricing mechanism does not account for a transaction's computational usage, allowing spam transactions to occupy computational resources.

The X1 Blockchain combines the strengths of both systems. It supports parallel execution utilizing multiple threads, which allows for local fee markets similar to Solana. Additionally, X1 adopts a global base fee enforcement strategy with congestion-reflective dynamic base fees. This approach discourages spam by adjusting transaction fees based on the actual computational load they impose on the network, ensuring that transaction pricing is fair and proportionate to resource usage.

Impacts of the X1 Blockchain's pricing model

The implementation of dynamic base fees on the X1 Blockchain offers several beneficial effects:

The dynamic base fee system ensures that the cost of a single transaction remains low and only increases when the usage of the chain rises. Additionally, as the chain experiences more usage, validators earn progressively more, and the chain itself becomes more deflationary due to increased native coin burns.

This deflationary mechanism means that over time, the blockchain becomes more valuable with fewer transactions. Validators benefit from higher earnings without needing a corresponding increase in transaction volume.

By aligning resource allocation with actual demand, the pricing strategy for X1's transaction fees promotes efficient, cost-effective transactions while minimizing spam. This approach ensures that the blockchain maintains high performance and reliability even as it scales.

Technical implementation and detail

Why Use Pinger?

When an RPC receives a transaction message to be included in a block, it must forward the message to the leader. Fast data transmission to the leader is crucial for network efficiency and consensus speed.

Monitoring your validator's ping times ensures it meets leader schedule performance requirements.

Pinger Dashboard

Ping times measure how long it takes for your validator to communicate with the current leader. Since the leader changes every four slots (1.6s), ping time variance (typically 500–3000ms) depends on the distance to the constantly switching leader.

Installation

Configure Keypair

Ensure the keypair has funds, as a transaction is sent with each ping.

Open Firewall Port (If Enabled)

Enable UFW if it is not already enabled:

Allow traffic on port 3334:

Install and Run Pinger

Verify Installation

Check the service status:

View logs to ensure correct operation:

Once running, your validator will continuously measure and share leader ping times.

Managing Pinger

Stop the Pinger

Retrieve Ping Metrics

You can also check your ping times on x1val.online:

• Voting rewards from inflation

• Commission from delegators

• Block rewards from block production

• Bootstrap bonus

Voting rewards from inflation

In the X1 consensus mechanism, validators cast votes on blocks proposed by the leader. Throughout each epoch, validators accumulate credits for their votes, which can be exchanged for a portion of the epoch's inflation rewards. The inflation rewards are allocated based on the number of credits each validator earns during the epoch; a validator's percentage of the total credits determines their share of the inflation rewards. This share is then adjusted according to the validator's stake relative to the total staked amount.

X1 also features a predefined inflation schedule. It begins at 8% and decreases annually by 15%, aiming for a long-term inflation rate of 1.5%.

Commission from delegators

X1 operates on a delegated proof-of-stake (dPoS) blockchain system. Holders of XNT can delegate their coins to a validator, increasing that validator's staking weight. This not only enhances the validator's potential rewards from inflation through increased voting power but also boosts their chances of being selected as the leader to earn block rewards. Validators set their own commission rates, typically around 10%, which they deduct from the inflationary voting rewards; the remaining rewards are distributed to the stakers.

Block rewards from block production

Transaction fees on the network are awarded to the leader who successfully produces a block. High-performing nodes have a greater chance of being selected as the leader. RPC forwards transactions to the leader for execution. If the leader manages to produce a block that is confirmed by over two-thirds (67%) of the validator cluster, weighted by stake and performance(), they receive the block rewards, which consist of the transaction fees paid by the network's users for that block.

Bootstrap bonus

To support the growth of the network's infrastructure, validators receive additional incentives through a bootstrap program. Eligibility for the bootstrap bonus requires meeting specific criteria. The distribution of the for each epoch is determined by a validator's score, which is based on a credit system.

Validator costs

The only direct cost for validators is the hardware expense, which varies depending on the server supplier. To learn more, please read about the for the X1 blockchain.

A major differentiator from Solana is that validators on the X1 Blockchain don't pay for votes. This significantly lowers the barriers to starting and maintaining a validator. Read more about.

Consensus

Once a transaction is executed by the leader, it is immediately recorded to the validator’s copy of the ledger and propagated to the rest of the network. After a block has achieved the necessary votes from consensus, the transaction is considered "confirmed." Finally, a block is considered "finalized" when 31+ confirmed blocks have been built upon it. These stages are returned through the RPC back to the front-end, allowing the user to see the status of their transaction.

Many blockchain networks construct entire blocks before broadcasting them, known as discrete block building. Solana, in contrast, employs continuous block building which involves assembling and streaming blocks dynamically as they are created during an allocated time slot, significantly reducing latency.

For a block to gain acceptance, all transactions within it must be valid and reproducible by other nodes. The leader divides the block into smaller pieces called "shreds." Each shred contains a portion of the block data and is linked to others using cryptographic hashes.

The leader broadcasts the shreds to the validator nodes in the cluster. This is typically done via a gossip protocol to ensure wide and efficient dissemination of data. Validators collect shreds and reconstruct the full block from the received shreds.

Validators verify the integrity and validity of the block by checking the PoH hashes and ensuring the transactions are valid and have not been double-spent.

Once a validator verifies a block, it sends a vote transaction to the rest of the network, indicating that the block is valid. When enough votes are collected, the network reaches consensus, and the block is added to the blockchain.

In the Solana blockchain, for a block to be confirmed, a supermajority of votes from the validators in the cluster is required. Specifically, this supermajority is defined as two-thirds (or 66.6%) of the total voting power in the network.

While the network is small this model works very well but will lead to scaling challenges over time, best addressed by the concept of algorithmic complexity.

Algorithmic complexity

Consensus Scalability Dilemma in Blockchain Technologies

Addressing scalability while maintaining security and decentralization presents a significant hurdle for blockchain technologies. Traditional blockchains, such as Bitcoin and Ethereum, encounter challenges in this area, frequently experiencing bottlenecks with the expansion of network size and activity. These networks utilize a Nakamoto-style consensus mechanism, necessitating that end-users compete through transaction fees for block inclusion.

Due to the static nature of block size and the fixed frequency of block creation, in contrast to the continuously increasing demand for network usage, this mechanism results in heightened transaction fees and prolonged confirmation times during peak demand periods.

Consensus Complexity: A Quadratic Conundrum

Unlike Bitcoin and Ethereum, blockchains like Fantom and Solana adopt an alternative approach by implementing asynchronous block voting mechanisms. This method requires a minimum participation of two-thirds of all network nodes in message exchanges that facilitate voting. The outcome of this process is a consensus complexity that grows quadratically, denoted mathematically as O(n^2). Although this strategy can be highly efficient and swift for the user's transactions, it inherently restricts the network's scalability with increasing node numbers.

Avalanche: Neighborhoods

Avalanche employs a novel strategy to mitigate complexity through the introduction of neighborhoods. By adopting a gossip-like structural mechanism, Avalanche effectively reduces its consensus complexity to a logarithmic scale, or O(log(n)). This advancement marks a significant leap towards enhancing scalability without a proportional increase in consensus complexity, while maintaining fast transaction execution times.

X1 Blockchain: Scaling through Reductionism

The X1 Blockchain improves its consensus algorithm by incorporating subcommittee voting, a concept borrowed from the HotStuff2 consensus model. This enhancement addresses the inefficiencies found in traditional blockchain networks, such as Solana, where the voting process is O(n^2) due to the flat network topology requiring all nodes to participate in voting. This excessive communication creates a bottleneck, slowing down the consensus process.

In contrast, the X1 Blockchain employs a more streamlined approach by selecting a smaller subset of nodes, or subcommittees, to handle voting and validation. This reduces the overall communication overhead and computational load, enabling faster consensus with fewer resources. By supporting an indefinite number of nodes (n) while only requiring a limited group (x) to vote, the X1 Blockchain maintains a constant time complexity, O(1), for consensus operations.

This strategic use of subcommittees enhances the scalability and efficiency of the X1 Blockchain, allowing it to handle larger networks and higher transaction volumes without the drawbacks of traditional consensus methods. The adoption of subcommittee voting ensures that the network remains both scalable and secure, providing a robust foundation for future growth.

Fund identity account

Check balance:

Create vote account

Creates a vote account with vote.json keypair + identity.json as identity + the withdrawer address and commission.

--commission: If you get a delegation then anything they make you get 10%.

Check vote account:

Create and fund stake account

Check stake account:

Stake

Do delegate stake operation:

Check condition of a stake:

Check validator

See validators. Your identity pubkey should show up there:

Monitor ledger, is continuous monitoring:

Block production, see skipped slots:

Check leader schedule:

or:

Check block production:

Check epoch information:

Check CPU and memory:

Type (shift+h). CPU should be lower than 100% with margin.

Check validator process:

Kill validator process:

Validators should see the guide for validator migration instructions.

This guide details the steps taken to migrate the X1 Testnet Chain to v2.0 to document the process for future reference.

Do not preform these steps.

On the bootstrap node, the following steps were taken to migrate the X1 Testnet Chain to v2.0:

1. Install Tachyon v2.0

2. Stop the Validator

Other X1 related community groups:

Quick Overview

During the restart and migration to v2.0, the testnet will undergo a fork. A new snapshot and genesis will be created, and the network will restart using the updated version.

To streamline the process, all stake accounts will be deactivated, requiring stakers to re-delegate their accounts upon rejoining the network. Rest assured, the original stake amounts will be preserved.

Follow the steps below to migrate your validator to v2.0.

Step 1: Install Tachyon v2.0

You will need Tachyon v2.0 to generate the correct snapshot.

1. Clone the Tachyon repository:

2. Build the repository:

3. Update your PATH environment variable:

   Replace /path/to/tachyon with the correct path. Use pwd to get your current directory path.

Step 2: Stop the Solana Validator

If your validator is still running, stop it before proceeding.

Step 3: Backup Your Data and Remove the Old Ledger

1. Backup your keys 🗝️: Save your validator keys in a secure location.

2. Backup or remove your old ledger directory:

   • If you have sufficient disk space, keep the old ledger as a backup.

   • Otherwise, you can delete it to free up space.

Step 4: Update Startup Configuration

1. Update the binary name in your startup script:

   Rename from solana-validator to tachyon-validator

See the example start script .

Step 5: Start your validator

1. Start your validator using the updated configuration.

2. Make sure your validator is in sync with the network:

   You should see the following output:

Step 6: Re-delegate Your Stake

⚠️ Warning: Do not re-delegate your stake accounts until you're fully synced with the network.

After the restart, you will need to re-delegate your stake accounts. Your original stake amounts will be preserved.

Note: Replace paths with the correct paths to your identity, stake, and vote account files.

📌 Tip: Your stake will take a few epochs to activate and gradually grow to its full amount.

Next Steps

• Check the logs to ensure your validator is running correctly.

• Use the solana validators command to verify your validator's status.

• Monitor the network and assist others during the migration process.

Bootstrap Fork Instructions

See the for the exact steps that will be taken to migrate the X1 Testnet Chain to v2.0 on the bootstrap node. These steps will be executed by the X1 team.

Bootstrap Bonus rewards early, performant, and decentralized validators who actively strengthen the X1 network. The purpose of the Bootstrap Bonus is to accelerate the growth of the validator network and enhance decentralization across the consensus layer.

It complements the Incentivized Testnet Rewards and distributes additional rewards based on validator credits and self-stake performance.

This program will remain active until further notice, after which it may evolve into Bootstrap Bonus v2 with updated parameters and incentive structures.

Reward Structure

• Base Reward: Distributed proportionally based on credits earned.

• Performance Bonus: An additional +16 % awarded to validators who meet all Bootstrap Criteria.

Bootstrap Criteria

1. Self-Stake Range

Bootstrap Bonus v1 is based solely on self-stake (delegated stake does not count). To maintain decentralization and fair participation:

• Minimum self-stake: 1 000 XNT

• Maximum rewarded self-stake: 10 000 XNT

• Validators may self-stake more than 10 000 XNT, but only the first 10 000 XNT will be eligible for the +16 % performance bonus.

Example: A validator with 1 000 XNT self-stake qualifies fully. A validator with 12 000 XNT self-stake will receive the bonus only on the first 10 000 XNT, while the remaining 2 000 XNT will not earn additional rewards.

2. Performance Criteria (Operational Standards)

To qualify for the Bootstrap Bonus, validators must maintain the following baseline performance defined in the :

3. Validator Ownership & Conduct

• Each individual or entity may operate a maximum of 10 validators.

• Running more than 10 validators, or attempting to split identity (Sybil) or circumvent this limit, results in disqualification from the program.

• Validators must adhere to the spirit of decentralization and act in good faith. Any manipulation or gaming of the system will lead to immediate removal.

Dynamic Parameters

Bootstrap Bonus v1 is a dynamic system. The X1 Foundation may adjust thresholds, bonus rates, or eligibility parameters at any time to maintain fairness, performance, and decentralization. Future updates will be released as Bootstrap Bonus v2, introducing new metrics and incentive structures as the validator ecosystem matures.

Program Purpose

Bootstrap Bonus v1 is designed to:

• Accelerate the growth of the validator network

• Encourage self-commitment and fair participation

• Enhance decentralization of the consensus layer

• Reward high-performing, independent operators

DeFi Origin of X1

The first DeFi protocol of X1 is not a DEX or a lending market — it is the Bootstrap Bonus. By making validation itself the first yield-bearing activity, X1 aligns incentives directly with the security and decentralization of the chain.

This is what truly sets X1 apart from most other blockchains — the ambition to let everyone participate at the core of the network, not just at the edge. Validators on X1 can participate in consensus with minimal barriers and also participate in block production itself.

In alignment with this vision, X1 introduces the democratization of block production, where randomness and validator performance define eligibility — not stake dominance. Learn more:

In short: Validating becomes the first DeFi of X1.

Activation

The Bootstrap Bonus will initiate after X1 completes its initial launch configuration and key operations.

Once your validator’s withdraw authority has been moved from a local keypair (id.json) to a Ledger hardware wallet, you can securely withdraw accumulated rewards directly from your vote account using your Ledger.

Step 0 — Set Your Variables

You’ll use these across commands:

To get your Ledger’s public key (run on your computer, Solana app open):

Step 1 — Verify the vote account (on the server)

• Confirm the Withdraw Authority matches your Ledger public key.

• Note the Account Balance; keep the account rent-exempt (don’t withdraw to zero).

Step 2 — Connect your Ledger (on your computer)

1. Plug in Ledger, unlock, open Solana app (close Ledger Live).

2. Verify the CLI sees your device:

You should see your Ledger address printed.

Step 3 — Withdraw rewards (on your computer, Ledger signs)

Withdraw a specific amount (example: 5 XNT):

If your local default wallet has no funds for fees, make the Ledger pay the fee too:

Tips

• Keep the vote account rent-exempt by leaving a buffer.

• If you hit “unfunded recipient”, first withdraw to your Ledger address, then transfer elsewhere.

Step 4 — Verify the transfer (server or computer)

Check the vote account:

Check the destination wallet:

Troubleshooting

The Metaplex Protocol is a decentralized protocol for Solana and the SVM ecosystem, designed to facilitate the creation, sale, and management of digital assets.

It is the preferred platform for digital asset creation and management on X1, offering tools and standards for developers, creators and businesses to build decentralized applications.

Known for powering digital assets including NFTs, fungible tokens, RWAs, gaming assets, DePIN assets and more, Metaplex is one of the most widely used blockchain protocols and developer platforms, with over 880M assets minted for a total transaction value of $9.8B (as of April 2025).

Products deployed

This is a Summary of all the products deployed on X1

Products

Metaplex Token Metadata

The Metaplex Token Metadata Program is the de facto standard Fungible Tokens on Solana and across all SVMs offering the widest level of support by SVM dApps and protocols. It is built on the SPL-Token and SPL-Token-2022 token programs.

The Token Metadata program supports a wide array of Token Standards depending on the requirements of the creator.

Fungible Tokens

Metadata can easily be attached to SPL-Tokens using the Token Metadata program to make Fungible or Semi-Fungible tokens. The Token Metadata program attaches a Metadata account to tokens to make them recognized and readable across dApps, protocols and explorers.

Non-Fungible Tokens

Token Metadata offers a basic standard for supporting non-fungible digital assets, allowing users to create onchain art, PFPs, or other singular assets. It supports common functionality such as delegation, sales, owned escrow (e.g. ERC-6551 equivalent) and more.

Programmable Non-Fungible Tokens

All of the same functionality of Non-Fungible Tokens with additional programmability and royalty enforcement. Programmable NFTs support attaching a ruleset to an NFT that can prevent the asset from being sold or delegated to malicious platforms, marketplaces that don’t support royalties, and more.

Editions

Token Metadata also includes the ability to print editions, commonly used for 1/1 or prints of artwork. The protocol utilizes a Master Edition NFT that can have derivative artworks printed off as numbered edition copies.

More information and details on developing with Token Metadata can be found below:

• Documentation:

• Javascript Package:

• Rust Crate:

Metaplex Core

Metaplex Core is the most programmatic standard for NFTs powering the next generation of digital assets on X1. It’s already been adopted by all major dApps and protocols for creating the next wave of NFTs. Metaplex Core offers all of the functionality of the previous Token Metadata standard and more, all while improving efficiency and cost by an order of magnitude.

Core supports the same features as Token Metadata such as Editions and Royalties enforcement, while also enabling new functionality through its novel Plugin system. The Plugin system creates a common interface that allows additional features to be added to an asset dynamically, even going so far as to allow third party integrations installed directly to NFTs. Popular plugins include Royalty, Attributes, Autograph, and more!

The Core protocol utilizes a single account design that allows it to achieve the smallest onchain footprint, reducing the overall rent cost to the smallest possible amount. This compact, single account also allows the protocol to abstract away many of the complexities of SVM by utilizing its advanced Plugin system, allowing users to have all of the flexibility of a custom protocol without having to develop a new program.

More information and details on developing with Token Metadata can be found below:

• Documentation:

• Javascript Package:

• Rust Crate:

Metaplex Candy Machine

The Metaplex Candy Machine protocol is the simplest way to deploy and launch NFT collections on the SVM. It works by deploying a lazy-minting protocol that stores the asset data for an entire collection and allows minters to mint assets from the collection. Candy Machine supports a wide array of “Guards” which offer a range of conditions that must first be met in order to mint an asset from the collection.

Popular Guards include Sol Payment, which represents the sale price; Token Gate, which can be used to gate the collection to an allowlist token mint; Token Payment, which allows payment in a custom token of the creator’s choosing; Start Date, which establishes the start time of the sale. Candy Machine currently supports over 20 guards with more being added regularly!

More information and details on launching with Candy Machine can be found below:

• Candy Machine for Token Metadata: ​​

• Candy Machine for Core:

Scheduling

Initiating the transaction

Once a user signs the transaction in their wallet, the wallet sends the transaction to a X1 RPC server. RPC servers can be run by any validator. Upon receiving the transaction, the RPC server checks the leader schedule (determined once per epoch, about 2 days long) and forwards the transaction to the current leader as well as the next two leaders. The leader is in charge of producing a block for the current slot, and is assigned four consecutive slots. Slots usually last around 400 milliseconds.

Step 1 — Check your current vote account (server)

Leader

Solana stands out because it was designed from the outset to operate without a mempool. Unlike traditional blockchains that use gossip protocols to randomly and broadly propagate transactions across the network, Solana forwards all transactions to a predetermined lead validator, known as the leader, for each slot. Once an RPC receives a transaction message to be included in a block, it must be forwarded to the leader.

Leader selection

A leader schedule is produced before every epoch (approximately every two days). The upcoming epoch is divided into slots, each fixed at 400 milliseconds, and a leader is chosen for each slot. The sequence of leaders is determined ahead of time, and validators know when they will become the leader. This rotation happens very quickly, with leaders changing every few hundred milliseconds.

💡 TL;DR

• Credits → XNT: 50,000 credits = 1 XNT

• Immediate (10%): Claimable at genesis, stake right away

• Vested (90%): Locked for 365 days, proportional unlock based on uptime + performance

• Example: 1B credits = 20,000 XNT → 2,000 claimable + 18,000 vested

• Goal: Fair rewards + immediate decentralization of the consensus layer at mainnet

The X1 incentivized testnet is designed to both reward validators for their participation and bootstrap decentralization at mainnet launch. By running validators, producing blocks, and voting on leader output, participants earn Validator Credits. These credits directly determine each validator’s allocation of XNT once X1 mainnet goes live.

How Validator Credits Work

• Every time a validator votes on a block, they accumulate credits.

• Credits reflect the validator’s uptime, participation, and consistency during the testnet.

• At mainnet launch, credits are converted to XNT according to a fixed conversion ratio:

50,000 Credits = 1 XNT

For monitoring validator performance and accumulated credits, check .

XNT Distribution at Mainnet

Validators’ earned XNT will be distributed in two phases:

1. Immediate Claimable Allocation (10%)

• 10% of earned XNT will be claimable at genesis.

• Validators will be airdropped a small amount of XNT to cover gas for claiming.

• This allocation enables validators to stake into their own node immediately, ensuring that X1 launches with strong decentralization for the consensus layer.

2. Locked & Vested Allocation (90%)

• The remaining 90% of earned XNT will be subject to a 365-day lock with vesting.

• To unlock the full allocation, validators must maintain their validator identity for the entire 1-year period.

• If a validator goes offline earlier, they unlock only a proportional share of the 90%. For example:

Performance will also be factored into vesting eligibility. Validators with poor performance (low uptime, missed votes, or other criteria to be defined) will not receive their full rewards.

A dedicated Vesting Dashboard will allow validators to track their progress and vesting status over time.

Numerical Example

Let’s assume a validator has accumulated 1,000,000,000 (1B) credits during the testnet.

1. Conversion to XNT

   • 1B credits ÷ 50,000 = 20,000 XNT

2. Distribution Breakdown

   • 10% immediately claimable

Reference Table

Why This Matters

This model ensures that:

• Rewards are fairly distributed based on actual testnet participation.

• Validators are incentivized to secure the chain long-term.

• X1 achieves immediate and sustainable decentralization for the consensus layer from day one.

Flow Diagram

Disclaimer

All details outlined above are subject to change. The X1 team may adjust reward mechanics, ratios, performance criteria, or vesting structures prior to mainnet launch.

Tutorial*

*below are additional steps not covered in tutorial

Open a Terminal application

1. Install rust, cargo, rustfmt etc

Install rustc, cargo and rustfmt.

Make sure you are using the latest stable rust version by running:

Also install git, libssl-dev, pkg-config, zlib1g-dev, protobuf etc.

Run the test

Paste this entire block into your terminal:

You can also use .

This section covers the steps to set up your local environment for X1 development.

Quick installation

On Linux, run this single command to install all dependencies.

After installation, you should see output similar to the following:

If the quick installation command above doesn't work, please refer to instructions below to install each dependency individually.

Step 1 — Switch RPC to X1 Mainnet

Set your Solana CLI to use the X1 Mainnet endpoint:

Due to a mainnet reboot and ledger backtrace to epoch 10, all validators need to manually reset and reconnect. Follow this short guide to restore your node and rejoin the X1 network.

✅ Steps to Get Back on X1

Overview

Usage

1. Copy the full script below into a file named x1_health.sh:

2. Make it executable:

3. Run:

Full Script

Example Output

Notes

• Run it as your validator user (not root) for accurate environment checks.

• Requires: bc, sysstat, and solana CLI in $PATH. Install with:

Overview

Requirements

Official X1 Specifications

Real-World X1 Validator Usage

Based on production validators (Nov 2025):

• Average usage: 150-200 Mbps sustained

• Peak usage: 300-700 Mbps during high activity

• Growth rate: Doubling every 1-2 months

• Network trend: Approaching 1 Gbps per validator

Bottom line: 1 Gbps minimum today, plan for 10 Gbps within 6-12 months.

⚠️ CRITICAL: Committed vs Burst Bandwidth

Common ISP Gotcha

Your ISP might advertise "1 Gbps Unmetered" but actually provide:

How to Check

1. Run this bandwidth test — Shows maximum capacity

2. Check your hosting provider's graphs — Shows actual usage vs thresholds

Example: InterServer "1 Gbps Unmetered" was actually 200 Mbps committed with red thresholds at ~180-200 Mbps.

Questions to Ask Your ISP

• "What is my committed information rate (CIR)?"

• "Is this sustained bandwidth or burst?"

• "What happens if my 95th percentile exceeds X Mbps?"

• "Can I sustain 500-1000 Mbps continuously?"

Usage

1. Install dependencies:

2. Copy the full script below into a file named x1_bandwidth.sh:

3. Make it executable:

4. Run:

Full Script

Example Output

Interpreting Results

✅ Good Result

Action: You're good. Monitor trends monthly.

⚠️ Warning Result

Action: Plan upgrade to 1 Gbps committed soon.

❌ Critical Result

Action: Upgrade immediately. Asymmetric connection will cause issues.

Continuous Monitoring

Run Periodically

Add to cron for weekly reports:

Check Provider Graphs

Don't just rely on speedtest — check your hosting provider's actual usage graphs:

1. Look for 95th percentile metrics

2. Check for red warning thresholds

3. Compare current usage vs thresholds

4. Monitor growth trends month-over-month

FAQ

Q: I have "1 Gbps" but speedtest shows 800 Mbps. Why?

A: TCP/IP overhead, network congestion, or provider throttling. Also verify if it's committed vs burst.

Q: My upload is lower than download. Is that OK?

A: No. Validators need symmetric bandwidth. Upgrade to fiber with equal upload/download.

Q: I'm at 60% utilization. Should I upgrade?

A: Yes. X1 network usage is growing. Upgrade before you hit 80-90%.

Q: What's the difference between committed and burst?

A: Committed = sustained 24/7. Burst = temporary spikes allowed. Validators need committed.

Q: Can I run a validator on cable internet?

A: No. Cable is asymmetric (low upload). You need symmetric fiber.

Notes

• Run during normal validator operation to see real-world throughput alongside capacity tests.

• Speedtest results may vary — run multiple times for accurate average.

• For continuous monitoring, consider setting up a cron job to log results.

• Requires: speedtest-cli, bc