Earlier this year we made a decision that some other operators we know thought was either brave or foolish: we published our full node inventory in a public Google Sheet, with country-level location, hardware class, protocol, role, and 30-day uptime for every node we run. As of writing, that document lists 85 nodes across 11 countries, refreshed every six hours from the same internal source of truth our SRE rotation uses.
This post explains what we publish, what we deliberately do not publish, and why we think the trade-off favors transparency for both us and the people who pay us to run their infrastructure.
The status quo in node operations
If you have ever evaluated a node operator as a protocol or a delegator, you have probably been through the same dance. You ask for hardware specs and get a marketing PDF with phrases like "enterprise-grade infrastructure" and "geographically distributed". You ask for uptime numbers and get a single percentage with no methodology. You ask where the nodes physically live and the conversation either ends or pivots to "we are happy to discuss under NDA".
Some of this opacity is justified, locations of specific machines and their hostnames are legitimately sensitive. But most of it is not. The aggregate footprint of an operator, how many nodes they run, in how many countries, on what general hardware tier, is the kind of information that buyers need to make an informed decision and that operators routinely refuse to share. The result is a market where the loudest marketing wins, and where smaller but better-engineered operators have a structural disadvantage.
We decided early on that we did not want to compete on marketing. We do not have the budget for it, and frankly we do not have the temperament for it. What we have is a fleet that performs well and an internal data model that already tracks every operationally relevant fact about every node we run. So we published it.
What is in the public sheet
The sheet currently has these columns:
- Node ID. Internal identifier. Not a hostname, not an IP. Just an opaque string that lets us reference a specific node in conversations without leaking anything.
- Country. ISO 3166-1 alpha-2 code. Not the city, not the facility, country only.
- Provider class. "Colo-A", "Colo-B", "Bare-metal-A", etc. We use letters to obscure which specific provider runs which node while still letting clients verify that we are not running half our fleet at a single vendor.
- Hardware tier. "Validator-S" (small, low-spec, suitable for L1 validators that do not need high I/O), "Archival-L" (large, NVMe-heavy), "Inference-G1" (single GPU), "Inference-G4" (quad GPU), etc.
- Protocol and role. e.g. "Ethereum / validator", "Filecoin / storage", "Aleo / prover".
- 30-day uptime. Percentage, refreshed every six hours from our internal monitoring.
- Commissioned date. The day the node went into production.
That is enough information for a serious buyer to evaluate us, and almost nothing that would help an attacker. The country gives geographic diversity confidence; the provider class gives single-vendor exposure confidence; the hardware tier gives performance confidence; the uptime gives operational confidence. Nothing in that list points to a specific physical machine.
What we deliberately do not publish
The list of things missing from the sheet is just as deliberate as the list of things on it. We do not publish:
- Hostnames or IP addresses. The single most common reason node operators get attacked is that someone correlated a hostname pattern across a customer's announcements and an operator's marketing pages.
- Specific cities or facilities. Country-level is enough for compliance and diversity claims. Telling you that node X is in Frankfurt rack B12 helps nobody who is not planning to drive there.
- Customer assignments. We never publish which customer runs on which node. Several of our customers are protocols whose delegators do not know who their infrastructure is, that is the customer's call to make, not ours.
- Real-time alerts. The uptime column is a rolling 30-day average, not a live status board. We do not want to make our incident response observable to the public in real time, because that turns every operational hiccup into a reputational event.
- Hardware vendor or specific SKU. "Validator-S" is enough. The exact CPU model and motherboard are not relevant to anyone evaluating us, and they are exactly the information someone would use to plan a supply-chain attack.
The principle is straightforward: publish anything that a sophisticated buyer would reasonably want to know to evaluate us, withhold anything that creates a clear attack surface without a corresponding evaluation benefit.
What changes for clients
The sheet has been public for about four months now. Three patterns have emerged.
Verify-before-talk. Most serious prospects show up in the first call having already looked at the sheet. The conversation starts at "I see you have 14 nodes in Germany across two colo providers, can you walk me through how you manage the per-provider failure domain" instead of "tell me about your infrastructure". That cuts the sales cycle for protocol customers from about six weeks to about two.
Capacity planning. Several of our customers use the sheet to plan their own capacity. If they know we already run inference hardware in Singapore and São Paulo, they do not have to ask us to "expand to LATAM", they can see the footprint and place workloads accordingly. This shifts the procurement conversation from "build me capacity" to "use the capacity you have, here is what I need on top of it".
Honest comparisons. A protocol foundation we work with recently ran a six-operator comparison for a new mainnet launch. Four of the six operators refused to share aggregate fleet data even under NDA. Two, us and one other, provided detailed inventory. The protocol picked the operator with better uptime in the regions they cared about, which happened to be the other one for that specific deployment. We did not win that bid. But we got three follow-up conversations from foundations who watched that process and concluded that transparency was a signal of operational maturity.
The third pattern is the most important one. The case for publishing inventory is not that it will win every bid, sometimes the data will show that someone else is a better fit, and that is fine. The case is that it filters out the buyers who only want to be sold to, leaving the ones who actually want to evaluate the work.
What we would do differently if we started over
Two things.
First, we would have built the sheet from a structured backend earlier. The current pipeline reads from our internal inventory database, applies the redaction rules in a single Python job, and writes to the Google Sheet via API. That is fine, but for the first three months we were maintaining the public sheet by hand, which led to a few embarrassing drift bugs where the public uptime number did not match what our internal dashboards showed. If you do this, automate it from day one.
Second, we would have published an explicit threat model alongside the sheet. We assumed the rationale would be self-evident, and it mostly was, but a couple of conversations with security teams at customers would have been faster if we had a one-pager that explicitly enumerated "we publish X because Y; we redact Z because W". That document exists internally now; we will probably publish it later in 2026.
Should you do this?
If you operate nodes, probably yes, with two caveats.
The first caveat is that you need to actually be confident in your numbers. Publishing uptime data that turns out to be optimistic is much worse than publishing nothing. If your monitoring methodology has caveats, document them on the sheet.
The second caveat is that you need a stable internal inventory model. Publishing a sheet that is updated by hand will eventually drift, and the credibility cost of being caught with stale public data is high. Get the pipeline right before you turn it on.
The sheet is linked from the footer on every page of this site. We update it every six hours, and we are happy to walk through any specific row if you have questions.
The XIMTRX team