xPrivFi
Architecture

How the xPrivFi protocol is wired

A small, deterministic Layer-1 protocol with a browser-based mining game on top. Consensus lives entirely in the node; the HexGrid pool and miner are an optional L2.

Architecture last updated: Nov 27, 2025
Layer-1: XPF Chain
Transparent base layer, deterministic consensus.
  • Account-based ledger storing balances and nonces.
  • Blocks contain a header and a list of validated transactions.
  • Block headers are secured by RandomHash (iPoW) with CP-Diff v1.0.
  • Consensus rules are enforced by every node – no trusted servers.
  • Monetary policy: hard cap of 1,000,000 XPF, fixed reward schedule.
L1 only Transparent balances Deterministic rules
Layer-2: HexGrid Mining Game
Browser UX that wraps block production into rounds.
  • Pool server tracks the current round, registered miners, and chosen tiles.
  • Between 200 and 890 miners join each round.
  • All participants compute RandomHash work in the browser via JavaScript.
  • The pool selects exactly one winning miner per round.
  • The node only sees the final winning block – not the game logic.
Optional L2 Equal-chance rounds 1 winner → 1 XPF
Consensus

RandomHash iPoW + CP-Diff v1.0

Every block is decided by a canonical proof-of-work over a clean header. The HexGrid game never bypasses the consensus rules.

1. Canonical block header
What miners actually hash.
  • Height
  • Previous block hash
  • Timestamp
  • Difficulty bits
  • Nonce

A helper function builds the header into canonical bytes. Miners never hash JSON; they hash this fixed binary or JSON representation, so all nodes interpret the header exactly the same way.

2. Proof-of-Work function
RandomHash (iPoW) – CPU-friendly, memory-bounded work.
  • Given header bytes and a nonce, RandomHash derives a pseudorandom, memory-hard hash.
  • The difficulty target is calculated by CP-Diff v1.0 to aim for ~6-minute blocks.
  • A block is valid only if powHash <= target.
  • This check is performed independently by every full node, including blocks originating from the HexGrid pool.
3. Block reward & supply
Monetary policy enforced in consensus.
  • Total supply hard-capped at 1,000,000 XPF.
  • Consensus code recomputes the expected reward from height (not from a field proposed by the miner).
  • Half the supply (500,000 XPF) is mineable over multiple years; the rest is reserved and accounted for in state.
  • Nodes refuse any block whose effective reward does not match the schedule.
Mining UX

HexGrid rounds and equal-chance mining

The mining experience is moved into a pool + browser layer so the base protocol can stay small and predictable.

4. HexGrid pool service
Stateful HTTP service running next to a full node.
  • Maintains round state: lobby → active mining → cooldown.
  • Enforces a hard cap of 200–890 participants per round.
  • Tracks which tile each miner chose (visualized in the browser UI).
  • Receives work shares from miners, tagged with tile + miner ID.
  • Selects exactly one winning miner per round – even if hundreds chose the same tile.
  • Submits the winner’s block to the node via standard RPC.

From the node’s perspective there is nothing special: it still only accepts blocks that satisfy RandomHash iPoW and the monetary rules. All “game” logic is off-chain.

5. Browser miner
JavaScript client + HexGrid UI.
  • Connects to the pool API to fetch current round status.
  • Lets the user choose a tile and lock in their position for the round.
  • Runs the RandomHash mining loop in the browser, submitting work shares.
  • Shows countdowns, round transitions and winner results in real time.
  • Hardware differences do not influence the chance of winning: all participants have the same probability inside a round.
Future Privacy Layer

CP-Shield (not implemented yet)

The current chain is fully transparent. Privacy is a clearly separated future layer, not partially-implemented or implied.

Design goals (research only)
What CP-Shield aims to become.
  • Introduce confidential “notes” represented by commitments instead of visible balances.
  • Maintain a global nullifier set to prevent double-spends in the shielded pool.
  • Support optional view keys for selective disclosure and audits.
  • Validate shielded transfers using zero-knowledge proofs (Groth16 / Plonk-family or similar).
  • Keep the monetary rules and base consensus unchanged – privacy is an additive layer, not a redesign of the core supply.

Until CP-Shield is fully designed, implemented, and audited, XPF should be treated as a transparent Layer-1 chain with a strong privacy roadmap – not as a completed privacy coin.

Ecosystem

Position in the broader stack

xPrivFi’s sole on-chain responsibility is to run XPF as scarce digital cash. Everything else lives around it.

Around the core protocol
  • Wallets – hold keys, build transactions, talk to the node RPC.
  • Explorers – read-only views on the public subset of chain data.
  • HexGrid Miner – turns mining into an accessible browser game.
  • XPRIVU (future) – satellite meme token on external platforms, used only for attention and community, never for protocol control.

This separation keeps the base protocol small and serious, while still allowing experimentation and growth at the edges of the ecosystem.