FRAC Seed Round: $0.25/FRAC — early allocation with vesting; no listing price or return is guaranteed — Buy Now
Back to Documentation
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.

Dilithium-3 / ML-DSA-65

NIST FIPS-204 standard, live in consensus. Secure against both classical and quantum attacks.

Cryptographic Primitives

CRYSTALS-Dilithium-3 / ML-DSA-65

Digital Signatures

Lattice-based signature scheme (FIPS-204) selected by NIST as a post-quantum signature standard. Wired into consensus and signing every block in production. Resistant to both classical and quantum attacks.

Security LevelNIST PQC Level 3 (FIPS-204)
Key Size1952 bytes (public)
Signature/Output3293 bytes

Used for: Transaction signing, block validation, wallet authentication

ML-KEM-768 / Kyber

Key Encapsulation

Lattice-based KEM for establishing shared secrets. Implemented and tested in the crate, but not yet wired into the node or the libp2p transport. The P2P layer currently uses classical Noise/X25519.

Security LevelNIST PQC Level 3 (FIPS-203)
Key Size1184 bytes (public)
Signature/OutputN/A (KEM)

Used for: Implemented in-crate; not yet wired into consensus or P2P (roadmap)

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 Dilithium-3 / ML-DSA-65
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-3 (3293-byte signature)
let tx_hash = tx.compute_hash();
let signature = dilithium3::sign(&tx_hash, &secret_key);

// Signature is 3293 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-3 private keys are ~4,032 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 VulnerabilityView Source Code

Security Comparison

FeatureFractalAIEthereumBitcoin
SignaturesDilithium-3 / ML-DSA-65 (PQ)ECDSAECDSA
Key ExchangeKyber in-crate (roadmap); Noise/X25519 todayECDHN/A
Hash FunctionBLAKE3Keccak-256SHA-256
State ProofsVerkle TreesMerkle PatriciaMerkle Trees
Quantum ResistantYes (native)NoNo
VM SandboxingWASMEVMScript
Smart Contract GuideFractalVM SpecsAPI Reference