Genesis

The genesis file, its hash, and the fields a client must not correct.

Identity

The file hash is of the published file with LF line endings. The block 0 hash covers every consensus-relevant field including the state root of the six allocations, so matching it is the complete identity check.

Where to get it

Inside the node package, as genesis.json. It is published byte for byte as the fleet holds it, not tidied.

git clone https://git.aere.network/aere-network/aere-node.git
sha256sum aere-node/genesis.json

Two fields you must not "fix"

The sub-second transition height. The genesis carries 2138451. The height at which the block period actually changed, measured on timestamps, is 2137652. The two differ by 799 blocks.

The value in the running configuration is the one every node uses, so a node with a "corrected" genesis computes a different chain. Do not change it. An archive node has resynchronised through that window without stopping, so the value does not impede sync.

The comment strings inside alloc. They are not consensus data, no client reads them, and two of them are textually wrong. They are published unaltered because the file is published as it is, not as it should have been written.

pqRegistryHash

The genesis config carries the hash of the canonical Falcon validator registry. Two genesis files can produce the same block 0 hash and still differ in config, and a node whose genesis lacks this field rejects every anchor the moment it receives the anchor rules, while peering happily with nodes that have it.

So the genesis check for a node that judges anchors is the file hash, not only the block 0 hash. Compare with sha256sum before giving a node the anchor rules.

EVM fork schedule

Homestead through Shanghai at block 0, Cancun and Prague at timestamp 1780189051, Osaka at timestamp 1780220351, and the AERE milestone at timestamp 1783820272, whose first block is 9,189,161. Details and the caveat about upstream's futureEips are on Chain parameters.