Understand/Limits & status

Limits & status

The honest boundary of the system: what exists, what does not, what cannot, and where it has already broken. Designing against an imagined feature set is the single largest source of wasted effort on this chain.

Unbuilt primitives9none are consensus-blocked

Structurally impossible6no VM, one asset

External audits0of the ZKas circuit delta

Post-quantumnoharvest-now-decrypt-later

51% of ZKas~7%of Kaspa hashrate

Not built yet

These gate most advanced designs. None exist in code today — plan around them, or propose building one.

Primitive	Status	What it gates
Adaptor signatures	0 code; re-randomizable Schnorr exists, so it is buildable	atomic swaps, DLCs, delivery-versus-payment, trustless escrow
Bonded oracle	0 code; the scheme is sound	every conditional or market product
FROST / threshold signing	ships in a dependency but unwired; the spend path is single-signer	multisig, organisational custody, trustless group funds
Per-note relative timelock	absent; needs a new note field, a changed commitment, a new circuit input and regenerated keys fork	vaults, payment channels, robust refunds
Cross-curve DLEQ	0 code	trustless BTC or XMR atomic swaps
Supply-reducing burn	built but gated off fork	verifiable supply reduction. A Nothing-Up-My-Sleeve address freezes value today — it stays counted in supply
KAS↔ZKAS peg	built and gated; blocked externally	Kaspa cannot mint or track a pegged token
2-of-2 co-signed notes	not wired	the minimum ZKas-side escrow
Diversified address derivation	Orchard supports it; nothing in the stack derives index > 0	per-customer deposit addresses — use memos instead

Not possible on the base chain

Do not design these as base-layer features. structural

Idea	Why not
AMM, order book, continuous perpetuals, pooled lending	need shared mutable state and an execution environment. There is no VM
Native stablecoin or any second asset	one `u64` value, no asset id. Multi-asset is a circuit and consensus fork
On-chain recurring pull payments	no VM; recurrence is client-side re-payment of push invoices
Uniqueness or anti-double-pledge registries	the nullifier accumulator is a MuHash — no non-membership proof exists
Markets settled on hashrate or difficulty	only the shielded state root is committed, not difficulty or hashrate
A Kaspa covenant controlling a ZKas note	notes have no script and one spend key. See the Kaspa interface

Rich shared-state DeFi is possible beside the chain: on a Kaspa-side rollup with a wrapped representation, where privacy applies at entry and exit only.

Measured performance

Spend proving (Halo 2): ~2.4 core-seconds per note spent — ~0.79 s wall per note at 3.13 of 4 cores. One proof already saturates the box, so there is no idle CPU to parallelise into
Practical spend capacity: 38 notes per transaction; 37 payees per send_many
Witness build, 38 notes: 538.8 ms (was 94.7 s for 2 notes before SubtreeCache)
Per-send witness cost at 200K leaves: 29.36 s → 0.357 s (82×)
Wallet scan split: ~80% public tree work, ~20% per-viewing-key trial decryption
Cross-device sync: a second device with the same seed clones a scan in ~32 ms
Compact history archive: ~148 bytes per action
GPU trial decryption: Pallas scalar mult at 1.567 µs — 52× one core, 12.7× the whole box, byte-identical output
L2 settlement, real Groth16: 24.8 s proving, 222,668-byte seal, ~26.2M cycles; end-to-end suite 4/4 in 256.94 s

Failures already encountered

All fixed. Listed because re-proposing the broken pattern wastes time, and because they show where this design is genuinely sharp.

Dropped-spend fee inflation: A dropped spend's fee was re-minted in the coinbase, creating unbacked supply. The coinbase must use applied fees only
Sibling coinbase collision: Parallel siblings share parent, mergeset and miner, and the coinbase commits the parent's root — so the original note seed made siblings mint byte-identical notes and identical tree roots. Fixed by mixing the block hash into the seed
Fail-open anchor source: When a source block's DAG data was pruned the check failed open — an inflation vector. Now fail-closed with peer-attested blue scores
DAG-order wallet ingestion: Clients ordering blocks themselves corrupted wallet trees. The tree is position-dependent, so order is the data
Reorg nullifier visibility: Staged database deletes are invisible to reads until written, so a down-walk revert must be committed before the up-walk re-applies
Template cache rewriting outputs.last(): Hijacked the dev-fee output and lost ~80% of blocks on the reference pool. See template caching
O(chain) witness climb: 93% of send time was the witness, not the proof. The intuitive bottleneck was the wrong one

Known weaknesses

Counterfeiting inside the pool would be invisible. The turnstile bounds what can leave — never more than was issued — but it never measures what is inside, and with no live peg there is effectively no exit seam. A circuit soundness bug could therefore dilute holders indefinitely with no public figure looking wrong. Detection would come from finding the bug, not from accounting.

The circuit delta is unaudited: Upstream Orchard is audited; our fork plus performance ports is not, and the shielded GHOSTDAG core has had no external audit
Disclosure is neither scoped nor revocable: No ZIP-32, so one seed means one viewing key for everything it ever received
Anonymity depends on concurrent volume: Not on cryptography alone. Coinbase leaves add tree size without adding confusion
Security is proportional, not inherited: 51% of ZKas is ~7% of Kaspa's hashrate, and that fraction shrinks as Kaspa grows
Acquisition is constrained: Mining is currently the only ungated way to obtain ZKAS; the trustless peg is blocked
Not post-quantum: Encrypted notes are subject to harvest-now-decrypt-later
One DNS seed: seed.zkas.info is a real single point of failure for bootstrap discovery

Verified against zkas-rusty at zkas-v1.0.9. Byte layouts, endpoint shapes and parameters are read from source; figures marked measured come from the live mainnet node. If this page contradicts the code, the code is right — report it.