Architecture

System Layers

The full node stack from user-facing CLI down to primitive types.

CLI / RPC Interface axiom-cli, axiom-rpc

▼

Wallet axiom-wallet, axiom-signer, axiom-crypto

▼

Consensus axiom-consensus: PoW, LWMA, validation

▼

Transaction Pool axiom-protocol: mempool, gossip

▼

Network axiom-node: P2P, peer discovery, sync

▼

Storage axiom-storage: blocks, chainstate, indexes

▼

Primitives axiom-primitives: Amount, Hash256, types

Consensus Model

Nakamoto-style proof of work with SHA3-256 hashing and per-block difficulty adjustment via LWMA. No staking, no committees, no delegation -- pure computational proof.

⚒

SHA3-256 Proof of Work

Block headers are hashed with SHA3-256 (Keccak). Miners iterate the nonce until the hash meets the current difficulty target. SHA3 was chosen for ASIC-resistance in early stages and alignment with NIST post-quantum standards.

⚙

LWMA Difficulty Adjustment

Linear Weighted Moving Average adjusts difficulty every block using the most recent window of block timestamps. This eliminates the oscillations and gaming vulnerabilities found in fixed-interval adjustment schemes.

Consensus Parameters

Block Time

30s

Max Block Size

4 MB

Max Transactions

10,000

Max TX Size

100 KB

Initial Reward

50 AXM

Reward Floor

0.0001 AXM

Decay Factor

0.99999/block

Floor Height

~1,312,000

Transaction Lifecycle

From construction to confirmed inclusion in the chain.

1

Construction

The wallet selects UTXOs, calculates fees, and builds the transaction structure with inputs, outputs, and metadata.

2

Signing (ML-DSA-87)

Each input is signed with the sender's ML-DSA-87 private key. The signature is appended to the transaction, providing NIST Category 5 post-quantum authentication.

3

Broadcast

The signed transaction is serialized and sent to connected peers via the gossip protocol. Peers relay it to their own connections.

4

Mempool

Receiving nodes validate the transaction (signature, UTXO existence, no double-spend, fee sufficiency) and add it to their local mempool.

5

Inclusion

A miner selects transactions from the mempool, orders them by fee priority, and includes them in a candidate block. The block is mined via SHA3-256 PoW.

6

Confirmation

Once the block is found and propagated, the transaction is confirmed. Each subsequent block adds another confirmation, increasing finality confidence.

Block Validation

Every block received from the network is validated against these rules before acceptance.

Block header hash meets the current difficulty target
Previous block hash matches the tip of the local chain
Timestamp is within acceptable range of network-adjusted time
Block size does not exceed the 4 MB limit
Transaction count does not exceed 10,000
Coinbase reward matches the expected value for the block height
All transaction signatures (ML-DSA-87) are valid
No double-spends: every input references an unspent UTXO

Data Storage

Persistent state is organized into block storage and chain state databases.

🗃

Block Storage

Complete blocks are stored sequentially and indexed by hash and height. Raw block data is kept in flat files for efficient sequential reads, with a separate index database for lookups.

🔗

Chain State (UTXO)

The UTXO set is the canonical record of all unspent transaction outputs. It is updated atomically with each block connection/disconnection and provides O(1) lookups for transaction validation.

Data Directory Structure

~/.axiom/
  blocks/
    blk00000.dat        # Raw block data files
    index/              # Block hash -> file position index
  chainstate/
    utxo.db             # Current unspent transaction outputs
  peers.dat             # Known peer addresses
  axiom.conf            # Node configuration
  wallet.dat            # Encrypted wallet (Argon2id + XChaCha20)
  debug.log             # Node log output

Networking

Peer-to-peer communication and node protection mechanisms.

🌐

P2P Protocol

Nodes communicate over TCP on port 9333. Peer discovery uses DNS seeds and addr message gossip. Block and transaction propagation follows an inv/getdata pattern to minimize bandwidth.

Default port: 9333
Protocol: TCP gossip
Discovery: DNS seeds + addr relay
Propagation: inv / getdata / block

🛡

Node Protection

Nodes enforce rate limiting and ban scoring to protect against abuse. Peers that send invalid data, flood messages, or violate protocol rules accumulate ban points and are disconnected.

Per-peer rate limiting
Ban scoring with auto-disconnect
Invalid message penalties
Connection slot management

RPC Interface

JSON-RPC server on port 9332 provides programmatic access to the node. Bound to localhost by default for security.

🔐

Authentication

RPC access is protected by challenge-response authentication. Clients request a challenge, sign it, and receive a JWT token for subsequent requests. Tokens expire and must be refreshed.

Challenge-response handshake
JWT bearer tokens
Token expiration + refresh
Localhost-only by default

🔌

API Coverage

The RPC interface exposes methods for blockchain queries, transaction submission, wallet operations, mining control, and network status. WebSocket support enables real-time event subscriptions.

getblockcount, getblock, getblockhash
sendrawtransaction, gettxout
getmininginfo, submitblock
getpeerinfo, getnetworkinfo