From Hashes to Relations
When a new project appears near the top of a profitability table, most miners only see a ticker, a symbol and a few numbers: revenue per day, power, hashrate.
Behind FACT, sitting today among the most profitable coins for CPUs like the Ryzen 7950X, there is a quiet story of engineering work that almost no one sees: a redefinition of what “hashrate” even means for a non‑hashing network, a reworked pool backend, and a long back‑and‑forth with the team at Hashrate.no to make everything line up correctly.
At the center of that work is Alex, FACTOR’s mining ambassador, leading the FACTOR team to accomplish this milestone.
This is how FACTOR made it onto Hashrate.no — and why that matters for miners who care about both their revenue and the kind of work their CPUs are actually doing.
Why listing FACTOR was not “just another integration”
Traditional PoW coins fit neatly into Hashrate.no’s mental model:
A hashrate measured in hashes per second
A difficulty that tells miners how many hashes are needed per block
A reward schedule and an emission curve
Factor is different by design. It comes from the FACTOR research: a blockchain where Proof‑of‑Work is not hashing, but integer factorization. Every block represents real progress on hard number‑theoretic problems related to the General Number Field Sieve (GNFS), the leading classical algorithm for factoring large integers.
In GNFS, miners are not counting hashes. They are producing relations: equations that link values in a number field and get stored in a huge, sparse matrix with hundreds of thousands of dimensions. That matrix is then solved to recover the factors.
For a site like Hashrate.no, built around hashes per second, this creates a problem:
What does “hashrate” mean on a network that doesn’t hash?
To get FACTOR listed in a fair, apples‑to‑apples way, that question had to be answered with code, not slogans.
Redefining “hashrate”: from hashes per second to relations per second
Alex’s starting point was simple and brutally pragmatic:
“We are measuring relations per second for each worker. That’s the hashrate.”
Everything else flows from that.
1. Worker hashrate: rel/s
Each miner in the FACTOR pool is constantly generating relations for GNFS. Those relations can be counted. Over time, that count stabilized into a natural unit:
Worker hashrate: the average number of valid relations a miner contributes per second
Reported as rel/s, with rolling 1‑hour and 24‑hour averages
It isn’t just a cosmetic rename of hashes/sec. For GNFS, relations/sec is the unit that actually tracks real work: the lines being added to that giant matrix.
2. Pool hashrate: sum of all rel/s
Once worker hashrate is defined, the pool hashrate falls out naturally:
Pool hashrate = sum of all workers’ rel/s
This is what Hashrate.no expects as the “pool hashrate”: a single number that captures the total computational pressure the pool is applying to FACTOR’s proof‑of‑work.
3. Network hashrate: derived from blocks in and out of the pool
The network hashrate is not just pool hashrate scaled up. It is inferred from the pool’s share of the blocks:
Observe how many blocks the pool finds
Compare with how many blocks are found outside the pool
From that ratio and the pool’s measured rel/s, derive the network‑wide rate of relations per second
In other words, network hashrate is anchored in observed block production, just like in a traditional hashing coin. The only difference is that the underlying unit is relations per second rather than hashes.
This is the core conceptual work that had to be done before Hashrate.no could even start thinking of FACTOR as a coin they could display.
The API work that made it real
With the definitions in place, the hard part still remained: wiring all of this into the tools Hashrate.no relies on.
Alex’s checklist looked roughly like this:
Expose the new metrics via API
Hashrate.no requires that pools expose:
per‑worker hashrate
pool hashrate
network hashrate
For a non‑hashing coin, those numbers don’t exist out of the box. They had to be computed, stored and served correctly.
That meant adding endpoints that return:
1h and 24h averages of relations/sec per worker
summed relations/sec at pool level
network relations/sec derived from block shares
Build a miner‑revenue API
A listing is not just about speed; it’s about payouts. Miners want to know, per unit of compute:
expected coins per day
expected revenue in fiat or BTC
Alex implemented an API that takes the pool and network metrics, the reward schedule and difficulty, and returns expected miner revenue in the format Hashrate.no’s engines understand.
This required a full rework of the pool page: the backend had to be refactored so that every number a miner sees is consistent with every number Hashrate.no sees.
Explain non‑hashing PoW to a hashing world
On the human side, there was a lot of back‑and‑forth in the Hashrate.no Discord:
Why does FACTOR not have “hashes”?
How is relations/sec comparable across difficulty changes?
How can the system remain fair if the underlying algorithm behaves differently than SHA‑based PoW?
These are engineer questions. They are also perfectly valid questions.
The answers lived in two places:
in the math (GNFS, relation collection, matrix size)
in the implementation details (how to normalize rel/s so that difficulty changes do not distort hashrate)
Adjusting hashrate across difficulty changes
One subtle issue is that relations/sec shifts when difficulty changes. Without care, a miner could see their “hashrate” move in ways that don’t really reflect what their CPU is doing.
The solution was to make hashrate self‑adjusting:
account for current difficulty in how rel/s is reported
ensure that when difficulty steps up, the metric stays meaningful and comparable
That way, when a miner sees a number on the pool page and a number on Hashrate.no, both line up with what their hardware is actually producing for the network.
Only once all of this was done, tested and reconciled with the Hashrate.no team did FACTOR earn its place in the tables.
Why this matters for CPU miners
The end result of all this work is simple to state:
On a Ryzen 7950X, FACTOR is currently listed as the third most profitable coin on Hashrate.no’s CPU page.
For a miner, that means three practical things.
1. Profitability backed by a metric that actually means something
Relations/sec is not a vanity number. Each relation is a line in a high‑dimensional matrix that pushes an integer closer to being factored.
Mining FACT means:
the CPU is driving GNFS relation collection, not spinning hashes in a vacuum
the reported “hashrate” corresponds to progress on real cryptographic workloads, not just nonce churn
There is a certain satisfaction in seeing performance mapped to a task that exists outside the coin’s own ecosystem.
2. A fair pool view — because the plumbing was rebuilt
Most miners are familiar with the frustration of:
a dashboard that doesn’t quite match what an external site shows
a pool where hashrate spikes and dips without explanation
The rework Alex did on the pool backend was driven precisely by the need to avoid that. The same machinery that powers the Hashrate.no integration drives the live pool statistics:
per‑worker rel/s
pool and network hashrate
estimated payouts
When a miner tunes threads, memory and flags for GNFS on a 7950X, the effects show up cleanly and consistently across the ecosystem.
3. A place where CPU tuning meets meaningful math
FACTOR is built for CPU and memory rather than ASICs. The GNFS pipeline has a completely different performance profile than SHA‑based mining. That opens up an interesting space for miners who enjoy:
experimenting with core counts and affinity
playing with memory hierarchies and cache behavior
seeing how real‑world number theory workloads respond to their tuning
The reward is not only a coins‑per‑day estimate, but also participation in a live, incentivized experiment on the practical hardness of factoring — the same problem that underpins RSA and much of today’s cryptography.
A small, important milestone
On the surface, getting listed on a profitability site might look like a minor checkbox in a project roadmap.
For FACTOR, it represents something more:
a proof that non‑hashing PoW can be integrated into the existing mining ecosystem without hand‑waving
a demonstration that it is possible to define a clean, linear measure of work (relations per second) for a GNFS‑based network
a recognition of the engineering care required to make numbers line up across pool, protocol and external tools
Alex’s work as mining ambassador turned a technically unusual protocol into a first‑class citizen on a platform that expects hashes — not relations, not matrices, not GNFS jargon.
The result is that miners looking at the 7950X page on Hashrate.no now see FACT in a familiar context: next to other coins, ranked by profitability, with transparent hashrate and revenue estimates.
Behind that row in the table is a lot of quiet, precise work. For an audience of engineers, that is exactly the kind of work that tends to matter.
FACTOR’s listing on Hashrate.no is one step in a longer journey: building a network where CPU miners are not only securing a ledger, but also driving forward a global, measurable benchmark for the strength of real‑world cryptography.