Useful output

Bitcoin’s mining produces nothing but the block: trillions of hashes, all discarded. Pearl’s pitch is that its mining can produce something else too. The work is a matrix multiplication, and matrix multiplications are what AI models spend most of their time doing. If the miner’s matrices are a real model’s numbers, the product is a real answer.

There’s a catch built into the puzzle: the miner multiplies noisy matrices, so the product it computes isn’t the one it wanted. This page shows how the noise is removed exactly, how mining sits inside a real AI serving engine, what it costs, and where “useful” stops being guaranteed.

Try it

Build low-rank noise and see why it’s cheap: each noise column is just one column of a thin matrix minus another.

How does the miner get the real product back?

With a little algebra. Write the noisy matrices as A′ = A + E_A and B′ = B + E_B, where each noise matrix is a thin random matrix times a ±1 selector: E_A = E_AL·E_AR and E_B = E_BL·E_BR. Then:

Both extra terms factor through the thin rank-r pieces, so they can be computed cheaply and subtracted:

This is called denoising. The mining happened on the noisy product (the tickets came from its running sums), but the useful output is the clean one.

What does denoising cost?

Very little, because of the low rank:

• A·E_BL and E_AR·B′ are just additions. The selectors hold only ±1, two per row or column, so these cost about as much as reading the matrices once.
• The two remaining products are m × r times r × n: about m·n·r multiply-accumulates each.

Against the main product’s m·n·k, that’s an overhead of about 2r/k:

These are operation counts, not measurements: real speed depends on how well the corrections fit around the main multiplication on the GPU. Generating the noise and fingerprinting the matrices add work that grows only with the matrix sizes, not their product. More on the arithmetic in rank and noise.

On the GPU, Pearl’s kernel does the whole thing in one fused pass: noise, multiply, extract tickets, denoise. The correction terms are computed in 16-bit floating point with fixed scale factors (2⁻¹⁴ and 2⁻¹²), then the result is multiplied by the usual quantization scales and written out in bfloat16, the format the model expects. The integer identity is exact; whether the GPU’s floating-point path reproduces it bit for bit is an open question. It almost certainly doesn’t matter for an AI model’s quality, but it matters for any claim of an “exact” product.

How does mining fit inside an AI model?

Pearl’s official miner is a plugin for vLLM, a widely used open-source engine for serving language models. It replaces the model’s quantized linear layers with Pearl’s noisy multiplication.

1. Quantize

   In mining mode, a layer’s input activations are rounded to 7-bit integers, in [−63, 63], per token. The weights are stored pre-quantized. See integers and quantization.

2. Decide whether to mine

   Only if the multiplication is big enough: at least 1,024 tokens (m), 256 output columns (n) and k ≥ 1,024. Smaller multiplications run as plain ones.

3. Commit and roll the noise

   Fingerprint the activations and the weights with the current job key, derive the salted seeds, generate the noise.

4. Multiply, mine and denoise in one kernel

   One fused GPU kernel noises, multiplies, checks every tile’s ticket against the share target, and denoises.

5. Hand off winners

   Winning shares are sent to the gateway in the background, while the model carries on with the clean output.

That covers the model’s big projections: the query, key, value and output projections of attention, and the feed-forward layers. Given the size thresholds, mining in practice happens during prompt processing and large batches, not when generating one token at a time for one user. Pearl Research Labs publish quantized Llama models for the miner (Llama-3.3-70B-Instruct and Llama-3.1-8B-Instruct, with a -pearl suffix).

What do the overhead claims say?

Pearl Research Labs publish two kinds of figure:

• The blog’s “measured in production” numbers: +5.08% on Llama 70B (4 H200 GPUs, data-parallel) and +3.9% on DeepSeek V3.2 (8 H200 GPUs, data- and expert-parallel), “versus stock serving engines”, running on integer hardware with 7-bit weights and activations.
• The INT whitepaper’s Table 1, on 4 H200s with Llama-3.3-70B: 18,291.66 tokens/s for the Pearl-certified model (data-parallel), against 15,269.81 for Meta’s bf16 model (pipeline-parallel), with the same MMLU score, 0.8198. Pearl’s pipeline-parallel run reached 17,206 tokens/s with MMLU 0.8190. Quantized to small integers, the Pearl model can be faster than the 16-bit original.

Is Pearl’s mining actually useful?

It can be, but nothing makes it so. This is the usefulness gap, and it’s worth stating plainly:

• Consensus checks arithmetic, not meaning. The certificate proves that committed matrices in range, plus the noise, produce the ticket. Random numbers satisfy that exactly as well as a model’s layer.
• Pearl’s own reference CPU miner multiplies random matrices. It’s described as a naive implementation for completeness and testing, but it shows that random work is valid work.
• What miners actually run is up to them. A 2026 study by Basu (arXiv 2606.04819) reported that the dominant third-party mining software contains no AI inference code at all. That study’s measurement covers one pool and rests on analysing one program; its network-wide extrapolations are its own and haven’t been checked here.

So the honest summary: Pearl’s design makes useful mining possible at small overhead, and its official software does it. How much of the network’s work is useful is an open question that the chain itself can’t answer.

ApEA = A + (EAL * EAR)
BpEB = B + (EBL * EBR)
AxEBL = s * A * EBL
EARxBpEB = EAR * (B + (EBL * EBR)) * t
AxEB = s^(-1) * (AxEBL * EBR)
EAxBpEB = (EAL * EARxBpEB) * t^(-1)
ApEAxBpEB = ApEA * BpEB
C = A_scales * (ApEAxBpEB - AxEB - EAxBpEB) * B_scales
# s is 2^(-14) if AxEBL is fp16; t is 2^(-12) if EARxBpEB is fp16