XIMTRX / ABOUT

About XIMTRX

XIMTRX is a DevOps / DataOps / SysAdmin team that runs infrastructure for Web3, AI, ZK and DePIN projects. We run our own fleet of 132 nodes as a training ground - we sharpen the discipline on our own infra before we bring it to clients.

> Our approach

Three principles shape how we run infrastructure. They are not slogans: each one shows up directly in how we operate and what we publish.

Transparency

We publish our node inventory. Anyone can see what we operate (country, type, count) without us hiding behind marketing claims.

Geographic redundancy

12 countries across Europe, the Americas, and APAC. No single-region risk, no single-AZ blast radius for client workloads.

Production-grade ops

24/7 monitoring, slashing-aware playbooks, structured incident response. Runbooks for everything. Not "best effort": engineered.

> Where we operate

Our fleet spans 12 countries. The distribution is intentional: regulatory diversity, network-route diversity, and time-zone coverage for follow-the-sun on-call. See full per-country counts on the geo distribution section of the homepage.

🇦🇹 AT 🇦🇺 AU 🇧🇪 BE 🇧🇬 BG 🇧🇷 BR 🇨🇦 CA 🇨🇿 CZ 🇩🇪 DE 🇫🇮 FI 🇷🇺 RU 🇬🇧 UK 🇺🇸 US

> Why we publish our node inventory

Transparency is the differentiator in DePIN. A lot of operators claim uptime and global reach with no way to verify either. We took the opposite stance: a public, regularly-updated spreadsheet showing country, node type, and count for every host we run.

What we do not publish: hostnames, IPs, customer-specific assignments, validator addresses. Operational security still matters, but the shape of the fleet is public. Read the full reasoning in our blog post: Why we publish our node inventory.

> Team

Small distributed team. Each engineer owns one or more ICP. We rotate follow-the-sun, handing off every 8 hours. On every call you talk to an engineer, never to sales. Full roster: /team/.

We don't run sales funnels or account managers. If you reach out about a workload you'll talk to an engineer who can answer questions about slashing protection, k8s rollouts, GPU memory sizing or archive-node storage layout on the first message.