Anatomy
What the Genesis Block Contains
The genesis block is the first record on the TIP Network and the origin proof that every later record derives its authority from. It fixes the founding Verification Provider, the founding nodes, the founding TIP-IDs and the launch parameters, and one hash binds them all to the network's starting state.
Every TIP-ID issued, every trust score computed, every VP accredited traces its chain of trust back to the genesis block.
protocolchain_id tip-mainnet-v2
Names the network, protocol version 2.0.0, the issuer and the link to the specification.
signed_atJuly 14, 2026, 02:34 UTC
The moment the founding record was signed. Network consensus time starts at 00:00 UTC that day.
founding_vpThe AI Lab, United States
The first Verification Provider and its ML-DSA-65 public key. This is the key that signs the block.
founding_nodes3 nodes
US East, US West and Mumbai. Each node's public key carries the founding VP's approval signature, and together they form the first consensus committee.
genesis_ring13 founding TIP-IDs
Twelve people and The AI Lab, from the United States, India, the United Kingdom and Canada. Each entry holds a public key, a zero-knowledge proof of uniqueness and the VP's signature.
protocol_constantsScore weights, tiers, limits
Trust score caps and tiers, rate limits, jury rules and consensus timing at launch. Later changes go through governance, not through this block.
genesis_hashSHAKE-256, 32 bytes
The digest of the founding payload (protocol, VP, nodes, ring and constants) in canonical JSON. Change one value and the hash changes.
signatureOne ML-DSA-65 signature
The founding VP signs the genesis hash. Any node can check it against the public key in the block.
Check it yourself
The genesis block is public. Read genesis.json in the TIP Protocol repository, keep its eight founding fields (version, protocol, notes, founding_vp, founding_nodes, genesis_ring, genesis_ring_keys and protocol_constants), serialize them as JSON with sorted keys and no spaces, and hash the result with SHAKE-256 at 32 bytes. You get this genesis hash.
d4666ce12479a5bc3ce074f8cb71f18a81d0d8011bb0552fe55513a9aa9ad52cCryptographic ceremony
How the Genesis Block is Signed
One key signs the genesis block, the ML-DSA-65 key (post-quantum, FIPS 204) of the founding Verification Provider, The AI Lab. The same VP signed the approval of each founding node and each founding TIP-ID recorded inside the block.
The signature covers the hash of the whole payload. Change any field, even one score weight, and the hash changes, the signature stops verifying, and every node rejects the block.
Payload assembly
The payload gathers the protocol declaration, the founding Verification Provider, the three founding nodes, the 13 founding TIP-IDs and the protocol constants.
Canonical serialization
The payload is serialized as canonical JSON with sorted keys at every level, so every node computes exactly the same bytes.
SHAKE-256 digest
The canonical JSON is hashed with SHAKE-256 (FIPS 202) to a 32-byte digest. This digest is the genesis hash.
ML-DSA-65 signing
The founding VP, The AI Lab, signs the genesis hash with its ML-DSA-65 private key (FIPS 204), a post-quantum signature scheme.
Node verification
Every node recomputes the hash and checks the signature when it starts. A node holding a block with a different hash is on a different network and cannot join this one.
Network publication
The block became the root of the DAG on July 14, 2026. Every later record in the network traces its authority back to it.
By design
What the Genesis Block Does Not Contain
No private keys
Only public keys are recorded. No private key appears anywhere in the block.
No biometric data
No face scans, identity documents, or addresses. Each founding TIP-ID carries a display name, a region, and a zero-knowledge proof that the person enrolled once, never the biometric itself.
No commercial terms
License fees and pricing are governance decisions, not protocol parameters. They can evolve. The genesis block cannot.
No expiration
The genesis block is permanent by design. Upgrades and parameter changes are new records that reference it. They never modify it.