Kairos Chain docs.
Everything about how Kairos Chain works: how blocks are proven and ordered, how state is kept small, how you own coins without a key, and how $KAIROS becomes native KAIROS.
01 · STARTOverview
Kairos Chain is a proof-native Layer 1 ordered by proof of work. Each block contains a recursive proof, the HistoryStep terminal, that the new block is valid and that the previous terminal was valid. By induction, one terminal proves the whole chain from genesis.
A node therefore needs three things to be a full, independent verifier: the current live state, the latest terminal proof, and a short recent suffix of headers. Peers supply data, never authority.
02 · STARTWhy proof-native
Bitcoin, Ethereum and Solana ask a new node to replay history or trust someone's snapshot. That cost grows forever. On Kairos the cost of verifying the chain is the cost of verifying one proof, which does not grow with height. Proof of work is still there, but only to choose the canonical order: it cannot forge ownership or validate an invalid state.
03 · PROTOCOLConsensus
- Validity requires the header rules, the recursive HistoryStep relation and proof of work together. Block bytes plus work alone are never accepted.
- Proof of work: a domain-separated Poseidon2b sponge over 16 GF(2¹²⁸) header elements, including a 128-bit nonce. A block is valid when the digest is below the target.
- Order of operations: the miner finishes the nonce-independent proof first, freezes the template, then searches the nonce. Hashpower alone cannot produce a block.
- Block time: 30-second mean, with ASERT difficulty (6-block reference epoch, 180 s half-life), computed with integer math so sibling blocks share an exact target.
- Timestamps must exceed the median of the last 11 headers and be at most 120 s ahead of local time.
- Fork choice: greatest cumulative work; an exact tie goes to the lexicographically smaller tip hash.
- Finality: a hard 18-block window. Reorgs deeper than 17 blocks are invalid by protocol rule.
Block classes
| Class | Pages | Live inputs | Contract calls | Notes |
|---|---|---|---|---|
| Small (m23) | 63 | 504 | 63 | default |
| Large (m24) | 206 | 504 | 63 | producer opt-in; every node verifies both |
04 · PROTOCOLProof stack
Addresses, authorization, transactions, state, recursive history and proof of work share one binary proof stack:
- Fields: traces live in the binary tower field GF(2¹²⁸); Fiat-Shamir challenges and recursive claims use GF(2²⁵⁶).
- Hash: Poseidon2b, width 4, S-box x⁷, 8 full + 58 partial rounds, one permutation for every purpose, separated by typed domains.
- FROST-GKR (Frobenius Reduction Over Shifted Tables) folds repeated Poseidon2b permutations and Merkle paths into global sumcheck relations instead of layer-by-layer GKR.
- FRI-Binius / BaseFold polynomial commitments close the relation. There is no trusted setup.
- HistoryStep proves the current block relation and verifies the previous terminal inside the circuit. Terminal size and verification time do not grow with chain height.
| Workload (laptop, 12 threads) | Prove | Verify | Terminal |
|---|---|---|---|
| Small block, 63 payments | 17.6 s | 0.83 s | 913 KB |
| Empty Small block | 16.6 s | 1.01 s | — |
| Large block, 206 payments | 42.6 s | 2.02 s | 981 KB |
Upstream measurements on an Intel i7-1365U with AVX2 + VPCLMUL. Proving time is roughly fixed per block: an empty block costs about as much as a full one.
05 · PROTOCOLLive state
State is a sparse Merkle vector of output slots, starting at 2²⁴ and able to grow to 2³². Each leaf holds {amount, creation_id, owner}. Spending clears a slot; new outputs reuse empty slots with a fresh, monotonic creation_id, so a stale reference can never spend a new occupant.
When occupancy stays at or above 75% across 10 of the last 18 finalized headers, the state doubles: the old root becomes the left child and nothing moves. Slots are grouped into 2¹⁶-slot segments; empty segments cost nothing to store.
06 · PROTOCOLTransactions
- A Tx8x2 page is a fixed 323-byte body with up to 8 inputs and 2 outputs.
- A PagedSpend joins 1 to 128 pages into one atomic transaction with one ID, one fee and one authorization capsule.
- Transactions anchor to a 144-block epoch (about 72 minutes).
- Value rule: inputs = outputs + fee.
07 · PROTOCOLReceipts
A sender's wallet can export a portable receipt: the canonical spend plus a Merkle inclusion path. Any node can verify it against the canonical header even after the block body has been pruned. A receipt proves the payment happened; it does not prove the output is still unspent.
08 · USESignatureless ownership
A Kairos address is the Poseidon2b image of a 256-bit secret. There is no public key. To spend, your wallet produces a freshly randomized, witness-hiding zero-knowledge proof that it knows the secret, bound to the exact transaction ID and input owner. Nothing that resembles a signature or public key appears on the wire.
- Address format: bech32m,
k1… - Authorization proof: up to about 92.7 KB
- The miner, not the wallet, proves that inputs are live in state.
09 · USEPhoto Key
A wallet can derive its master secret from an image. The image is decoded locally to canonical RGBA8 pixels, never uploaded, and hashed with BLAKE3 in derive-key mode over the width, height and pixels. File metadata is ignored, so any resize or re-compression produces a different wallet. Images must be at least 32×32 with at least 64 distinct pixel values.
10 · USEContracts
A live output can commit to a program, spending authorities, recipients, height conditions and two persistent u64 counters. The integer core has 16 instructions (keep, move, add, subtract, min, max, less-than, equal, and assertions), checked arithmetic, and no loops, timers or cross-contract calls, which keeps every call cheap to prove.
Ready-made templates: refundable payment, timelocked vault, delegated allowance, budget per period, recurring payment, and gradual tranche release. Custom programs compile through the Pruv language, which checks declared postconditions with the Z3 solver.
11 · NETWORKEconomics
Native KAIROS has 6 decimals (1 KAI = 1,000,000 μKAIROS). After genesis, every new KAIROS is created by mining. There is no developer allocation in the block reward: 100% goes to the miner who proves the block.
| Year | Reward per block | New KAIROS that year |
|---|---|---|
| 1 | 16 | 16,819,200 |
| 2 | 11.30 | 11,878,560 |
| 3 | 8 | 8,409,600 |
| 4 | 5.65 | 5,939,280 |
| 5 | 4 | 4,204,800 |
| 6 | 2.83 | 2,974,896 |
| 7 | 2 | 2,102,400 |
| 8 | 1.41 | 1,482,192 |
| 9+ | 1 (tail) | 1,051,200 per year |
A "year" is 1,051,200 blocks at the 30-second target. The permanent 1 KAIROS tail keeps miners paid to prove blocks forever.
Fees
5,000 μKAIROS per transaction, plus 100 μKAIROS per input and 700 μKAIROS per output, plus a state-growth fee of 2,500 μKAIROS × pressure for each net-new slot. Pressure is 1× below 50% occupancy, then 2×, 4× and 8× at 50%, 75% and 90%. The state-growth part is burned; the rest goes to the miner. Consolidating outputs avoids the burn.
12 · NETWORKMining
A miner is a proving full node backed by hashpower. Mining needs a 64-bit CPU with carry-less multiplication: x86-64 with SSE4.1 + PCLMULQDQ (AVX2 or AVX-512 with VPCLMUL is faster), or ARM64 with NEON + PMULL. No GPU is used.
- Internal miner: run the node with mining enabled; proving and nonce search share a CPU thread budget.
- External miner:
kairos-minerfetches single-use nonce templates over RPC and returns only a nonce; proving stays in the node. - Wallet mining: the desktop wallet can mine with one click.
13 · NETWORKRun a node
kairos --check-hardware # ends with NODE READY kairos # start a full node (P2P 9700, RPC 127.0.0.1:9701) kairos-cli getChainInfo kairos-cli walletBalance
Recommended: a recent multi-core CPU, 8 GB of RAM or more (16 GB to mine), SSD storage and a 100 Mbit/s connection. A verifying node peaked at about 1.65 GB of RAM in upstream tests. Binaries and the desktop wallet for Windows, macOS and Linux are published with the testnet.
14 · NETWORKSecurity model
Kairos uses only hash-based, binary-field cryptography: no elliptic curves, no pairings, no trusted setup, and no public keys for ownership. The upstream protocol publishes an executable soundness certificate assessing the design at NIST post-quantum Category 1, conditionally, with a dominant half-success gate-depth floor of about 2173.39.
The word "conditional" matters. The assessment assumes Poseidon2b behaves as an ideal random oracle, assumes proximity-gap conjectures for the codes used, and models the compiler as ideal. It is a careful accounting tool, not a machine-checked proof, and the implementation has not had an independent third-party audit.
15 · $KAIROSMigration
$KAIROS exists first as a Solana token launched on pump.fun. When Kairos mainnet launches, holders move it into native KAIROS one for one:
- A holder snapshot and the migration rules are published before mainnet, with the snapshot time announced in advance.
- Holders bind their Solana wallet to a
k1…Kairos address through the migration portal. - Bound balances are written into the genesis block as migration allocations, visible to anyone who inspects genesis.
- After genesis, all new KAIROS comes from mining.
16 · REFERENCEParameters
| Parameter | Value |
|---|---|
| Block time | 30 s mean |
| Difficulty | ASERT, 6 blocks / 180 s half-life |
| Finality window | 18 blocks |
| PoW nonce | 128-bit |
| Trace / challenge fields | GF(2¹²⁸) / GF(2²⁵⁶) |
| Terminal proof cap | 1,100,000 B |
| Authorization cap | 256 KiB wire (≈92.7 KB worst case) |
| State slots | 2²⁴ → 2³² |
| Tx page | 8 in / 2 out, 323 B |
| Max atomic spend | 128 pages |
| Address | bech32m k1… |
| Units | 1 KAI = 10⁶ μKAIROS |
| Ports | P2P 9700 · RPC 9701 |
17 · REFERENCEOpen source
The Kairos node is public at github.com/kairoschain/kairos: every change from upstream is listed in KAIROS-FORK.md.
Kairos Chain is an independent fork of Parano1d, an open-source proof-native Layer 1 by Ignotus Nemo, released under the Apache-2.0 license. Its cryptographic core builds on binius64 (Irreducible), hekate-math (Oumuamua Labs) and bolt-rs (Bain Capital Crypto, Succinct). Kairos runs its own network with its own genesis, economics and brand, and keeps every original copyright and NOTICE attribution, as the license requires.
Kairos Chain is not affiliated with, endorsed by, or a successor to Parano1d or its NOID coin. KAIROS and NOID are separate assets on separate networks.