§ 11 · Blockchain
The genesis block
Block 0, its message, and the Bitcoin block it quotes
On this page 8 sections
Every chain has to start somewhere. The first block has no parent to point to and no earlier blocks to check against, so nobody mines it. It is written straight into the node software, and every node starts from the same copy.
That is the genesis blockGenesis block: Block 0, written into the software rather than mined. Pearl's is dated 27 April 2026, pays no reward, and quotes a Bitcoin block hash to show it wasn't made earlier., height 0. Pearl’s is dated 27 April 2026, 09:00:00 UTC. It pays no reward, carries a placeholder proof, and holds a short message: a summary of Pearl’s rules, followed by the hash of a Bitcoin block, to prove when it was made.
Try it
Here is the genesis header in the header explorer. Change any field and the hash no longer matches the one built into every node.
What’s in the genesis header?
The same six fields as any Pearl header, 108 bytes:
| Field | Bytes | Value |
|---|---|---|
| Version header.version | 4 @0 | 0x00000001 int32 LE. BIP-9 style 0x20000000 since block 1; no consensus meaning in Pearl. |
| Previous block header.prevBlock | 32 @4 | 0000000000000000000000000000000000000000000000000000000000000000 Hash of the parent block, stored byte-reversed; shown in display order. |
| Merkle root header.merkleRoot | 32 @36 | 302f59c6f1239648bd38eddf16b22acc8c8df3c96de2e4f552bd2f38371675c1 Root of the SHA256d Merkle tree of this block’s txids, stored byte-reversed. |
| Time header.timestamp | 4 @68 | 1777280400 (2026-04-27 09:00:00 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 | 0x1b00ffff Compact target. Difficulty 1. The certificate's jackpot hash (not this header's hash) must meet it. |
| Proof commitment header.proofCommitment | 32 @76 | 0000000000000000000000000000000000000000000000000000000000000000 SHA256d(LE32(certificate version) ‖ public data). Replaces Bitcoin’s nonce: Pearl headers have no nonce. |
| Field | Value | Notes |
|---|---|---|
| Version | 1 | Later blocks use Bitcoin-style version-bit values such as 0x20000000. |
| Previous block | 32 zero bytes | There is no parent. |
| Merkle root | 302f59c6…371675c1 |
The txid of its only transaction, the coinbase. |
| Time | 1,777,280,400 | 2026-04-27 09:00:00 UTC |
| Bits | 0x1b00ffff | The easiest target: difficulty 1. |
| Proof commitment | 32 zero bytes | Unique to genesis: no real certificate behind it. |
Hash those 108 bytes with SHA256d and reverse the result, and you get a18d3093b7ff618f0cdd073fa3d10374e2e0105fe7ef53ff48b55f41c58dadd7. That hash is hard-coded in pearld, and block 1’s previous-block field holds it.
What does its coinbase say?
The genesis block’s only transaction is its coinbase, 295 bytes:
| Field | Bytes | Value |
|---|---|---|
| Version version | 4 @0 | 1 int32 little-endian. Pearl wallets and pearld coinbases use version 1; relay policy accepts 1-2. |
| Input count vin.length | 1 @4 | 1 CompactSize number of inputs. |
| Previous txid vin[0].txid | 32 @5 | 0000000000000000000000000000000000000000000000000000000000000000 All zeros: this input creates new coins (coinbase). |
| Output index vin[0].vout | 4 @37 | 0xffffffff 0xffffffff together with a zero txid marks a coinbase. |
| scriptSig length vin[0].scriptSig.length | 1 @41 | 234 CompactSize length of the scriptSig. |
| Coinbase script vin[0].scriptSig | 234 @42 | 04ffff001d01044ce1546865206e61746976652063757272656e637920666f72206d616368696e657320616e642068756d616e732e20546f74616c20322e31653920506561726c732c2043756d756c617469766520656d697373696f6e20682f28682b363530323236292c205754454d4120336d3134732037642c20426974636f696e20626c6f636b20233934363834322077697468204d5450203137373732373035323420697320303030303030303030303030303030303030303033613932323138363165633734313134323764643234663937396662393161336238663732363565316462632e Coinbase data: starts with the block height (BIP-34), then anything the miner likes (2-100 bytes). |
| Sequence vin[0].sequence | 4 @276 | 0xffffffff Final (0xffffffff): no RBF signal, no relative locktime, and locktime is ignored for this input. Pearl wallets use this. |
| Output count vout.length | 1 @280 | 1 CompactSize number of outputs. |
| Amount vout[0].value | 8 @281 | 0 grains (0.00000000 PRL) int64 little-endian, in grains (1 PRL = 100,000,000 grains). |
| Script length vout[0].scriptPubKey.length | 1 @289 | 1 CompactSize length of the locking script. |
| Locking script vout[0].scriptPubKey | 1 @290 | OP_RETURN data (unspendable) OP_RETURN data carrier: provably unspendable, never enters the UTXO set. |
| Locktime locktime | 4 @291 | 0 0: no time lock. |
Its scriptSig, 234 bytes, has three pushes:
| Field | Size | Description |
|---|---|---|
| 04 ffff001d | 5 | Push 4 bytes: ffff001d, which is Bitcoin’s own difficulty-1 bits, 0x1d00ffff. Copied from Bitcoin’s genesis block, not Pearl’s 0x1b00ffff. |
| 01 04 | 2 | Push 1 byte: 04. Also copied from Bitcoin’s genesis. |
| 4c e1 … | 227 | OP_PUSHDATA1, length 0xe1 = 225, then 225 bytes of text. Bitcoin’s shorter message fit a one-byte push; Pearl’s needs OP_PUSHDATA1. |
The first seven bytes, 04ffff001d0104, are exactly how Bitcoin’s genesis coinbase begins. The text that follows is Pearl’s own.
What does the message mean, line by line?
Here it is in full:
The native currency for machines and humans. Total 2.1e9 Pearls, Cumulative emission h/(h+650226), WTEMA 3m14s 7d, Bitcoin block #946842 with MTP 1777270524 is 000000000000000000003a9221861ec7411427dd24f979fb91a3b8f7265e1dbc.
Broken into its five parts:
| Text | Meaning |
|---|---|
| The native currency for machines and humans. | Pearl’s motto: a currency mined with the matrix arithmetic AI runs on. |
| Total 2.1e9 Pearls, | The supply cap: 2.1 × 10⁹ = 2.1 billion PRL. See supply and grains. |
| Cumulative emission h/(h+650226), | The emission curve: after block h, at most that fraction of the supply exists. See emission. |
| WTEMA 3m14s 7d, | The difficulty rule: WTEMA with a 3 min 14 s (194 s) target and a 7-day time constant. See WTEMA. |
| Bitcoin block #946842 with MTP 1777270524 is 0000…1dbc. | A timestamp proof, explained next. |
So the first block states, in one sentence, the three numbers that shape Pearl’s money: the cap, the curve and the clock.
Why quote a Bitcoin block?
To prove the genesis block is not older than it claims.
A block hash can’t be predicted before the block is mined. Bitcoin block 946,842’s hash, 000000000000000000003a9221861ec7411427dd24f979fb91a3b8f7265e1dbc, didn’t exist before that block was found. Pearl’s genesis coinbase contains it; the coinbase’s txid is the genesis Merkle root; and the genesis hash covers that root. So the genesis block, and everything after it, was made after Bitcoin block 946,842.
The research for this site checked that Bitcoin block on mempool.space:
| Unix time | UTC | |
|---|---|---|
| Block 946,842’s median time past (quoted) | 1,777,270,524 | 2026-04-27 06:15:24 |
| Block 946,842’s own timestamp | 2026-04-27 06:48:52 | |
| Pearl genesis timestamp | 1,777,280,400 | 2026-04-27 09:00:00 |
Genesis is stamped 2 hours 44 minutes 36 seconds after the quoted median time, and about 2 hours 11 minutes after the Bitcoin block itself. It’s Satoshi’s newspaper-headline idea, updated: instead of a front page, the hash of a Bitcoin block.
What about the certificate?
Every Pearl block travels behind a mining certificate, and genesis has one too, but it’s a placeholder. It is a V1 certificate with the genesis block hash, 164 zero bytes of public data, and a 4-byte proof: deadbeef, labeled a “vanity proof” in the code.
| Field | Bytes | Value |
|---|---|---|
| Certificate version certificate.version | 4 @0 | 1 u32 LE. V1 before block 71,935, V2 until 98,999, V3 (salted noise seeds) from 99,000. 0 = no certificate. |
| Block hash certificate.blockHash | 32 @4 | a18d3093b7ff618f0cdd073fa3d10374e2e0105fe7ef53ff48b55f41c58dadd7 SHA256d of the 108-byte header this certificate proves (stored byte-reversed); must equal the header’s hash. |
| Common dimension k certificate.publicData.k | 4 @36 | 0 u32 LE: the shared dimension of A (m×k) and B (k×n). |
| Noise rank r certificate.publicData.rank | 2 @40 | 0 u16 LE: rank of the low-rank noise; must be ≥ 128 since block 96,251. |
| MMA type certificate.publicData.mmaType | 2 @42 | 0 0 = Int7 × Int7 → Int32. |
| Rows pattern certificate.publicData.rowsPattern | 6 @44 | [0] (h=1) Periodic row offsets of the hash tile, stored as (factor−1, length−1) × 3. |
| Columns pattern certificate.publicData.colsPattern | 6 @50 | [0] (w=1) Periodic column offsets of the hash tile. |
| Experts e certificate.publicData.experts | 2 @56 | 0 Number of MoE experts; 0 = dense (MoE is invalid on mainnet since 91,630). |
| Top-k certificate.publicData.topK | 2 @58 | 0 0 for dense jobs. |
| Reserved certificate.publicData.reserved | 28 @60 | 00000000000000000000000000000000000000000000000000000000 Must be zero. |
| hash_A certificate.publicData.hashA | 32 @88 | 0000000000000000000000000000000000000000000000000000000000000000 Keyed-BLAKE3 Merkle root of matrix A (key = job key). |
| hash_B certificate.publicData.hashB | 32 @120 | 0000000000000000000000000000000000000000000000000000000000000000 Keyed-BLAKE3 Merkle root of Bᵀ (B column-major). |
| hash_jackpot certificate.publicData.hashJackpot | 32 @152 | 0000000000000000000000000000000000000000000000000000000000000000 The winning ticket: BLAKE3 keyed with seed_A over the tile transcript; read as a little-endian number and compared with the bound. |
| m (rows of A) certificate.publicData.m | 4 @184 | 0 u32 LE; bound into the noise seeds since certificate V3. |
| n (columns of B) certificate.publicData.n | 4 @188 | 0 u32 LE; bound into the noise seeds since certificate V3. |
| Tile row offset certificate.publicData.tRows | 4 @192 | 0 Smallest row index of the winning hash tile. |
| Tile column offset certificate.publicData.tCols | 4 @196 | 0 Smallest column index of the winning hash tile. |
| Proof length certificate.proofLength | 4 @200 | 4 u32 LE; at most 60,000 bytes. |
| ZK proof certificate.proof | 4 @204 | 4 bytes pow_bits(3) ‖ rate_bits(3) ‖ zeta(16) ‖ Plonky2 proof: a STARK wrapped in two Plonky2 recursions. Not covered by the block hash. |
It couldn’t be a real proof: there was nothing to mine on. And it doesn’t need to be, because nodes never verify genesis. Pearl’s code says it plainly: “Genesis blocks are never verified (hardcoded and trusted), only serialized.”
That’s also why the header’s proof commitment is all zeros. For any other block it would be SHA256d of the certificate version and public data. For this placeholder certificate that would be 1879296ca34cb1aa416a341f3b49dfd9516f48d36fcd5a2ad761c07030466d22, which doesn’t match the zeros, and doesn’t have to. The whole block, certificate, header, one-byte transaction count and coinbase, is 612 bytes: 208 + 108 + 1 + 295.
Can the genesis coins be spent?
There are none. The subsidy formula returns 0 for height 0, and the coinbase’s only output is worth 0 grains, locked by a bare OP_RETURN (6a), which nothing can ever unlock. The code adds a third guard: “the coinbase for the genesis block is not spendable”.
The first real reward came one second later, in block 1: 3,229.64134063 PRL. Pearl had no premine.
Make a guess
The genesis scriptSig is 234 bytes, but coinbase scriptSigs may only be 2 to 100 bytes. Why is genesis allowed?
Think of your answer first, then check it.
Answer Because the genesis block is never validated.
The 100-byte limit is checked when a node validates a block. Genesis isn’t validated: it’s built into the software and trusted as is. Every block from 1 on must obey the limit, and they do. Block 130,825’s coinbase scriptSig, for example, is 39 bytes.
Do other networks share it?
Partly. Pearl’s regtest, simnet and signet reuse the mainnet coinbase and its message. Testnet and testnet2 use a different one, quoting 03/May/2024 and a different Bitcoin block hash, and paying 50 PRL to a dummy key. Each network has its own genesis block hash in pearld.
The whole 612-byte genesis block, by offset
| Offset | Bytes | Field |
|---|---|---|
| 0 | 01000000 |
Certificate version 1 |
| 4 | d7ad8dc5…93308da1 |
Certificate’s block hash (internal byte order) |
| 36 | 164 × 00 |
Public data, all zero |
| 200 | 04000000 |
Proof length: 4 |
| 204 | deadbeef |
The “vanity proof” |
| 208 | 108 bytes | The header |
| 316 | 01 |
Transaction count: 1 |
| 317 | 295 bytes | The coinbase (version 1, no witness) |
The coinbase and block are defined in genesis.go (node/chaincfg/genesis.go:16-106 at v1.5.2, on GitHub):
var genesisBlock = wire.MsgBlock{
MsgHeader: wire.MsgHeader{
MsgCertificate: wire.MsgCertificate{
Certificate: &wire.CertificateV1{
Hash: genesisHash,
ProofData: []byte{0xde, 0xad, 0xbe, 0xef}, // Vanity proof for genesis block
},
},
BlockHeader: wire.BlockHeader{
Version: 1,
PrevBlock: chainhash.Hash{},
MerkleRoot: genesisMerkleRoot, // 302f59c6…371675c1
Timestamp: time.Unix(1777280400, 0), // 2026-04-27 09:00:00 +0000 UTC
Bits: 0x1b00ffff,
},
},
Transactions: []*wire.MsgTx{&genesisCoinbaseTx},
} The research behind this site recomputed the genesis hash from these bytes and compared the serialization with the public explorer’s raw block 0: identical, all 612 bytes.