Architecture
Understanding how Kaizen Core works internally.
Overview
Kaizen Core is a blockchain-like system optimized for prediction markets:
- Single sequencer (Write node) for ordering
- Multiple read nodes for query scalability
- 100ms checkpoints with streaming execution
- Deterministic STF for fraud proofs
Node Types
| Node | Purpose | Ports |
|---|---|---|
| Write Node | Sequencer - orders and executes transactions | 8545, 9000 |
| Read Node (aggressive) | Low-latency queries, ~16 min history | 8547, 9001 |
| Read Node (archive) | Full history for indexing | 8548, 9002 |
All nodes run the same STF - read nodes re-execute blocks from the write node.
Key Properties
| Property | Description |
|---|---|
| Streaming Execution | Transactions execute immediately on arrival |
| 100ms Checkpoints | Oracle updates + state commits |
| Deterministic | Same block → same state (enables fraud proofs) |
| Pull-based Oracle | Write node pulls prices from Oracle Service |
Guides
- Overview - High-level system design
- State Transition Function - How transactions are executed
- Block Production - Checkpoint and streaming model
- Parallel Execution - High-performance parallel processing
- Settlement - How theses are resolved
- Oracle - Price feed architecture
- Storage - RocksDB + JMT design
Quick Reference
Transaction Flow
TX arrives → Validate → Execute immediately → Add to pending
↓
Checkpoint (100ms)
↓
Oracle pull → Commit → BroadcastSettlement Flow
Thesis Created → Active → [Settler monitors]
↓
Breach detected? → SolverWins
Deadline passed? → UserWinsComponent Map
┌─────────────────────────────────────────────────────┐
│ Kaizen Node │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌────────┐ │
│ │ RPC/WS │→ │ Engine │→ │ Storage │ │Indexer │ │
│ │ Server │ │ (STF) │ │(RocksDB)│ │(PgSQL) │ │
│ └─────────┘ └─────────┘ └─────────┘ └────────┘ │
└─────────────────────────────────────────────────────┘
↑ ↑
Clients External
(Frontend, (Oracle,
Solver) Settler)