Hashrate

In Bitcoin, hashrate means what it says: SHA-256 hashes per second. Pearl explorers show a hashrate too, in the same units, “EH/s” for the network and “TH/s” per GPU. But on Pearl, the thing being counted isn’t a hash. It’s a multiply-accumulate: one multiplication added onto a running total, the basic step of a matrix multiplication.

This page shows why that is, how the number is estimated, and what it means for one GPU.

Try it

Put in a GPU’s speed and see how long it would take, on average, to find a block at today’s difficulty.

How is hashrate estimated?

Nobody counts it. A node or explorer looks at recent blocks, adds up the expected work each one represents, and divides by the time they took. Pearl’s node does exactly what Bitcoin’s does, over the last 120 blocks by default:

The work of a block is the number of attempts you’d expect to need, on average, to beat its target. In Bitcoin an attempt is one hash. The question is what an attempt is on Pearl.

Why is a “hash” a multiply-accumulate?

Because of how the ticket bar is scaled. A ticket from a tile of h·w cells, each summed over L steps, costs W = h·w·L multiply-accumulates, and it wins if it’s at most the target times W. So:

W cancels. Whatever the tile shape or matrix size, the expected number of multiply-accumulates per block is 2²⁵⁶ ÷ T, which is exactly the “work” number the node already adds up. So the node’s hashes per second are multiply-accumulates per second. Pearl’s INT whitepaper describes the difficulty the same way, as an “acceptance probability per int8 multiply-add”.

Two refinements:

• These are multiply-accumulates on the noisy 8-bit matrices, the ones actually multiplied.
• They’re counted at the reference noise rank, 128. Since the rank penalty, a miner using rank r above 128 needs r/128 multiply-accumulates per unit of credited work.

Pearl’s software still calls the result “hashes per second”; the multiply-accumulate reading follows from the ticket rule rather than from a label in the code. It’s the natural reading, but it is an interpretation.

How much work is a block?

Pearl’s difficulty compares a target with the easiest one, bits 0x1b00ffff. Plugging that in:

Difficulty, 2026-10-20

40,157,376

bits 0x176af3a6

Work per block

≈ 1.13 × 10²²

multiply-accumulates

Per second, at 194 s

≈ 5.83 × 10¹⁹

if blocks were on schedule

That last number is about 58 EH/s. Blocks were actually coming faster than 194 seconds that day (174.3 s on average over 144 blocks), which pushes the estimate up: PRLScan’s difficulty-based figure was 6.49 × 10¹⁹ per second, and MiningBoard showed 65.61 EH/s. Different averaging windows give slightly different numbers, but they agree on the scale.

Right now, from PRLScan:

What does that mean for one GPU?

Pool data collected for a 2026 study lists NVIDIA H100 workers at about 500 to 700 TH/s and RTX 3090 workers at 75 to 120 TH/s. On Pearl, “TH/s” means trillions of multiply-accumulates per second. Estimates only, from those figures and the difficulty above:

Each 2 × 64 × 8,192 ticket wins with probability about 9.3 × 10⁻¹⁷. That’s why almost everyone mines in pools.

What doesn’t the number count?

It counts the multiply-accumulates that buy tickets. Real miners do more:

• Commitments and noise: fingerprinting both matrices and generating the noise, which grows with the matrix sizes.
• Denoising, for miners who keep the product: about 2r/k extra, 3% at k = 8,192.
• Proving a winning tile: seconds of CPU per block found.
• Rank above 128, as above.

And the opposite caveat: the number says nothing about whether the work was useful. A multiply-accumulate on random numbers counts the same as one inside an AI model.

func CalcWork(bits uint32) *big.Int {
	difficultyNum := CompactToBig(bits)
	if difficultyNum.Sign() <= 0 {
		return big.NewInt(0)
	}
	// (1 << 256) / (difficultyNum + 1)
	denominator := new(big.Int).Add(difficultyNum, bigOne)
	return new(big.Int).Div(oneLsh256, denominator)
}