ZKas — the six questions

Six questions people
actually ask about ZKas

Short answers, with the real numbers — including the ones that do not flatter us.

Block time1 smeasured 1.016 blocks/s
Network hashrate50.9 PH/smerged-mined with Kaspa
Notes in the tree6,184,135every one shielded
Left the pool, ever0turnstile out
01

Why one block per second, and not ten?

Because on a shielded chain, every block spends privacy — and ten blocks a second spend it ten times faster without giving users anything they can feel.

Each block mints a coinbase note into the same tree that users hide in. Coinbase notes are public: anyone can recompute their recipient and value. They make the tree bigger without making it more confusing.

One day of leaves added to the anonymity set 1 block/s 86.4k public coinbase leaves + whatever users actually send 10 blocks/s 864k public coinbase leaves + exactly the same user traffic Ten times the public noise. Identical private signal.
The user traffic is set by demand, not by block rate. Raising the block rate only multiplies the part of the tree an observer can already read.

What one second actually buys

Finality4 blocksThe deepest reorg in 2,000 observed

The histogram is 1,745 at depth 1, 223 at 2, 31 at 3, one at 4. The deepest this node has ever recorded is 5. Waiting ten seconds puts you beyond every reorg in the chain's history — the same safety margin an exchange buys on Monero by waiting twenty minutes.

No fee market1.0 = 1.0Priority costs the same as low

The estimator quotes feerate 1.0 for the priority, normal and low buckets alike, at a 1-second ETA. Capacity exceeds demand by enough that there is nothing to bid for. Private payments do not get priced out during a rush.

Cost per note2.4 sProving stays on consumer hardware

Cost is per note spent, not per block. Ten times the blocks would not change a user's proving bill by one cycle — it would multiply the per-block verification and state-transition overhead carried by every node on the network.

Set quality91.1%The share of the tree that is already public

One coinbase mint per block is the floor the emission schedule imposes. Raising the block rate raises that floor. One block per second keeps the publicly readable share of the anonymity set as low as the design allows.

We tested the alternative. The testnet ran at 14 blocks per second in July. It bought nothing anyone could perceive and multiplied the shielded verification load on every node. We brought it to one and kept it there.
02

Be honest about the anonymity set

"Isn't the pool small enough to be trackable?"

Partly, yes — and here is the exact shape of it, because a privacy project that rounds this up is not worth trusting.

6,184,135 notes in the commitment tree coinbase mints — recipient and value are public 8.9% 91.1% 547,298 user notes — the honest plausible set for any one spend For scale, a Monero ring hides one spend among 16 — the same job, four orders of magnitude apart 340,666 notes have ever been spent — 5.5% of the tree. The rest has never moved.
Live mainnet figures. The tree is large; the part of it that carries real entropy is smaller, and we would rather say so than quote the headline number.

What this model gives you that a ring cannot

Attack surfaceNo decoy selection to analyse

Most published deanonymisation work against ring signatures attacks how decoys are chosen — their age distribution, their reuse, their correlation with real spends. A zero-knowledge membership proof has no decoys, so that entire branch of research has nothing to grip.

DirectionThe set only ever grows

It cannot shrink, and it grows every second whether or not a single user transacts, because mining appends to it. There is no parameter to tune, no hard fork needed to raise a ring size, and no version of the chain where yesterday's privacy gets weaker.

Fragmentation1 poolNot four

Zcash splits its users across transparent, Sprout, Sapling and Orchard, and each migration resets the set. ZKas has one pool, from genesis, with no transparent tier to leak into and no future migration to dilute it.

Front-runningMEV has nothing to read

Extractable value needs a readable mempool: visible amounts, visible recipients, visible ordering intent. Here a pending transaction exposes none of those. Sandwiching and front-running are not mitigated, they are structurally absent.

FungibilityNo lineage, so no taint

Every note is structurally uniform. There is no history to trace, so no coin can be blacklisted, frozen or discounted for where it has been — the failure mode that produces tainted-BTC discounts and frozen stablecoin balances.

BehaviourUsing privacy is not an event

On an opt-in chain the choice to shield is itself a signal, and it is the signal surveillance firms actually cluster on. Here there is no choice to observe: the coinbase is shielded, so even miners are in the set by default.

Said plainly. If you are the only person transacting in a ten-minute window, timing analysis can narrow you down. That is true of every privacy chain at low volume, and we are not going to pretend otherwise.
03

Why fork Kaspa instead of building on it?

"Why a separate network rather than a layer on Kaspa?"

Because privacy only works if it is mandatory, and you cannot make an existing chain mandatory in retrospect.

Privacy bolted onto a transparent chain every output is visible by default opt-in pool choosing it is the signal and the old history stays public forever ZKas there is no transparent output type the whole chain is the pool including the coinbase, from genesis nobody is flagged for using it Same proof of work. Same miners. Different rule about what an output may be.
This is the whole argument in one picture: an opt-in pool starts empty and marks its users; a mandatory one starts full and marks nobody.

What the fork actually bought

CompoundingMining grows the anonymity set

Because the block reward is itself a shielded note, the set is fed by hashrate, not only by usage. A new privacy chain normally has to win users before it has privacy. This one accrues a set from the day it starts, which is the bootstrap problem solved backwards.

StoragePruning that protects funds

Forking let us diverge where it matters: block bodies are pruned, the note archive and nullifier set never are. A pruned node still serves complete wallet history from its first sync. Nobody had to keep an archival node alive for users to recover money.

AlignmentWe take security without taking anything else

Merged mining means we consume none of Kaspa's block space, none of its fee revenue and none of its hashrate — the marginal cost of the second chain is zero. Two chains that would have fought over one consensus instead compound.

FreedomDesign decisions they could never make

Mandatory privacy, a shielded coinbase, a consensus-enforced append order and a supply turnstile are all things a live transparent chain with real holders cannot adopt without breaking everyone already on it.

one kHeavyHash grind Kaspa block → KAS ZKas block → ZKAS tested against two targets
Fork for the rules; merge-mine for the security. A Kaspa miner earns ZKAS at essentially zero additional cost.
04

What is inherited, and what had to be rebuilt?

We kept the engine. We replaced what a block means.

Kept from Kaspa, unchangedRebuilt for privacy
kHeavyHash proof of work — byte-identical. The same ASICs, the same stratum, the same difficulty maths, no miner changes at all. Every output is an Orchard note. There is no transparent output type on mainnet, and the block reward is minted directly into the shielded pool.
GHOSTDAG BlockDAG consensus — parallel blocks, one-second cadence, the ordering rule that makes it work. A second consensus state machine beside the UTXO set: a note-commitment tree, a nullifier accumulator, and a public supply turnstile.
Networking, sync and pruning architecture, the transaction mass and fee model, and most of the RPC surface. Append order became consensus. Coinbase mint first, then accepted actions in applied order. The tree is position-dependent, so on a DAG the order is the data.
The mempool and relay policy, inherited and then tightened for shielded standardness. The shielded state root sits in the coinbase, committing the parent's state. It is proof-of-work anchored, so a divergence surfaces as a rejected block rather than silent drift.
— Pruning had to diverge. Block bodies are pruned; the note archive and nullifier set never are. The reason is user funds.
— Aux-PoW, so a Kaspa block can carry our work.

What the rebuild bought, in practice

TrustState you can check, not state you are told

The shielded root lives inside the coinbase, so it carries the block's proof of work. A client can verify the chain's shielded state without trusting the server that served it, and a divergence shows up as a rejected block rather than as quiet drift nobody notices for months.

BootstrappingHistory from a stranger, verified

The tree frontier is a pure function of the leaf sequence, so replaying history must reproduce a value the node already holds and never learned from the peer. Fabricate, omit, reorder or truncate and it will not match. Peers do not have to be trusted or reputable.

Restore32 msA second device clones a scan

A wallet birthday is placed anywhere in history in a single call using the node's DAA locator, and a second device holding the same seed adopts a twin checkpoint in about thirty milliseconds. Restoring a private wallet stops being an overnight job.

Audit0Sompi that have ever left the pool

The turnstile is public integers: issued minus fees minus burns. Anyone can pull it from any node and check that the pool has never been drained. Hidden amounts do not have to mean an unverifiable money supply.

One consequence worth stating. Because the coinbase is shielded and the state root is inside it, a ZKas block cannot be validated by ignoring the privacy layer. Privacy is not a module that can be disabled — it is load-bearing structure.
05

If Kaspa adds its own privacy, is that good or bad for ZKAS?

Good — and not for a hand-waving reason. The best Kaspa can ship is opt-in privacy, and opt-in is the failure mode we exist to avoid.

The technical tension, stated precisely. Kaspa's roadmap is covenants, transaction introspection and zk verification opcodes — a script layer that works by reading transaction data. A shielded output has nothing to read: no script, no amount, no recipient, one spend key. The more capable Kaspa's introspection becomes, the less of it applies to a shielded output. Their direction and full shielding pull against each other; ours does not have to.

Every branch ends well for us

If they ship opt-inWe become the mandatory venue

Their pool starts empty and marks its users. Ours is the whole chain. The comparison gets easier to make, not harder, because there is finally a familiar example of the thing we are not.

If they ship OrchardOur tooling transfers

Same circuit family, same viewing-key model, same note format. Our wallets, SDK, signer and scanning work would largely apply — and we would have years of operational experience running it in production that a fresh deployment does not.

If they ship nothingNothing changes

We are merged-mined either way. Their hashrate growth raises the cost of attacking us whether or not a single privacy feature ever lands.

Either wayThe asset stays distinct

Privacy on Kaspa would be a feature of a transparent asset. ZKAS is a private asset. Those are different instruments with different holders, and one does not absorb the other.

The honest risk. It would compress the story and compete for attention, and we would have to explain "mandatory versus optional" to people who hear the same word twice. That is a marketing problem. It is not a technical one, and it is a much better problem than being the only project that thinks privacy matters.
06

Monero already exists. Why build another private coin?

Because Monero settles in minutes and carries nothing but money. ZKas settles in one second and can carry an authenticated public payload alongside a private payment — which is a different product, not a better slogan.

MoneroZKas
Privacymandatory ✓mandatory ✓
Hiding modelring signatures — one spend among 16 todayzero-knowledge membership in the whole tree
Settlement~2 minutes~1 second
Feessmall but real, and they rise with loadnear zero
MiningRandomX, its own network to securemerged-mined with Kaspa at zero marginal cost
Message channelno standard encrypted memo512-byte memo, encrypted and signature-committed
Selective disclosureview keys, tx proofsviewing keys, plus keyless third-party payment proofs
Supply audithard — amounts are hidden end to endpublic turnstile integers, checkable from any node
Setup assumptionnonenone — Halo 2, no trusted setup

Six things that are impractical on Monero

01 · SpeedPayments you can stand next to

One second, no fee market, no congestion premium. A private coin becomes usable at a counter, in a vending machine, inside a checkout flow or behind an API call. Two-minute blocks make private money a transfer rail; one-second blocks make it a payment rail.

02 · DataPublic protocols with private participants

The 512-byte memo rides inside the encrypted note and is hashed into the signature, so it is authenticated rather than merely attached. Publish the viewing key of a registry address and that memo becomes world-readable while addresses, amounts and wallet relationships stay private. That is enough for an NFT protocol, a marketplace, a public registry or a notarisation service — with no fork, because the mechanism already ships.

03 · DistributionAcquisition that does not need an exchange

Every Kaspa miner can earn ZKAS from work they are already doing, at zero marginal cost. For a privacy asset this is the decisive property: the exchange listing is exactly the chokepoint regulators press, and mining is the one distribution channel that cannot be delisted, sybil-farmed or gated by an on-ramp.

04 · MachinesPer-request and streaming payments

Sub-second settlement at a flat floor fee makes pay-per-call APIs, metered compute and machine-to-machine billing workable — a class of product where a two-minute wait and a variable fee are both disqualifying, and where the payer usually has excellent reasons not to be profiled.

05 · AssuranceHidden amounts, checkable supply

The turnstile is public: issued, minus fees, minus burns, verifiable from any node. A privacy chain normally asks you to take the money supply on faith. This one does not, which is the single most common institutional objection answered with arithmetic instead of argument.

06 · DisclosureProve things without publishing them

Keyless third-party payment proofs from a send-time disclosure, and proof of reserves by handing an auditor the viewing key of a dedicated seed. Compliance becomes something you grant to one counterparty, rather than something the whole world gets by default.

Where Monero is ahead, plainly. It has a decade of adversarial attention, a far larger live user base, and an audited implementation. We run Zcash's Orchard circuit unchanged, but our anonymity set is younger. We are not claiming to have replaced it — we are claiming that fast, free, mandatory privacy that can carry an authenticated public payload is a category Monero does not serve.
—

The short version

Four properties. Any three of them exist somewhere already. All four together do not exist anywhere else.

OnePrivacy is mandatory

No transparent tier, no opt-in signal, no pool to migrate between. The coinbase itself is shielded, so the set includes everyone from genesis.

TwoSettlement is interactive

About one second, with no congestion market. Fast enough that privacy stops costing the user a waiting room.

ThreeIt carries authenticated public data

An encrypted, signed, selectively discloseable 512-byte channel per action — programmable privacy without a virtual machine.

FourSecurity and distribution are borrowed

Merged-mined with Kaspa at zero marginal cost: 50.9 PH/s today, and an acquisition path that does not route through an exchange.

And what we are not claiming. Not more battle-tested than Monero — it has a decade of adversarial attention we do not. Not immune to timing analysis at low volume. Those are the real gaps, they are written down in the developer documentation rather than buried, and they are the work.
Figures are live mainnet values read from a node on 29 September 2026: 6,184,135 notes, 340,666 spends, 50.9 PH/s at 1.016 blocks per second, 0 sompi ever removed from the shielded pool. Protocol claims are verified against the zkas-rusty source at release zkas-v1.0.9. Full detail: developer documentation · whitepaper · explorer.