1. Abstract
Axiom Network (ticker: AXM) is a purpose-built, proof-of-work monetary blockchain implemented entirely in Rust. It addresses three core design goals missing from earlier UTXO-based systems: a deterministic smooth emission curve that avoids the volatility of halving events; a responsive per-block difficulty algorithm (LWMA-3) that adjusts to sudden hashrate changes without the instability of short retarget windows; and a memory-safe, formally auditable implementation stack that eliminates entire classes of integer overflow and use-after-free vulnerabilities common in C/C++ node software.
Axiom targets a capped supply of approximately 21,000,000 AXM achieved through exponential decay rather than discrete halvings, converging to a permanent tail emission of 0.1 AXM per block (~10,512 AXM/year) to fund long-run miner security and preserve fee-market bootstrapping on the path to mainnet.
2. Introduction
Bitcoin demonstrated that a decentralised, permissionless monetary network can operate securely without a trusted third party. Yet its implementation carries constraints set in 2009 that, with hindsight, introduce suboptimal properties: step-function supply shocks at halvings, a 2016-block difficulty window that reacts slowly to hashrate volatility, and a codebase that has grown into millions of lines of mixed C++.
Axiom does not attempt to replace Bitcoin. It is an independent, clean-room implementation of the same proof-of-work monetary primitive, rebuilding the critical path — transaction validation, UTXO management, block production, and consensus — with modern tooling and improved economic parameters.
Design principles
- Security first: Rust ownership semantics eliminate memory-safety bugs at compile time. All consensus-critical arithmetic uses explicit overflow checking.
- Predictable emission: A smooth decay curve removes supply-shock volatility around halving events.
- Responsive difficulty: LWMA-3 (N=60) adjusts every block, damping timewarp and oscillation attacks that plague short-window algorithms.
- Minimal protocol surface: The RPC API is small and well-specified, reducing attack surface and simplifying third-party integrations.
- Auditability: Every consensus rule is documented in
CONSENSUS_INVARIANTS.mdand tested with integration tests against a live single-process node.
3. Architecture
Axiom is organised as a Cargo workspace of eleven crates, each with a single responsibility and minimal cross-dependencies. This structure allows the consensus layer to be audited independently of networking, and the wallet to be reviewed in isolation from the node.
| Crate | Responsibility |
|---|---|
| axiom-primitives | Hash256, Amount — domain types with overflow-safe arithmetic |
| axiom-crypto | SHA-256d, Ed25519 signing, key derivation (HKDF-SHA-512) |
| axiom-protocol | Transaction, TxInput, TxOutput, canonical serialisation (bincode) |
| axiom-consensus | Block, ConsensusValidator, PoW check, LWMA, smooth reward |
| axiom-storage | sled persistent store: UTXO set, nonce tracker, TxIndex, undo data |
| axiom-node | ChainState, Node, Mempool, NetworkService, reorg engine |
| axiom-wallet | KeyPair, Address, TransactionBuilder, BIP39 seed, Argon2id keystore |
| axiom-rpc | axum HTTP server — 11 REST endpoints, Bearer auth, rate limiting |
| axiom-cli | Binary: axiom-node — wires all crates, starts miner + RPC |
| axiom-faucet | Testnet AXM dispenser with per-address/IP cooldown |
| axiom-stress | Flood, metrics, wallet generator, benchmark CLI |
Block structure
Each block consists of a 76-byte header and an ordered list of transactions:
BlockHeader {
version: u32, // Protocol version
prev_block_hash: [u8;32], // SHA-256d of parent header
merkle_root: [u8;32], // Simplified Merkle root (SHA-256d of all TXIDs)
timestamp: u32, // Unix seconds
difficulty_target: u32, // Compact representation (Bitcoin format)
nonce: u32, // Proof-of-work solution
}Transactions use an Account/UTXO hybrid model: each output is identified by(txid, output_index) and carries a value in satoshis and apubkey_hash. Inputs reference previous outputs by TXID and index. A per-address nonce is enforced at the consensus layer to prevent replay attacks.
4. Monetary Policy
Axiom's block reward follows an exponential decay function applied per-block, rather than the discrete step-function (halving) used by Bitcoin. This produces a smooth, continuously decreasing emission curve that removes supply-shock price volatility at fixed block intervals.
Emission formula
reward(height) = max(
INITIAL_REWARD_SAT × DECAY_FACTOR^height,
TAIL_EMISSION_SAT
)| INITIAL_REWARD_SAT | 5,000,000,000 sat (50 AXM) |
| DECAY_FACTOR | 0.99995 per block |
| TAIL_EMISSION_SAT | 10,000,000 sat (0.1 AXM) |
| Tail activates at | ~height 124,287 (~1.18 years at 5-min blocks) |
Supply curve
The geometric series sum of the pre-tail emission is approximately 998,000 AXM. Once the tail floor activates at height ~124,287, the network permanently emits 0.1 AXM per block (≈ 10,512 AXM/year). The long-run supply converges asymptotically toward ~21,000,000 AXM.
| Height | Block Reward | Cumulative Supply | ~ Time |
|---|---|---|---|
| 0 | 50.00 AXM | 0 AXM | Genesis |
| 10,000 | 30.35 AXM | ~401,000 AXM | ~35 days |
| 50,000 | 8.21 AXM | ~758,000 AXM | ~174 days |
| 100,000 | 0.67 AXM | ~972,000 AXM | ~347 days |
| 124,287 | 0.10 AXM ✓ | ~998,000 AXM | ~432 days |
| 200,000 | 0.10 AXM | ~1.01 M AXM | ~1.9 years |
| 2,100,000 | 0.10 AXM | ~9.0 M AXM | ~20 years |
Comparison with halving
Bitcoin's halving reduces the block reward by 50% every 210,000 blocks (~4 years). The mechanism is simple and auditable, but it introduces three structural problems that Axiom's continuous decay model is designed to avoid.
Supply shocks
At each halving, miner revenue is cut in half overnight. Miners operating near break-even are immediately unprofitable and shut off hardware. Hashrate drops, blocks slow, and the network is temporarily weaker. The price must double just to keep the same miners online. Axiom's decay of 0.99995× per block spreads the same total emission reduction across hundreds of thousands of blocks. No single block ever represents a discontinuity — miner economics change by ~0.005% per block, which is undetectable in practice.
The long-run security cliff
Bitcoin's final halving (around year 2140) reduces the block reward to zero. From that point, miners earn only transaction fees. If fee revenue is insufficient to sustain the current hashrate, rational miners exit, and the network becomes cheaper to attack. This is an open, unsolved problem. Axiom removes it entirely: the tail emission permanently floors miner revenue at 0.1 AXM per block (~10,512 AXM/year). Attacking the network always costs more than the attacker can gain, regardless of fee market maturity.
Emission predictability
Both models are fully deterministic given block height. The difference is granularity. Halving produces a step-function; smooth decay produces a continuous curve. Both converge to approximately 21 million units. The table below compares key properties:
| Property | Bitcoin (halving) | Axiom (smooth decay) |
|---|---|---|
| Reward reduction | 50% every 210,000 blocks | 0.005% every block |
| Supply shock | Hard cliff every ~4 years | None — continuous |
| Tail emission | Zero (reward → 0 ~2140) | 0.1 AXM/block forever |
| Miner revenue floor | Transaction fees only | Tail + fees |
| Security after cap | Fee-market dependent | Guaranteed base subsidy |
| Supply cap | 21,000,000 BTC | ~21,000,000 AXM |
| Curve shape | Staircase | Smooth exponential |
5. Consensus & Proof of Work
Axiom uses SHA-256d (double-SHA-256) proof of work. A block is valid if its header hash (serialised as version ‖ prev_hash ‖ merkle_root ‖ timestamp ‖ difficulty_target ‖ nonce, little-endian u32 fields) is numerically less than or equal to the compact target expanded to a 256-bit big-endian integer.
| Hash function | SHA-256d (double SHA-256) |
| Block time target | 300 seconds (5 minutes) |
| Initial difficulty | 0x1d00ffff (Bitcoin genesis level) |
| Max block size | 1 MB |
| Max transactions | 10,000 per block |
| Coinbase rule | First transaction must be coinbase; nonce encodes height |
Block validation rules
- prev_block_hash must match the stored tip
- merkle_root must be the SHA-256d of all serialised TXID bytes concatenated
- Coinbase value ≤ block_reward(height); no fees in current testnet
- Coinbase nonce must equal block height (height binding)
- No duplicate TXIDs within a single block
- All transaction outputs must have non-negative values
- Block size ≤ MAX_BLOCK_SIZE; tx count ≤ MAX_BLOCK_TRANSACTIONS
- difficulty_target must equal get_next_difficulty_target (enforced via ConsensusValidator)
Testnet mode
On testnet, PoW hash validation is disabled (validate_pow = false). Difficulty target fields are still validated deterministically so that nodes reject blocks with incorrect compact targets, preserving consensus correctness while allowing fast block production without mining hardware. PoW will be enabled for mainnet.
6. Difficulty Adjustment (LWMA-3)
Axiom replaces Bitcoin-style 2016-block retargeting with the Linear Weighted Moving Average (LWMA-3) algorithm. LWMA adjusts difficulty on every block using the last N=60 solvetimes, providing fast, stable response to hashrate changes with mathematically bounded oscillation.
Algorithm
T = 300s // Target block time
N = 60 // Window size
k = N·(N+1)/2 · T // Normalisation constant = 54,900s
For each block i in [1..N]:
solvetime[i] = clamp(timestamps[i] - timestamps[i-1], 1, 6·T)
weighted_sum += i · solvetime[i]
LWMA = weighted_sum / k
new_target = prev_target × (LWMA / T)The linear weight assigns weight 1 to the oldest solvetime and weight N=60 to the most recent, making the algorithm responsive to rapid recent changes while incorporating historical context. Solvetimes are clamped to [1 s, 1800 s] to resist timestamp manipulation attacks.
Properties
- Per-block adjustment: No fixed retarget interval — every block gets a fresh difficulty calculation.
- Timewarp resistance: The 6T solvetime cap prevents miners from manipulating timestamps to inflate future rewards.
- Early-chain fallback: While chain height < N (first 60 blocks), the parent's difficulty is carried forward. Below the window the LWMA has insufficient data.
- Determinism: Given the same block headers (timestamps + compact targets) all nodes compute identical results. The calculation uses IEEE 754 double-precision arithmetic which is bitwise reproducible on compliant hardware.
Comparison with Bitcoin retargeting
Bitcoin's 2016-block window responds very slowly to sudden hashrate changes: a 50% hashrate drop takes up to 3.5 weeks before difficulty falls. During this period blocks arrive every ~20 minutes, doubling the confirmation time. LWMA-3 with N=60 reacts within ~5 hours (60 × 5 min), limiting maximum deviation from the 5-minute target to a few multiples.
7. Wallet & Key Management
Key generation
Axiom uses Ed25519 as the signature scheme. Addresses are derived from the SHA-256d of the 32-byte compressed public key, producing a 20-byte pubkey hash. Addresses are encoded as axm followed by 40 lowercase hex digits (20 bytes), yielding 43-character addresses.
address = "axm" + hex(SHA256d(pubkey)[0..20])BIP39 seed
The wallet module supports 24-word BIP39 mnemonics. PBKDF2-HMAC-SHA512 (2048 iterations) derives a 64-byte seed from the mnemonic + optional passphrase. Accounts are then deterministically derived using HKDF-SHA512 with a domain separator, without a hardened BIP32 tree — a flat derivation optimised for a single-curve key hierarchy.
Keystore encryption
On-disk keystores use Argon2id (m=65536 KiB, t=3, p=4) for key derivation from a password, followed by XChaCha20-Poly1305 authenticated encryption of the private key. The keystore format is JSON and is fully self-describing (algorithm params, salt, nonce, ciphertext, and MAC are all stored).
8. Networking
The P2P layer uses TCP with a simple binary framing protocol. Messages are length-prefixed and serialised with bincode. Peer connections begin with a Version/VerAck handshake that exchanges block height; if the remote peer is behind, the node proactively pushes its canonical blocks in ascending height order (Initial Block Download sync).
| Default P2P port | 8333 |
| Default RPC port | 8332 |
| Serialisation | bincode 1.x (little-endian) |
| Message framing | 4-byte length prefix + payload |
| Peer discovery | Static seed list + in-process peer exchange |
| IBD strategy | Push canonical chain since peer best_height |
9. Security Model
Memory safety
The entire node, wallet, and consensus stack is written in safe Rust. The type system eliminates buffer overflows, use-after-free, integer overflow, and null pointer dereferences at compile time. The only unsafe blocks permitted are in low-level serialisation primitives, each of which is reviewed and documented.
Consensus safety
Consensus rules are encoded as 27 numbered invariants (CI-1–CI-14, ST-1–ST-6, DA-1–DA-4, CS-1–CS-3) documented in CONSENSUS_INVARIANTS.md. All invariants are verified by integration tests through the full node code path (not mocked).
RPC security
The JSON-HTTP RPC server supports optional Bearer token authentication and per-IP rate limiting. CORS, X-Frame-Options, and X-Content-Type-Options headers are enforced. The explorer frontend is read-only — it never handles private keys or signs transactions.
Known limitations (testnet)
- PoW hash validation is disabled; difficulty is enforced but not mined against.
- Transaction fees are not yet implemented; block reward is the only coinbase income.
- Script engine is not yet present; all inputs unlock via pubkey+signature pair directly.
- Bincode serialisation format is not yet versioned for forward-compatibility.
10. Comparison with Bitcoin
| Property | Bitcoin | Axiom |
|---|---|---|
| Implementation language | C++ | Rust (safe) |
| Block time | ~10 minutes | 5 minutes |
| Emission model | Halving every 210,000 blocks | Smooth decay (0.99995×/block) |
| Supply cap | 21,000,000 BTC | ~21,000,000 AXM |
| Tail emission | None (reward → 0) | 0.1 AXM/block permanently |
| Difficulty algorithm | 2016-block window | LWMA-3 (N=60, per-block) |
| Signature scheme | ECDSA (secp256k1) | Ed25519 |
| Hash function | SHA-256d | SHA-256d |
| Address format | Base58Check (P2PKH/P2SH) | axm + 40 hex chars |
| UTXO model | Pure UTXO | UTXO + per-address nonce |
11. Roadmap
12. Conclusion
Axiom Network demonstrates that the core primitives of a monetary blockchain — UTXO accounting, proof-of-work consensus, deterministic difficulty adjustment, and a bounded coin supply — can be implemented in a memory-safe systems language with substantially improved economic properties and a smaller, more auditable codebase than prior systems.
The combination of smooth emission decay and LWMA-3 difficulty adjustment addresses two of the most well-known economic and stability weaknesses of Bitcoin-derived networks, while maintaining full backward-compatible UTXO semantics and SHA-256d proof of work. Ed25519 keys and an Argon2id-encrypted keystore bring the security baseline in line with current cryptographic best practices.
The public testnet (axiom-testnet-v1) is live. All source code, build scripts, node software, and this document are available for review. Feedback and security disclosures are welcome.