The chain

null's Phase-1 core is a minimal sovereign chain: a single PoA sequencer producing blocks on a fixed interval, real SVM transaction execution, an embedded KV store for account state, and a Solana-compatible JSON-RPC server that standard tooling talks to unmodified.

chain/
  sequencer/   binary: slot timer, block production loop, startup banner
  executor/    SVM integration (litesvm wrapper)
  state/       redb KV store + the Node (executor + mempool + persistence + PoA identity)
  rpc/         axum JSON-RPC server mirroring Solana's method names and schema

One Node lives behind a single Arc<Mutex<..>>. RPC handlers and the block production loop both take that lock — the same serial execution model a single sequencer has, with no interior concurrency to reason about.

Consensus: PoA, single sequencer

There is no consensus protocol. The sequencer generates an ed25519 identity at first start (persisted). Every block header — sha256(parent_hash, slot, timestamp, tx signatures…) — is signed with that key. With a single sequencer there are no forks, so inclusion in a block is finality; every status is reported finalized. Decentralizing the sequencer is explicitly a later phase.

Execution: litesvm

The executor wraps litesvm, Anza's lightweight SVM harness — it wires up the program runtime, builtins, sysvars, fee charging, signature verification, and blockhash checking. Sigverify is enabled, so clients are exercised honestly. The executor crate is deliberately the only place litesvm types appear, so a later migration to full solana-svm (for a real bank lifecycle / custom fee logic) replaces one small wrapper.

Block production

A fixed 500 ms slot interval (empty blocks included, like Solana). Each tick: slot += 1, drain the mempool, execute each transaction, record per-signature status, then hash + sign + persist the block header atomically. sendTransaction runs a preflight simulation and enqueues; execution happens at the next tick, so confirmation latency is ≤ 500 ms.

Blockhash window

The Node owns a rolling 150-blockhash window (RECENT_BLOCKHASH_WINDOW, ~75 s at 500 ms slots, mirroring Solana). Each produced slot advances the blockhash and pushes it to the front, dropping the oldest. A transaction whose blockhash is not in the window is rejected (-32002 Blockhash not found). litesvm's signature history still rejects duplicate signatures, so replay protection is not weakened.

State store: redb

A single chain.redb file holds accounts, chain metadata, transaction statuses, signed block records, and the pool/bridge tables. After each executed transaction the post-state of every referenced account is upserted inside one atomic redb transaction per block, and rebuilt into a fresh litesvm instance on startup. This is deliberately not AccountsDB.

JSON-RPC

An axum server with a single POST route and manual dispatch (chosen over a framework to control the response schema byte-for-byte — context/value wrappers, apiVersion, Solana error codes). It implements the core Solana methods plus pool/bridge extensions — see the RPC reference.