Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.paxeer.app/llms.txt

Use this file to discover all available pages before exploring further.

​
Overview

HyperPaxeer is a sovereign Proof-of-Stake blockchain running on the Alexandria Fork (Cosmos SDK + CometBFT). It extends the standard EVM-on-Cosmos model with a second execution environment — the Argus Virtual Machine (AVM) — and four custom stateful/stateless precompiles that accelerate exchange-critical computation.

​
Dual-VM Design

┌──────────────────────────────────────────────────────────────────┐
│                       HyperPaxeer                        │
│                                                                  │
│  ┌──────────────────────────┐    ┌────────────────────────────┐  │
│  │     EVM OS Layer          │    │     Argus VM (AVM)         │  │
│  │     Alexandria Fork       │◄──►│     C++ runtime            │  │
│  │                           │    │                            │  │
│  │  Solidity contracts       │    │  ArgLang scripts (.arg)    │  │
│  │  Custom precompiles       │    │  Risk engine               │  │
│  │  (0x901 – 0x904)         │    │  Capital orchestration     │  │
│  │  x/evm, x/erc20 modules  │    │  Smart wallet lifecycle    │  │
│  │  JSON-RPC / gRPC / REST   │    │  .avm bytecode execution   │  │
│  └──────────────────────────┘    └────────────────────────────┘  │
│                                                                  │
│  CometBFT v0.37.4  ·  Cosmos SDK  ·  IBC  ·  x/paxoracle       │
└──────────────────────────────────────────────────────────────────┘
  • EVM OS — the blockchain shell: consensus, networking, EVM execution, standard Ethereum tooling
  • AVM — the value engine: capital allocation, drawdown policy, funded smart-wallet management
  • Communication boundary — on-chain interfaces IPaxSpotReader and IAllowanceProvider

​
Consensus

PropertyValue
EngineCometBFT v0.37.4 (Tendermint-based BFT)
ConsensusProof-of-Stake with instant finality
Block time~200 ms median (measured), ~2 s target
Validators7 active (US-East, EU-East, UK-East)
FinalitySingle-block (no reorgs under 2/3 honest assumption)
CometBFT’s PrepareProposal and ProcessProposal hooks allow validators to enforce fair transaction ordering at the consensus level — providing MEV protection without external infrastructure.

​
Custom Precompiles

Four precompiled contracts live at reserved addresses and execute native Go code at consensus speed:
AddressNameTypePurpose
0x901OROBResolverStatelessConvert basis-point offsets to absolute prices and back
0x902BatchClearingStatelessCompute uniform clearing price for sealed-bid auctions
0x903OracleAggregatorStatefulRead/write validator price submissions via x/paxoracle keeper
0x904PoFQScorerStatelessScore fill quality against oracle at execution time
Precompiles use the HyperPaxeer stateful-precompile framework (cmn.Precompile embedded struct with RunSetup for SDK context access). Solidity interfaces are at contracts/paxspot/src/interfaces/.

​
Cosmos SDK Modules

​
Standard Modules (Alexandria Fork)

x/evm, x/erc20, x/feemarket, x/vesting, x/inflation, x/epochs, x/staking, x/distribution, x/gov, x/ibc

​
Custom Module: x/paxoracle

Validator Oracle Module — validators submit prices via the 0x903 precompile’s submitPrice(bytes32, int256, uint256) method. The module stores submissions in a KV store and aggregates them:
  • GetMedianPrice: filters stale submissions (>15 blocks), requires minimum quorum, computes confidence-weighted median
  • IsValidator: verifies submitter is an active validator via x/staking keeper
  • Parameters: staleness_threshold (default 15 blocks), min_quorum (default 1)

​
Chain-Level Advantages

These capabilities are possible because HyperPaxeer is a sovereign chain, not a shared L1/L2:
  1. Custom precompiles — move expensive computation (batch clearing, oracle aggregation) to native Go. Near-zero gas for critical operations
  2. Transaction ordering control — PrepareProposal/ProcessProposal enforce fair ordering. No front-running at the consensus level
  3. Native gas policy — gas prices can be set to near-zero for exchange operations or subsidised for funded smart wallets
  4. IBC interoperability — native token transfers from Osmosis, Injective, Noble (USDC), and other Cosmos chains. No bridges, no wrapping
  5. Validator-integrated keepers — validators run keeper logic as sidecars, making conditional order execution a first-class chain service

​
Node Architecture

Nodes are deployed via the hpx CLI as Docker containers. Two node types:
TypePurposeConfiguration
RPCServe JSON-RPC, gRPC, REST, WebSocketFull indexing, all endpoints exposed
ValidatorProduce blocks, participate in consensusDefault pruning, optimised for consensus
Each node runs under /root/hyperpax-nodes/<name>/ with an FD Guardian sidecar that monitors file descriptors and auto-restarts on leak detection.

​
Endpoints per Node

ProtocolDefault Port
P2P26656
CometBFT RPC26657
REST API1317
gRPC9090
JSON-RPC (EVM)8545
WebSocket8546
Ports auto-increment for multi-node deployments on a single server.

​
Upgrade Process

Network upgrades are coordinated across all validators:
  1. Halt all validators at a target block height
  2. Back up chain state from one validator
  3. Distribute new binary as a Docker image
  4. Fix any app-hash or priv_validator mismatches
  5. Restart all validators simultaneously
The hpx CLI and validate/upgrades/ docs cover automated and manual upgrade procedures.

​
Resources

Network Status

Live validator health, node latency, and block timing

Run a Node

Deploy RPC or Validator nodes with the hpx CLI

Argus VM

Register architecture, ISA, gas model, and ArgLang

PaxSpot

Spot exchange leveraging all four precompiles