Versioning

How Paxeer Network names and versions its forks, protocol releases, and binary builds

Naming Hierarchy

Paxeer Network uses a four-layer naming scheme. Each layer changes at a different cadence and carries a distinct naming convention.

┌─────────────────────────────────────────────────┐
│              HPXEER NETWORK                      │
│              The chain. The ecosystem.           │
│                                                  │
│  ┌───────────────────────────────────────────┐   │
│  │  Fork: ALEXANDRIA                         │   │
│  │  Consensus era. Cryptographic protocol.   │   │
│  │                                           │   │
│  │  ┌───────────────────────────────────┐    │   │
│  │  │  Version: HYPERPAXEER             │    │   │
│  │  │  Features. Precompiles. Modules.  │    │   │
│  │  │                                   │    │   │
│  │  │  ┌───────────────────────────┐    │    │   │
│  │  │  │  Binary: hyperpaxd_2.0.3  │    │    │   │
│  │  │  │  VM. Validator software.  │    │    │   │
│  │  │  └───────────────────────────┘    │    │   │
│  │  └───────────────────────────────────┘    │   │
│  └───────────────────────────────────────────┘   │
└─────────────────────────────────────────────────┘

---

Layer 0 — Paxeer Network

The chain, the native HPX token, and the community. This is the permanent identity that never changes regardless of forks, versions, or binary releases. Everything else is a version of Paxeer Network.

---

Layer 1 — Fork (Protocol Era)

Forks are rare, landmark events that change the fundamental cryptographic or consensus protocol of the chain — a shift in consensus mechanism, new signature schemes, a core re-architecture. Each fork defines an era.

Naming convention: Ancient seats of knowledge and civilisation.

Fork	Status	What Changed
Alexandria	Active	Migration to Proof-of-Stake EVM, CometBFT consensus, dual-VM architecture (EVM OS + Argus VM)

Future fork names follow the same theme: Persepolis, Carthage, Byzantium, Petra, Thebes.

Format: Alexandria Fork or just Alexandria In config: fork: alexandria

A fork changes the rules of the chain itself. Think of it as a constitutional amendment — everything built on top must adapt.

---

Layer 2 — Network Version (Feature Release)

Network versions are periodic protocol upgrades that add new capabilities — custom precompiles, Cosmos SDK modules, on-chain features, governance parameters. They happen within a fork era and do not change the underlying consensus or cryptographic primitives.

Naming convention: Hyper prefix + evocative compound noun.

Version	Status	What Changed
HyperPaxeer	Active	Initial Alexandria-era release — EVM OS, Argus VM integration, x/paxoracle module, precompiles 0x901–0x904, PaxSpot contracts

Future version names: HyperNexus, HyperForge, HyperPrime, HyperVault.

Format: HyperPaxeer In config: network_version: hyperpaxeer Chain ID: hyperpax_125-1

---

Layer 3 — Binary Release (Runtime)

Binary releases are the actual compiled software that validators and RPC nodes run. They cover VM patches, validator-side optimisations, node infrastructure changes, and bug fixes. Multiple binary releases can ship within a single network version.

Naming convention: hyperpaxd executable plus semantic runtime version.

Release	Status	What Changed
hyperpaxd_2.0.3	Active	Production binary from hyperpaxeer-os with CronosRelease precompiles, CometBFT v0.38.15, x/paxoracle keeper, and the stateful precompile framework

Format: hyperpaxd_<version> In config: binary_version: 2.0.3 Binary executable: hyperpaxd

---

Current Status

Layer	Name	Convention
Network	Paxeer Network	Permanent identity
Fork	Alexandria	Ancient seats of knowledge
Version	HyperPaxeer	Hyper + compound noun
Binary	hyperpaxd_2.0.3	hyperpaxd + runtime version

Status badge: Alexandria / HyperPaxeer / hyperpaxd_2.0.3

---

How Upgrades Work

Fork Upgrade

1. Governance proposal defining the new consensus/crypto changes
2. All validators halt at a coordinated block height
3. Chain state backed up from one validator
4. New fork binary distributed as Docker image
5. All validators restart simultaneously on the new fork

Network Version Upgrade

1. New precompiles, modules, or features implemented
2. Binary updated to include new features
3. Coordinated upgrade at target block height
4. Chain continues with new capabilities active

Binary Release

1. VM or validator software patch prepared
2. Docker image published to registry
3. Operators update via hpx CLI: re-run the installer
4. Existing chain data preserved, no coordination required for non-breaking changes

---

Resources

Architecture

Dual-VM design and precompile framework

Run a Node

Deploy nodes with the hpx CLI