ecc.
A planet-scale cosmic-ray sensor network using Error-Correcting-Code (ECC) memory as our detector.
Pre-alpha gathering baseline data on our own nodes before public launch
Open the live globe →Our network right now
Auto-updates every 60 seconds. Heartbeats fire hourly per stick; events post when ce>0 or ue>0.
Humanity's distributed canary in a coal mine
Every server with ECC memory is already an unwitting cosmic-ray detector. Through Hamming's error-correcting codes — invented by Richard Hamming at Bell Labs in 1950 because "two errors a week was just unacceptable" on their relay computer — our memory controllers detect and correct billions of bit-flips per year worldwide. Each one is a high-energy particle striking silicon, recorded by the kernel's Error-Detection-And-Correction (EDAC) subsystem at /sys/devices/system/edac/, then thrown away by every sysadmin who's not us.
We don't throw it away. We collect it, distill it, and share it. Distributed across hundreds of latitudes, altitudes, and continents — the first time humanity has assembled an existing-infrastructure cosmic-ray detector network at this scale. Every ECC Random-Access-Memory (RAM) server on the planet is a potential pixel. There are tens of millions of them.
The particles we measure don't just affect server RAM. They affect aerospace electronics, satellites, hospital equipment, automotive Electronic-Control-Units (ECUs), every embedded chip exposed to sky. ECC is the first wave of silicon with built-in self-monitoring; the rest of our civilization's electronics are downstream. If something is hurting our Dual-In-line-Memory-Modules (DIMMs) at scale, something is starting to hurt everything. Our network is positioned to see it first.
Why ECC RAM is the right sensor
Richard Hamming's 1950 paper introduced single-error-correcting codes — extra parity bits arranged so a single bit-flip can be detected, located, and silently corrected. The extended-Hamming Single-Error-Correcting-Double-Error-Detecting (SECDED) variant is what virtually every modern ECC memory controller implements.
Every server-class machine on Earth ships with this silicon doing Hamming-derived math billions of times per second. The hardware is already detecting bit-flips; the kernel is already counting them. The only missing piece is the network that aggregates the counts and looks for patterns — that's us. Zero new hardware, fits the permacomputer ethos: use what already exists.
Moving servers — cars, robots, drones, satellites
ECC RAM doesn't sit still. Teslas have ECC compute in their Full-Self-Driving (FSD) stacks. High-end drones use NVIDIA Jetson AGX with ECC enabled. Aircraft avionics, hospital infusion pumps, automotive ECUs — anything safety-critical. And the sky: CubeSats and orbital stations have ECC by mandate, because at Low-Earth-Orbit (LEO) altitude one cosmic ray hits with about 300-1000× the flux it has at sea level.
Our pipeline handles intermittent connectivity (queue + retry with 7-day backfill), so a drone offline for a week flushes on landing, a Tesla through dead zones backfills cleanly, a CubeSat queues through Earth-shadow side and flushes over the next ground pass.
One LEO node is worth roughly 100-1000 ground nodes for detecting Solar-Energetic-Particle (SEP) bursts — they're above most of the atmospheric shielding that drowns our signal at the surface. A Starlink-scale orbital mesh, if ever participating, would dwarf every science satellite ever built combined for cosmic-ray purposes.
The micronova question
Mainstream solar physics tracks the cycle, X-class flares, and ground-level enhancements during major SEP events. The Sun's variability is generally well-understood. The contested micronova hypothesis — periodic minor novas tied to galactic current-sheet crossings, possibly approaching — sits outside mainstream consensus. We are not endorsing it.
We are sysadmins, scientists, and curious citizens who'd rather have data than not have data. If the Sun behaves exactly as predicted forever: we have the largest open dataset of cosmic-ray ground flux ever assembled. If it behaves anomalously: we're positioned to be the first to notice. Either outcome justifies the network. Measure first, conclude later.
How to participate
Our agent is in development. When it ships, expect a one-liner along these lines:
# Coming soon — do not run yet
curl -s https://ecc.unturf.com/install.sh | sh
Our agent is a Portable-Operating-System-Interface (POSIX) shell script (single file, ~800 lines, no daemon, no compiled dependencies). It runs on any Linux box with ECC RAM. It tails our EDAC counters, buckets events by minute per stick, always writes a local Tab-Separated-Values (TSV) log (useful even if you never join our network), and optionally posts anonymized aggregates back to us.
Want to follow progress or contribute code? See our source repo and DESIGN.md.
Privacy & anti-extraction
What we always do
- Open-source agent and proxy (auditable)
- Hash every identifier (host, stick) with a salt our agent generates on your box
- Bucket geography wide (continent-scale region, altitude band)
- Rate-limit at our edge only (no auth needed)
- Publish daily anonymized data dumps so anyone can mirror
What we never do
- Store hostnames, Internet-Protocol (IP) addresses, or exact locations
- Require accounts, Application-Programming-Interface (API) keys, or login
- Sell data or use it for advertising
- Lock our software as proprietary
- Refuse a withdrawal request
How much work does the agent do?
Tiny. No background daemon, pure cron-driven. Per-minute tick reads EDAC sysfs files, diffs a state file, posts a per-event Hyper-Text-Transfer-Protocol-Secure (HTTPS) request only if CE or Uncorrectable-Error (UE) counts increased — typically ~20-50 ms wall, zero network when memory is happy. Per-hour heartbeat posts per-stick {minutes, ce, ue} for the previous hour always, even all-zero — ~200-500 ms wall, 16-24 small JavaScript-Object-Notation (JSON) requests.
Daily totals for a typical healthy host: ~45 s Central-Processing-Unit (CPU) time, ~1 KB local log, ~25 KB network, 0 background RAM.
Verdict thresholds
Each stick earns a verdict based on accumulated observation:
| Verdict | Trigger |
|---|---|
unknown | < 2880 minutes observed (~2 days) |
failing | any UE ever, OR CE rate >10× altitude baseline AND accelerating |
watch | CE rate >3× altitude baseline OR above baseline AND accelerating |
healthy | none of the above |
UE events short-circuit straight to failing regardless of observation window.
The science
Government cosmic-ray neutron monitors cover roughly 50 fixed stations worldwide. A distributed citizen-owned network could cover thousands of points across every continent and altitude band, giving finer geographic and temporal resolution than what currently exists publicly.
What we hope to measure:
- Forbush decreases — the dip in Galactic-Cosmic-Ray (GCR) flux at our surface during geomagnetic storms (the Coronal-Mass-Ejection's (CME's) magnetic field deflects incoming GCR)
- SEP events — bursts of high-energy protons from solar flares that can reach our surface and increase soft-error rates
- Per-stick coincidence signatures — when multiple DIMMs in one chassis flip in the same minute, that is almost certainly a single cosmic shower hitting our box
- Long-term DIMM aging — intrinsic error rates by manufacturer, model, batch, deployment altitude (the StickFacts dataset)
How many nodes to actually detect a CME?
Honest math. Real-world ECC fleet studies (Google 2009, Facebook 2015) report ~0.1 CE per terabit per day from cosmic background — so a 384 GB host (~3 Tb) sees about 0.4 CE per day. A major SEP event might double that briefly.
Statistical floor (5σ detection)
| To detect | Cammy-equivalent hosts |
|---|---|
| 10× spike (X-class Ground-Level-Enhancement (GLE)) | ~250 hosts |
| 2× spike (M-class SEP) | ~1,000 hosts |
| 10% Forbush decrease (GCR dip during a CME) | ~100,000 hosts |
Coincidence detection — multiple DIMMs in one chassis hit in the same minute = almost certainly a single cosmic shower. Counting coincidences instead of raw CEs roughly quarters the hosts we need: ~50-100 geographically-distributed hosts could detect an X-class event.
Geographic spread matters more than count. 100 hosts spread across latitudes and altitudes beats 1,000 in one basement. Carrington-class detection at ~100 hosts would be a genuine scientific contribution — we may go years without one, but our network would be ready.
How it fits together
Three repos, one mission:
ecc.unturf.com(this one) — our landing page and client agentproxy.unturf.com/ecc-capacitor— server-side aggregation, mesh-synced across peer proxies (in development)
This mirrors our blobrand.com pattern: client lives in its own repo (deskblob), central aggregation lives in proxy.unturf.com.