Proof-of-Useful-Verification: turning real radio astronomy data triage into blockchain consensus

1 Abstract

Galaxy SIGNAL is a blockchain in which mining a block requires doing real, verifiable radio-astronomy data triage — not solving an arbitrary cryptographic puzzle. We call this consensus mechanism Proof-of-Useful-Verification (PoUV).

Every block on the network starts from a real detection ("hit") published by Breakthrough Listen, the largest funded SETI (Search for Extraterrestrial Intelligence) survey. A block can only be closed once that hit clears four deterministic rejection rules — real reference-position filtering, drift, and two coincidence checks against the rest of the dataset (section 4.3) — independently re-derived by every node from the same public data, the same class of decision a real radio-SETI pipeline has to make to separate a genuine candidate signal from terrestrial radio interference (RFI). A classifier score is also attached to each block, but it's declared by the miner and never independently verified (section 4.4) — it is metadata, not part of the gate. Only after the four rules are satisfied does a GPU-resistant proof-of-work hashing layer, SignalX, finish the block.

The result is a network where the electricity spent on consensus is spent doing something that has value independent of the blockchain itself: real triage of public scientific data, at a continuous, incentivized, auditable pace. This document lays out the mechanism, the protocol, the security model, and — deliberately — what it does not claim.

2 The problem this solves

Bitcoin's proof-of-work spends enormous amounts of electricity solving puzzles whose only purpose is securing the network itself — the computation has no value outside of Bitcoin. Distributed-computing citizen-science projects like SETI@home showed, over two decades, that millions of people are willing to donate real processing power to sift through actual telescope data — but with no reward beyond curiosity, which is not a sustainable long-term incentive on its own. SETI@home itself shut down in 2020, largely for that reason.

Galaxy SIGNAL asks a simple question: what if a blockchain's proof-of-work were real scientific work, and whoever did it were actually paid for it? PoUV is the answer — not a discovery claim, but a systems answer: a way to make continuous, incentivized, independently-auditable data triage the actual consensus mechanism of a running network, instead of throwing the electricity away on numbers with no meaning outside the chain.

3 Proof-of-Useful-Verification

PoUV replaces a single-step "guess a nonce" puzzle with a three-part gate:

1. Deterministic rejection. The hit must pass four hard-rejection rules — real reference-position filtering, drift, and two coincidence checks against the rest of the dataset (section 4.3) — before anything else happens. These are the actual triage; every node recomputes them from the same public data and always reaches the same answer. This is binary, not graded: a hit clears the gate or it doesn't.
2. Declared verification score. The miner also attaches a classifier score, required to clear a fixed threshold (section 4.4) — but, unlike step 1, this number is declared by the miner and not independently recomputed or verified by other nodes. It carries no further weight: every block that reaches this point pays the same fixed reward (section 9.1), regardless of the exact score attached to it. It's published on the block as informational metadata, nothing more.
3. Hashing. Once both gates are satisfied, the miner still has to find a nonce whose hash beats the network's real difficulty target — SignalX (section 5), the layer that makes the block's cost and timing genuinely tunable and hard to shortcut.

Every node independently re-derives what actually gates consensus when it receives a new block: it re-checks the hit's authenticity against its own local copy of the canonical dataset, re-derives whether the hit falls inside the unpredictable candidate window, and re-applies the four deterministic rejection rules — all from the same raw data, with no step taken on trust. The verification score is different: it's a number the miner declares, required to clear a fixed threshold, but never independently recomputed or verified by other nodes (section 4.4 explains why).

4 How a hit becomes a block

4.1 The source data

Every hit on the network comes from a real, publicly published Breakthrough Listen L-band survey — tens of millions of individual radio detections across hundreds of real observed stars, in the standard turboSETI format the project's own pipeline produces. Nothing in the dataset is synthetic or simulated.

4.2 Labeling methodology (RFI vs. genuine candidate)

The classifier isn't trained on synthetic labels. It's trained the same way the source survey itself separates signal from noise: each observing campaign alternates pointing the telescope ON the target star and OFF it, several times in sequence. A signal seen in an ON scan is labeled interference if the same frequency (within the drift tolerance between scans) also shows up in an OFF scan — proof the source isn't following the telescope, so it can't be coming from the star. If it only appears while pointed ON, it's labeled a genuine candidate. This is exactly the logic real radio-SETI pipelines use before ever reporting something as worth a human's attention.

4.3 Deterministic rejection

Before a hit is even scored, it has to survive four deterministic checks — the actual triage the network performs, recomputed identically by every node from the same public dataset, with no step taken on trust:

1. No-drift exclusion. A hit with zero measured Doppler drift is rejected. This isn't a claim about interference in general — it targets a specific population found in this corpus, at least partly an instrument-processing artifact (confirmed for ≥15.8% of it; the rest open across three named hypotheses, see /audit §6), that a modern turboSETI run in default configuration no longer produces. Kept as a permanent, near-zero-cost rule rather than removed, in case a future dataset reproduces the same artifact.
2. Reference-position exclusion. Every cadence alternates observing the target star ("A" scans) with a reference pointing ("B" scans). A hit has to come from an actual "A" scan position — not merely from a file whose name happens to suggest that.
3. Cadence coincidence. A hit is rejected if any detection from the same cadence's reference ("B") positions falls within a tolerance derived from the pair's own drift rate and the real time elapsed between them — the same logic real ON/OFF cross-checking uses, applied deterministically.
4. Cross-target coincidence. A hit is rejected if a detection from a different target star sits within 50Hz of it anywhere in the dataset — a threshold anchored to the measured frequency spread of a real, known terrestrial emitter, not a chosen constant.

These four rules were retroactively applied to this network's own early mined history and found a real error in how the second rule had been implemented — see /audit for the full, permanent record of that correction, including what changed and why.

4.4 The declared verification score

Each hit also gets a score from a Random Forest classifier — four features (frequency, drift rate, SNR, and whether the frequency falls in a band already known to be crowded with terrestrial transmitters) mapped to a single confidence number. A block's score has to clear a fixed threshold to be valid at all.

This score is declared by whoever mines the block. No node — not the one validating a received block, not any other node on the network — ever independently recomputes it. The only thing checked is that the declared number falls inside a fixed valid range; the value itself is taken as given, the same way classifier_version (section 4.5) is required to be present but not checked against a specific canonical model. It carries no further consequence: every valid block pays the same fixed reward (section 9.1) regardless of the exact score attached to it. Anyone can independently recompute it against the published model file (see /dataset) — the chain itself just doesn't, as a matter of consensus.

This is a deliberate scope boundary, not an oversight, and not a gap waiting to be closed: the four hard-rejection rules (section 4.3) are what does the network's real, deterministic triage work, and they don't need a score to do it. The classifier's features are weak signals by design (the crowded-band feature alone carries importance 0.0045 in the current model, because roughly 99% of the corpus falls inside some known band). The score is published as informational metadata on every block — nothing more, and this document does not suggest otherwise anywhere else in it.

4.5 Candidate selection and provenance

Which hits are even eligible to be tried for the next block is itself part of the protocol, not left to whatever order a miner happens to read the dataset in.

1. Unpredictable candidate window. Eligible candidates for the next block come from a window into the dataset whose position is derived from the previous block's own hash — nobody, including the miner who ends up using it, can know in advance what that window will contain, because it doesn't exist until the block that seeds it does. This closes a real gap a naive fixed reading order would leave open: with a public dataset and a fixed order, anyone could pre-score candidates for several blocks ahead of time, off-network, and simply wait for their turn. Independently re-derived by every node.
2. Hit authenticity. Every node holds its own local copy of the canonical dataset and, for every hit a block claims, looks it up by its position in that dataset and requires every field to match exactly — closing the gap where a hand-crafted set of numbers, engineered to clear the classifier but never actually observed by any telescope, could otherwise be accepted as if it were a genuine detection. Independently re-derived by every node.
3. Classifier version. Every block records a classifier_version field. This is declared metadata, not a verified guarantee: the field only has to be present, never checked against the model that actually produced the score. Same status as the score itself (section 4.4) — published, not verified.

5 SignalX: the hashing layer

Verification alone doesn't fix a block's timing or cost — that's still the job of proof-of-work hashing. SignalX is Galaxy SIGNAL's own memory-hard hashing VM, designed specifically to keep GPUs from getting an outsized advantage over ordinary CPU hardware, and internally red-teamed against real GPU implementations during development rather than assumed to be GPU-resistant on paper.

Two qualifiers to the design intent above, registered here rather than left implicit: 32 × 64-bit registers is 256 bytes of state per thread — against a modern GPU streaming multiprocessor's register file (commonly 256 KiB), that budgets roughly a thousand concurrent threads on register pressure alone, well short of being a binding occupancy limit by itself. And because the working-memory table is read-only and rebuilt from public, predictable inputs (the previous block hash), a sufficiently large GPU's L2 cache (tens of MiB on current high-end parts) can hold the whole table resident, which cuts against the bandwidth-pressure argument the design otherwise relies on. Neither has been re-measured against current-generation GPU hardware since being identified; both are open items, not resolved ones. Consistent with the honesty standard set out in section 12, this document does not cite exact GPU-vs-CPU benchmark numbers here: those figures need a fresh, reproducible run before they're fit to publish, and stale numbers are worse than none.

6 Protocol and block structure

Each block carries: its index, timestamp, the full hit that produced it, the previous block's hash, the verification score, the nonce and resulting hash, the miner's address and signature, the difficulty it was mined at, the fingerprint of the classifier model that scored the hit (section 4.5), and optionally a single transfer.

6.1 Addresses and signatures

Every address is derived from an Ed25519 keypair generated locally on the client — the private key never touches the server. An address is SIG followed by a hash of the public key, a one-way derivation: the public key can't be recovered from the address alone. Whenever a block claims a reward, its miner's address is part of what gets hashed, and the signature over that hash is verified before the claim is honored — a mined block's reward can never be silently reassigned afterward. A block mined with no wallet attached (no reward claimed) carries no such guarantee over its own signature field, which is neither part of the hash nor checked in that case — an intentional allowance for walletless mining, not a gap in the reward-claim check itself.

6.2 Transfers

A block may carry at most one transfer, which can pay multiple recipients in a single signed transaction. Sequential per-sender nonces prevent replay; a small fixed minimum fee (paid to whoever mines the block the transfer lands in, not to the recipient) discourages spamming the pending-transaction pool.

7 Difficulty adjustment

Every node recomputes difficulty independently from the chain's own history — a block's claimed difficulty is never trusted at face value, which would let a node simply declare an easy difficulty for itself. Galaxy SIGNAL uses ASERT (an absolutely scheduled exponentially rising/falling target, the same family of algorithm Bitcoin Cash adopted in 2020): a smooth exponential function of how far the chain has drifted — in real elapsed time — from a fixed anchor block, recomputed fresh at every single block rather than averaged over a trailing window. That removes the "cliff-edge" behavior a windowed average is prone to (a sudden jump the moment an old, unrepresentative block ages out of the window) and lets the network start correcting toward a genuine, sustained hashrate change immediately, without first needing enough new blocks to fill a window. A single tunable constant, the half-life, sets how long a sustained deviation from the target pace takes to double or halve the difficulty. Its current value was set from a real Monte Carlo measurement of the trade-off it controls (noise sensitivity to a single slow or fast block versus how quickly the network re-converges after a genuine hashrate change), not guessed — but "measured trade-off" is not the same claim as "calibrated against measured hashrate," and this document doesn't make the stronger one: live monitoring on this network's own real, low-participant hashrate has shown the current half-life reacting visibly to ordinary Poisson noise (a single block's own random timing), not only to genuine hashrate shifts, and stays an open tuning question rather than a settled one.

8 Security model

8.1 What's independently re-derived, and what isn't

Three mechanisms exist specifically to close real consensus-level gaps, not just to describe how the network works, and are re-derived and re-checked by every node independently: the four deterministic rejection rules (section 4.3); the unpredictable candidate window (section 4.5) — without it, a public dataset and a fixed reading order would let anyone pre-score candidates for future blocks off-network, ahead of time; and hit authenticity (section 4.5) — without it, nothing would stop a hand-crafted set of numbers, engineered to clear the classifier but never actually observed, from being accepted as a genuine detection.

The declared verification score and classifier_version (sections 4.4 and 4.5) are not in that list, and this is stated here plainly rather than left to be inferred. Neither is independently recomputed or checked against a canonical value by any node — both are trusted as declared. This used to be a real incentive problem: a self-declared score directly scaled a block's reward, so a miner always benefited from declaring the maximum. As of the 2026-08-26 correction (section 9.1), reward no longer depends on the declared score at all, which removes the incentive rather than merely bounding it. What remains is a scope boundary, not a live gap: the score and classifier_version are metadata, not security-relevant claims.

8.2 Reorganization checkpointing

Nodes refuse to accept a chain reorganization deeper than a fixed checkpoint depth, even if the competing chain is longer and otherwise cryptographically valid. This directly mirrors how established proof-of-work networks have responded to real 51%-style attacks in the wild: limiting how much damage a deep reorg can do, even though it cannot by itself prevent one. Real decentralization — not this mechanism alone — is what actually prevents an attack from becoming possible in the first place (see section 12).

8.3 Reward maturity

Newly mined block rewards only become spendable after the same checkpoint depth's worth of confirmations — the same maturity model conventional proof-of-work chains use for coinbase rewards. Received transfers, by contrast, are spendable immediately; only freshly minted supply has to mature.

8.4 Wallet custody

Private keys never leave the client as raw bytes. Native tools encrypt keys locally before storing them; the browser-based webminer generates and holds its key entirely client-side as well, so mining requires no account and no custodial trust in the network operator.

Creating an optional account (for backing up or moving a wallet across devices) changes that trade-off, and it's worth being precise about how: logging in sends the account password to the server, over TLS, to check it against a stored hash -- and the server also stores the wallet's encrypted blob. The raw private key itself is still never transmitted, and nothing on the server decrypts or persists a decrypted copy of it. But the server does receive everything needed to decrypt a wallet at the moment of every login (the password, in the clear, and the ciphertext, already stored) -- that it doesn't is a matter of what the code does, not a structural guarantee the way client-side-only key generation is. Mining or holding a wallet without ever creating an account keeps the stronger guarantee described above; creating one trades some of it for password-based recovery.

9 Token economics (SGNL)

The round 21M cap is a deliberate nod to Bitcoin's own, but the corpus this network currently mines against comes nowhere close to it on its own: 113,468 hits clear the four deterministic rejection rules used to select candidates (drift, cadence position, and two coincidence checks against the rest of the dataset) out of 28,858,709 in the dataset (0.3932%, measured directly, not estimated) — the network's ENTIRE first pass over the corpus mints 1,134,680 SGNL, and because the reward halves every subsequent pass (9.3), every pass after that adds less than the one before. Summed to infinity, that series converges to ~2,269,360 SGNL — about 11% of the nominal 21M cap — before tail emission ever enters the picture. The 21M figure is not a property this dataset supports; it's an inherited round number from the design's own Bitcoin analogy. What actually grows the real supply past that point is tail emission (9.2), at a fixed per-block rate, dominating the total far sooner than the nominal cap would suggest. The cap only becomes a real constraint if future real survey data is added to keep feeding the network.

9.1 Why the reward is fixed, not scaled by the score

Earlier versions of this network paid a bonus (up to +10 SGNL) scaled by the hit's classifier confidence, on top of the fixed base. That bonus rewarded triage QUALITY — a gradient, more confidence paying more. That premise didn't hold up: the four deterministic rejection rules used to select candidates (drift, cadence position, and two coincidence checks against the rest of the dataset) are what genuinely discriminates a real candidate, and they're binary — a hit clears the gate or it doesn't, nothing about passing it comes in degrees. The classifier's confidence score, meanwhile, is declared by whoever mines the block and never independently recomputed by the nodes that validate it — there was no real gradient left to pay for, only an unverified number every miner had every incentive to always declare at its maximum. The reward is fixed at 10 SGNL per block for this reason, not as a simplification: the bonus's justification is gone, not just its implementation.

9.2 Why tail emission

A hard cutoff to zero removes the incentive to keep doing verification work at exactly the moment the cap is reached. Rather than a cliff, Galaxy SIGNAL decays the reward smoothly in the final stretch before the cap and then holds a small constant reward forever after — the same principle Monero adopted for its own tail emission, applied here to a reward that is earned by triage work rather than pure hashing.

9.3 Halving by dataset cycle

Instead of halving on a fixed block-count schedule, the reward curve halves each time the network completes a full pass over the source dataset. A "cycle" only ever advances forward, one full pass at a time — it can't be skipped or reversed by any single block.

9.4 No pre-mine, no token sale

Every genesis block on this network starts with zero pre-allocated supply — independently verifiable on-chain, since a genesis carrying any inherited balance would show it directly in that block's own record (see section 6). Every SGNL in existence came from a real, mined block; none was minted to a founder or team allocation, and none was sold. The infrastructure this testnet runs on is self-funded by the project's operator, not by token sales or a pre-allocated founder supply -- there is no institutional or corporate funding behind this network today.

9.5 What the token is for

Worth being direct about, since the rest of this section leads here anyway: the four deterministic rejection rules (section 4.3) are cheap and binary, the declared verification score (section 4.4) is informational metadata that no node re-checks, and every valid block pays the identical fixed reward regardless of it (section 9.1). None of that, by itself, needs a blockchain — a plain scheduled job could triage the same corpus for a fraction of the infrastructure.

What the token actually pays for is the mechanism, not the triage. SGNL is the incentive that gets independent operators to keep running nodes that re-derive the four rejection rules from the raw public data themselves, rather than take a central server's word for it, and that keep the network open to anyone with a browser or a CPU instead of one party's private pipeline. The real triage work is a cheap, genuine side effect of paying for that — a running, permissionless, independently-re-verified network — not the thing the token exists to fund.

10 Network and tools

A peer-to-peer network of always-on nodes discovers new peers by gossip, each learning about new nodes from the peer lists its own neighbors already expose. A dedicated pool coordinator aggregates hashrate from many individual miners using a PPLNS (Pay-Per-Last-N-Shares) payout model, anchored to when each block was actually found rather than only to the most recent shares at payout time.

Three ways to participate, all client-side key custody:

• Browser webminer — generates a wallet and mines directly from a tab, no install required. See /miner.
• Native CLI — scriptable, statically-built binaries for Linux, Windows, and macOS.
• Native GUI — a full desktop miner with wallet management, for the same three platforms.

11 Live, checkable evidence

A whitepaper's numbers go stale the moment they're published. Because every hit's verification score is deterministic and every block is public, Galaxy SIGNAL's actual output can be checked live, at any time, against the real chain — not just cited from a document.

This is deliberate: rather than asking a reader to trust a fixed set of numbers in this document, the intent is that the network's actual, growing body of real verification work is the evidence — and it keeps accumulating whether or not anyone reads this page.

11.1 Permanent, citable archive (Zenodo)

The four pages above are all live, which is exactly the point — but a live page isn't a stable thing to cite: its content changes under the same URL every time a block is mined. /dataset exists to solve that specific problem. By design, every 100 confirmed blocks the network's confirmed-block record is deposited on Zenodo — a research-data archive operated by CERN and OpenAIRE, the standard place independent and citizen-science work gets a permanent, citable DOI without needing a journal's gatekeeping first. Automated publishing is currently paused — see the notice below and /audit §10.3.

Each deposit contains three things: the full record of every hit each block cleared the four deterministic rejection rules on (frequency, drift rate, SNR, sky position, and its exact row position in the original Breakthrough Listen survey file), the declared verification score attached to it, and the classifier model file whose fingerprint matches that score — so any row can be independently re-scored and reproduced by a third party, without needing to trust this project's own infrastructure. Every new snapshot is published as a new version of the same Zenodo record, under one permanent "concept" DOI that always resolves to whichever version is most recent, while every earlier version stays exactly as it was published — a snapshot, once deposited, can never be silently altered afterward. Licensed CC-BY 4.0.

12 What this is not

Worth stating plainly, not burying in a footnote.

13 Status and roadmap

Galaxy SIGNAL is a testnet today, and this document describes it as such. Two things worth being direct about:

• Infrastructure is currently centrally operated. Reorganization checkpointing limits the damage a deep reorg could do, but it is not a substitute for real, independent decentralization — which this network does not yet have. Growing a genuinely independent set of node operators is the priority ahead of any mainnet discussion.
• The protocol has changed under active development. Consensus-critical changes — the block hash format, the hashing algorithm, the transfer format — have each required a coordinated network reset so far. A height-indexed fork mechanism already exists for difficulty-parameter changes; extending that same discipline to larger protocol changes, so a future upgrade doesn't require starting the chain over, is ongoing work.

Both are stated here because a whitepaper that omits known limitations isn't a credible one.