Part I — Introduction & Overview

1. What is Kortana?

Kortana is a Layer 1 blockchain engineered entirely from the ground up in modern C++23. It is designed to solve the fundamental trade-offs between execution security, mathematical determinism, and developer accessibility. Rather than attempting to incrementally patch the well-documented design flaws of first-generation smart contract platforms, Kortana introduces a purpose-built dual-execution architecture. This architecture natively hosts an Ethereum Cancun-compatible Ethereum Virtual Machine (KEVM) side-by-side with the Kortana Virtual Machine (KVM)—a capability-secure, 32-register virtual machine. Both execution engines operate over a single, unified Merkle-Patricia state trie, drawing execution gas from a shared meter and writing atomically to the world state.

The entire node daemon (kortanad) is architected with zero tolerance for non-deterministic behavior or memory corruption. Kortana eliminates the stochastic probabilistic finality models that plague traditional proof-of-work and proof-of-stake networks by pairing a high-throughput cryptographic clock—Delegated Proof of History (dPOH)—with a pipelined HotStuff-family Byzantine Fault Tolerant consensus engine known as Kortana Consensus (KSC BFT). By enforcing mathematical invariants at every boundary (including the strict enforcement of std::expected error handling, checked 256-bit arithmetic, and RAII-managed database flushes), Kortana provides a decentralized platform where decentralized finance (DeFi), real-world asset tokenization (RWA), and enterprise settlement protocols can execute with institutional confidence.

1.1 Vision & Mission

The core mission of Kortana is to establish a foundational ledger that strictly prioritizes security over speed and determinism over cleverness. In the broader blockchain ecosystem, protocol developers have repeatedly sacrificed formal verification and structural safety in pursuit of inflated transactions-per-second (TPS) benchmarks, resulting in billions of dollars lost to smart contract exploits, reentrancy vulnerabilities, compiler edge cases, and catastrophic chain reorganizations. Kortana fundamentally rejects this paradigm. Our vision is to deliver an execution environment where security invariants are enforced at the compiler and virtual machine levels rather than relying solely on the discipline of individual application developers.

To realize this mission, Kortana provides the Quorlin programming language and the KVM execution engine as first-class citizens. Quorlin replaces unsafe dynamic stack operations with explicit static capability declarations, requiring every function to announce its state effects (reads or writes) before execution begins. Simultaneously, Kortana recognizes the immense value of the existing Ethereum tooling ecosystem and liquidity network. By embedding an unmodified Cancun-grade EVM engine powered by evmone directly into the consensus pipeline, Kortana allows protocols to seamlessly deploy battle-tested Solidity contracts while progressively migrating critical core infrastructure to capability-secure Quorlin modules.

1.2 Key Differentiators

Kortana departs from conventional Layer 1 architectures through three foundational engineering innovations:

KVM Capability-Secure Register Architecture: Traditional smart contract virtual machines, most notably the EVM, rely on stack-based architectures that require complex stack juggling opcodes (DUP, SWAP) and deep stack management, making formal verification and static analysis computationally expensive and error-prone. The Kortana Virtual Machine (KVM) is a 32-register machine featuring 256-bit fixed registers (r0 hardwired to zero) and a fixed-width 4-byte instruction set. Quorlin contracts compile directly into KVM bytecode modules with explicit capability flags, eliminating entire classes of reentrancy and unexpected state-mutation exploits before runtime execution begins.
Delegated Proof of History (dPOH): Instead of relying on vulnerable local system clocks or asynchronous block-gossiping bottlenecks to establish the chronological sequence of transactions, Kortana runs a continuous, sequential SHA-256 verifiable delay function (VDF) on a dedicated hardware thread. Operating at a fixed rate of 600,000 hashes per 1.5-second slot, dPOH generates an immutable, tamper-proof cryptographic record of the passage of time, completely decoupling transaction ordering from validator consensus voting.
Deterministic 1-Block Finality (KSC BFT): Finality on Kortana is absolute, deterministic, and instant. Utilizing a HotStuff-derived BFT consensus protocol backed by BLS12-381 elliptic curve signature aggregation, validator votes are combined into constant-size Quorum Certificates (QCs). Once a proposed block receives a valid QC, it is permanently locked into the canonical history. There are no probabilistic reorganizations, no longest-chain forks, and no uncle blocks.

[!TIP] Bridges and dApps building on Kortana do not need to wait 128+ blocks for probabilistic finality. A single finalized block is cryptographically guaranteed to never be reorganized.

1.3 Architecture at a Glance

The Kortana architecture operates as a tightly integrated, multi-stage processing pipeline where each subsystem enforces strict isolation and deterministic state transitions. Transactions enter the node via authenticated RPC interfaces or the peer-to-peer gossip network into the Mempool, where signatures are verified, fees are sorted according to EIP-1559 priority metrics, and sender nonces are strictly validated. The scheduled leader node feeds these admitted transactions into the dPOH Generator, which interleaves transaction hashes directly into the continuous SHA-256 hash stream at precise tick intervals.

Once a slot's tick sequence is completed, the leader constructs a proposed block and broadcasts it to the active validator set. The KSC BFT Consensus engine collects validator votes, aggregates them into a BLS12-381 Quorum Certificate, and certifies the block. The block is then handed to the Execution Router. The router examines the target account's bytecode: if the bytecode begins with the magic prefix 4B 56 4D 00 ("KVM\0"), execution is dispatched to the KVM Register Machine; otherwise, it is dispatched to the KEVM Cancun Engine. Both engines mutate the shared Merkle-Patricia State Trie and record changes atomically to durable RocksDB storage via a Write-Ahead Log (WAL).

Loading diagram...

1.4 Design Philosophy

The development of the Kortana blockchain is governed by an unyielding set of engineering constraints codified in the core production specification:

[!IMPORTANT] 1. Security over speed. A faster chain that loses funds is a failed chain. Every performance target is subject to the security architecture, never a reason to relax it.

2. Determinism over cleverness. An optimization that makes two honest nodes disagree, even once in a billion blocks, is worse than a boring implementation that never does. No floating-point math, no system clocks in consensus, and strict canonization.

These core commitments dictate every architectural choice in kortana-node. For example, all consensus data structures use strictly ordered std::map rather than non-deterministic hash maps to guarantee byte-identical iteration across distinct compilers and CPU architectures. Floating-point arithmetic is strictly prohibited in all financial and consensus paths, using custom 256-bit fixed-point checked arithmetic (uint256_t) instead. Furthermore, every fallible internal C++ function returns a Result<T, ErrorCode> wrapped with [[nodiscard]], ensuring that errors cannot be dropped or ignored at compile time.

1.5 Specification Reference

This documentation is derived directly from the authoritative Kortana Blockchain Production Engineering Specification v3.0.0. Every mechanism, cryptographic constant, state machine transition, network protocol framing rule, and JSON-RPC endpoint documented across this reference traces explicitly back to the formal algorithms implemented in the kortana-node C++ source tree.

Throughout the codebase and this documentation suite, section markers (§) provide bidirectional traceability between formal specification requirements and executable C++ implementations. Whether analyzing the Merkle-Patricia Trie proofs in state/, the HotStuff view-change timeouts in consensus/, or the 14-column family storage schema in storage/, developers and auditors can verify that the runtime behavior precisely satisfies the mathematical proofs and security bounds mandated by the specification.