Bits · Pearl Codex

The bits field tells you how hard the block was to win. It holds the target: a 256-bit number that a winning lottery ticket must not exceed. The smaller the target, the harder the block.

A 256-bit number takes 32 bytes, but this field is only 4. So the target is stored in a compact, scientific-notation-like form, the same one Bitcoin uses: an exponent and three digits of mantissa.

What’s different on Pearl is what the target is for. It’s never compared with the block hash. It judges a ticket inside the block’s certificate, scaled by how much work that ticket cost.

Try it

Type a bits value and see the target it stands for, its difficulty, and how small a slice of all 256-bit numbers it is.

Bits, target and difficulty

Three ways to write how hard a block is

Bits 4 bytes, in the header

Difficulty vs. 0x1b00ffff

Target 256-bit number, hex

How bits encode the target

17 6a f3 a6

target = 0x6af3a6 × 256^{23 − 3} : the exponent says the target is 23 bytes long; the mantissa gives its first 3 bytes, the rest are zeros.

0000000000000000006af3a60000000000000000000000000000000000000000

Difficulty

40,157,376.49334089

The PowLimit target (difficulty 1) ÷ this target.

Target

0000000000000000006af3a60000000000000000000000000000000000000000

How small the target is, on a log scale from 1 to 2²⁵⁶

The target is about 2^182.7. A random 256-bit number lands below it about once in 1.13 × 10²² tries. Each step left on this bar is a doubling of difficulty. Expected work per block (chain work) is 2²⁵⁶ ÷ (target + 1) ≈ 2^73.3.

Pearl: nothing is compared with this target alone. A block wins when its certificate’s BLAKE3 ticket is at most target × the work in one tile, and the block hash is never checked against it.

Runs in your browser · nothing is sent src/lib/block.ts · btcd’s CompactToBig / BigToCompact

What does it look like?

Size: 4 bytes
Type: Compact number: exponent ‖ 3-byte mantissa
Format: Little-endian

Block 130,827 · header 108 bytes

00000020 999c961b04d94b8b21134e862dc31d5fa56cf9d1f027adb2a0cf95c6525c55eb 6389faa36bd9daffdefc800dea88ac3ef5af1198f7d7179ef3b904420c1cc2c6 1a96d76a a6f36a17 4d52a3fd32160cb032e22edf76912f67dfb1b88946a215281f203836c77ae649

Hover or focus the bytes to name each field Version bytes 0–3 0x20000000 Previous block bytes 4–35 eb555c52c695cfa0b2ad27f0d1f96ca55f1dc32d864e13218b4bd9041b969c99 Merkle root bytes 36–67 c6c21c0c4204b9f39e17d7f79811aff53eac88ea0d80fcdeffdad96ba3fa8963 Time bytes 68–71 1792513562 (2026-10-20 16:26:02 UTC) Bits bytes 72–75 0x176af3a6 Proof commitment bytes 76–107 49e67ac73638201f2815a24689b8b1df672f9176df2ee232b00c1632fda3524d

Field	Bytes	Value
Version header.version	4 @0	0x20000000 int32 LE. BIP-9 style 0x20000000 since block 1; no consensus meaning in Pearl.
Previous block header.prevBlock	32 @4	eb555c52c695cfa0b2ad27f0d1f96ca55f1dc32d864e13218b4bd9041b969c99 Hash of the parent block, stored byte-reversed; shown in display order.
Merkle root header.merkleRoot	32 @36	c6c21c0c4204b9f39e17d7f79811aff53eac88ea0d80fcdeffdad96ba3fa8963 Root of the SHA256d Merkle tree of this block’s txids, stored byte-reversed.
Time header.timestamp	4 @68	1792513562 (2026-10-20 16:26:02 UTC) uint32 LE Unix seconds. Must be at least 1 s after the parent and at most 5 min in the future.
Bits header.bits	4 @72	0x176af3a6 Compact target. Difficulty 40157376.49334089. The certificate's jackpot hash (not this header's hash) must meet it.
Proof commitment header.proofCommitment	32 @76	49e67ac73638201f2815a24689b8b1df672f9176df2ee232b00c1632fda3524d SHA256d(LE32(certificate version) ‖ public data). Replaces Bitcoin’s nonce: Pearl headers have no nonce.

Block hash: 1df2f2c1bf39b1a444e622c1788c11736da2f91f4e9a875a38dc23063c6d45b9
Height: 130,827
Time: 2026-10-20 16:26:02 UTC
Difficulty: 40,157,376.49

Bytes 72 to 75 of block 130,827 are a6 f3 6a 17. As a little-endian integer, that’s 0x176af3a6.

How do you decode it?

Split the four bytes into one byte of exponent and three of mantissa:

0x176af3a6, field by field
Field	Size	Description
Exponent	1	`0x17` = 23: the target is 23 bytes long.
Mantissa	3	`0x6af3a6`: the target’s first three bytes. (Its top bit is a sign bit, as in Bitcoin; targets are never negative.)

Then shift the mantissa left by the remaining 20 bytes:

\text{target} = \texttt{0x6af3a6} \times 256^{\,23 - 3} = \texttt{0x6af3a6} \times 2^{160}

Written out as 32 bytes, that’s

0000000000000000006af3a60000000000000000000000000000000000000000

nine zero bytes, the three mantissa bytes, then twenty more zero bytes. Only three bytes of the target are ever free to vary. That’s the price of fitting it into 4 bytes.

What is difficulty?

Difficulty compares a target with the easiest one Pearl allows, the target of bits 0x1b00ffff:

\text{difficulty} = \frac{\text{target}(\texttt{0x1b00ffff})}{\text{target}(\text{bits})} = \frac{\texttt{0xffff} \times 2^{192}}{\texttt{0x6af3a6} \times 2^{160}} = \frac{65{,}535 \times 2^{32}}{7{,}009{,}190} \approx 40{,}157{,}376.49

Block 130,827

That’s exactly what explorers show for block 130,827. A few more points along the chain’s history:

Block	Bits	Target (32 bytes)	Difficulty
0 and 1	`0x1b00ffff`	`000000000000ffff000…`	1.00000000
2	`0x1b00ffea`	`000000000000ffea000…`	1.00032054
10,000	`0x1a0ab2a8`	`0000000000000ab2a8000…`	23.92961877
100,000	`0x1800c4ef`	`000000000000000000c4ef000…`	21,808,883.27997620
120,000	`0x180089e0`	`00000000000000000089e0000…`	31,150,692.72892112
130,827	`0x176af3a6`	`0000000000000000006af3a6000…`	40,157,376.49334089

What is the target compared with?

Not the block hash. On Pearl, the block hash 1df2f2c1…3c6d45b9 of block 130,827 is a big, random-looking number, nowhere near the target. See block hash.

The comparison happens inside the certificate. Its hash_jackpot, a BLAKE3 hash of one tile’s transcript, read as a little-endian number, must be at most the target times the work that tile cost:

\text{ticket} \le \text{target} \times h \cdot w \cdot L

h·w is the number of cells in the tile and L = k − (k mod r) the length of each cell's sum. For block 130,827: 8 × 16 × 8,192 = 1,048,576 = 2²⁰.

For block 130,827 that bound is 00000000000006af3a6000…, the target shifted left by 20 bits, and the ticket 0000000000000436… is below it. The whole check, with every number, is on tickets and target.

A node checks two simple things about bits itself: the target must be positive and no larger than Pearl’s limit, and the bits must equal what the difficulty rule computes from the parent block.

How do bits change?

After every block. Pearl’s WTEMA rule nudges the target up when the last block was slow and down when it was fast, measured against 194 seconds, then re-encodes it in compact form. Each block’s bits come from its parent’s bits and how long the parent took to arrive after the grandparent. Here are six real consecutive blocks:

Block	Parent’s solve time	Bits
130,822	204 s	`0x176adb49`
130,823	29 s	`0x176ad3d2`
130,824	29 s	`0x176acc5b`
130,825	295 s	`0x176ad0eb`
130,826	510 s	`0x176adf34`
130,827	646 s	`0x176af3a6`

A 29-second gap shrinks the target (harder); a 646-second gap grows it (easier). The details are on WTEMA.

Make a guess

A block with bits 0x176af3a6 arrives 300 seconds after its parent. Will the next block's difficulty go up or down?

Think of your answer first, then check it.

Answer Down, slightly: bits 0x176af872, difficulty 40,150,342.21.

300 seconds is slower than the 194-second target, so the target grows by about (300 − 194) ÷ 604,800 ≈ 0.0175%. Re-encoded, the mantissa goes from 0x6af3a6 to 0x6af872. Pearl’s own code gives exactly this. Because the compact form truncates, small changes can round away: the encoding always rounds the target down, a tiny bias toward higher difficulty.

How much work does a target represent?

On average, 2²⁵⁶ ÷ (target + 1) attempts’ worth. That’s the “work” a node adds up to pick the chain with the most work, as in Bitcoin. For block 130,827 it’s about 1.13 × 10²² (exactly 11,303,469,090,474,696,447,598).

On Pearl that number has a physical meaning: because tickets are scaled by their tile’s work, it is, roughly, the expected number of multiply-accumulates needed to win the block (at the standard noise rank of 128). That reading is an inference from the design, not a figure Pearl publishes. Divided by time, it’s Pearl’s hashrate. See hashrate.

Code: compact encoding and the difficulty number

pearld decodes bits exactly like btcd and Bitcoin Core, in CompactToBig (node/blockchain/difficulty.go:23-57 at v1.5.2, on GitHub): mantissa = bits & 0x007fffff, exponent = bits >> 24, and target = mantissa × 256^(exponent − 3) (shifted right instead when the exponent is 3 or less), negated if bit 0x00800000 is set. The difficulty explorers show comes from getDifficultyRatio (node/rpcserver.go:1034-1050 at v1.5.2, on GitHub):

node/rpcserver.go Go

max := blockchain.CompactToBig(params.PowLimitBits)   // 0x1b00ffff on mainnet
target := blockchain.CompactToBig(bits)
difficulty := new(big.Rat).SetFrac(max, target)
outString := difficulty.FloatString(8)

In JavaScript, with BigInt:

JavaScript

const bits = 0x176af3a6;
const target = BigInt(bits & 0x007fffff) << BigInt(8 * ((bits >>> 24) - 3));
// 0x6af3a6n << 160n