X1 is one of the cheapest major networks to validate on, and the reason is a single design decision: validators do not pay for votes. On Solana, vote transactions are the largest recurring cost an operator carries — often around 1 SOL per day whether or not the node ever earns a block reward. On X1 that line item is simply absent. What remains is the server bill.
That changes who can realistically run a node. This guide covers both routes onto X1 mainnet: the official path documented by X1 Labs, which builds the client from source and gives you complete control, and the X1 Console fast track, which automates the same steps behind a menu and is what a large share of the operator community actually runs.
The network as it stands today
Numbers below were read directly from rpc.mainnet.x1.xyz on September 11, 2026, so you can reproduce them yourself:
| Vote accounts | 725 total — 574 voting, 151 delinquent |
| Delinquent stake | 0.96% of total active stake |
| Total active stake | ~1.01 billion XNT |
| Gossip nodes | 532 |
| Current epoch | 373 (216,000 slots per epoch) |
| Typical commission | 10% — 560 of 574 voting validators sit exactly there |
Two things are worth reading out of that table. First, delinquent stake under 1% means the network currently has plenty of consensus headroom — which, as explained below, is the condition X1 Labs asks you to check before restarting for an upgrade. Second, the count of delinquent accounts (151) is high relative to the stake they represent (under 1%), which is the signature of a long tail of small or abandoned nodes rather than a network in trouble.
What you need before you start
X1 Labs publishes these as recommendations rather than enforced minimums, and the docs are explicit that they "can and most likely will change over time." The one item that is not negotiable in practice is the last row.
| CPU | 12 cores / 24 threads or more, 3GHz base clock or faster |
| RAM | 192GB or more |
| Disk | 4TB NVMe |
| OS | Ubuntu 22.04.5 LTS (what X1 Console targets) |
| Hosting | Bare metal dedicated — not a VPS |
| User | A non-root user with sudo privileges |
The RAM figure looks aggressive until you know why it is there. Since Tachyon v3.1 the accounts index is held fully in memory by default and the on-disk index is deprecated. Operators who tried to carry a smaller box through that transition ran into kernel and memory-limit problems before the client would start cleanly. Treat 192GB as the real floor, not a comfortable recommendation.
The bare-metal requirement is equally load-bearing. A validator is a latency-sensitive, IOPS-hungry, bandwidth-hungry workload, and shared virtualised storage is the single most common cause of a node that starts fine and then quietly falls behind. X1 publishes a disk IOPS test and a bandwidth test — run both against a prospective host before you commit to a contract.
What it actually costs
Server pricing moves constantly and varies by region and provider, so price your own box rather than trusting any figure in an article — including this one. As an indicative band, a dedicated machine meeting the spec above typically lands somewhere around $150 to $400 per month at mainstream providers, with refurbished and auction inventory (Hetzner's server auction is the usual example) sitting at the bottom of that range and on-demand bare metal from cloud-adjacent providers at the top.
On top of the server you need XNT for three things: a small amount to fund the identity and fee-payer accounts, rent for the vote account, and whatever you choose to self-stake. The first two are trivial. The third is the real economic decision, and it is covered further down under delegation.
Which path should you take?
| Official / manual | X1 Console | |
| Time to first vote | Hours — the cargo build --release alone is lengthy | Substantially less; the console drives the same build |
| You understand every flag | Yes, by necessity | Not automatically |
| Upgrades | Manual: fetch, checkout, rebuild, restart | Menu-driven, with an auto-updater option |
| Delinquency recovery | You, at 3am | Autopilot checks every 30 minutes and restarts |
| Stake management | Raw solana CLI | Ten sub-options including auto-staker and merge/split |
| Best for | Operators who want full control and no extra moving parts | Operators who want the node running reliably with less hand-holding |
These are not mutually exclusive, and the honest recommendation is to do both in order: read the manual path first so you know what a validator actually is, then decide whether you want the console managing it. An operator who cannot read their own startup script cannot debug it when the console hits something unexpected — and during the v3.1 rollout, some operators had to update the console itself before a branch change would take.
Fast track: X1 Console
X1 Console is an interactive, menu-driven manager for an X1 validator written by BlackBeard — the same developer behind Ripper Pool and RipperSwap. It handles installation, updates, health checks, stake management and monitoring from one place. We have a community review of X1 Console if you want operator opinion before installing it.
Installation is two commands on a clean Ubuntu 22.04.5 box, run as a non-root sudo user:
git clone https://github.com/BlackBeard085/x1console.git && cd x1console
./x1console.shFrom there you work the menu. The options that matter most in the first session:
- Option 10 — Other → Installation. Start here. This performs the dependency install, client build and initial setup that the manual path does by hand.
- Option 1 — Health Check and Start. The daily driver. It reports validator status and will attempt to fix a delinquent node automatically.
- Option 3 — Check Balances. Shows all four wallets at once:
id.json,identity.json,vote.json,stake.json. - Option 5 — Manage Stake. Activate, deactivate, create, merge, split, withdraw, plus epoch info and the auto-staker.
- Option 8 — Set Commission and Option 9 — Publish Validator (name, icon, webpage) — do these once you are voting, not before.
- Option 10 — Other also holds network selection, server security, authority management, the pinger, and Telegram alert setup.
Three automations are the actual reason people run it. Autopilot checks status every 30 minutes and restarts a delinquent validator. The auto-staker sweeps excess funds from the vote account into stake, merging active stakes and activating inactive ones. The auto-updater pulls a new validator release within 48 hours of an X1 Labs bootstrap update.
That last one deserves a caveat, because it is where operators get bitten: the console tracks a specific branch, and the auto-update will not cross a major version boundary on its own. During the v3.1 rollout the tracked branch had to be changed manually (Option 10 → 2 → 3, entering v3.1) before the updater would do anything. Expect the same shape of step for every major release, and confirm the branch before assuming you are current.
The official path, step by step
This is the route documented at docs.x1.xyz. Everything below is for mainnet.
1. Install Rust and build dependencies
curl https://sh.rustup.rs -sSf | sh
source $HOME/.cargo/env
rustup component add rustfmt
sudo apt-get update
sudo apt-get install -y build-essential pkg-config libssl-dev libudev-dev \
zlib1g-dev llvm clang libclang-dev cmake make libprotobuf-dev \
protobuf-compiler git curl2. Build Tachyon, X1's validator client
git clone https://github.com/x1-labs/tachyon.git
cd tachyon
git checkout v4.0
cargo build --release
export PATH=$PATH:$(pwd)/target/release
tachyon-validator --versionThe build takes a while and is memory-hungry; this is not the step to run on a laptop over SSH you might disconnect. Confirm the version string reports 4.0.3 before continuing. Add the export PATH line to your shell profile so it survives a new session.
3. Tune the kernel
Skipping this produces a node that starts and then misbehaves under load, which is a far more annoying failure than one that refuses to boot.
sudo bash -c "cat >/etc/sysctl.d/21-tachyon-validator.conf <<EOF
net.core.rmem_default = 134217728
net.core.rmem_max = 134217728
net.core.wmem_default = 134217728
net.core.wmem_max = 134217728
vm.max_map_count = 1000000
fs.nr_open = 1000000
EOF"
sudo sysctl -p /etc/sysctl.d/21-tachyon-validator.confThen raise the file-descriptor and memlock limits:
echo "LimitNOFILE=1000000
DefaultLimitMEMLOCK=2000000000" | sudo tee -a /etc/systemd/system.conf
sudo systemctl daemon-reload4. Point the CLI at mainnet and generate keypairs
solana config set --url https://rpc.mainnet.x1.xyz
solana-keygen new --no-passphrase -o ~/.config/solana/id.json
solana-keygen new --no-passphrase -o ~/.config/solana/identity.json
solana-keygen new --no-passphrase -o ~/.config/solana/vote.json
solana-keygen new --no-passphrase -o ~/.config/solana/stake.jsonBack these four files up now, off the server, before you fund them. They are plain 64-byte secret keys on disk. Losing identity.json or vote.json means losing the validator; losing stake.json means losing the stake. The docs recommend going further and using a hardware wallet as the withdraw authority on both the vote and stake accounts — the withdraw authority is what can actually move funds out, and there is no good reason for it to live on an internet-facing machine.
The --no-passphrase flag is there because the validator has to be able to start unattended. That is a deliberate trade, and it is exactly why the withdraw authority should be somewhere else.
5. Fund the accounts and create the vote account
Send roughly 1 XNT each to identity.json and id.json to cover fees, then:
solana create-vote-account vote.json identity.json <WITHDRAWER_PUBKEY> --commission 10Replace <WITHDRAWER_PUBKEY> with the withdraw authority — the hardware wallet address, if you took that advice. The commission figure is yours to set, but note from the table above that 560 of 574 voting validators are at exactly 10%; deviating upward is a visible choice delegators will notice.
6. Write the startup script
Create ~/bin/validator.sh:
#!/bin/bash
export RUST_LOG=solana_metrics=warn,info
exec tachyon-validator \
--identity $HOME/.config/solana/identity.json \
--vote-account $HOME/.config/solana/vote.json \
--entrypoint entrypoint0.mainnet.x1.xyz:8001 \
--entrypoint entrypoint1.mainnet.x1.xyz:8001 \
--entrypoint entrypoint2.mainnet.x1.xyz:8001 \
--entrypoint entrypoint3.mainnet.x1.xyz:8001 \
--entrypoint entrypoint4.mainnet.x1.xyz:8001 \
--known-validator 2skZy1HiefFby6a8raendfWGKGRmpcDiwvuPj1v7atch \
--known-validator 9zkHekQ7TS1JddcGMgMsZYDUc3xvGzUnXCAfKERvuwUR \
--known-validator ErccS37ii8NbPjsDdGso93vGj7rkF8WhuCV7GhoWmqsS \
--known-validator 8MUdMKKnod3zD1errE1jjeswLtuZ7jNiTvN2EC5cqbCG \
--known-validator 3ka4FFFTm3YgTJ17598ApHuzxELd7PcHnHQsY8uqbDsu \
--known-validator wwcXJz47MTnZacxJ4WSxbhtKuiZvHVqDrBbNCCpjVp1 \
--only-known-rpc \
--log $HOME/validator.log \
--ledger $HOME/ledger \
--rpc-port 8899 \
--full-rpc-api \
--dynamic-port-range 8000-8030 \
--wal-recovery-mode skip_any_corrupted_record \
--limit-ledger-size 50000000 \
--enable-rpc-transaction-history \
--enable-extended-tx-metadata-storage \
--rpc-pubsub-enable-block-subscriptionThose six known-validator keys are the current entrypoint set, rekeyed by X1 Labs during the v3.1 cycle. If you are working from an older tutorial, check them against the official mainnet page rather than copying blind.
Three flags in that script are worth understanding rather than pasting:
--dynamic-port-range 8000-8030— v4 needs a wider range than v3 did. Your firewall and any cloud security group must actually permit that range. A node that starts but cannot reach its full port range looks healthy and performs badly, which is the worst category of problem.--only-known-rpc— restricts snapshot downloads to the known validators above. Keep it.--limit-ledger-size 50000000— what keeps the 4TB disk from filling. Do not remove it unless you know you want an archival node, in which case 4TB will not be enough anyway.
Then make it executable and start:
chmod +x $HOME/bin/validator.sh
nohup $HOME/bin/validator.sh &Running it under nohup is fine for a first boot, but move it to a systemd unit before you rely on it — otherwise nothing restarts the validator when the box reboots. (If you are coming from testnet, clear the old ledger first with rm -rf ~/ledger, or the node will refuse to start against mainnet genesis.)
7. Create and delegate stake
solana create-stake-account stake.json 10
solana delegate-stake stake.json vote.jsonThere is no protocol-enforced minimum to run an X1 validator — the docs say so explicitly, and a stake account can be opened with as little as 0.1 XNT. But "allowed to vote" and "economically worth running" are different questions, and the answer to the second one is set by the delegation program below.
Stake activates at an epoch boundary, so expect a wait before it counts.
Confirming it actually works
solana catchup --our-localhost # are we caught up to the cluster?
solana validators # are we in the validator set?
solana stake-account stake.json # is the stake active?
tail -f $HOME/validator.log # what is it doing right now
tachyon-validator --ledger ./ledger monitorThe sequence that means success is: the node starts, downloads a snapshot, replays, catchup reports it is caught up, and your vote account appears in solana validators as current rather than delinquent. Do not walk away before you have seen it voting.
Monitoring, once it is running
The community has built better dashboards than the CLI for day-to-day watching. All of these are in our verified links directory:
- X1VAL — uptime and performance monitoring
- X1 Validator HQ — percentile ranking and self-stake status, which is what determines delegation eligibility
- X1 Galaxy — validator explorer
- X1 Watch — network monitoring
- X1 Wiki (Validator) — community-maintained operator documentation
- Official explorer — raw vote account data
X1 Console can also push alerts to Telegram (Option 10 → Telegram setup), which is the single highest-value thing you can configure on day one. A validator that goes delinquent at 3am and stays that way until morning costs you an epoch of rewards and, worse, your delegation standing.
Common failure modes
| Node starts, never catches up | Almost always disk IOPS or bandwidth. Run the IOPS test. This is the classic symptom of a VPS pretending to be bare metal. |
| Node will not start after an upgrade | A removed flag is still in your startup script. See the upgrade section below. |
| Starts, looks healthy, performs badly | Firewall is blocking part of --dynamic-port-range 8000-8030. |
| Out-of-memory during build or run | The in-memory accounts index. Check RAM against the 192GB figure, and raise kernel memory limits as in step 3. |
| Went delinquent and stayed there | Nothing was watching. Set up Telegram alerts and either X1 Console autopilot or your own systemd restart policy. |
| Ledger corruption after an unclean stop | --wal-recovery-mode skip_any_corrupted_record handles most cases; otherwise remove the ledger and resync from a snapshot. |
Getting delegation: the part that decides whether this pays
Running a validator with only your own stake on it earns very little. The X1 Foundation Stake Delegation Program is what turns a node into a business: the Foundation delegates stake to validators that meet its criteria, and that delegated stake is where the meaningful commission income comes from.
The program is competitive and the bar has moved upward over time. As of the Project Capybara upgrade, delegation required a 3,000 XNT minimum self-stake, with the formula rewarding self-stake above the network average and a dynamic filter that sat near 3,977 XNT at the time of writing. Those thresholds change — check the delegation portal and X1 Validator HQ for current figures before budgeting, rather than trusting any published number including this one.
The practical planning implication: your real capital requirement is not the 0.1 XNT the protocol permits or the 10 XNT in the example command. It is whatever self-stake clears the current delegation threshold, plus the server. Budget for that from the start. If you would rather earn yield on XNT without operating anything, staking to an existing validator is the alternative — and it is genuinely the right answer for most holders.
Keeping the node current
Upgrades are not optional. Nodes left on old versions get forked out of the network eventually. The current release is Tachyon v4.0.3, which rebases X1's client onto Agave v4.0.3 — we covered what v4.0.3 changes and what it breaks in detail.
The rollout is genuinely still in progress. Of the 532 gossip nodes visible on September 11, 160 were on 4.0.3 and 364 were still on 3.1.14, with a handful on older builds. If you are setting up now, build v4.0 directly and skip the migration entirely.
The rule that governs when you restart
X1 Labs asks operators to hold their upgrade until network delinquent stake is below 5%. This staggers restarts so the network never loses consensus headroom. Check it before every restart — at the time of writing delinquent stake was 0.96%, comfortably inside the window.
Manual upgrade
cd ~/tachyon
git fetch --all --tags
git checkout v4.0
git pull
cargo build --release
tachyon-validator --version # confirm before restartingThen stop the validator, restart with your script, and confirm with solana catchup --our-localhost that it rejoined.
Upgrade via X1 Console
- Change Branch (Option 10 → 2 → 3), entering the new branch name — this must be done first or the auto-update will not work
- Update X1 Validator (Option 10 → 2 → 1), once delinquent stake is confirmed below 5%
- Update X1 Console (Option 10 → 2 → 2) — do this too; console updates carry things like revised known-validator lists
Read the release notes every time
This is the habit that separates operators who have quiet upgrades from operators who have outages. v4.0.3 removed thirteen deprecated flags, and a node whose startup script still contains any of them will not start. The three that stop a node cold: the UDP transaction flags (--tpu-enable-udp, --tpu-disable-quic, --use-udp, --use-quic) are gone since v4 is QUIC-only; --block-verification-method blockstore-processor is no longer supported; and the port range must be wide enough.
v4.0 also drops fallback reads for several legacy blockstore formats, which creates a genuine one-way door: once a ledger has been written by v4.0 there is no clean downgrade path. Snapshots remain wire-compatible in both directions, so if you want the ability to roll back, take a snapshot before upgrading and be ready to start from it rather than from the existing ledger directory.
Where to get help
X1 validator operations are a community sport, and the channels are genuinely active — most problems in this guide have already been hit by someone else this month.
- X1 Validators Army (Telegram) — the main operator channel. Upgrade coordination, release announcements from X1 Labs, and the fastest place to get a straight answer when your node is misbehaving. Join this before you start, not after something breaks.
- X1 Builders (Telegram) — developer-focused, for tooling and program questions rather than node operations
- Official validator community page
- Tachyon repository — release notes and issues
- X1 Console repository — issues and updates for the console itself
Our full directory of verified X1 links is at x1report.com/official-links, and our ongoing validator coverage tracks releases and delegation changes as they happen.
Bottom line
The technical barrier to validating on X1 is modest — the official path is roughly seven commands plus a startup script, and X1 Console compresses it further. The real barriers are the ones people underestimate: a bare-metal server that genuinely meets spec, enough self-stake to clear the delegation threshold, and the operational discipline to read release notes and watch for delinquency.
Get those three right and X1 is about as cheap a network to validate on as exists, because the cost that dominates everywhere else — paying for your own votes — simply is not charged here.
Thresholds, versions and network figures in this guide were verified on September 11, 2026 and will drift. Always confirm against docs.x1.xyz and the X1 Validators Army channel before acting on any specific number.