Overview
Version: 0.4.0
What is Kaizen?
Kaizen is a price range prediction market protocol. Users predict whether an asset's price will stay within a specific range for a certain period, and solvers (market makers) provide quotes for these predictions. If the prediction is correct, the user receives the payout; if wrong, the solver takes it.
Kaizen Core is the core backend of this protocol, handling thesis matching and settlement. It has a blockchain-like structure, but instead of decentralized consensus, a single Sequencer orders and executes transactions.
Why Blockchain Architecture?
Reasons for adopting a blockchain-like structure:
1. Deterministic Replay
All state changes are recorded block by block, allowing state reconstruction at any point. This enables dispute resolution with proof.
2. Rollup Migration Readiness
When transitioning to a Rollup on DA layers like Celestia or Avail, architecture changes are minimized.
3. State Proofs
Merkle Tree-based state management enables cryptographic proofs of balances or thesis states at specific points in time.
Core Properties
| Property | Description |
|---|---|
| Real-time | Streaming execution with 100ms checkpoints, oracle pull-based updates |
| Deterministic | Same block always produces same result. Oracle snapshot included in block removes external dependency |
| Write/Read Split | Single Write node produces blocks, multiple Read nodes serve queries. Read load distributed |
| Rollup Compatible | Compliant with Evolve (formerly Rollkit) go-execution interface |
Thesis Type: Box
Kaizen currently supports Box theses which observe price over an entire time interval.
How Box Theses Work
- Example: "Solana will stay between $130-150 for the next 30 seconds"
- If price exits range even once, user loses (auto-detected by the system)
- If price stays in range until settlement window ends, user wins
Settlement
The system automatically scans for breaches during each 100ms checkpoint:
- Check price at all intervals within observation period
- If breach found → Solver wins immediately
- If settlement window expires without breach → User wins
Settlement Mechanism: Settler Service
Settlement is handled by an external Settler service that monitors theses and submits settlement transactions:
1. Event-Driven Monitoring
The Settler subscribes to thesis events via gRPC sync and tracks active theses with their price ranges and deadlines.
2. Breach Detection
The Settler continuously monitors oracle prices and detects breaches in real-time. When a breach is found, it submits a SystemSettle(SolverWins) transaction.
3. Timeout-based User Win
If no breach is found after the challenge deadline passes, the Settler submits a SystemSettle(UserWins) transaction.
Settlement Flow
This architecture keeps block production fast and decoupled from settlement logic. See Settler for details.
Architecture Highlights
Streaming Execution
Transactions execute immediately upon arrival, not batched:
100ms Checkpoints
Every 100ms, the system:
- Pulls oracle prices from Oracle Service
- Commits executed transactions to a block
- Broadcasts block to Read nodes
:::info Settlement Settlement is handled asynchronously by the Settler service, not during checkpoint processing. This keeps block production fast and decoupled from settlement logic. :::
Pull-based Oracle
The Write node pulls prices from Oracle Service via HTTP:
This eliminates nonce management for oracle data and ensures deterministic ordering.