Integers and quantization

Pearl’s mining multiplies matrices of small whole numbers, between −64 and 64. Not fractions, not big numbers.

That choice does three jobs at once. Whole numbers make the arithmetic exact, so everyone agrees on every bit. Small ones fit in a single byte, even after noise is added, so GPUs can use their fastest circuits. And their sums fit comfortably in 32 bits, so nothing ever overflows.

Why whole numbers and not fractions?

Because a mining ticket must come out identical on every computer that checks it.

Computers store fractions as floating-point numbers, which round after every operation. Add the same numbers in a different order and the last digits can differ. A GPU, a CPU and a proof circuit would sometimes disagree, and the ticket, a hash, would change completely.

Integer arithmetic has no rounding. 3 × (−4) + 7 is −5 on every machine, in any order. So Pearl’s rules define the work in integers: small inputs that fit in a byte, 32-bit running sums. The format is named in every certificate: Int7 × Int7 → Int32.

What are the ranges, exactly?

The first row is enforced twice. The plain check a pool runs on a winning share rejects any revealed entry outside [−64, 64], and the zero-knowledge circuit that every node verifies has the same range check built in. The noise ranges come from how the noise is built, on the rank and noise page.

Why can’t the sums overflow?

A 32-bit signed integer holds values up to 2,147,483,647. Check the worst case:

So the GPU can accumulate a whole dot product in 32-bit registers without ever checking for overflow. This is one reason k has an upper limit at all.

What is quantization?

AI models are trained with fractional numbers, usually 16-bit floating point. Quantization squeezes them into a few integer levels, with a scale factor to convert back.

The common symmetric method: find the largest magnitude in a row, divide it into 63 steps, and round each number to the nearest step.

Pearl’s official miner does this inside vLLM. In mining mode, each token’s activations are quantized to 7 bits, [−63, 63], with one scale per token. The weights were quantized ahead of time, with one scale per output channel. After the integer multiplication and denoising, the result is multiplied by both scales and written back as 16-bit floating point, the layer’s normal output.

Pearl Research Labs describe this setup as W7A7 (7-bit weights and activations), prepared with the GPTQ and SmoothQuant methods. Their whitepaper reports Llama-3.3-70B accuracy scores (MMLU) of 0.8198 for the original 16-bit model and 0.8190 to 0.8198 for Pearl-certified runs: little or no loss on that test.

How does the ticket read a negative sum?

As raw bits. Every 128 steps the miner XORs a tile’s running sums together into one 32-bit word, and XOR works on bits, not on values. A negative sum is read in two’s complement.

In Pearl’s toy example, a tile’s first four running sums are 6, 1, −66 and 10:

That word is what goes into the ticket’s diary. See tickets and target.

// Verify all strip values are in [-64, 64] (matching the ZK circuit's IRANGE7P1 range check)
for strip in private_params.s_a.iter().chain(private_params.s_b.iter()) {
    for &val in strip {
        ensure!((-64..=64).contains(&val), "Matrix value {} out of range [-64, 64]", val);
    }
}