XGR Chain Technical Whitepaper
Version: 2.0.5
Valid from: 25 May 2026
Publisher: XGR Network GmbH
Network: xgrchain, chain ID 1643 / 0x66b
Baseline: public standalone node release xgr-node v2.0.5 and mainnet genesis xgr-network/XGR:genesis/mainnet/genesis.json.
Abstract
XGR Chain is an EVM-compatible Layer-1 blockchain using IBFT deterministic finality and delegated Proof of Stake validator participation from the XGR2.0 mainnet cutover. This document defines the current public technical baseline for node operators, validators, RPC operators, integrators and auditors.
1. Public baseline
| Item | Value |
|---|---|
| Node repository | xgr-network/xgr-node |
| Release tag | v2.0.5 |
| Mainnet genesis | xgr-network/XGR, branch main, genesis/mainnet/genesis.json |
| Operating mode | Public standalone chain node |
| xgrEngine / XDaLa requirement | Not required for normal public chain-node operation |
2. Network identity
| Field | Value |
|---|---|
| Network name | xgrchain |
| Chain ID | 1643 |
| Native decimals | 18 |
| Execution model | EVM-compatible |
| Finality model | IBFT deterministic finality |
| PoS activation | Block 5446500 |
| Genesis gas limit | 60000000 |
3. Execution model
XGR Chain uses Ethereum-style accounts, balances, nonces, contract code and contract storage. It supports contract deployment, contract calls, value transfers, event logs and receipts. Validators independently verify transaction execution, state roots, transaction roots and receipt roots before accepting finalized blocks.
4. Transaction model
| Transaction category | Code-level type |
|---|---|
| Legacy transaction | LegacyTx / 0x00 |
| Access-list transaction | AccessListTx / 0x01 |
| Dynamic-fee transaction | DynamicFeeTx / 0x02 |
| Internal system transaction | StateTx / 0x7f |
Replay protection uses chain ID 1643. Dynamic-fee transactions use effective gas price equal to min(maxFeePerGas, baseFee + maxPriorityFeePerGas).
5. Fork schedule
| Fork group | Activation |
|---|---|
| Homestead, Byzantium, Constantinople, Petersburg, Istanbul, London, LondonFix | Block 0 |
| EIP150, EIP155, EIP158, QuorumCalcAlignment, txHashWithType | Block 0 |
| EIP2930, EIP2929, EIP3860, EIP3651 | Block 1208500 |
| FeePoolSplit | Aligned to first PoS block, mainnet block 5446500 |
6. Consensus
XGR Chain uses IBFT for deterministic finality. The target block time is configured as 2000000000 ns, approximately two seconds.
| Phase | Type | From | To |
|---|---|---|---|
| Initial phase | PoA / BLS | 0 | 5446499 |
| Delegated PoS phase | PoS / BLS | 5446500 | ongoing |
In PoS mode, committed power is verified using effective voting power with weighted quorum ceil(2 * totalVotingPower / 3).
7. Delegated PoS and staking
| Parameter | Value |
|---|---|
| Staking contract | 0x0000000000000000000000000000000000001001 |
| Minimum validators | 4 |
| Maximum validators | 25 |
| Validator minimum self-stake | 200000 XGR |
| Validator total threshold | 2000000 XGR |
| Default delegator minimum | 10000 XGR |
| Maximum delegators per validator | 200 |
| PoS epoch size | 1000 blocks |
Validator participation depends on staking state, active validator status, BLS key validity, total stake and validator-set limits. Delegation pools can define delegation enablement, maximum delegated stake, minimum delegator stake and commission basis points.
8. Gas and fees
| Item | Behavior |
|---|---|
| eth_gasPrice | Returns latest header BaseFee |
| eth_maxPriorityFeePerGas | Returns 0 |
| Minimum base fee fallback | 100 gwei |
| FeePoolSplit | Active from block 5446500 |
| FeePool address | 0x000000000000000000000000000000000000fEE2 |
Receipts expose XGR-specific fee accounting through XGRFeeSplit. From FeePoolSplit activation, XGRFeeAccounting separates donation, immediate validator, pooled validator and burned fee accounting.
9. Public RPC
XGR Chain exposes Ethereum-compatible eth_*, net_* and web3_* RPC surfaces. Public PoS monitoring methods are eth_getPosValidatorsOverview and eth_getPosValidatorDelegators.
10. Networking
XGR Chain uses libp2p networking. Mainnet P2P port is 1478. The published bootnode is /ip4/217.154.225.157/tcp/1478/p2p/16Uiu2HAmGYfGAKCNzuzZPPauKk7FpqMk192hEmiQsqYTXvrga4Ck.
11. Operational boundary
Full and RPC nodes run with sealing disabled. Validator nodes run from a validator data directory with sealing enabled after validator onboarding. The node-operation runbook defines exact CLI commands for startup, join, pool configuration, activation, staking, unstaking and withdrawal.
12. Upgrade model
Protocol changes use deterministic block-height activation. Operators must not locally change chain ID, genesis, fork activation blocks, PoS activation values or validator-set rules for mainnet nodes.
Version note: This document supersedes technical whitepaper v1.0 as the current technical baseline.