Root of trust.
Everything a third party needs to connect to the network, reproduce its state and check that what this explorer shows is what the validators signed.
Identity of the chain
The genesis block fixes the chain ID, the consensus rules and the first validator set. Its hash is the root every later block links back to.
Validator set
Four validators written into the genesis block. Changes to the set require a vote of more than half of the existing validators (with four: 3 of 4; the White Paper’s requirement of more than two thirds gives the same number at n = 4 but must be enforced separately for larger sets) and are visible in every block header.
| Entity | Role | Data centre | Address | In genesis | Current set |
|---|
One network, many registers.
Every company has its own register on Blockchain Genesis. All registers share one network and one validator set, and every validator checks every transaction of every register. That is what makes a record impossible to forge – it is not duplication.
| Validators | 4 to 50 for the whole network – the limit of BFT consensus set out in White Paper v1.1, not a number per company. Validators are licensed network operators; a company does not need validators of its own. |
| Register of a company | A separate set of contracts: token, identity register, compliance rules, agents and its own code authority. Today Token XIX (XIXOIO, a.s., CZ) and Token 19 (XIXOIO LTD, UK). A transfer in one register cannot touch the other, and a code change in one does not change the other. |
| Own network (exception) | Where a company needs separate data, a jurisdiction of its own or high volume, it can run its own Genesis instance with its own validators. Into the main network it writes only fingerprints of its state (anchors); the main network notarises them and does not validate the same transactions a second time. |
| Open point | No company runs its own instance today. Whether separation of registers within one network meets the register requirements under the law of the issuer’s state is for a lawyer or the regulator to confirm. |
Consensus parameters
Pinned software
Topology and permissioning
Validators accept connections only from nodes on their allowlist and have no public inbound traffic; peer-to-peer traffic runs on a private network. The observer holds a full copy of the chain and is the only node that serves the public.
| Entity | Role | Data centre | Provider | Head seen by observer |
|---|
What this network is not – yet.
The limits of the current setup, stated plainly. They are part of the record, not small print.
| Status | Built and running as a testnet since 23 Oct 2026 – every block, anchor, snapshot, backup and recovery test is verifiable here. Not yet production (LIVE), not independently AUDITED and not REGULATOR-ACCEPTED. Genesis One OS writes its control-plane decisions here and BlockID issues the identity claims the token contracts check – both on the testnet. The book Regulovaná tokenomika (as of 8 Aug 2026) still described these as designs; this network is the build that followed. |
| Independence | All four validator keys are derived from one operator’s seed and all nodes run on one cloud provider (Hetzner, three locations). This is a consortium under common control, not independent decentralisation. Production requires separate key custody (HSM) per entity, separate failure domains and an independently verified ownership structure of each validator. |
| Resilience | QBFT with n = 4 tolerates exactly one faulty validator (n ≥ 3f + 1), quorum ⌈2n/3⌉ = 3. Four online: normal operation. Three: running with zero reserve – a trigger for remediation, not a resilient state. Two or fewer: no new block can be finalised. Data survival and consensus availability are different things: any surviving node keeps the full history, but no single node can create new canonical history. |
| Client | All nodes run one client, Besu. The historical second implementation, GoQuorum, was archived on 5 June 2026, so there is no client diversity. The Blockchain Genesis White Paper v1.1 described IBFT 2.0; this network uses QBFT, which the Besu documentation recommends for new private networks. |
| Signing keys | The anchoring service that writes audit anchors runs on the observer host and holds the anchor-writer key, so the observer is not a purely read-only node. It is scheduled to move to a separate signing service; the key can be revoked by governance at any time. |
| Recovery | A full backup and a recovery test (recomputing every daily Merkle root) run every day and are anchored on chain. Backups currently stay with the same provider; off-site storage is pending. |
| Monitoring | This explorer shows the state of the chain; it is not a security monitoring, alerting or supervisory service. |
| Finality | A block is final at protocol level once a quorum has committed it. Protocol finality is not operational, accounting or legal finality: for those, the law of the issuer’s state and the relevant register or accounting decide. |
Run your own observer
Auditors, supervisors and counterparties can run a read-only node and verify every block independently. The node needs the files above and a place on the allowlist.
- Download Besu and the Java runtime from the links above and check their SHA-256 against the values on this page.
- Place
genesis.jsonandconfig.tomlnext to the node; keepdata-storage-format="FOREST"if you intend to serve historical queries. - Generate a node key and send us its enode public key. We add it to the observer’s allowlist and open peer-to-peer traffic for your address.
- Start the node with the observer as bootnode; it will download and verify every block from genesis.
- Run
verify-block.mjsagainst your own node instead of ours — the result must be identical.
Requests for observer access and all technical questions:
ops@blockgns.com
On request, a supervisory authority can additionally be given access to the full explorer (addresses and amounts, pseudonymised) and to signed state snapshots. No such access has been granted to date; offering it does not imply supervision or approval.