XGRChain — Introduction

XGR Chain — Introduction

Document ID: XGRCHAIN-INTRO
Status: Draft
Last updated: 2026-02-07
Audience: Developers, node operators, auditors


What is XGR Chain?

XGR Chain (chain name: xgrchain) is an EVM-compatible blockchain network built using Polygon Edge as the base client stack.

Two important clarifications:

1) Bootstrap chain (not a fork):
XGR Chain starts from a custom genesis block and a clean state (block 0).
It does not inherit state or history from Ethereum mainnet (or any other chain). In other words, it is a new network with its own validator set, chain ID and parameters.

2) Open chain code vs. closed Engine:
The chain client / protocol implementation is intended to be made public (open source).
The Engine component remains closed source. Where protocol-relevant parameters are controlled by governance, the chain uses an on-chain registry contract (see EngineRegistry) so that network behavior remains verifiable on-chain even if some off-chain components are closed.


Quick facts (from genesis.json)

Parameter Value
Network name xgrchain
Chain ID 1643
Client basis Polygon Edge (EVM-compatible)
Consensus IBFT (Istanbul BFT), PoA
Validator signature scheme BLS (validator_type = bls)
Block time ~2.0 s
Epoch size 500 blocks
Block gas limit (genesis) 60,000,000
Bootnodes 1

Where to start

This documentation set is split into:

  • Chain Spec — a normative overview of the network parameters and protocol choices
  • IBFT Consensus — how finality and validator-based consensus work on XGR Chain
  • Genesis & Network Configuration — how genesis is structured and which parameters matter
  • Gas & Fees — described in XRC-GAS_Gas_Price_Behavior.md (already present)

Glossary

  • Bootstrap chain: a new network started from a genesis block (no inherited history).
  • Chain ID: the EIP-155 chain identifier used in transaction signing to prevent replay attacks.
  • IBFT: Istanbul Byzantine Fault Tolerance, a PBFT-family consensus protocol with immediate finality.
  • PoA: Proof-of-Authority; validators are permissioned entities.
  • BLS validators: validators identified by an ECDSA address but using BLS keys for aggregated commit seals.
  • EngineRegistry: an on-chain configuration registry contract used to store governance-controlled parameters such as minBaseFee.

Out of scope

This chain documentation intentionally does not document the closed-source Engine implementation internals.
Where the Engine affects consensus-critical or fee-critical behavior, the chain will reference on-chain parameters that are independently verifiable.