A novel, Byzantine Fault Tolerant (BFT) Raft consensus algorithm, based on a hybrid Proof-of-Stake and Proof-of-Authority model. Raft was chosen as it's mathematically proven to be correct, can be implemented very efficiently, and above all, is very simple to understand (unlike many other efficient consensus algorithms). The original formulation of Raft is not BFT, so we use a more modern version of the algorithm to add this property without adding much extra complexity.

An optimized block structure designed for multiple goals: · Fast replay of block-history to reconstruct and verify current state · Configurable block-time targets: "Minutes" for side-chains aimed at interoperability with legacy systems "Seconds" for side-chains aimed at financial transactions "Milliseconds" for side-chains aimed at real-time gameplay · Simple binary encoding allows extremely quick in-memory parsing · Progressive levels of detail allow the minimum data required to reconstruct the blockchain state as fast as possible. · If required, continued transmission of remaining details allows even thin web clients (e.g. a phone with Javascript) to verify blocks pass validation.

A dual transaction format allowing specific minimal encoding for common transaction types (e.g. balance transfers), but can be extended with generic contract calls (e.g. complex trades, business/game logic).

A new contract VM supports multiple modules. · Built-in specialized transactions (e.g. Fungible / Non-fungible token interactions) · PhantasmaVM transactions (e.g. TOMB contracts) · EVM contracts (WIP) · WASM contracts (WIP) allowing developers to choose almost any language (C, C++, C#, Rust, Lua, Java, PHP, Go, Javascript, etc...)

Configurable tokenomics and "Gas fees". · Separation of concepts for computation fees & data-storage fees. · Dual-token (e.g. SOUL & KCAL) or single token (e.g ETH) configurations are possible per side-chain.

A plain English *specification* that acts as the central reference for all contributors. To reduce the risk of inside-man attacks, multiple *implementations* of the specification are being authored by different teams. · C++ (Guyline) · LAMP (Cerberus) · C# (Phantasm) The main-net of any blockchain should ensure that there are a healthy number of block producers using each implementation, eliminating the possibility that any errors (or malicious code) in one implementation cannot reach consensus.