Security
Security is not a feature added on top — it is the foundation of every design decision in Axiom.
Security Philosophy
Axiom is built with defense in depth: multiple independent layers of security so that no single point of failure compromises the system. Cryptographic algorithms are selected from NIST standards. The codebase is written in Rust to eliminate memory safety vulnerabilities. All arithmetic is performed with fixed-point integers to prevent floating-point consensus divergence.
Security extends beyond code. The distribution model uses no pre-mine, no team allocation, and no privileged access. Every AXM is earned through proof of work. The RPC interface binds to localhost by default. Wallet keys are encrypted at rest and never transmitted.
Cryptographic Primitives
ML-DSA-87 (FIPS 204)
Post-quantum digital signature scheme based on lattice problems. NIST Category 5 — equivalent to AES-256 security. Protects all transaction signatures against quantum computing attacks.
SHA3-256
Keccak-based hash function used for proof-of-work, block hashing, and merkle trees. NIST standardized. Distinct construction from SHA-2 — no length extension attacks.
Argon2id + XChaCha20-Poly1305
Memory-hard key derivation prevents brute-force password attacks. Authenticated encryption protects wallet keys at rest. 256-bit keys, 192-bit nonces.
BIP39 Mnemonics
24-word seed phrases (256-bit entropy) for wallet generation. Standard format compatible with secure physical backup practices.
| Purpose | Algorithm | Standard | Security Level |
|---|---|---|---|
| Transaction signatures | ML-DSA-87 | FIPS 204 | Category 5 |
| Proof of work | SHA3-256 | FIPS 202 | 256-bit |
| Block hashing | SHA3-256 | FIPS 202 | 256-bit |
| Key derivation | Argon2id | RFC 9106 | Memory-hard |
| Wallet encryption | XChaCha20-Poly1305 | RFC 8439+ | 256-bit |
| Seed generation | BIP39 | BIP-0039 | 256-bit entropy |
Node Verification Model
Every full node independently verifies every block and transaction. There is no trusted third party. This is the fundamental security guarantee of the network.
Full Validation
Nodes verify proof-of-work, transaction signatures, input availability, amounts, merkle roots, and block structure. Invalid blocks are rejected and the sending peer is penalized.
Deterministic Consensus
Q64 fixed-point arithmetic ensures identical reward calculations on all platforms. No floating-point divergence. Consensus cannot split due to hardware differences.
Network Trust Model
Axiom operates on a zero-trust network model. Peers are never trusted — all data received from peers is independently verified before acceptance.
- Blocks are validated against all consensus rules before acceptance
- Transactions are verified for valid signatures and unspent inputs
- Peers that send invalid data receive ban score penalties
- Peers exceeding the ban threshold are disconnected and blocked
- Connection limits prevent resource exhaustion from malicious peers
- Checkpoint hashes for historical blocks are hardcoded in the binary
Verify Downloads
Always verify the integrity of downloaded binaries before running them. Each release includes SHA-256 checksums.
curl -LO https://github.com/axiom-network/axiom/releases/latest/download/SHA256SUMS
sha256sum -c SHA256SUMSGet-FileHash axiom-v0.5.0-x86_64-pc-windows-msvc.zip -Algorithm SHA256
# Compare output against published checksumResponsible Disclosure
If you discover a security vulnerability in Axiom, please report it responsibly. Do not open a public issue. Instead, email the details to security@axiom-network.org with a description of the vulnerability, steps to reproduce, and your assessment of impact. We will acknowledge receipt within 48 hours.
We commit to:
- Acknowledging reports within 48 hours
- Providing regular updates on remediation progress
- Crediting researchers in security advisories (with permission)
- Not pursuing legal action against good-faith researchers