XGR Chain — Technical Whitepaper

Abstract

XGR Chain is an EVM-compatible Layer-1 blockchain operated by XGR Network. The current public technical baseline is xgr-node v2.0.5, a standalone public node release that operates the published XGR mainnet without private engine dependencies. The mainnet uses IBFT for deterministic finality and delegated Proof of Stake for validator participation from the XGR2.0 cutover.

This whitepaper defines the current public chain-level baseline: genesis identity, chain configuration, EVM execution, transactions, fork activation, IBFT finality, delegated PoS, staking, delegation, FeePool rewards, gas and fee accounting, public RPC, P2P networking, node operation boundaries and upgrade rules.

The document intentionally does not specify XDaLa workflow semantics, XRC application standards, private engine internals, UI behavior or business-process orchestration. These systems may build on XGR Chain, but they are outside the public chain-node baseline documented here.

Reading guide

• Validators and node operators: Sections 1, 3, 8, 9, 10, 11, 12, 15, 16 and 18.
• RPC operators and explorers: Sections 6, 13, 14, 15 and 17.
• Wallet and dApp developers: Sections 3, 5, 6, 7, 13 and 14.
• Auditors and protocol reviewers: Sections 1 through 14 and the appendices.

1. Release baseline and source hierarchy

1.1 Public release baseline

1.2 Source hierarchy

The active node implementation and the published genesis are authoritative. This whitepaper explains those sources; it does not override them.

1.3 Baseline distinction

The public chain node is the minimum verifiable infrastructure unit. It is not a UI package, not an XDaLa runtime and not a private application engine. A node operator can run the public mainnet by using the release binary and the mainnet genesis. Application-specific engines may interact with the chain, but they are not required to verify blocks, execute EVM transactions, participate in P2P propagation or join validator consensus.

2. Design goals

2.1 EVM compatibility

XGR Chain preserves the Ethereum developer model: externally owned accounts, contract accounts, bytecode execution, logs, receipts, gas accounting, transaction nonces and Ethereum-compatible JSON-RPC. Wallets and infrastructure tools integrate through chain ID 1643, normal transaction types and public RPC endpoints.

2.2 Deterministic finality

XGR Chain uses IBFT to provide deterministic finality. A finalized block is accepted after the required quorum commits it under the active validator-set rules. This property is relevant for wallets, bridges, explorers, exchanges and backend systems because a finalized block is not merely a probabilistic observation.

2.3 Delegated PoS with IBFT finality

The current mainnet combines IBFT finality with delegated Proof of Stake validator participation. IBFT remains the finality protocol; delegated PoS determines validator eligibility, stake weighting, validator economics and epoch-based validator-set behavior.

2.4 Predictable fee behavior

The fee model keeps Ethereum-style transaction fee fields while applying XGR-specific fee accounting. Under normal utilization, the base fee is clamped to a resolved minimum. Under high utilization, emergency base-fee behavior can raise fees according to defined parameters.

2.5 Operator reproducibility

The release model is designed so that a public operator can reproduce the node binary from the tag, validate the published genesis, run a node, compare RPC output and verify the consensus chain without relying on private infrastructure.

3. Network identity and genesis

3.1 Network identity

3.2 Genesis header

3.3 Mainnet bootnode

/ip4/217.154.225.157/tcp/1478/p2p/16Uiu2HAmGYfGAKCNzuzZPPauKk7FpqMk192hEmiQsqYTXvrga4Ck

Bootnodes are a discovery mechanism. They do not grant validator authority and do not determine the consensus validator set.

3.4 Network-defining values

Chain ID, genesis header, genesis allocation, fork schedule, IBFT configuration, PoS activation block, validator genesis data, bootnodes and configured protocol addresses define the network. Changing any of these locally creates an incompatible network view.

4. Node architecture

The proposer can choose transaction ordering, but cannot choose arbitrary state. Validators independently execute the same transactions against the same parent state and verify the same state root, transaction root, receipts root and consensus metadata.

4.1 Local runtime versus protocol state

Runtime options such as data directory, RPC bind address, P2P bind address, logging and sealing mode affect the local node. They do not redefine protocol rules. Protocol rules are derived from release code and the published chain configuration.

5. EVM execution model

1. The proposer selects pending transactions.
2. The proposer builds a candidate block on the parent state.
3. Transactions execute sequentially under active fork rules.
4. Account balances, nonces, storage and contract state are updated.
5. Logs and receipts are generated.
6. Gas usage and fee accounting are applied.
7. Header roots are committed.
8. Validators independently verify the block.
9. IBFT finality is reached after quorum commit.

XGR Chain preserves Ethereum-style receipts and logs for normal EVM execution and emits XGR-specific fee-accounting logs for correct explorer display.

6. Transaction model

TxPool admission is local node state. Inclusion and finality are separate from local txpool visibility.

7. Fork schedule

XGR Chain uses deterministic block-height fork activation. A fork is active when blockNumber >= configuredForkBlock.

8. IBFT consensus and finality

weightedQuorum = ceil(2 * totalVotingPower / 3)

In PoS mode, the consensus layer verifies committed voting power rather than merely counting validators. This preserves IBFT finality while allowing stake-weighted participation.

9. Delegated Proof of Stake

Delegated PoS is active from block 5446500. It defines validator eligibility, active stake, delegation, validator selection, uptime-sensitive reward weighting and staking lifecycle semantics.

Normal validator eligibility depends on staking active state, minimum self-stake, total active stake threshold, BLS public-key validity and selection within the maximum validator count. Current consensus membership, staking active state and epoch-effective stake are separate concepts.

10. Staking contract and delegation model

A validator position is created through self-staking and BLS public-key registration. A delegator stakes to a validator pool. The validator pool controls whether delegation is enabled, the pool cap, minimum delegator stake and commission basis points.

11. Epoch, micro-epoch and snapshot model

microEpochSize * macroEpochMicroFactor = 25 * 40 = 1000 blocks

Join and deactivation effects are interpreted through epoch boundaries. Epoch snapshots freeze validator membership, validator stake, staker stake and delegation effectiveness for a given accounting period.

12. FeePool, rewards and slashing

From FeePoolSplit activation, part of validator-fee accounting is pooled at 0x000000000000000000000000000000000000fEE2. At epoch finalization, the FeePool balance is distributed according to effective validator weights.

The documented default slash rate in the current model is 20 bps. Slashing is bounded by protocol rules, emergency no-slash behavior and available staking balance.

13. Gas and fee behavior

totalFeeRaw = gasUsed * effectiveGasPrice
burnedApplied = min(totalFeeRaw, 1000 gwei)
remainingAfterBurn = totalFeeRaw - burnedApplied
donation = remainingAfterBurn * donationPercent / 100
validator = remainingAfterBurn - donation

Every normal transaction appends an XGRFeeSplit(uint256,uint256,uint256) log at 0x000000000000000000000000000000000000fEE1. With FeePoolSplit active, the node also appends XGRFeeAccounting(uint256,uint256,uint256,uint256). Explorers should display fee components from actual receipt logs.

14. JSON-RPC surface

eth_getPosValidatorsOverview
eth_getPosValidatorDelegators

15. P2P networking

The published mainnet bootnode is /ip4/217.154.225.157/tcp/1478/p2p/16Uiu2HAmGYfGAKCNzuzZPPauKk7FpqMk192hEmiQsqYTXvrga4Ck.

16. Node operation model

Exact CLI examples are maintained in the node-operation runbook. This whitepaper defines the technical model and public baseline.

17. Access-control and permission boundaries

18. Network upgrades

Network-defining changes require coordinated release management. Consensus, staking, fee, validator-set and fork changes are not local operator preferences. They require a compatible node release, deterministic activation data and validator/operator coordination.

The XGR2.0 delegated PoS cutover is active from block 5446500. Future protocol changes must be documented as explicit network upgrades.

19. Appendices

Appendix A — Key constants

Appendix B — Current document set

• XGR Chain introduction
• XGR Chain specification
• XGR Chain genesis and configuration reference
• XGR Chain IBFT consensus reference
• XGR Chain node-operation runbook
• XGR Chain staking and delegated PoS model
• XGR Chain staking / PoS JSON-RPC endpoint reference
• XRC-GAS gas price and fee behavior reference
• XGR Chain networking and P2P reference
• XGR Chain access-control and permission-boundary reference
• XGR Chain network-upgrade and hardfork process

Version note. This document supersedes technical whitepaper v1.0 for the current public technical baseline. Version v1.0 remains part of the historical whitepaper archive and is listed with its own validity period.