Security Architecture

Security & Post-Quantum Cryptography

FractalAI is built with post-quantum security from the ground up. Every layer of the stack uses cryptographic primitives that are resistant to both classical and quantum computer attacks.

Why Post-Quantum?

Current blockchains (Bitcoin, Ethereum, Solana) rely on ECDSA/Ed25519 signatures that will be broken by quantum computers running Shor's algorithm. A sufficiently powerful quantum computer could forge transactions, steal funds, and compromise entire networks.

ECDSA / Ed25519

Broken by quantum computers. Used by Bitcoin, Ethereum, Solana.

Harvest Now, Decrypt Later

Adversaries record encrypted data today to decrypt when quantum arrives.

CRYSTALS-Dilithium

NIST-selected standard. Secure against both classical and quantum attacks.

Cryptographic Primitives

CRYSTALS-Dilithium

Digital Signatures

Lattice-based signature scheme selected by NIST as the primary post-quantum signature standard. Resistant to both classical and quantum attacks.

Security LevelNIST PQC Level 3

Key Size1312 bytes (public)

Signature/Output2420 bytes

Used for: Transaction signing, block validation, wallet authentication

CRYSTALS-Kyber

Key Encapsulation

Lattice-based KEM for establishing shared secrets. Used for encrypted peer-to-peer communication in the libp2p network layer.

Security LevelNIST PQC Level 3

Key Size1184 bytes (public)

Signature/OutputN/A (KEM)

Used for: Encrypted P2P communication, secure key exchange between nodes

BLAKE3

Hash Function

High-performance cryptographic hash function. Faster than SHA-256 while maintaining equivalent security guarantees.

Security Level256-bit pre-image

Key SizeN/A

Signature/Output32 bytes output

Used for: Block hashing, Merkle/Verkle trees, address derivation

Verkle Trees

State Commitment

Vector commitment tree structure with O(log n) proof sizes. More efficient than Merkle trees for state proofs, enabling lightweight verification.

Security LevelPolynomial commitment

Key SizeN/A

Signature/Output~150 bytes proof

Used for: State storage, efficient state proofs, light client verification

Defense in Depth

Security is enforced at every layer of the FractalAI stack, from consensus to smart contract execution.

Consensus Layer

Proof of Fractal Work requires genuine fractal computation

Golden ratio scoring prevents trivial proof generation

Minimum PoFW score threshold for block validity

Validator stake slashing for malicious behavior

Challenge rotation prevents pre-computation attacks

Network Layer

libp2p encrypted transport (Noise protocol)

Peer authentication with Dilithium signatures

Eclipse attack protection via diverse peer selection

Rate limiting on P2P message handlers

Gossipsub message validation before propagation

Transaction Layer

All transactions signed with CRYSTALS-Dilithium

Nonce tracking prevents replay attacks

Gas metering prevents DoS via computation

Transaction size limits (max 128 KB)

Signature verification before mempool admission

VM Layer

WASM sandboxed execution environment

Gas metering on all host function calls

Memory limits per contract execution (16 MB)

Stack depth limits prevent recursion attacks

Deterministic execution across all nodes

Signing a Transaction

Rust - Dilithium Transaction Signing

use pqcrypto_dilithium::dilithium3;

// Generate a post-quantum keypair
let (public_key, secret_key) = dilithium3::keypair();

// Create a transaction
let tx = Transaction::new(
    sender,           // your address
    recipient,        // destination address
    1_000_000_000,    // 1 FRAC (18 decimals)
    nonce,            // account nonce
    100_000,          // gas limit
    1,                // gas price
);

// Sign with Dilithium (2420-byte signature)
let tx_hash = tx.compute_hash();
let signature = dilithium3::sign(&tx_hash, &secret_key);

// Signature is 2420 bytes (vs 65 for ECDSA)
// But provides quantum-resistant security
let signed_tx = tx.with_signature(signature);

// Submit via JSON-RPC
client.send_raw_transaction(signed_tx).await?;

Best Practices

Wallet Security

Never share your private key or seed phrase
Dilithium private keys are 2528 bytes - store them encrypted
Use the CLI wallet with a strong password (AES-256 encryption at rest)
Verify transaction details before signing
Back up wallet files to multiple secure locations

Node Operation

Run nodes behind a firewall with only P2P port (30303) exposed
Keep RPC port (9545) accessible only to trusted clients
Enable TLS for RPC in production deployments
Monitor node logs for unusual peer behavior
Keep node software updated to latest release

Smart Contract Development

Validate all inputs in contract entry points
Use checked arithmetic to prevent overflow/underflow
Minimize storage writes to reduce gas costs
Test contracts thoroughly on devnet before deployment
Audit contract logic for reentrancy-like patterns

API & Integration

Use HTTPS when connecting to remote RPC endpoints
Validate all JSON-RPC responses before processing
Implement request signing for authenticated endpoints
Rate-limit your RPC calls to avoid node overload
Never embed private keys in client-side code

Bug Bounty Program

We take security seriously. If you discover a vulnerability in FractalAI, please report it responsibly. Rewards are paid in FRAC tokens based on severity.

Critical

Up to 50,000 FRAC

High

Up to 20,000 FRAC

Medium

Up to 5,000 FRAC

Low

Up to 1,000 FRAC

Report a Vulnerability View Source Code

Security Comparison

Feature	FractalAI	Ethereum	Bitcoin
Signatures	Dilithium (PQ)	ECDSA	ECDSA
Key Exchange	Kyber (PQ)	ECDH	N/A
Hash Function	BLAKE3	Keccak-256	SHA-256
State Proofs	Verkle Trees	Merkle Patricia	Merkle Trees
Quantum Resistant	Yes (native)	No	No
VM Sandboxing	WASM	EVM	Script

Smart Contract Guide FractalVM Specs API Reference