v1.0.0 · Rust · MIT licensed
Xperova is a purpose-built layer-1 blockchain. Its proof-of-work consensus, account model, state layer, peer-to-peer networking and native XPERO token are implemented from first principles in a single Rust workspace — written from scratch rather than forked, and deliberately without a virtual machine.
01 — Network
Each network is fixed by a chain specification whose genesis hash is the network's identity. Nodes verify that hash during the handshake, so a node configured for the wrong network disconnects immediately rather than forking quietly.
No public Xperova network is running yet. The mainnet specification exists in the repository (chain id 7777) but ships with an empty bootnode list, and no genesis launch has taken place. The panel below queries a node you run — it shows no numbers until you connect one.
Start a node with xperovad run --rpc-listen 127.0.0.1:8645 and press
Connect. Browsers block plain-HTTP requests from an HTTPS page, so a local
node reads correctly when this page is served over http://localhost,
or when the node sits behind HTTPS.
The canonical specification. No premine, no allocation — every XPERO must be mined.
Identical rules on a separate chain id, at lower difficulty. Coins carry no value.
A local network with trivial difficulty, optional genesis allocation, and a one-command three-node script.
02 — Engineering philosophy
Every feature a chain adds is a rule two implementations must agree on byte for byte. Xperova keeps that set of rules small enough to state in a single document — and then states it.
Xperova moves value and carries a short memo. Leaving out programmable execution removes the largest single source of consensus bugs and keeps the validity rules compact: a block either applies cleanly or is rejected in full. There is no notion of an included-but-failed transaction.
Consensus objects are never hashed or signed through a general-purpose serialisation format. They use one deterministic encoding — fixed-width big-endian integers, length-prefixed byte strings — so every value has exactly one valid byte representation, and decoders reject trailing bytes and enforce length limits before allocating.
The consensus crate has no networking and no storage, which is what makes every rule directly testable. The layers above it — storage, chain, networking, RPC, mining — depend downwards only.
The state root is a commitment to the set of accounts, not to the history of writes: it does not depend on insertion order. Trie nodes are content addressed, so any historical root stays queryable and a chain reorganisation needs no state unwinding — the new head simply names a different root.
An account is a balance and a nonce. That is simpler to index and produces smaller transactions than an unspent-output set; the cost is that ordering matters within one sender's stream, which is exactly what the nonce is for.
The whitepaper closes with what the design does not do: a young chain is cheap to reorganise, blocks are gossiped whole, the state trie is never pruned, and the RPC interface is unauthenticated. A specification that only lists strengths is not much of a specification.
03 — Technology
Eight components, each with one job. All of them are specified in the
whitepaper and implemented in the xpero-core crate.
SHA3-256 applied twice over the canonical header encoding. Because the nonce is part of that encoding, a block's identity and its proof of work are the same value.
Accounts live in a trie keyed by the hash of the address. Empty subtrees are never stored, and a subtree holding exactly one key collapses to a single leaf.
Recoverable ECDSA: the sender is recovered from the signature rather than carried alongside it. High-s signatures are rejected, so a third party cannot alter a transaction's id without invalidating it.
Addresses carry the xpero prefix and a BIP-350 checksum that catches every error of up to four characters — and rejects the older bech32 constant, so an address from another chain cannot be mistaken for one of these.
The network identifier sits inside the signed payload. A transaction signed for one network can never be replayed on another — including on any network created later.
Every 120 blocks — roughly an hour — the target is rescaled by how far the window ran from its intended span, clamped to a factor of 4× so one window of manipulated timestamps cannot move difficulty far.
A balance and a nonce per address. Untouched accounts occupy no storage; the nonce must match exactly, which makes every transaction naturally single-use.
Length-prefixed TCP frames, a handshake that checks the genesis hash, and pull-based sync: a node behind its peer sends a block locator and converges on the fork point in a handful of round trips.
04 — Token
There is one way coins are created: mining a block. The miner named in a block's header receives the subsidy plus that block's fees. No foundation allocation, no team unlock, no pre-sale — the mainnet genesis block carries no balances at all.
Native token. 8 decimals; the base unit is the zep, and 1 XPERO is 100,000,000 zep.
Initial block reward, in XPERO, paid to the miner of each block.
Blocks between halvings — approximately two years at 30-second blocks.
Maximum supply in XPERO: the exact sum of the halving schedule, not a rounded figure.
| Era | First block | Reward (XPERO) | Issued in era | Cumulative supply |
|---|
The subsidy is an integer number of zep, and integer halving truncates. Summing the schedule exactly gives 8,399,999,972,700,000 zep — 83,999,999.727 XPERO, about 0.273 short of the round figure. The constant in the code is the exact sum, and a test asserts the two agree.
A transaction pays a minimum of 0.0001 XPERO, plus 0.000001 XPERO per memo byte. That floor is a consensus rule — a block containing an underpaid transaction is invalid. Fees move existing coins to the miner; nothing is burned, and nothing is minted.
What this page does not state. XPERO has no price, market capitalisation, exchange listing, staking yield, investor allocation or team allocation, because none of those exist. The circulating supply is whatever the chain has mined, and today no public chain is running.
05 — Architecture
From a signature on one machine to a state root committed in a block header, with the crate responsible for each step.
06 — Developers
Two binaries: xperovad, the node, and
xpero-cli, the wallet and client. Rust 1.82 or newer;
no other toolchain required.
# build both binaries
cargo build --release
export PATH="$PWD/target/release:$PATH"
# create an account to mine into
xpero-cli wallet new miner
# start a development chain that mines to it
xperovad init --home ~/.xperova-dev --network devnet
xperovad run --home ~/.xperova-dev --mine \
--miner-address <your-xpero1-address># three local nodes, two of them mining
make devnet # or ./scripts/devnet.sh start
docker compose up # the same, in containers
# talk to a node
xpero-cli info
xpero-cli balance --account miner
xpero-cli send --to xpero1... --amount 25 --account miner
# or over JSON-RPC
curl -s localhost:8645/status07 — Engineering
These are facts about the codebase and its test suite as of v1.0.0. They describe engineering discipline — they are not a security guarantee, and Xperova has not been audited.
Bech32m against the BIP-350 vectors; rejection of malleable high-s signatures; trie proofs of presence and of absence; difficulty retargeting in both directions; block execution determinism; mempool nonce and balance accounting; chain reorganisation; two-node propagation and catch-up sync over real sockets; and the JSON-RPC surface driven end to end over HTTP.
On a local three-node devnet, two competing miners produced blocks and all three nodes converged on the same chain head at block 457. Difficulty retargeted upward as designed, a wallet-signed transfer submitted to one node was mined by another, fees and balances reconciled exactly, and the circulating supply matched the emission schedule to the zep.
Thirteen sections covering the canonical encoding, cryptography, accounts and the state trie, transactions, blocks, proof of work, fork choice, the peer-to-peer protocol, the mempool, issuance — and a closing section on what the design does not do.
08 — What's next
There is no published roadmap and no committed timeline. What follows is drawn from the whitepaper's stated limitations and from infrastructure the repository does not yet contain.
The mainnet specification exists but has no bootnodes and no launched genesis. Seed-node infrastructure and a published chain spec are prerequisites for any public chain.
The node already serves the queries an explorer needs over JSON-RPC — blocks, transactions, accounts, proofs — but no explorer front end exists in the repository.
Every historical state root stays queryable and disk use grows monotonically. Pruning is a compatible addition: a node that prunes simply cannot answer old queries.
Blocks are gossiped whole today, so bandwidth scales with block size times peer count. Adequate at the current limits; it would need revisiting if blocks grew.
The JSON-RPC interface is unauthenticated and binds to loopback by default. Exposing it safely currently requires an authenticating reverse proxy in front of the node.
The codebase has not been audited. Independent review of the consensus rules and the cryptographic handling is work that has been identified but not carried out.