Skip to main content

Network Upgrades

This page documents how protocol upgrades reach the XPHERE network, who is obliged to act, and how each participant can verify that an upgrade took effect. It is written for node operators, miners, Union validators, exchanges, and integrators.

How Upgrades Activate​

XPHERE upgrades activate at a deterministic block height. The client carries the activation height — for the xpHash fork it is read from the XPHASH_FORK_BLOCK setting, so you can inspect and confirm it on your own node — and every node applies the new rules from that block onward and the old rules to every block before it.

This has three consequences that matter operationally:

PropertyWhat it means for you
Full history is preservedThe chain is not reset and chaindata is not re-downloaded. Pre-upgrade balances, transactions, and blocks remain valid.
The boundary is verifiableThe activation point is a single, public block number. Anyone can check it on XPScan or the Tamsa Explorer — there is no ambiguity about when the rules changed.
Upgrading is time-bound, not optionalFor a consensus-breaking change, every affected operator must be running a compatible client before the activation height. Work produced by an outdated client after that height is not accepted by the network.

This is exactly how the xpHash hard fork activated: a fork height was published for Testnet, soaked there, and then activated at a separate height on Mainnet.

note

Not every upgrade is consensus-breaking. Client releases that only change performance, logging, RPC ergonomics, or tooling do not need a fork height and can be adopted on your own schedule. Check the release notes on GitHub for which category a release falls into.

Upgrade History​

UpgradeScopeTestnet blockMainnet blockStatus
xpHash hard forkProof Chain PoW algorithm327,4001,740,000Active — completed on both networks

No further hard fork activation height has been announced. Planned protocol work is described in the whitepaper roadmap; when a height is announced for any of it, it will appear in this table.

Who Is Affected by What​

Miners​

Miners are the group most directly exposed to Proof Chain changes, because a consensus-breaking PoW change invalidates work produced by non-compliant hardware or software.

  • Mining on XPHERE today requires an xpHash-capable ASIC — the IceRiver XP0. The legacy CPU software miner is deprecated and cannot produce valid xpHash blocks.
  • Keep at least two mining endpoints configured (sgp-mining, bkk-mining, hkg-mining, idn-mining) so an endpoint outage around an activation height does not stop your hashrate.
  • After an activation height passes, confirm your ASIC dashboard still shows accepted shares, and confirm payouts to your address on an explorer.

See Mining — Getting Started and the xpHash Hard Fork guide.

Endpoint Node (XEN) Operators​

Endpoint Nodes serve RPC and follow the chain, so they must be able to validate post-activation blocks even when they produce none.

  • Replace the xen binary with the release that carries the new activation height, from XEN Package Downloads.
  • The xpHash fork was applied in place — no genesis re-initialisation and no chaindata re-download were required.
  • After restart, confirm the head block advances past the activation height.

Setup and operations are covered in Install XEN and XEN CLI Commands.

Union Validators​

Union members validate blocks on the Main Chain under optimized PBFT consensus.

  • A Proof Chain change does not necessarily alter Main Chain consensus. xpHash, for example, did not change validator consensus rules — but validators were still advised to update their xen binary so they stayed compatible with headers produced by upgraded miners.
  • Treat every announced upgrade as applying to you until the announcement says otherwise, and complete the update before the activation height.
  • Union membership carries governance participation — one vote per member, with the XPHERE Foundation holding the tie-breaking vote. The Foundation has not published a separate on-chain voting procedure or threshold specific to activating protocol upgrades; do not assume one exists.

See Validator Node and Union Staking.

Exchanges and Integrators​

Exchanges, custodians, bridges, and indexers should plan around the activation height rather than around a wall-clock time, since block production rate determines when the height is reached.

  • Upgrade any self-operated Endpoint Nodes before the activation height. If you depend on a third-party RPC provider, confirm with that provider that they will have upgraded in time.
  • Check the announcement for whether the upgrade touches account state, RPC surface, or the chain ID. The xpHash fork was scoped to the PoW function only — economic parameters, RPC, and account state were unaffected — but that scope is specific to that upgrade and must be re-read for each one.
  • Current chain IDs and endpoints are listed in Network Information. Verify the chain ID directly against the live RPC with eth_chainId before resuming signing in production.
  • The Foundation does not publish a network status page. Use the explorers and the official channels below to confirm network state.

Where Upgrades Are Announced​

Upgrade announcements — including activation heights, affected components, and required operator action — are published on the official XPHERE channels and reflected in these documentation pages. There is no other authoritative source.

ChannelAddress
Telegramt.me/Xphere_official
Xx.com/Xphere_official
Discorddiscord.com/invite/xphere
GitHub (releases and source)github.com/xpherechain
Documentationdocs.x-phere.com
caution

The Foundation has not published a fixed advance-notice period, upgrade calendar, or service-level commitment for network upgrades. Do not plan against an assumed notice window — subscribe to the channels above and act on the announcement itself.

For questions that are not answered by an announcement, contact Contact@X-phere.com. Suspected security issues should go to security@x-phere.com rather than a public channel.

Pre-Upgrade Checklist​

Run this sequence for any announced consensus-breaking upgrade.

1. Verify your client version. Confirm the binary you are running is the release named in the announcement, and that it came from the official Downloads or GitHub source.

2. Confirm the configured activation height. Check that your client actually carries the announced height rather than assuming the upgrade shipped. For the xpHash fork the configured height is exposed as:

xen --help | grep -i fork

Reference clients read the height from an environment variable:

XPHASH_FORK_BLOCK=327400   # testnet
XPHASH_FORK_BLOCK=1740000  # mainnet

3. Rehearse on Testnet. The xpHash fork activated on Testnet before Mainnet, which made Testnet the place to validate configuration, hardware, and integration first. Where an announcement gives both heights, rehearse against the Testnet height before the Mainnet one arrives. Testnet parameters are in Network Information.

4. Watch for the activation block. Track the head block against the announced height:

curl -X POST https://en-hkg.x-phere.com \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

Cross-check the same height on XPScan or the Tamsa Explorer.

5. Confirm acceptance after activation. Once the height has passed, verify that your node's head advances monotonically, that a miner's blocks are still accepted rather than orphaned, and that a validator is still proposing and finalising. If your node stalls at the activation height, you are almost certainly running a pre-upgrade binary.

Rollback Stance for the xpHash Fork​

For the xpHash fork the Foundation stated that there is no rollback: if a critical bug were found after activation, it would coordinate a follow-up fork — a new upgrade with its own published activation height — rather than reverting blocks already produced. This is documented in the xpHash Hard Fork guide.

That is the only upgrade for which a rollback position has been published; the Foundation has not stated a general stance covering future forks, so do not assume one. For the xpHash fork the practical implication was that recovery from a missed upgrade ran forward: update the client and resync from the network, rather than waiting for the chain to return to a prior state.

See Also​