ZKas

Contents

1 · Introduction

Most public blockchains expose every balance and every payment to anyone, permanently. Ledgers that hide this information exist, but the ones with the strongest guarantees run on linear chains that confirm in minutes, so privacy has come bundled with low throughput and high latency.

Kaspa showed that proof-of-work need not be slow. Its GHOSTDAG protocol generalizes Nakamoto consensus from a single chain to a directed acyclic graph of blocks and orders that graph into one agreed sequence, while producing blocks in parallel at ten per second. The result is sub-second settlement without weakening proof-of-work security. Kaspa's ledger, however, is fully transparent.

ZKas combines the two: Orchard's confidentiality on a GHOSTDAG BlockDAG. This is workable because an Orchard transaction is self-contained. It balances its own value through homomorphic commitments and proves its own validity in zero knowledge, independent of the order of other transactions. Only two structures are globally order-sensitive: the set of spent-note nullifiers and the Merkle tree of note commitments. A BlockDAG already linearizes its accepted transactions, and ZKas advances those two structures along that existing order. Confidentiality therefore adds little latency, and the problem that usually makes a private chain hard — keeping global state consistent under parallel block production — reduces to reusing an ordering the engine already computes.

Two properties follow from making privacy mandatory. Because there is no transparent pool to reconcile against, supply integrity has to be enforced directly as a consensus rule rather than observed after the fact. And because there is no transparent fallback, every participant scans continuously and every spender must be able to produce a proof, which makes wallet performance a protocol concern rather than an afterthought.

2 · Inspirations & related work

ZKas reuses established cryptography and consensus, and adds new engineering only where combining them requires it. It draws on four bodies of work.

2.1 Kaspa & GHOSTDAG

The consensus engine, block structure, virtual-chain processor, difficulty machinery, and UTXO conflict-resolution model are inherited from rusty-kaspa. GHOSTDAG (the PHANTOM line of work) is what lets blocks be mined in parallel yet still be totally ordered, and it is precisely this after-the-fact linearization that ZKas exploits to serialize its shielded state. The consensus engine is otherwise left untouched: the only surgery is inserting the shielded state transition into the accepted-order path.

2.2 Zcash & Orchard

The privacy layer is Orchard — Zcash's third-generation shielded protocol — reused through the audited orchard crate rather than re-implemented. Orchard's Action (a merged spend-and-output), its Pedersen value commitments, its Sinsemilla note-commitment tree, and its nullifier derivation are adopted as-is. Critically, Orchard has no interstitial treestates: transactions within a block do not chain tree state to one another, which is what makes the three-tier construction of §6 possible.

2.3 Halo 2

Statements are proven in Halo 2 over the Pallas/Vesta ("Pasta") curve cycle. Halo 2 needs no trusted setup — a decisive property for a coin with no trusted-setup ceremony and no privileged parties — and its inner-product argument supports both batch verification and, ultimately, recursive proof composition, the two levers ZKas uses to make shielded verification scale (§9).

2.4 Monero & Mina (forward influences)

Two systems shape the roadmap rather than v1. Monero's Full-Chain Membership Proofs (FCMP++ / Curve Trees) point toward an anonymity set spanning the entire history rather than a single anchor's tree, and their tree structure is an even cleaner fit for a DAG. Mina's recursive-proof architecture points toward per-chain-block aggregation and, at the limit, a single succinct proof for the whole shielded history. Both are treated as future upgrades, and the tree/membership module is kept behind an interface so the swap is possible without re-architecting consensus.

3 · Design goals & threat model

Goals

• Confidential by construction. No transparent transfer type. Amounts, senders, and recipients are hidden for every payment; the sole public quantity is the fee a spender chooses to expose to the miner.
• Fast. One block per second, roughly one-second settlement — privacy without surrendering throughput.
• Sound money. No inflation bug can silently counterfeit. A supply violation halts the chain rather than debasing it.
• Fair. Proof-of-work issuance with no venture allocation; CPU/GPU-mineable from block one at the low-difficulty launch, and merge-mineable with Kaspa.
• Upgradable privacy. A membership argument that can migrate to full-chain proofs later.

Adversary & assumptions

The network adversary controls a minority of hash power and may reorganize the recent tip, produce conflicting parallel blocks, and attempt double-spends; GHOSTDAG's security bounds hold as in Kaspa. The privacy adversary observes the full public DAG and all network traffic and attempts to link, deanonymize, or forge. The economic adversary attempts to create value through any seam — malformed coinbase, value-commitment edge cases, dummy/zero-value notes, or a spend against an anchor from an abandoned branch. ZKas assumes it inherits latent bugs from the code it forks: in 2026 a missing equality constraint in a Halo 2 scalar-multiplication gadget allowed nullifier forgery and silent pool inflation in live Orchard, undetected for four years of expert review. The turnstile invariant (§8) exists precisely so that such a class of bug degrades to a halt, not a counterfeit.

4 · Consensus: the GHOSTDAG BlockDAG

Blocks reference multiple parents and form a DAG. GHOSTDAG selects a k-cluster of well-connected blocks, derives a single selected chain, and from it a total order over every block and transaction in the graph — the same order used to resolve transparent UTXO double-spends (first occurrence in accepted order wins). The virtual block represents the current tip of this ordering, and the virtual-chain processor is where the ledger's state is advanced.

ZKas runs this engine at a target of one block per second (1 s spacing). Everything that follows hooks into a single point: the place where the processor has already linearized the accepted transaction set. That linear order is the substrate on which the private state becomes deterministic.

5 · The shielded value layer

5.1 What an observer sees

A shielded transaction is a new transaction version carrying an Orchard bundle in its payload and no transparent inputs or outputs. The bundle contains a set of Actions, one Halo 2 proof, a binding signature, a public value balance, and the anchor its spends prove against. Each Action reveals exactly three things:

• a nullifier — a unique, unlinkable tag for the note being spent, which prevents double-spends without revealing which note;
• a note commitment (cmx) — the on-chain commitment to a newly created note, a leaf for the tree;
• a net value commitment (cv_net) — a Pedersen commitment to (value in − value out) that hides the amount while remaining additively homomorphic.

Amounts, addresses, and the spend/output link are never disclosed. Balance is proven homomorphically through the value commitments; membership, ownership, nullifier correctness, and well-formedness are proven in zero knowledge by the Halo 2 proof.

5.2 Two pieces of order-sensitive global state

Only two structures must be globally consistent:

• The nullifier set — every nullifier ever spent. Append-only, checkable forever; a repeat is a double-spend.
• The note-commitment tree — a fixed depth-32 Sinsemilla Merkle tree of all note commitments. Its root is the anchor.

Everything else in a shielded transaction is self-contained: each transaction balances its own value locally, and Orchard's absence of interstitial treestates means transactions in a block do not chain tree state to each other. Hence the only ordering that matters is at the level of these two structures.

6 · Shielded state on a DAG — the core construction

This is the one component of ZKas that is genuinely new; everything else is integration.

6.1 The three-tier commitment tree

The note-commitment tree is built in three layers, so that the only serialized step is as small as possible:

• Bundle subtree — built entirely by the wallet from a single transaction's new commitments. No consensus involvement; order-independent.
• Chain-block subtree — accumulated when a block is processed, from the bundle contributions it carries. Parallel blocks build their own subtrees with zero contention.
• Global tree — advanced only inside the virtual processor, by appending finalized chain-block subtree roots in GHOSTDAG accepted order. This is the single serialized operation, and the engine already produces that exact order.

6.2 The state transition

At the point where the processor linearizes the accepted set, ZKas appends the following steps immediately after the transparent UTXO update, per accepted chain block, in order:

1. Resolve nullifier conflicts. For each Action in accepted order, if its nullifier is already present, the transaction is a conflict and is dropped — identical to a double-spent UTXO. First occurrence wins.
2. Insert surviving nullifiers into the set.
3. Append the block's chain-block subtree to the global tree, producing the new anchor.
4. Check the turnstile invariant (§8) holds after the update.
5. Record the new anchor so that later spends can prove against it once it matures.

Because steps 1–5 run in the already-linearized accepted order, every honest node computes an identical nullifier set and an identical anchor. That is the entire solution to the DAG-ordering problem — no new agreement protocol, no locking, no global mutex on the tree.

6.3 Why this scales

No part of the per-transaction cost depends on the block rate. Wallets build bundle subtrees offline and in parallel; blocks build chain-block subtrees in parallel with no contention; and the one serialized step, appending to the global tree, is a handful of Sinsemilla hashes per block over a ~32-node frontier rather than the whole tree. The private layer inherits the DAG's parallelism instead of collapsing back to a single-threaded chain, so confidentiality does not reintroduce the latency of a linear private ledger.

7 · Anchors, finality & reorg safety

The selected chain reorganizes its recent tip frequently, so a spend must never prove against the volatile tip. Orchard permits proving against any historical anchor at no extra cost, so ZKas requires spends to reference a matured anchor — one buried at least shielded_anchor_depth blocks deep, roughly ten minutes at one block per second — after which reorg probability past it is negligible. At this block rate even a ten-minute-old anchor already commits to an enormous note set, so the anonymity cost of "deep" anchors is negligible.

Maturity alone is not sufficient; the anchor must also be canonical. ZKas indexes each anchor to the chain block that produced it and, at validation time, accepts a spend only if that source block is a selected-chain ancestor of the spending block (decided by the reachability service) and at least shielded_anchor_depth deep. An anchor produced on a branch that a deep reorg later abandoned fails the ancestry test by construction, closing a value-creation vector in which a note could otherwise be "un-spent" by a reorg while its spend remained valid. Coinbase-funded, output-only bundles carry the empty-tree anchor and are exempt, since they reveal no nullifier.

8 · Supply integrity: the turnstile invariant

In an all-shielded chain there is no transparent ledger to cross-check, so the supply invariant is the anti-inflation mechanism. It is a hard consensus rule from the first block:

Enforcement has two parts, and their division matters: the design is easy to misread as missing a check that is in fact neither necessary nor possible.

8.1 The public ledger

An integer accounting tracks subsidy minted into the pool and fees removed from it. After every accepted block the pool value must be non-negative — a negative pool would mean value was spent that was never issued. Because a shielded transaction's fee is re-minted in the coinbase of the block that merges it, the pool nets to the cumulative subsidy over the fee cycle: fees are neither burned nor inflationary.

8.2 Homomorphic balance, per bundle

Each bundle's binding signature verifies under the key

which is a valid key iff the bundle's true net value equals its declared, public value_balance. Since consensus takes that same value_balance as the transaction's fee — and requires it to be non-negative, so no ordinary transaction can mint — the integer ledger above is fed cryptographically pinned numbers. The homomorphic anti-inflation guarantee is therefore enforced per bundle, and it is already active.

8.3 The coinbase seam

Mining rewards are created from nothing and so have no input note. A coinbase output is a note commitment with a publicly stated value, checked against the emission schedule and entered into the turnstile as minted supply; the recipient's Orchard address travels in the reward script. After one hop the note is indistinguishable from any other. This is the single point at which value visibly enters the system, and it is verified against the exact expected coinbase for the block, so a miner cannot mint more than consensus allows.

9 · Verification & scalability

A shielded proof costs on the order of 100–700× a signature check, so at one block per second naive per-Action verification would still overwhelm a node under load. ZKas addresses this in layers.

Encoding & soundness gates (implemented)

Every bundle is checked for the three independent properties that make private value trustworthy: balance (the binding signature), membership + authority + nullifier integrity (the Halo 2 proof against the audited upstream circuit), and spend authorization (per-Action randomized-key signatures over a domain-separated sighash that binds each bundle to this chain and this transaction, preventing cross-network and cross-transaction replay). Consensus additionally rejects non-canonical field encodings and, following the 2026 disclosure, identity-point randomized and ephemeral keys that could split consensus by panicking a verifier. A node built without proof verification refuses shielded transactions outright, rather than admitting an unverified bundle.

Batch & parallel verification (implemented)

Halo 2 inner-product openings and RedPallas signatures both batch, so a block's worth of bundles is verified together for far less than the sum of their individual costs; and because the DAG is inherently parallel, independent blocks verify concurrently across cores.

Recursive per-chain-block aggregation (roadmap)

The decisive lever is recursion. Each accepted chain block can emit a single Halo 2 accumulator proof attesting that all of its shielded Actions are valid and that the global tree advanced correctly from the old root to the new one. Nodes then verify one proof per chain block instead of one per Action, decoupling verification cost from transaction count. Pushed to its limit this becomes incremental verifiable computation over the chain of tree states — a syncing node verifies essentially one recursive proof for the entire shielded history. This is the throughput unlock that lets a private ledger sustain high block rates; it is specified and architected for, and is the primary engineering objective beyond the initial launch.

10 · Proof-of-work: kHeavyHash & merged mining

ZKas secures block production with kHeavyHash — byte-for-byte the same proof-of-work as its parent chain, Kaspa. This is a deliberate design choice, not an incidental inheritance: sharing Kaspa's algorithm makes ZKas merge-mineable with Kaspa, so one hashing effort can secure both chains at once. For a young network, security borrowed from an established chain — at zero marginal cost to that chain's miners — is a stronger and more honest bootstrap than an isolated hashrate that must be grown from scratch. For a shielded chain the decisive protection against a chain reorg is finality, not raw hashrate (§7): spends prove only against a matured, canonical anchor, so merged mining is a security amplifier on top of that guarantee rather than the sole line of defense.

Under merged mining ZKas is the auxiliary chain and Kaspa the parent: a miner embeds a 32-byte commitment to its ZKas block in the parent coinbase, mines Kaspa normally, and any solution clearing ZKas's own target yields a valid ZKas block — proven by the parent header plus a Merkle path to that commitment. ZKas sets its own difficulty and is never slaved to Kaspa's; because that target is typically far easier, the great majority of hashes that fail Kaspa's target still secure ZKas. Blocks are admitted by dual acceptance — valid if they carry either a native kHeavyHash header or a valid auxiliary proof — so liveness never depends on merged-mining participation: native mining is always the backbone, and merged mining augments security as it is adopted.

The launch difficulty follows a three-phase schedule so that ordinary hardware can mine from block one without leaving the chain permanently easy to attack:

• Low-difficulty start — the first ~50,000 blocks (~1.4 h) are pinned to a very easy genesis target, so a bootstrap fleet of CPUs/GPUs can mine immediately.
• Ramp — over the next ~200,000 blocks the difficulty ceiling tightens geometrically toward real network difficulty; the standard difficulty-adjustment algorithm takes over the moment the ceiling drops below actual difficulty, so there is no post-launch cliff.
• Steady state — from roughly blue score 250,000 (~7 h in) onward, difficulty is governed entirely by the block-rate target.

11 · Monetary policy & emission

Issuance is proof-of-work only, with no venture or investor allocation. Rewards enter the mandatory shielded pool as coinbase notes (§8.3), so even newly issued coins are private after a single hop.

11.1 Key figures

The block reward begins at 60 ZKAS per block (60 ZKAS per second at one block per second) and follows a smooth decay that halves every three months from genesis. The curve does not fall to zero: it is caught by a two-step perpetual tail. The decay crosses 6 ZKAS per block around month 10, and that floor is paid through month 24; the reward then steps down once to 3 ZKAS per block and stays there permanently. The final 3 ZKAS/block tail — roughly 95 million ZKAS per year — funds proof-of-work security indefinitely rather than leaving miners to rely on fees alone. There is therefore no fixed supply cap; issuance is steeply disinflationary early and settles onto a low constant floor in the long run.

11.2 Halving schedule

The schedule is front-loaded: a fast three-month halving distributes most coins in the first year, after which the reward is caught by the tail and issuance slows sharply. The curve halves 60 → 30 → 15 → 7.5 ZKAS over the first four quarters, crossing the 6 ZKAS first-step floor around month 10; that floor holds through month 24, then steps down once to the perpetual 3 ZKAS floor. The figures below are computed from the on-chain per-block subsidy schedule.

The per-block reward tracks the shape of Kaspa's emission table, divided by the block rate so per-second issuance is rate-invariant, with two ZKas-specific transforms: every value is scaled by 3/22 (setting a per-second rate of 60 ZKAS/s versus Kaspa's unscaled base), and the table is traversed four times faster so a full halving takes three months rather than a year. At the live one-block-per-second rate this yields 60 ZKAS/block. Once the curve decays below the tail it is replaced by a fixed floor — 6 ZKAS/block through month 24, then 3 ZKAS/block forever — giving the two-step perpetual tail. Because the schedule is defined per second and divided by the block rate, per-second issuance is rate-invariant and there is no over-issuance.

12 · Keys, wallets & disclosure

ZKas uses Orchard's key hierarchy: a spending key (spend authority), a full viewing key, an incoming viewing key, and an outgoing viewing key, with diversified addresses. A wallet tracks a Merkle witness per owned note, advancing it as the global tree finalizes, and detects spends of its own notes by matching on-chain nullifiers. A reference wallet builds, proves, and submits real multi-note shielded payments — selecting input notes, adding a recipient output and change, and paying the fee as the bundle's value balance — against a matured anchor.

12.1 Selective disclosure

Viewing keys provide opt-in transparency: a holder can reveal their own transaction history — for an auditor, an exchange, or a counterparty — without exposing spend authority and without weakening anyone else's privacy. Disclosure is a choice made by the coin's owner, not a property forced on the network. By Orchard's key separation, delegated services (e.g. proving, §15) can be handed the material they need without ever gaining the ability to spend.

13 · State growth & fees

Two structures grow monotonically. The note-commitment tree is append-only, but nodes need only its ~32-node frontier; wallets hold their own witnesses. The nullifier set, by contrast, can never be pruned — a spent note must remain un-spendable forever. This is irreducible; the design bounds the rate rather than eliminating it. ZKas extends Kaspa's KIP-9 storage-mass formula to price nullifier and commitment insertion, so that shielded-dust spam costs roughly what transparent dust already costs on Kaspa and cannot be used to bloat consensus state cheaply.

14 · Comparison

Block times are nominal. ZKas settles roughly 750× faster than Zcash and 1,200× faster than Monero while shielding every transaction by default — the combination this design exists to demonstrate.

15 · Roadmap & next steps

Stage 1 — Shielded mainnet

A proof-of-work launch on a one-block-per-second GHOSTDAG BlockDAG with shielded-by-default coinbase and payments, the turnstile invariant enforced from block one, matured reorg-safe anchors, native kHeavyHash mining, and batched/parallel verification. This is the foundation the rest builds on.

Stage 2 — Full-chain membership proofs (FCMP)

Migrate the membership argument from per-anchor Orchard trees toward FCMP++ / Curve Trees, so a spend's anonymity set becomes the entire transaction history rather than a single anchor's note set. The membership/tree module is deliberately kept behind an interface so this is an upgrade, not a rewrite — and the resulting tree structure is an even cleaner fit for the DAG.

Stage 3 — Private smart contracts

Extend the shielded model from payments to programmable state: confidential contracts whose logic executes and whose state transitions verify in zero knowledge, so that programmability does not reintroduce the transparency it was built to avoid. This is the long-horizon direction — private computation on a fast BlockDAG.

Cross-cutting engineering

• Recursive aggregation / IVC — one proof per chain block, then one for the whole history; the core scalability unlock (§9).
• Light-wallet infrastructure — indexer, compact filters, oblivious sync, delegated and GPU-assisted proving.
• Audit & formal verification — independent review of the circuit, a public high-block-rate testnet soak, and a real bug bounty before final launch.
• Multi-node network — seeders and shielded-state sync for pruned and fast-bootstrapping nodes.
• Merged mining — full deployment of auxiliary-proof propagation and merged-mining pool tooling, so ZKas can be secured alongside Kaspa at zero marginal cost (the auxiliary-proof verifier is already built and tested).

16 · Conclusion

Privacy and throughput have looked like a tradeoff largely because private ledgers were built on linear chains with opt-in confidentiality. ZKas changes both: privacy is the default, and the shielded state transition runs along the order a GHOSTDAG BlockDAG already produces. The result is Orchard-grade confidentiality at roughly one-second settlement, with supply integrity enforced as a consensus rule rather than assumed. The remaining work — recursive verification at scale, light-client infrastructure, full-chain membership, private programmability, and independent audit — is substantial but well understood. The design goal is a proof-of-work currency that is fast, openly mineable, and private at once.

References

1. Y. Sompolinsky, S. Wyborski, A. Zohar. PHANTOM & GHOSTDAG: A Scalable Generalization of Nakamoto Consensus. ia.cr/2018/104.
2. rusty-kaspa — reference implementation of the Kaspa BlockDAG. github.com/kaspanet/rusty-kaspa.
3. Electric Coin Company. The Orchard Book — commitment tree (depth 32, block-boundary anchors), nullifiers, keys. zcash.github.io/orchard.
4. ZIP-224 — Orchard shielded protocol. zips.z.cash/zip-0224.
5. Zcash Protocol Specification (normative; Orchard sections). zips.z.cash/protocol/protocol.pdf.
6. S. Bowe, J. Grigg, D. Hopwood. Halo 2 — recursive proof composition without trusted setup; Pasta curve cycle. zcash.github.io/halo2; Halo paper ia.cr/2019/1021.
7. Monero Research Lab. Full-Chain Membership Proofs (FCMP++ / Curve Trees). getmonero.org/2024/04/27/fcmps.html.
8. BlockSec. Analysis of the 2026 Zcash Orchard soundness bug (missing-constraint nullifier forgery / pool inflation). blocksec.com.
9. Kaspa Improvement Proposals — including KIP-9 storage mass. github.com/kaspanet/kips.

Appendix · Parameters at a glance

This whitepaper describes the ZKas protocol. Sections marked (roadmap) describe planned work; all other mechanisms are specified and, in the reference implementation, built. Parameters may be finalized at spec freeze prior to mainnet. Nothing herein is investment advice.