Core map | ZKas

Area

State

Fork

02Measured baseline

What the chain and the code cost today. Deep round, 18–21 Oct 2026, on the live chain and on benchmarks; these figures replace earlier estimates.

Quantity	Value
Size	3,156 B per action (72% of it proof) + 2,869 B fixed per bundle; a 2-action payment is 9,181 B; a block holds 76 (standard) to 78 (consensus) actions in 250 KB
Capacity	≈ 24–26 two-action payments/s, ≈ 15–16/s in the uniform 4-action shape; 1.05% of the byte ceiling used
Load	≈ 3,600 transactions and ≈ 68,500 actions per day; 47–48% of new notes are coinbase (chain files, 3 Nov)
Proving (one thread)	≈ 0.27 + 0.531·n s for n actions: 1.33 s at n = 2, 20.4 s at n = 38; 6 threads: 0.26 s / 3.98 s
Verification	≈ 16 + 0.63·n ms per bundle; batched 1.0 ms/action (2-action) and 0.58 ms/action (38-action); the network's total verification load ≈ 0.11% of one core
Trial decryption	41–43 µs per action per key on one core (75% is the key agreement); browser WebAssembly ≈ 5× slower than native
Storage	16.77 M note leaves (3 Nov); archival growth ≈ 0.96 GB/day; a pruned node keeps ≈ 196 B per action; headers + merged-mining witness ≈ 3.2 KB per block, kept forever
Merged mining	21.6% of Kaspa blocks carry a ZKas tag (≈ 82 of ≈ 380 PH/s; 9,844-block sample, 4 Nov): our own bridge 12.1%, K1Pool 7.3%, RabidPool 1.6%. HumPool and F2Pool (58% of Kaspa) do not
Spend wait	received funds and own change become spendable after ≈ 630–750 s (anchor depth 600 plus margin); merchant-grade finality 12 h today
Anonymity in practice	a payment whose time is known to ±5 min matches a median of one other transaction on every visible feature; 45% are unique. 85% of transactions come from three automated senders; 92.4% of new value-bearing notes have a public owner (mostly coinbase)

03Release trains

The baseline plan from the 14 core specs, after reconciliation and fixes. Effort ≈ 73.5 core dev-months (the specs' own estimates, unchecked). Product tracks (≈ 35–55) and the post-quantum pool (≈ 34–44) come on top.

Train	Content	Kind	State

04The alternative stack and the experiments that decide it

The forks study (21 Oct) proposes a bigger target: Based ZKas (Kaspa orders and finalises ZKas transactions), tagged channels everywhere, spends in ≈ 5–7 s, native private DeFi and a hash-based post-quantum pool by ≈ 2029–30. ≈ 194 core dev-months against ≈ 108–118 for the baseline plus the pool; ≈ 3–4 years at 4–5 engineers. It is not adopted. Two experiments decide most of it, and neither the Kaspa-mainnet half of E1 nor E2's phone run has been done.

Experiment	Decides	Result so far	State

If E1 passes (Kaspa-mainnet posting at ≤ $0.005 per transaction, median inclusion ≤ 5 s, and no objection from Kaspa's core developers), Kaspa-anchored finality is replaced by Based ZKas. If E2 fails, the long-term pool falls back to a Pasta/Halo 2 design and post-quantum soundness waits for upstream. Orchard plus a multi-asset pool, tagged channels and Based ZKas are the hedge if the STARK pool dies.

05Rejected after analysis

Each was measured or argued against in the research and is not on any plan.

06Core decisions waiting on the owner

Decision	What it unblocks

Sources: the October 2026 consensus round (16 lenses), the deep round and its errata, the 14 core specs with their reconciliation and fixes, the forks study with experiments E1–E11, the wallet-daemon and client work, and the implementation logs, reconciled and checked against zkas-rusty main 045a7b42, the v1.0.12 node tag (d2c97763) and the 1.0.52-rc18 wallet engine pin on 28 October 2026. Dev-month figures are the specs' own estimates and are unchecked (±50%). Where a later spec overruled an earlier round, this page follows the later spec. Details of open, exploitable issues are left out until the fixes are deployed. Source code: zkas.info/code.