Skip to main content

24. Security Model

24.1 Defensive Components

The repository contains security managers and checks for transaction validity, consensus conditions, network behavior, time drift, DDoS controls, Sybil/eclipsing signals, VM limits, storage isolation, replay protection, and slashing evidence. These are implementation controls, not a complete security proof or production audit.

AreaCode evidenceQualification
Transaction safetyNonce, chain ID, timestamp and signature checksMust be tested across replay and serialization cases
Consensus safetyQuorum accounting, checkpoint validation, duplicate-signer and equivocation pathsDepends on committee configuration and multi-node behavior
VM safetyWasm validation, compute-unit limits, host-function bounds and call-depth controlsRequires bytecode fuzzing and deterministic cross-platform tests
Network safetyPeer, time, message and admission protectionsDeployment and topology dependent
Economic safetyStake and slashing data structuresMonetary policy and attack cost are not finalized
Cross-chain safetyL0 verifier/relay strategiesTrust model differs per chain and adapter

24.2 Cryptographic Scope

The official repository uses ML-DSA-65 for signing, ML-KEM-768-compatible Kyber for KEM operations, Rescue-Prime + STARK for the hash-based VRF path, SPHINCS+ support, and SHA3/BLAKE3 commitments. Security depends on concrete parameters, implementation correctness, domain separation, proof soundness, key custody and side-channel resistance.

24.3 Slashing and Recovery

Slashing code validates evidence, deduplicates submissions, computes configurable penalties, records history, and can jail validators. Penalty percentages, burn policy, reporter rewards, appeals and unbonding must be fixed by network configuration before mainnet.

24.4 What Is Not Claimed

The repository does not justify a projected dollar attack cost, a guaranteed BFT fault threshold for every deployment, a universal front-running solution, or a production security certification. Those claims require a canonical genesis, threat-model review, independent audits, fuzzing, formal analysis where appropriate, and adversarial multi-validator testnets.

For L0, an external chain inherits only the verification and trust model actually used by its adapter. RPC oracle attestation is not equivalent to a cryptographic light client.