Byte order

When a number takes several bytes, someone has to decide which byte goes first. That choice is called byte order, or endianness.

Pearl, like Bitcoin, stores most numbers smallest byte first. That’s little-endian. The other way, biggest byte first, is big-endian, and it’s how people write numbers on paper.

This one choice explains most of the “why does this look backwards?” moments you’ll have reading raw Pearl data.

Try it

Pick a byte width, type a number and compare the two orders. The converter shows the bytes as written and as Pearl stores them.

What does little-endian look like?

Think of a date. Writing 2026-10-20 puts the biggest unit first. Writing 20-10-2026 puts the smallest first. Same date, different order.

Take the number 1,792,512,899. In hex it’s 0x6ad79383, four bytes: 6a d7 93 83. Little-endian stores them the other way round:

That number isn’t random. It’s the time of block 130,825, and 83 93 d7 6a is exactly what sits in its header:

To read any little-endian field, reverse the bytes, then read the hex normally. Reverse whole bytes, not single characters: 83 stays 83.

Why are hashes shown backwards?

Here’s the part that trips everyone up. A hash isn’t a number you do arithmetic with, so you’d expect it to be shown exactly as stored. It isn’t.

Block 130,825’s header points to its parent with the bytes d3221e43…de7ac7ab. But explorers show the parent’s hash as abc77adee0d6eda61720687d5642efbe4a6a7d9853eee1dad0c559dc431e22d3. It’s the same 32 bytes, reversed.

The same happens to the block’s own hash. SHA256d of the header comes out as ae3355ee…7651c83f. Reversed, that’s the hash you see everywhere: 3fc851763893a0135ea756d5dcbe355f375e613957930e7f401fafc8ee5533ae.

Why? In Bitcoin’s original code, a block hash was treated as a 256-bit little-endian number so it could be compared with the target. When the code printed that number, it printed it the human way, biggest byte first, which reversed the bytes. The habit stuck, and Pearl inherited it unchanged.

Transactions do the same. An input names the transaction it spends by its txid, stored internally. The payment below spends 33218153…70553959, but its first input holds 5939557091bae792…e253812133 on the wire:

Where does byte order decide who wins a block?

In Bitcoin, the reversed hash display is a leftover: the block hash read as a little-endian number is what gets compared with the target.

Pearl never compares the block hash with the target. Instead, the winning check reads a different hash, the BLAKE3 mining ticket called hash_jackpot, as a little-endian 256-bit number. A small number has zero high bytes, and in little-endian the high bytes come last. So a winning ticket’s zeros sit at the end of its raw bytes.

Block 130,825’s winning ticket, as stored in its certificate:

Reversed, the ticket is 0x00000000000000ed2d91…bbeb4. The bound it had to beat was 0x00000000000006ad0eb0… (the target times the 1,048,576 multiply-accumulates its tile cost), and it did. Read the bytes the wrong way round and the same ticket would be an enormous number that loses. The tickets and target page explains the bound.

Is anything big-endian?

Yes, a few things:

• Private keys are 32-byte big-endian numbers. Key 1 is 00…0001.
• Inside SHA-256, the algorithm reads its input in 4-byte big-endian words. You never see this from outside.
• Hex written by people, like 0x176ad0eb or a hash in display order, reads biggest first.

The rule of thumb for Pearl’s own fields: if it’s a count, an amount, a time or a version, it’s stored little-endian. If it’s a hash, it’s stored in internal order and shown reversed.

const reverseHex = (hex) => hex.match(/../g).reverse().join('');
reverseHex('8393d76a');                    // '6ad79383'
parseInt(reverseHex('8393d76a'), 16);      // 1792512899