This is the first post on the XIMTRX blog, so it's worth being honest about why this site exists, who we are, and what we plan to put here. If you found us through a validator leaderboard, a DePIN protocol announcement, or a referral from another operator, welcome. If you landed here by accident, the short version: we run 85 nodes across 11 countries for DePIN networks, and we publish what we learn operating that fleet.
Where this came from
XIMTRX did not start as a node operations business. It started in 2022 as a side project running two Ethereum validators on a single Hetzner box, mostly to understand what the staking economy actually felt like from the operator side rather than the protocol side. Within six months the project had grown to seventeen nodes across four protocols, and we were spending more time on it than on our day jobs.
The decision to formalize the operation came when a friend running a small testnet asked us to take over their incentivized testnet allocation because their cloud bill was getting out of hand. We migrated their workload from a single us-east-1 region to four colocation racks across Frankfurt, Singapore, São Paulo, and Tallinn over two weeks. Their per-month infrastructure cost dropped by 61 percent, their median p99 attestation latency improved from 1.4s to 380ms, and they stopped getting paged at 3am about availability zone outages. That migration is what convinced us this was a real business.
By the end of 2024 we were operating 48 nodes across nine protocols. Today, in May 2025, we run 85 production nodes across 11 countries with a 30-day rolling uptime of 99.94 percent. We are still a small team: five engineers, no sales department, no marketing budget. The fleet has scaled because the underlying playbook scales.
What we actually do
The DePIN space has a vocabulary problem. "Node operator" can mean anything from someone running a single Solana RPC on Vultr to a venture-backed firm with $50M in TVL custody. To be specific, XIMTRX runs four workload classes:
- Validators. L1 and L2 consensus participants on Ethereum, Solana, Cosmos chains, Avalanche, NEAR, and several smaller networks. We hold no customer keys: operators sign locally, we run the infrastructure.
- Archival and RPC nodes. Full historical state for chains where pruned data is not enough. This is where most of our storage capacity goes: about 240 TB of NVMe and 760 TB of HDD across the fleet at the moment.
- GPU inference nodes. Bare-metal NVIDIA hardware (mostly L40S and A100 80GB) running inference for decentralized AI protocols. Lower volume but the highest revenue per node.
- Testnet operations. Incentivized testnets for protocols preparing for mainnet. This is where the most interesting failure modes live.
We do not own any of the underlying hardware. The fleet is split across eight colocation providers and three bare-metal vendors, chosen for geographic diversity, network peering, and absence of single points of failure. The orchestration layer is ours: Kubernetes for stateless workloads, plain systemd units for validators (because we trust systemd more than we trust ourselves not to misconfigure a pod for a slashing-relevant workload).
Why we are publishing this blog
There are two reasons we put time into this.
The first is selfish: writing things down is the cheapest engineering tool in existence. Every postmortem we publish is one less time we have to re-derive the same lesson when a new engineer joins the rotation. We have an internal runbook that is approaching three thousand pages, and the blog is going to be the public-facing 5 percent of that, the part that does not contain credentials, customer-specific topology, or specific protocol exploit details.
The second is industry-level. The DePIN operator community is small, and it is not well-served by the existing engineering content on the internet. There are excellent resources on Web2 SRE, plenty of marketing material from staking-as-a-service companies, and almost nothing in between. We want to publish the technical-but-honest writing that we wished existed when we started: what hardware actually fails, what slashing incidents we have witnessed, what monitoring queries catch problems before they catch us, what the economics of running a small fleet look like, and where the industry is heading.
What you will find here
A non-exhaustive list of what is in the editorial backlog:
- Node fleet transparency: why we publish our full 85-node inventory publicly (the next post).
- Slashing postmortems, three of them, none of which were our customers, but all of which we analyzed in detail.
- The case against single-validator setups on consumer hardware, even when the protocol says it is fine.
- Storage economics for archival nodes: when NVMe pays for itself and when it does not.
- Migrating from cloud to colo without downtime: a worked example from a Cosmos validator we onboarded earlier this spring.
- GPU inference node operations: power budgets, cooling failures, and the difference between "Linux on a GPU" and "production GPU infrastructure".
Posts will go out roughly weekly. There is no newsletter signup because we do not run trackers and we do not want to be in the email business. Either bookmark the page, subscribe via RSS once we ship it, or follow us on the channels listed in the footer.
A note on tone
We are not going to be diplomatic about bad operators, bad protocols, or bad practices. The DePIN space is small enough that everyone knows everyone, and we generally do not name names in public, but we will be specific about technical decisions we disagree with, even when those decisions are made by protocols we run nodes for. If that bothers you, this is probably not the blog for you.
If you operate nodes yourself and disagree with something we publish, we would rather hear about it. The contact details are in the footer.
Welcome again. The next post explains why our full node inventory is published in a public Google Sheet, and what it changes about how clients evaluate us.
The XIMTRX team