Updated September 2026. The Triforce Dashboard beta is live. The provider grid on this page has changed since it first went up. Hetzner doesn’t support web3 deployments of any kind, so the cluster now runs on OVH, Cherry Servers, and Latitude.sh.
Project Triforce is a multi-client, eclipse-resistant node deployment for EVM-compatible blockchains. The full stack ships as open-source NixOS and Clan configuration any operator can clone. This will be its first production reference on a live proof-of-work EVM chain, and what we learn running it goes upstream as public goods.
This page is the public overview of Project Triforce: what it is, why we are building it, and how the deployment is shaped.
Why We Are Building It
The Ethereum Classic Cooperative, ETC’s institutional sponsor since 2017, is winding up, and the public RPC that it currently supports is likely to go dark with it. Classix incorporated in 2026 as the Cooperative’s operational successor, and Project Triforce is the flagship piece of public infrastructure under that mission.
A deployment of this size is a visible piece of work that strengthens ETC and signals that Classix is doing the unglamorous infrastructure work. The configs are open-source, so anyone who wants the same setup can clone them and stand up their own cluster. The public stack survives if any single operator drops out.
The whole deployment runs on NixOS and Clan, a combination that has not yet had a production reference at this scale on an actively-mined proof-of-work EVM chain. Operational learnings flow back upstream to the Clan maintainers as patches, issues, and reference configs.
What is Project Triforce?
Three regional triangles, three nodes each. Every triangle covers one region and pins all three clients across three distinct providers and three sync modes.
Running getc, Nethermind, and Besu side by side under real RPC load surfaces bugs that a homogeneous setup hides. Their language runtimes and memory behaviours diverge enough that pathologies hiding in one client appear in another’s traffic. Client diversity also strengthens the network itself, since a critical bug in one cannot take ETC down if the other two keep relaying.
The three clients are:
- getc - ETC’s modernized Go client, Geth Classic. The deployment uses getc in place of Core-Geth as part of an active modernization effort.
- Nethermind - a C# client maintained for ETC via a plugin that tracks Nethermind’s mainnet releases.
- Besu - a Java client with ETC support contributed upstream.
Each provider hosts one archive, one full, and one snap node. Clients run in all three sync modes across all three providers (OVH, Cherry Servers, and Latitude.sh), and within a region the three nodes sit in three different countries. No two Project Triforce nodes share a physical facility.
Archive, full, and snap nodes should agree on canonical state, and the dashboard surfaces disagreement the moment it appears. Nine geographically and administratively independent endpoints behind the public RPC mean no single provider outage or regional disruption takes the service down. Three nodes can drop and the other six still serve. A private WireGuard mesh between the nine pins eight authenticated peers per node that no attacker can displace, and keeps partitioned regions on the chain when the public p2p layer goes hostile. The Mesh Network section below covers the mechanism.
The grid is a starting point. Adding nodes, regions, sync modes, or a fourth client is a config change.
Public Endpoint
A single public RPC endpoint at rpc.classix.dev routes each caller to a node in the nearest region, and within a region routes by request type across full and snap nodes. Visiting in a browser redirects to the cluster dashboard.
The free public endpoint serves ETC dapp developers and ecosystem participants who rely on RPC access that is not gated behind authentication or commercial pricing. Every method is available unauthenticated at launch, including archive queries: full historical state, wide-range log queries, trace methods. Rate limits sit tighter on the expensive archive methods to keep the cluster healthy under shared load.
Dashboard
The dashboard at triforce.classix.dev shows live status, sync height,
peer count, version, and resource usage for all nine nodes on a single
world map. Cross-client and cross-sync disagreement is surfaced
front-and-centre, since that is the signal the deployment exists to
produce. The dashboard ships under MIT and reads from a shared
time-series store that also backs the on-call alerts, so anything that
fires a page also shows up visually, and vice versa.
Architecture
The deployment splits into three regional cells, fronted by a geo-aware DNS authority and tied together by a private WireGuard mesh.
Inside each cell, the regional edge node terminates TLS and routes each JSON-RPC method to the right backend over the mesh.
Each EVM node ships metrics and logs back to the Observation Server over the mesh through Clan’s experimental monitoring module. We will land upstream fixes and help develop the module as we run it in production.
Why Clan?
Clan is a NixOS-native deployment framework funded in part by the Golem Foundation. It sits inside the crypto-friendly end of the NixOS ecosystem: reproducible infrastructure, sovereign deployment, p2p networking. The whole nine-node cluster runs on it, and Project Triforce would be the first production reference on an actively-mined proof-of-work EVM chain using it.
The stack splits into two open-source layers. A generic layer of reusable NixOS code, one flake per execution client (getc, Nethermind, Besu) plus shared modules for monitoring and the API gateway, that any operator running an ETC node can consume directly. A deployment layer on top, the Clan configuration for Project Triforce specifically, imports those flakes and pins them to each machine with per-machine settings (region, role, sync mode, secrets). Deployments and updates run through one command, the whole thing reproducible from a clean checkout.
# Illustrative example.
{
meta.name = "classix-triforce";
meta.domain = "classix.dev";
inventory.machines = {
# DNS authoritative
dns-1 = { tags = [ "infra" ]; };
# 3 regional edges (Caddy + proxyd)
edge-amer = { tags = [ "edge" ]; };
edge-emea = { tags = [ "edge" ]; };
edge-apac = { tags = [ "edge" ]; };
# 9 EVM nodes (3 regions × 3 clients × 3 sync modes)
getc-amer = { tags = [ "evm" "amer" "getc" "archive" ]; };
neth-amer = { tags = [ "evm" "amer" "nethermind" "full" ]; };
besu-amer = { tags = [ "evm" "amer" "besu" "snap" ]; };
getc-emea = { tags = [ "evm" "emea" "getc" "full" ]; };
neth-emea = { tags = [ "evm" "emea" "nethermind" "snap" ]; };
besu-emea = { tags = [ "evm" "emea" "besu" "archive" ]; };
getc-apac = { tags = [ "evm" "apac" "getc" "snap" ]; };
neth-apac = { tags = [ "evm" "apac" "nethermind" "archive" ]; };
besu-apac = { tags = [ "evm" "apac" "besu" "full" ]; };
# Central monitoring server
obs-1 = { tags = [ "monitoring-server" ]; };
};
inventory.instances = {
sshd.roles.server.tags.all = { };
# Private WireGuard mesh between all nodes.
mesh = {
module.name = "mesh";
roles.peer.tags.all = { };
};
# Devp2p keys generated per machine, every other node pinned as a static peer.
etc-p2p-peers = {
module.name = "etc-p2p-peers";
roles.peer.tags.all = { };
};
# One client module per language, applied by tag.
getc-node.roles.node.tags = [ "getc" ];
nethermind-node.roles.node.tags = [ "nethermind" ];
besu-node.roles.node.tags = [ "besu" ];
# Observability.
monitoring = {
module.name = "monitoring";
roles.client.tags = [ "all" ];
roles.client.settings.useSSL = true;
roles.server.machines.obs-1.settings.grafana.enable = true;
};
# Backups for monitoring data.
borgbackup = {
module.name = "borgbackup";
roles.client.machines.obs-1.settings = {
destinations.hetzner = {
repo = "[email protected]:./triforce-obs";
rsh = "ssh -p 23 -i /run/secrets/vars/borgbackup/key";
};
};
};
# Fleet hygiene.
admin = {
module.name = "admin";
roles.default.tags = [ "all" ];
roles.default.settings.allowedKeys = {
operator = "ssh-ed25519 AAAA... operator@classix";
};
};
emergency-access.module.name = "emergency-access";
emergency-access.roles.default.tags = [ "all" ];
users-operator = {
module.name = "users";
roles.default.tags = [ "all" ];
roles.default.settings = { user = "operator"; share = true; };
};
# Nix binary cache proxy.
ncps = {
module.name = "ncps";
roles.server.machines.obs-1.settings.cache.dataPath = "/var/lib/ncps";
roles.client.tags = [ "all" ];
};
};
}Two properties of the Clan model compound here: the Mesh Network, a private peer mesh that holds the cluster together against hostile public networks, and the Extropy Harvest, our process for converting operational learnings into upstream contributions.
Mesh Network
A private WireGuard mesh runs between all nine nodes, alongside the public p2p network they all join. Each node holds eight authenticated peers (the other eight Project Triforce nodes), pinned into the configuration and unevictable. The mesh sits on its own IPs and ports, separate from the public listener.
Peer pinning runs off the Clan inventory. Each Triforce node needs to
know every other node’s enode URI so the ETC clients keep static,
authenticated connections regardless of what happens on the public
p2p layer. The etc-p2p-peers module generates a devp2p key per
machine, stores the private halves in sops-nix, and exposes the public
node IDs as inventory facts. At config-eval time, NixOS walks the
inventory, builds the nine enode URIs from each peer’s mesh IP and
node ID, and writes the list into every client’s static-peers config.
Blocks, transactions, and peer signals flow over the mesh the same way they flow over the public layer. The difference is who else is on the wire. On the public p2p network anyone can connect. On the mesh, only the eight signed peers, so it acts as a clean carrier for block propagation between regions whatever the state of the public layer.
The private mesh closes off three concrete threats:
- Peer-table flooding, the textbook eclipse attack, cannot evict pinned peers. Even if every public slot is hostile, a node still has eight honest views of the chain.
- Public p2p denial of service does not reach the cluster. The mesh runs on different IPs and ports and stays up when the public listener is saturated.
- Regional censorship leaves the mesh intact. The Triforce node receives blocks through the mesh and propagates them to other public nodes in the silo over local p2p, acting as a gateway between the isolated region and the rest of the network, which strengthens the network as a whole.
Extropy Harvesting
Running a production cluster at this scale on NixOS and Clan generates a constant stream of operational learnings. Provider quirks, workarounds discovered the hard way, mesh templates refined under real load, dashboard wiring patterns proven against the cluster they describe. Extropy harvesting is the deliberate process of crystallising that experience into reproducible configs anyone can run.
The primary output is the configs themselves. The same flakes and Clan modules that run the production cluster ship as public artifacts, with provider-specific derivations attached so other operators do not have to rediscover the same edges. Patches and issues against Clan upstream fall out of the same process whenever a learning belongs in the framework rather than the deployment.
The three-provider deployment is where a large share of the harvest comes from. OVH, Cherry Servers, and Latitude.sh each get pushed under the same production workload, which surfaces gaps between each provider and the NixOS/Clan stack that a single-provider cluster would never see.
Entropy is what running infrastructure feels like day to day. Extropy harvesting is what we send back to the commons.
Chain Agnosticism
Nothing about Triforce is blockchain-specific, and using Nix means the mesh, multi-provider, multi-region setup composes with whatever client modules sit on top. Swap the ETC clients out, the rest of the stack carries over.
The stack is layered by design. The geo-routing module, the observability stack, and the mesh configuration each address a distinct concern and carry no hard dependencies on each other. Project Triforce runs all three composed together, but an operator who wants geo-routing without the mesh, or observability without either, can take just that piece.
Next Steps
Work on Project Triforce starts soon. We will be posting updates, configs, and operational notes at classix.dev as the deployment comes online.
Funding
Project Triforce is a public good that needs funding to exist. The configs ship free and the public RPC carries no commercial gate, but nine nodes across three providers do not run themselves, and the engineering and operator time to bring them online and keep them healthy costs real money. We are seeking backers who want to keep ETC’s public infrastructure alive and are willing to fund the unglamorous work directly.