[PROPOSAL] Ztarknet — A Starknet L2 for Zcash

[abdel]

Shortlink to prior context: This proposal builds on the earlier forum thread, STARK verification as a Transparent Zcash Extension (TZE), i.e. enabler for a Starknet‑style L2 on Zcash.

Ztarknet POC website: https://ztarknet.cash

Ztarknet L1 testnet explorer: https://explorer.ztarknet.cash/

Why Cairo / FAQ and concerns / security, blockspace footprint, etc

---

Plain‑English overview (start here)

What we change on Zcash L1: add one narrowly scoped extension point—a built‑in STARK proof checker (using the TZE mechanism already contemplated by ZIP‑222). It does one job: given some bytes (a STARK proof + public inputs), it returns true/false inside consensus.

What that unlocks: we can run a separate, scalable Starknet‑style layer (L2) where most transactions and app logic live. The L2 posts “old state root, new state root, proof” to Zcash. Full nodes verify the proof via the TZE. If valid, L1 accepts the update. Privacy and value accounting stay with Zcash; scale and programmability move to L2.

What we don’t change: no changes to shielded pools, no new L1 scripting language, no L1 programmability features. We add one auditable verifier and keep all ZEC value conservation rules exactly as they are today.

Value proposition for ZEC holders (non‑technical)

• Keep the base layer conservative. Zcash remains the privacy‑first settlement layer.

• Get utility without L1 churn. Payments, stablecoins, perps, and other apps run on L2 with cheap, fast transactions.

• Direct linkage to ZEC:

• L2 settlement transactions pay ZEC fees on L1.

• ZEC is bridged and becomes a base asset on L2.

• Option (policy): denominate L2 gas in ZEC to deepen usage.

Honest risk summary: any consensus change is non‑zero risk. This proposal restricts the new surface to a single verifier with pinned parameters and byte‑size limits, and keeps all value accounting in existing, time‑tested code paths. That’s the prudent way to add scale.

What exactly changes on Zcash? (high‑level technical)

Mechanism: introduce a Transparent Zcash Extension (TZE) type, called (working name) STARK_VERIFY_V1.

• Purpose: verify a bounded STARK proof under pinned algorithms/parameters, returning a boolean into consensus.

• Inputs (public): a small, fixed‑format byte string containing at least:

• root_old (previous L2 state commitment),

• root_new (next L2 state commitment),

• program_or_air_id (identifies the Cairo/AIR semantics we’re verifying),

• optional data‑availability (DA) commitment (if used by the L2),

• and any other minimal public inputs required by the verifier.

• Inputs (private): the proof bytes.

• Outputs: success (true) means “the claimed transition (root_old → root_new) follows from the pinned verifier and the provided public inputs”; failure means the transaction is invalid.

Consensus & policy bounds:

• Consensus: proof byte size is capped (so verification cost is indirectly bounded). Parameters (field, hash(es), FRI settings, etc.) are pinned.

• Mempool policy: standardness rules can be stricter (lower byte caps per tx and/or per block) to be DoS‑safe during rollout.

No minting path. The TZE is pure verification. It cannot create ZEC or relax any existing conservation rules.

What does the L2 look like?

Ztarknet proposes an L2 that:

• executes Cairo programs (Starknet‑compatible),

• proves state transitions using Circle STARKs (via the Stwo/Cairo prover),

• and settles on Zcash L1 by having full nodes verify a STARK proof with the TZE.

Lifecycle of an L2 block:

1. Users submit L2 transactions to a Starknet‑compatible sequencer.

2. The sequencer executes Cairo, updates the L2 state root, and emits an execution trace.

3. A prover constructs a Circle‑STARK proof that “given root_old and the batch, the resulting root_new is correct.”

4. A submitter posts a Zcash L1 transaction embedding {root_old, root_new, (optional) DA commitment, proof} via the TZE verifier.

5. Zcash full nodes verify the proof inside consensus. If true, the L2 anchor on L1 advances to root_new.

Withdrawals & deposits (sketch):

• Deposit to L2: an L1 transaction “locks” ZEC to a bridge UTXO (transparent or unified address path), emitting a small, verifiable record that the L2 can read as an allowed credit.

• Withdraw to L1: an L2 exit operation is proven (with a STARK) and verified by the same TZE, which authorizes releasing a specific L1 output to the exiting party.

Note: This uses the same yes/no primitive—no new mint rules.

Safety & invariants (explicitly)

Inflation / counterfeiting:

• The TZE verifier does not manipulate ZEC amounts. It cannot mint coins.

• Conservation of value remains enforced by existing Zcash code paths (exactly as today).

• The verifier is pinned and bounded (algorithms, security level, byte caps), minimizing consensus surface.

DoS resistance:

• Consensus caps on proof size; validation cost tracks bytes.

• Mempool standardness can be stricter initially (e.g., lower per‑tx limits).

Soundness assumptions:

• The L1 verifier relies on the soundness of the STARK scheme (transparent, hash‑based) and the chosen cryptographic hash.

• No trusted setup. Hash security becomes the main assumption (plus classical finite‑field assumptions). This is post‑quantum‑plausible pending the hash.

L2 failure modes:

• If the L2 halts or is upgraded, Zcash L1 is unaffected. The anchor can pause; funds on L1 stay safe.

• Withdraw proofs remain verifiable on L1 as long as the verifier type is present and parameters are pinned.

Why STARKs (and Circle‑STARKs / Stwo) here?

• Transparent (no trusted setup); assumptions are mainly about hashes + FRI.

• Verification scales well (dominated by hashing; predictable cost as a function of proof size).

• Tooling exists today for Cairo/Starknet (mature developer ecosystem and provers).

Concrete deliverables & repos (work in the open)

Check the Ztarknet Github Organization repositories.

Economics & fees (initial framing)

• L1 fees: settlement transactions (posting L2 blocks, exits) pay ZEC.

• L2 fees: sequencer fees fund proving; can be denominated in ZEC (policy choice).

• Bridged ZEC: locked on L1; represented 1:1 on L2. Withdrawals provably redeem on L1.

Goal: more ZEC utility without increasing L1 complexity—activity migrates to L2 while L1 remains the conservative privacy base.

Implementation status & how to try it

• Run a local devnet: see the ztarknet repo for Docker Compose / K8s recipes (sequencer + prover + Zcash node).

• L1 experiments: use the Zebra fork to test verification on regtest/testnet.

• L2 experiments: use the Madara fork for Cairo execution/state roots.

Appendix — STARK primer

A STARK proof lets a prover convince a verifier that a computation was done correctly. It’s transparent (no trusted setup) and relies primarily on the security of hash functions and algebraic checks (FRI). Verification cost grows much slower than re‑executing the computation, so you can batch thousands of transactions, prove the result once, and verify it cheaply on‑chain. Circle‑STARKs (as implemented in Stwo) are a modern STARK instantiation with efficient Cairo support and production‑grade engineering.

Closing

Zcash is already the right privacy base layer. By adding one carefully specified, auditable proof‑checking port (TZE), we can let a Starknet‑style L2 handle scale and programmability—without entangling those concerns with L1 custody and privacy. The proposal is minimal by design: a single verifier, pinned parameters, byte caps, staged rollout, and independent review. If we do this right, we keep ZEC hard and make it more useful.

Appendix: Simple pitch (for sharing)

• Don’t change L1 privacy. Add a tiny STARK proof‑checker (TZE) so experimentation happens on L2.

• One small port, many apps. Zcash stays private; Starknet‑style L2 brings speed and programmability.

• No inflation path. TZE only returns yes/no on proofs; value rules stay unchanged.

• Direct ZEC linkage. Settlement pays ZEC; bridged ZEC is used in L2 apps; gas can be ZEC‑denominated.

[januszgrze]

I’m not familiar enough with Zcash script to know the answer here.

Is there a way to embed L2 state differentials within a transparent zcash transaction? I.e. something similar to the witness field in bitcoin.

I’m curious who is responsible for making the L2 state data available?

With a 2MB block size, I think we should also be conscious of increased L1 fees and how that affects shielded pool fee dynamics. I’m not up to date on the latest fee mechanisms, but something to consider. I do think miners should get paid, however, and this is a sustainable fee source if/when ZEC is used in these onchain applications.

All in all, I love it! A great business here is for someone to build an atomic swap protocol between Ztarknet and Orchard

[phreaknik]

Great write-up! I’m curious, would I be able to bridge directly from shielded ZEC on L1 to L2 without linking all my bridge transactions together?

[abdel]

Yes exactly, this is exactly what we imagined doing, have another extension to handle the state diffs. Agreed that we should be careful about the block size.
That’s why I suggest adding clear consensus bounds on the proportion of available block space that can use those extensions (let’s say 5-10% of block space).
We could think about having a separate fee market for some extensions also.
And finally, hybrid DA models can be used on the L2s too, as you already know.

A great business here is for someone to build an atomic swap protocol between Ztarknet and Orchard
100%

[abdel]

It would be possible in theory, but out of scope of this initial proposal. But of course this is something to think about.
I just want focus on the scalability and programmability dimensions for now, but you are right, this will have to be considered.

[januszgrze]

@abdel

That’s why I suggest adding clear consensus bounds on the proportion of available block space that can use those extensions (let’s say 5-10% of block space).

@abdel

We could think about having a separate fee market for some extensions also.

I agree with both of these paths forward being viable options.

[cybercent]

Would this still work with the updates required for Tachyon ?

[daira]

Tachyon is going to be very hard to engineer even without any complications from verifying Starks. So I would say it’s almost certain that an initial implementation wouldn’t support TZEs or any TZE-based Stark verifier.

That said, it doesn’t really have to. Tachyon will in any case have to deal with the fact that it’s infeasible to verify Zcash’s Bitcoin-like script in a circuit. It’s actually less infeasible now that there is both a Rust library for Zcash script, and VVMs [Verifiable Virtual Machines] for RISC V, which is a Rust target platform. But the performance of doing it that way would be terrible compared to specialized circuits, and I can’t say I really trust those RISC V VVMs; they are very complicated. Therefore what Tachyon will probably do is just to not attempt to scale the transparent part of the protocol. That would include not attempting to scale TZEs (if they had been deployed), including the Stark verifier TZE. Later, you could write a circuit for the Stark verifier in Tachyon’s proof system if you needed to and if you had the tooling to do that feasibly.

[Milton]

Does the STARK scheme support any kind of VM?

[benh]

Super interesting. For the L2, would it run on a single centralised node?

[januszgrze]

Yes, the verification scheme on the L1 is independent to the L2’s execution semantics. I’d imagine Ztarknet would use Cairo VM (all my dev friends think this is better fwiw)

[januszgrze]

It depends. As a start, I’d say it’s likely. But, Starknet does have a federated sequencer and is pushing the boundaries on decentralized sequencing / proving

[iJaack]

This is a great initiative!

I’m not super deep into the tech, but I believe I can still provide some value for the conversation:

1. How would shielding work in the L2? Both for ZEC at first and then ZSAs (when/if they’ll come) I believe it would be ideal to make everything possibly shielded, even in contract interactions
2. I know that it’s optional, but one core feature of economics on a chain is its sustainability. ZEC is strong of 9 years of value distribution, and giving the sequencer all the fees may concentrate selling power in the hands of a few. On the other hand, using an L2 (governance) token might dilute value in the ecosystem. I don’t have an answer to this issue, just putting it here for debate. Maybe a based sequencer with some internal distribution mechanism would suffice.
3. I would 100% go against a hybrid DA model, because it would mean posting data on a public or not-shieldable layer. Just brainstorming, but isn’t it possible to post state diffs directly in shielded utxo, like in the memo field or similar? that would mean maximum privacy and a true MVP for zcash, which is now being fought by other privacy coins like XMR and DASH

Excited to see this!

Also BTW I work at routescan, we’d love to explorer if we can make a unified explorer for zcash + ztarknet eventually.

[januszgrze]

@iJaack

How would shielding work in the L2? Both for ZEC at first and then ZSAs (when/if they’ll come) I believe it would be ideal to make everything possibly shielded, even in contract interactions

It depends on the L2 execution environment. I think the proposal here is that programmability is the L2 focus, and that private SOV is the job of L1. I.e. hold shielded ZEC in orchard, swap and do defi things in L2, go back to shielded ZEC when done. This isn’t bad for privacy

1. I know that it’s optional, but one core feature of economics on a chain is its sustainability. ZEC is strong of 9 years of value distribution, and giving the sequencer all the fees may concentrate selling power in the hands of a few. On the other hand, using an L2 (governance) token might dilute value in the ecosystem. I don’t have an answer to this issue, just putting it here for debate. Maybe a based sequencer with some internal distribution mechanism would suffice.

Zcash’s lower-ish throughput would see fees earned by miners for including tx’s with state diffs increase, not decrease. The sequencer is simply a service provider, I disagree that it concentrates power. If users don’t want to use a network with a centralized sequencer, then they’ll just not use it. Market forces will incentivize to build a network with more distributed sequencing. Based sequencing in PoW for chains with arbitrary execution is a bad idea imo. 1) bad for UX 2) Just gives miners too much opps for MEV extraction

[iJaack]

@januszgrze

It depends on the L2 execution environment. I think the proposal here is that programmability is the L2 focus, and that private SOV is the job of L1. I.e. hold shielded ZEC in orchard, swap and do defi things in L2, go back to shielded ZEC when done. This isn’t bad for privacy

I do see it bad for privacy actually, in the sense that it’s not adding anything new than a simple bridge to another L1. What would be the reason why users would choose to use Ztarknet instead of, say, bridging to Solana via NEAR intents now?

@januszgrze

Zcash’s lower-ish throughput would see fees earned by miners for including tx’s with state diffs increase, not decrease. The sequencer is simply a service provider, I disagree that it concentrates power. If users don’t want to use a network with a centralized sequencer, then they’ll just not use it. Market forces will incentivize to build a network with more distributed sequencing. Based sequencing in PoW for chains with arbitrary execution is a bad idea imo. 1) bad for UX 2) Just gives miners too much opps for MEV extraction

makes sense, yeah

[januszgrze]

@iJaack

I do see it bad for privacy actually, in the sense that it’s not adding anything new than a simple bridge to another L1. What would be the reason why users would choose to use Ztarknet instead of, say, bridging to Solana via NEAR intents now?

Better trust assumptions

[highlow]

this must be tested first and see that bytes modified don’t alter the whole word.

test it before modification

[abdel]

Not for the first iteration but it’s certainly part of the plan.

Note that Starknet-based chains have application-specific privacy, so similarly to Zcash you can have both transparent and shielded transfers, but also more complex primitives like shielded trading, private shared state, etc.

In other words, you have pseudonymity by default, privacy on demand. Shielded bridging is essentially a UX improvement that hides the unnecessary steps of unshielding on L1/shielding on L2.

Here is how the progressive Ztarknet bridge privacy rollout would look like:

• Transparent bridging
• Shielded ZEC on L1 → transparent ZEC on L2 (and vice versa)
• Shielded ZEC on L1 → shielded ZEC on L2 (and vice versa)

TZE transactions can have Orchard inputs/outputs so there’s no technical limitations that prevent us from implementing shielded bridging.

[abdel]

There are two separate issues here:

• Data availability as an enabler for self-sequencing/proposing and escape hatch mechanism
• Private state

The first aspect is not Ztarknet specific, it’s a generic requirement for all rollups/validiums to make their data verifiably available to ensure security. There is a spectrum of solutions with different trade-offs.

For Zcash L2s specifically we have the following constraints:

• Zcash block space is limited and expensive, there’s no separate venue for pushing data like Ethereum blobs
• L2 state diffs (even aggregated & compressed) would pose the same issues for the network as large STARK proofs
• STARK TZE allows cost efficient ZK bridges between Zcash (settlement layer) and external DA layers

It should be noted that DA is absolutely necessary for a generic L2 chain, but for an application specific chain (e.g. perp DEX) we can engineer a custom escape hatch mechanism that works even if the sequencer is down and there’s no data access (see DyDx v3 case).

The privacy aspect is a slightly different story:

• The state of a privacy application is already encrypted (on the client side or in a MPC like TACEO, Arcium, etc) so you don’t have to encrypt it again when storing state diffs
• In other words, it doesn’t really matter where you save the diffs, as long as they are made highly available
• If encrypted DA IS the privacy solution (e.g. constructions called privadium) then the diffs are privately stored by the operators of a DA committee; we do not explore such solutions in the context of Ztarknet

[abdel]

Our initial setup will indeed be centralized, but longer term plans include progressive decentralization of the sequencer network. That is a necessary step because most of the privacy solutions on L2 are not compatible with the centralized setting. Decentralized sequencing also provides better liveness guarantees and fast soft finality which improves UX.

Luckily we can piggyback on the work done in the Starknet ecosystem and core infra.

The hard problems that we’d need to solve are:

• Bootstrapping the stake weighted operator consensus
• Forming a governing body that controls the L2 upgrades
• Coordinating the network launch

From our experience sequencer decentralization takes a lot of effort and time, so the Starknet’s approach of progressive rollout seems reasonable to apply in this case.