# STARK verification as a Transparent Zcash Extension (TZE), i.e enabler for a Starknet‑style L2 on Zcash

**URL:** <https://forum.zcashcommunity.com/t/stark-verification-as-a-transparent-zcash-extension-tze-i-e-enabler-for-a-starknet-style-l2-on-zcash/52486>\
**Category:** Governance\
**Created:** [October 14, 2025, 3:00pm UTC](https://forum.zcashcommunity.com/t/stark-verification-as-a-transparent-zcash-extension-tze-i-e-enabler-for-a-starknet-style-l2-on-zcash/52486 "2025-10-14T15:00:03Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![abdel](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/abdel/32/40042_2.png) [@abdel](https://forum.zcashcommunity.com/u/abdel)\
**Post date:** [October 14, 2025, 3:00pm UTC](https://forum.zcashcommunity.com/t/stark-verification-as-a-transparent-zcash-extension-tze-i-e-enabler-for-a-starknet-style-l2-on-zcash/52486/1 "2025-10-14T15:00:03Z")

</div>

# STARK verification as a Transparent Zcash Extension (TZE), i.e enabler for a Starknet‑style L2 on Zcash

[DRAFT BIP PULL REQUEST](https://github.com/zcash/zips/pull/1107)

Hey ZCash fam, greeting from StarkWare. I am Abdel. I personally like the vibes of the ZCash community. Cyperpunk ethos and freedom tech is the way.  
And privacy is normal and is a fundamental right. I am glad that the recent surge of interest on ZCash project has sparked a strong interest for privacy in the whole space. This is very relieving. I wanted to share a proposal to the community, as I believe that our tech can actually be complementary to ZCash. I think there are some cool options to explore together.

## TL;DR

I’m proposing a **Transparent Zcash Extension (TZE)** that verifies a **bounded‑size STARK proof** within Zcash consensus. The intent is to make Zcash a credible base layer for a **Starknet‑style L2** : account abstraction, a Cairo VM execution environment (i.e., full programmability on L2), and high throughput with very low per‑tx L2 fees, while keeping **L1 privacy** exactly as it is today.

Concretely, this would define a TZE **type** “STARK\_VERIFY” with two **modes** :

- **Mode 1 — Stone (vanilla FRI STARK)**: a pinned Stone verifier/format (C++) with explicit parameter bounds.
- **Mode 2 — Stwo (Circle STARK)**: a pinned Stwo verifier/format (Rust) with explicit parameter bounds. (Stwo is newer and faster, but not as battle tested as Stone.)

This is intentionally narrow: **verify a proof + public inputs** under strict limits; **no** changes to shielded pools, and **no** new scripting language. It plugs into the **TZE framework** (ZIP‑222), which already defines how to add new transparent preconditions and witnesses to transactions.

> Dislaimer: I am working at StarkWare, the company building and operating Starknet. This is my own initiative and not instructed by my company. I believe it’s an interesting discussion to raise in the ZCash technical community. Also, before working on this proposal, I was actively working on an OP\_STARK\_VERIFY proposal for Bitcoin. Still planning to publish it, and the Bitcoin proposal work was prior to the current one.

* * *

## Why Zcash community should consider this

- **Programmability & scale live on L2, privacy stays on L1.** Zcash already has strong base‑layer privacy. What it lacks is a general‑purpose execution environment and cheap throughput. A Starknet‑style L2 (Cairo VM) provides programmability and scale, while Zcash L1 keeps doing what it does best: finality and private custody.
- **Clean integration surface.** Using **TZE** avoids entangling this work with shielded protocols or Bitcoin‑style Script. ZIP‑222 was created precisely to add well‑specified “transparent preconditions” with consensus verification.
- **Hash‑based, transparent assumptions.** STARK verification relies mainly on the collision/preimage resistance of transcript/Merkle hashes and the soundness of the polynomial IOP; this is widely regarded as **post‑quantum‑plausible** (subject to the hash we pin).
- **Reasonable verification cost & static pricing.** STARK verification is **polylogarithmic** in trace size and dominated by hashing (Merkle/FRI). Proof sizes are typically **few hundred kilobytes** , i.e., heavier than pairing SNARKs (but with better scaling properties, quantum resistance, simpler cryptography and other advantages) but workable if bounded and priced by bytes.

* * *

## What this enables (if adopted)

- **A Starknet‑style L2 on Zcash:**

- **Programmable bridges and assets:** Combine with future ZSA work to mint/burn L2‑tracked assets with L1 settlement, or to move value between shielded addresses and an L2 account space via well‑defined preconditions.

* * *

## Proposal overview (TZE‑style, not an opcode)

This proposal defines a **new TZE `type` = STARK\_VERIFY** with two `mode`s:

- `mode = 1`: **Stone** (vanilla FRI STARK) — pinned format/params.
- `mode = 2`: **Stwo** (Circle STARK) — pinned format/params.

Per **ZIP‑222** , each TZE has a `(type, mode)` and a **`precondition`** (challenge) plus **`witness`** (evidence). The consensus rule is: for each TZE input, run the extension’s **`tze_verify(mode, precondition, witness, context)`** and it must return `true`.

### Precondition / witness layout (high‑level)

- **Precondition** (prefix‑free encoding within this `(type, mode)`):

- **Witness** (prefix‑free):

**Determinism and non‑malleability** of these encodings are the extension’s responsibility, per ZIP‑222: any malleation of `precondition` must cause `tze_verify` to reject; the verifier’s output must be deterministic.

### Verification

`tze_verify` for this `(type, mode)`:

1. Parses `verifier_id`; loads the **exact** pinned parameter set (includes hash choice, FRI/query bounds, etc.).
2. Initializes the proof transcript and **absorbs `pub_in`** exactly as specified.
3. Parses `proof` per pinned wire format and runs the Stone or Stwo verifier accordingly.
4. Returns `true` iff the proof verifies under the pinned params; otherwise `false`.

* * *

## Bounds & pricing (DoS safety and fee model)

- **`PROOF_MAX_BYTES` (consensus):** a conservative constant per `mode` and possibly per `verifier_id`. Initial **discussion ranges** could be **64–256 KiB** for Stone and **≤256 KiB-1MB** for Stwo (subject to benchmarks on realistic traces).
- **`PUBIN_MAX_BYTES` (consensus):** e.g., **≤ 32MB**.
- **Runtime bound:** implied by pinned FRI/query limits + hash choice + byte caps; parser must **fail fast** on malformed inputs and cap allocations.
- **Fee signal:**  **bytes** (witness size). This mirrors how Zcash currently prices transaction bytes; we avoid introducing new “op‑count” style budgets unless needed.
- **Policy (non‑consensus):** start with strict mempool limits (e.g., at most one STARK\_VERIFY input per transaction; tighter size limits under policy). These can relax as we gain operational experience.

* * *

## Starknet‑style L2 sketch (informative, not part of this TZE spec)

- **Bridge model:** L1 TZE outputs carry a precondition that references the **current L2 state root** ; L2 operator(s) post a STARK proof that a batch of L2 transactions moves state from `root_old` to `root_new`. The **witness** contains that proof; the **precondition** carries the public inputs (roots, batch commitments, etc.).
- **Data availability (DA):** out of scope for this TZE. DA can be a) fully on‑chain (expensive), b) via commitment to an external DA layer, or c) hybrid. The precondition must make the DA commitment explicit if required by the verifier.
- **Deposits/withdrawals:** are protocols on top of this primitive, potentially combined with ZSAs to represent L2 balances on L1.

* * *

## References / prior art

- [ZIP‑222: Transparent Zcash Extensions (TZE)](https://zips.z.cash/zip-0222)
- STARK paper: [Scalable, transparent, and post-quantum secure computational integrity](https://eprint.iacr.org/2018/046)
- Circle STARKs paper: [Circle STARKs](https://eprint.iacr.org/2024/278)
- Stone prover/verifier: [GitHub - starkware-libs/stone-prover](https://github.com/starkware-libs/stone-prover)
- Stwo prover/verifier: [GitHub - starkware-libs/stwo](https://github.com/starkware-libs/stwo)
- OP\_CAT Circle STARK verifier: [GitHub - Bitcoin-Wildlife-Sanctuary/bitcoin-circle-stark: Building blocks of a Circle STARK verifier in Bitcoin script](https://github.com/Bitcoin-Wildlife-Sanctuary/bitcoin-circle-stark)
- M31 opcodes proposal: [M31 arithmetic opcodes for efficient STARK verification on Bitcoin - HackMD](https://hackmd.io/@AbdelStark/m31-opcodes-bitcoin-stark)

* * *

### Next steps

- If there’s interest, I’ll draft a ZIP titled **“STARK verification as a Transparent Zcash Extension”** (Category: **Consensus** ), cross‑referencing ZIP‑222/244/245.
- The ZIP will include: exact wire formats; pinned parameter sets for **Stone** and **Stwo** ; consensus bounds; test vectors; and a plan for staged activation.

---

<div class="post-metadata">

**Author:** ![jimmyzhao-hash](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/jimmyzhao-hash/32/40059_2.png) [@jimmyzhao-hash](https://forum.zcashcommunity.com/u/jimmyzhao-hash)\
**Post date:** [October 14, 2025, 3:43pm UTC](https://forum.zcashcommunity.com/t/stark-verification-as-a-transparent-zcash-extension-tze-i-e-enabler-for-a-starknet-style-l2-on-zcash/52486/2 "2025-10-14T15:43:08Z")

</div>

Why not directly make starknet a Zcash L2 as well?

---

<div class="post-metadata">

**Author:** ![abdel](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/abdel/32/40042_2.png) [@abdel](https://forum.zcashcommunity.com/u/abdel)\
**Post date:** [October 14, 2025, 3:48pm UTC](https://forum.zcashcommunity.com/t/stark-verification-as-a-transparent-zcash-extension-tze-i-e-enabler-for-a-starknet-style-l2-on-zcash/52486/3 "2025-10-14T15:48:26Z")

</div>

you mean the public Starknet to migrate to ZCash instead of Ethereum / Bitcoin ? to extend to also settle on ZCash ?  
technically everything could be possible. it’s not only a matter of technical options as you might understand.  
but the proposal is agnostic to those non technical challenges anyway.  
and Starknet stack is open source so this would enable anyone to build a Starknet based L2 on top of ZCash, not necessarily StarkWare.  
But thanks for this suggestion, it’s interesting!

---

<div class="post-metadata">

**Author:** ![greatk0001](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/greatk0001/32/40057_2.png) [@greatk0001](https://forum.zcashcommunity.com/u/greatk0001)\
**Post date:** [October 14, 2025, 4:00pm UTC](https://forum.zcashcommunity.com/t/stark-verification-as-a-transparent-zcash-extension-tze-i-e-enabler-for-a-starknet-style-l2-on-zcash/52486/4 "2025-10-14T16:00:35Z")

</div>

In other words, if this proposal is implemented it would bring L2 programmability to Zcash, and can become a potential path/bridge for encrypting and shielding token and other assets from ethereum ecosystem :thinking:?

---

<div class="post-metadata">

**Author:** ![abdel](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/abdel/32/40042_2.png) [@abdel](https://forum.zcashcommunity.com/u/abdel)\
**Post date:** [October 14, 2025, 4:03pm UTC](https://forum.zcashcommunity.com/t/stark-verification-as-a-transparent-zcash-extension-tze-i-e-enabler-for-a-starknet-style-l2-on-zcash/52486/5 "2025-10-14T16:03:38Z")

</div>

yes! you got it right. not only programmability btw, also scaling and UX improvements.

---

<div class="post-metadata">

**Author:** ![januszgrze](https://avatars.discourse-cdn.com/v4/letter/j/aeb1de/32.png) [@januszgrze](https://forum.zcashcommunity.com/u/januszgrze)\
**Post date:** [October 14, 2025, 4:03pm UTC](https://forum.zcashcommunity.com/t/stark-verification-as-a-transparent-zcash-extension-tze-i-e-enabler-for-a-starknet-style-l2-on-zcash/52486/6 "2025-10-14T16:03:57Z")

</div>

Hey @abdel - great to see you outside of the bitcoin space 🙂

Super interested in this. I wrote this proposal a year or so ago (there are technical errors in the post fwiw), but conversations at the first Zeboot shifted towards Zcash having its own rollup ecosystem versus rolling up somewhere else.

> [@Zcash to sovereign rollup](https://forum.zcashcommunity.com/t/zcash-to-sovereign-rollup/46404):
>
> Introduction This post only focuses on zk-rollups. Thank you to [Cooper Kunz](https://twitter.com/cooper_kunz) and [c-node](https://twitter.com/colludingnode) for feedback which influenced edits made to the original draft. Thank you to @joshs, @pacu and @aquietinvestor for their review. Zcash community – This post is to solicit discussion and feedback around the possibility of Zcash deprecating the Zcash Layer 1 (L1) blockchain, and seeing the Zcash protocol become a Sovereign Rollup. In this design, Zcash will become a lightweight blockchain that sovereignly oper…

This might be an interesting GitHub issue to review. It was re-discussed during my presentation at the first Zeboot 18~ months ago. [Shielded transaction aggregates · Issue #4946 · zcash/zcash · GitHub](https://github.com/zcash/zcash/issues/4946)

Let me know if you would like me to review any other documentation/ideas you have on this. I know there’s an appetite for this. Nate (shielded labs) and I discussed this idea recently on a Twitter space with ZecHub.

---

<div class="post-metadata">

**Author:** ![abdel](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/abdel/32/40042_2.png) [@abdel](https://forum.zcashcommunity.com/u/abdel)\
**Post date:** [October 14, 2025, 4:08pm UTC](https://forum.zcashcommunity.com/t/stark-verification-as-a-transparent-zcash-extension-tze-i-e-enabler-for-a-starknet-style-l2-on-zcash/52486/7 "2025-10-14T16:08:35Z")

</div>

ohhhh good to see you here my friend!!!  
oh interesting i missed this!  
wow stars are aligning. yeah let’s work together bro. i have many ideas. glad to see there is appetite. let’s consolidate and join forces.

---

<div class="post-metadata">

**Author:** ![Shawn](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/shawn/32/187_2.png) [@Shawn](https://forum.zcashcommunity.com/u/Shawn)\
**Post date:** [October 14, 2025, 4:09pm UTC](https://forum.zcashcommunity.com/t/stark-verification-as-a-transparent-zcash-extension-tze-i-e-enabler-for-a-starknet-style-l2-on-zcash/52486/8 "2025-10-14T16:09:48Z")

</div>

Yes, super interesting proposal!

Curious what @daira and @pacu think about the feasibility of getting this into a NU?

(assuming the larger community supported it of course)

---

<div class="post-metadata">

**Author:** ![abdel](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/abdel/32/40042_2.png) [@abdel](https://forum.zcashcommunity.com/u/abdel)\
**Post date:** [October 14, 2025, 4:10pm UTC](https://forum.zcashcommunity.com/t/stark-verification-as-a-transparent-zcash-extension-tze-i-e-enabler-for-a-starknet-style-l2-on-zcash/52486/9 "2025-10-14T16:10:41Z")

</div>

thanks!  
curious too!

---

<div class="post-metadata">

**Author:** ![pacu](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/pacu/32/15383_2.png) [@pacu](https://forum.zcashcommunity.com/u/pacu)\
**Post date:** [October 14, 2025, 4:42pm UTC](https://forum.zcashcommunity.com/t/stark-verification-as-a-transparent-zcash-extension-tze-i-e-enabler-for-a-starknet-style-l2-on-zcash/52486/10 "2025-10-14T16:42:38Z")

</div>

Hello @abdel! Thanks for posting this idea. I don’t know much about Cairo VM but I know that there’s a vibrant community of builers over there.

I have a few insights:

Given that @ebfull has estimated that Tachyon could be developed within the next 12 months or so, how would that interact with your proposal?

When it comes to finality, does your proposal depend on Crosslink being implemented and deployed or is the PoW consensus enough to go by at first?

Cheers!

---

<div class="post-metadata">

**Author:** ![EthosVentures](https://avatars.discourse-cdn.com/v4/letter/e/f9ae1b/32.png) [@EthosVentures](https://forum.zcashcommunity.com/u/EthosVentures)\
**Post date:** [October 14, 2025, 5:10pm UTC](https://forum.zcashcommunity.com/t/stark-verification-as-a-transparent-zcash-extension-tze-i-e-enabler-for-a-starknet-style-l2-on-zcash/52486/11 "2025-10-14T17:10:17Z")

</div>

This is very interesting. There is great opportunity to continue to make ZCash everything Bitcoin could have been and embracing L2s is part of that IMO.

> [@abdel](#):
>
> **Programmable bridges and assets:** Combine with future ZSA work to mint/burn L2‑tracked assets with L1 settlement, or to move value between shielded addresses and an L2 account space via well‑defined preconditions.

I can’t speak to the implementation of ZSAs but am I correct that bridging shielded ZEC to an L2 account would require future work and is outside of the scope of this initial proposal? Without private transfers or programmable privacy on the L2, it seems the main or sole benefit of the L2 would be driving tx fees to the L1 via settlement. However with the L2 space very crowded, I assume people would only be attracted to this option if it had privacy and was an extension of the ZCash ethos. IMO it makes sense that any proposal includes at least a plan for privacy on the L2 from the beginning, even if the implementation and rollout is staged.

---

<div class="post-metadata">

**Author:** ![Milton](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/milton/32/21375_2.png) [@Milton](https://forum.zcashcommunity.com/u/Milton)\
**Post date:** [October 14, 2025, 6:25pm UTC](https://forum.zcashcommunity.com/t/stark-verification-as-a-transparent-zcash-extension-tze-i-e-enabler-for-a-starknet-style-l2-on-zcash/52486/12 "2025-10-14T18:25:52Z")

</div>

I don’t think it is a good idea to promote transparent L2s as part of “Zcash”. It carries similar problems as the transparent pool.

I do think we should eventually build a L2 for Zcash to add programmability, but it should be based on FHE technology so that we don’t lose privacy.

---

<div class="post-metadata">

**Author:** ![abdel](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/abdel/32/40042_2.png) [@abdel](https://forum.zcashcommunity.com/u/abdel)\
**Post date:** [October 15, 2025, 7:57am UTC](https://forum.zcashcommunity.com/t/stark-verification-as-a-transparent-zcash-extension-tze-i-e-enabler-for-a-starknet-style-l2-on-zcash/52486/13 "2025-10-15T07:57:56Z")

</div>

Yeah Starknet definitely has a very vibrant community of builders! And Cairo is a great language to build scalable verifiable apps. The DexX keeps improving at fast pace and there are more and more great example of cool apps working in production at large scale.

Regarding Tachyon I need to check as I am not really familiar with it. I will try to check soon and comeback with insights on how this would interact with this proposal.

PoW consensus enough to go by at first for sure, no problem about this any time soon.

---

<div class="post-metadata">

**Author:** ![abdel](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/abdel/32/40042_2.png) [@abdel](https://forum.zcashcommunity.com/u/abdel)\
**Post date:** [October 15, 2025, 7:58am UTC](https://forum.zcashcommunity.com/t/stark-verification-as-a-transparent-zcash-extension-tze-i-e-enabler-for-a-starknet-style-l2-on-zcash/52486/14 "2025-10-15T07:58:55Z")

</div>

Starknet does not have privacy support, yet! The proof verification is agnostic to this btw and it would totally be possible to verify ZK proofs that are actually ZK and privacy preserving.  
So it’s not an issue regarding this specific proposal.

---

<div class="post-metadata">

**Author:** ![abdel](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/abdel/32/40042_2.png) [@abdel](https://forum.zcashcommunity.com/u/abdel)\
**Post date:** [October 15, 2025, 8:02am UTC](https://forum.zcashcommunity.com/t/stark-verification-as-a-transparent-zcash-extension-tze-i-e-enabler-for-a-starknet-style-l2-on-zcash/52486/15 "2025-10-15T08:02:55Z")

</div>

> There is great opportunity to continue to make ZCash everything Bitcoin could have been and embracing L2s is part of that IMO.

Agreed. And for us it would honestly be an amazing field of experimentation / anticipation on what Starknet on top of Bitcoin could look like in the future.

> am I correct that bridging shielded ZEC to an L2 account would require future work and is outside of the scope of this initial proposal?

Correct. Outside of the scope of this initial proposal. But this proposal is a prerequisite to think about this as a later step.

> it seems the main or sole benefit of the L2 would be driving tx fees to the L1 via settlement.

Yes the main advantage is scaling, but not only. Also UX and expressivity. With account abstraction you can build amazing UX, especially for normies, while remaining trustless and self custodial.

> IMO it makes sense that any proposal includes at least a plan for privacy on the L2 from the beginning, even if the implementation and rollout is staged.

The proof verification on L1 (this proposal) would TOTALLY enable this going forward. To be specific and give a concrete example, once we had proper ZK support in stwo (our next gen prover) and privacy support in the Starknet OS, this would naturally enable privacy on the L2.

---

<div class="post-metadata">

**Author:** ![abdel](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/abdel/32/40042_2.png) [@abdel](https://forum.zcashcommunity.com/u/abdel)\
**Post date:** [October 16, 2025, 10:37am UTC](https://forum.zcashcommunity.com/t/stark-verification-as-a-transparent-zcash-extension-tze-i-e-enabler-for-a-starknet-style-l2-on-zcash/52486/16 "2025-10-16T10:37:56Z")

</div>

# Update: TZE-based Circle‑STARK verification vs. opcode fallback: constraints, options, and questions

**Context.** I started a PoC to verify **Stwo/Cairo (Circle‑STARK)** proofs on Zcash L1 using **Transparent Zcash Extensions (TZE)**. While wiring this into Zebra I also evaluated an **opcode fallback**. Below is what I learned, plus concrete paths we could take.

## What I learned (facts & constraints)

- **TZE exists at the spec level and is designed for large, typed, non‑script witnesses.**  
_ZIP‑222_ defines TZE objects (preconditions/witnesses) and how they integrate with transactions without touching Script; _ZIP‑245_ defines how TZEs are committed in the txid/sighash/auth digests. This is the cleanest way to carry and verify big proof blobs in consensus.

- **Zcash Script alone can’t carry large ZK proofs.**  
Transparent Script inherits Bitcoin‑style resource limits (stack item and script size). Even if we chunked a proof, Script limits and lack of native covenants make feeding ~100 KB+ proofs via Script unrealistic. (Zcash’s non‑malleable txid/sighash split from _ZIP‑244_ doesn’t create a separate “witness stack” for transparent inputs.)

- **If we avoid TZE, we still need a way to feed big data to consensus.**  
The only practical “opcode path” is to introduce a **per‑input witness area** in the v6 tx format (added to the authorizing‑data digests per _ZIP‑246_), and have the opcode read from there. Otherwise the opcode has no way to access multi‑10s/100s‑of‑KB inputs.

- **Implementation surfaces today.**

## Options on the table

### **A) Stay on the TZE track (my original proposal)**

- **What:** Define a single **TZE type** “Circle‑STARK Verify”. Precondition commits to program + public inputs (e.g., L2 root transition or app message). Witness contains the Stwo proof blob. Nodes verify via a Rust adapter.
- **Why:** TZE is **purpose‑built** for this: large, typed witness; crisp digest integration via _ZIP‑245_; no pressure on Script limits.
- **Work:** Finish a minimal TZE host path in Zebra; pin verifier params; add size/runtime caps; test vectors; tooling to construct TZE txs.
- **Pros:** Architecturally clean; lowest risk of resource‑limit surprises; forwards‑compatible with other extensions.
- **Cons:** TZE infra isn’t widely exercised yet; requires Zebra/RPC/wallet changes to expose/build TZE txs.

### **B) Opcode fallback — but with a small v6 format addition**

- **What:**

- **Why:** Looks/feels like “a single opcode”, but avoids Script size/element limits by moving large data to TIW (committed in authorizing‑data digests, excluded from txid per _ZIP‑244/246_ semantics).

- **Work:** Two small consensus ZIPs (TIW layout + opcode semantics), `zcash_script` opcode + host callback to read TIW, Zebra v6 parsing and digest updates, policy caps.

- **Pros:** Narrow change set; no new TZE object model; can be implemented entirely in Rust.

- **Cons:** Still a **transaction‑format change** ; wallets/RPC must learn to build/inspect TIW; less general than TZE.

### **C) Opcode‑only with no format change**

- **What:** Try to push proof bytes through Script itself.
- **Reality check:** Not viable at realistic proof sizes without lifting Script limits and/or introducing covenants (e.g., `OP_CAT`‑style constructions). That’s a much larger design discussion with more risks.

## What I need feedback on

1. **Preference for TZE vs. opcode+TIW.**  
From a consensus/maintenance perspective, which path is more acceptable for NUx? My read is that **TZE (A)** is architecturally right, while **opcode+TIW (B)** is the smallest alternative that actually works.

2. **Are there near‑term plans to ship TZE?**  
_ZIP‑222_ and _ZIP‑245_ are Draft. Is there an intended activation window for a first TZE type (not necessarily this one)? If yes, I’ll align with that process.

3. **If we go (B), is a small v6 “TIW” addition acceptable?**  
Concretely: per‑input byte‑strings included in the **authorizing‑data** tree (per _ZIP‑246_), excluded from txid (per _ZIP‑244_ principles), with conservative consensus/policy caps. Any gotchas with digest plumbing or signer UX I should account for?

4. **`zcash_script` engine: Rust path OK for consensus?**  
I’d like to target the **pure‑Rust** interpreter in `zcash_script` for the opcode. Is that considered feature‑complete and acceptable for Zebra’s consensus path, or should I go through the C++ FFI? (Trying to avoid Rust↔C++ FFI for the Stwo verifier.)

5. **Resource bounds.**  
What proof size and CPU budget would reviewers be comfortable with? (E.g., `< 192–256 KiB` proof bytes; `< N ms` on standard hardware). I’ll produce benchmarks once we agree on a direction.

6. **Process: where to place the work.**

7. **Tooling expectations.**  
For either path: preferred RPC shape for building/inspecting TZE/TIW; any minimum wallet SDK hooks needed for signers (since the authorizing‑data digest must commit to the proof).

---

<div class="post-metadata">

**Author:** ![JoakimEQ](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/joakimeq/32/27704_2.png) [@JoakimEQ](https://forum.zcashcommunity.com/u/JoakimEQ)\
**Post date:** [October 16, 2025, 11:51am UTC](https://forum.zcashcommunity.com/t/stark-verification-as-a-transparent-zcash-extension-tze-i-e-enabler-for-a-starknet-style-l2-on-zcash/52486/17 "2025-10-16T11:51:44Z")

</div>

Fully supportive of this expedition.

---

<div class="post-metadata">

**Author:** ![daira](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/daira/32/43253_2.png) [@daira](https://forum.zcashcommunity.com/u/daira)\
**Post date:** [October 17, 2025, 2:02pm UTC](https://forum.zcashcommunity.com/t/stark-verification-as-a-transparent-zcash-extension-tze-i-e-enabler-for-a-starknet-style-l2-on-zcash/52486/18 "2025-10-17T14:02:41Z")

</div>

It’s an interesting idea that deserves further exploration. I agree that TZEs are probably the best mechanism for this if it goes forward.

---

<div class="post-metadata">

**Author:** ![str4d](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/str4d/32/64_2.png) [@str4d](https://forum.zcashcommunity.com/u/str4d)\
**Post date:** [October 17, 2025, 8:22pm UTC](https://forum.zcashcommunity.com/t/stark-verification-as-a-transparent-zcash-extension-tze-i-e-enabler-for-a-starknet-style-l2-on-zcash/52486/19 "2025-10-17T20:22:18Z")

</div>

> [@abdel](#):
>
> TZE exists at the spec level

TZEs do not just exist at the spec level. TZEs were implemented for integration into zcashd:

- [librustzcash/zcash\_extensions at main · zcash/librustzcash · GitHub](https://github.com/zcash/librustzcash/tree/main/zcash_extensions)
- [librustzcash/zcash\_primitives/src/extensions/transparent.rs at main · zcash/librustzcash · GitHub](https://github.com/zcash/librustzcash/blob/main/zcash_primitives/src/extensions/transparent.rs)
- [https://github.com/zcash/zcash/pull/4480](https://github.com/zcash/zcash/pull/4480)

The zcashd PR was never merged because TZEs are not a standalone feature and can’t be independently “activated” in a network upgrade: they are a framework for deploying new UTXO-style transparent pools to Zcash, and only make sense in the context of at least one such pool being added to the consensus rules. The Rust code OTOH has been living quietly in the librustzcash repo behind feature flags, and we’ve been maintaining it across refactors of the rest of the Rust code.

---

<div class="post-metadata">

**Author:** ![str4d](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/str4d/32/64_2.png) [@str4d](https://forum.zcashcommunity.com/u/str4d)\
**Post date:** [October 17, 2025, 9:50pm UTC](https://forum.zcashcommunity.com/t/stark-verification-as-a-transparent-zcash-extension-tze-i-e-enabler-for-a-starknet-style-l2-on-zcash/52486/20 "2025-10-17T21:50:35Z")

</div>

> [@abdel](#):
>
> **Resource bounds.**  
> What proof size and CPU budget would reviewers be comfortable with? (E.g., `< 192–256 KiB` proof bytes; `< N ms` on standard hardware).

From a chain data perspective:

- Sapling (Groth16) requires around 400 bytes of proof data per logical action (1 Spend + 1 Output). The minimum ZIP 317 fee covers 2 logical actions, so around 800 bytes of proof data, but in practice wallets only pad the outputs (so the smallest typical Sapling-only tx is 1-Spend 2-Output, with around 600 bytes of proof data).
- Orchard (Halo 2) has (IIRC, rounding up quite a bit) a base cost of 2.5 kiB and a marginal cost of 2.5 kiB per logical action (1 Action). The minimum ZIP 317 fee covers around 7.5 kiB of proof data.
  - We accepted this one order of magnitude (12.8x on typical, 9.6x on equivalent) increase in proof data size, in exchange for Orchard having no trusted setup.
  - We kept the fee per logical action consistent between Sapling and Orchard because we didn’t want to discourage usage of Orchard, and the 10x proof data size increase was still manageable.

- Transparent (Bitcoin-derived Script) has a maximum script size of 10,000 bytes. The marginal ZIP 317 fee uses a typical P2PKH input size (150 bytes) and output size (34 bytes) as the cost of 1 logical action (providing approximately equivalent functionality to Sapling and Orchard), so a single max-size Input would count as a bit under 70 logical actions, and a single max-size Output would count as a bit under 300 logical actions (with the fee being based on whether the transparent input or output logical count is larger in the tx, per ZIP 317).
- From a raw data perspective: ZIP 231 Memo Bundles (currently proposed to be deployed in NU7 as part of the v6 tx format) have a maximum single-memo size of 16 kiB, or at most 17 kiB of ciphertext data. Per the ZIP, this largest-size memo would be counted as 62 logical actions (2 free memo chunks are provided for historic reasons, but essentially it’s 1 logical action per 272 bytes).

Your proposed example upper bound of 192-256 kiB would be a:

- 12-16x increase over max-size ZIP 231 Memo Bundle data.
- 20-26x increase over max-size transparent (for either 1-Input or 1-Output being large; half this if both are).
- 26-34x increase over 2-Action Orchard.
- 246-328x increase over 2-Spend 2-Output Sapling.
- 328-437x increase over 1-Spend 2-Output Sapling.

We had previously decided that 1 order of magnitude increase in proof data over Sapling would not harm the network. The Zcash ecosystem would need to think very carefully about the implications of an \>2 orders of magnitude increase over Sapling, and (if that upper limit cannot be lowered without compromising the entire feature) how fees would map to it for controlling the cost to the chain, or what the plan would be to reduce the chain cost over time.

- For example, if calculated using the same marginal cost as memo bundles (which may be too low given that proofs have a verification cost in addition to a size cost), a max-size STARK proof using the example upper bound would be 722-963 logical actions.

[Next page](https://forum.zcashcommunity.com/t/stark-verification-as-a-transparent-zcash-extension-tze-i-e-enabler-for-a-starknet-style-l2-on-zcash/52486.md?page=2)