Tezos Encrypted Ledger.
Private. Post-quantum. Now.

TzEL is an experimental Tezos smart rollup for private, post-quantum transactions. It replaces elliptic-curve cryptography with hashes, ML-KEM, and STARK proofs.

Why post-quantum?

Quantum computers capable of breaking elliptic curve cryptography are no longer a theoretical concern. Google's Willow chip crossed the quantum error correction threshold in 2024, demonstrated a 13,000x speedup over the fastest supercomputer in 2025, and in March 2026 Google accelerated its own post-quantum migration deadline to 2029, citing "store now, decrypt later" as a primary driver. NIST finalized post-quantum standards in 2024. The NSA requires all national security systems to migrate by 2035.

Every deployed privacy protocol—Zcash, Aztec, Penumbra—relies on elliptic curves for note encryption, key agreement, or signatures. When those curves break, the transaction graphs will be fully exposed retroactively.

2024  NIST finalizes PQC standards
2024  Google Willow: error correction threshold
2025  Willow: 13,000x supercomputer speedup
2026  Google moves PQ migration to 2029
2035  NSA CNSA 2.0 migration deadline

Mosca's theorem: if migration time +
data shelf life > time to CRQC,
you are already too late.

Why now?

Adversaries can collect encrypted blockchain data today and hold it for future decryption, a "harvest now, decrypt later" threat U.S. agencies have already warned about.

For financial privacy, that risk does not expire. If quantum computers break the cryptography protecting Zcash, anyone who knows your shielded address could later recover sensitive details from payments sent to you, including amounts and memos.

today:
  adversary records encrypted tx data

quantum era:
  break EC → recover DH shared secrets
  → decrypt note values and memos
  → link addresses, correlate payments

with TzEL:
  no EC anywhere → nothing to decrypt
Live on Shadownet
Shield and private-send transactions already execute on a public Tezos test network.
No elliptic curves
The privacy stack uses hashes, ML-KEM, and STARK proofs instead of elliptic-curve cryptography.
Authorize locally
Spending authority stays in the wallet while proof generation can run on a larger machine.
Open stack
Wallet, prover, operator, and rollup code are all developed in the open.

How far along is it?
Experimental, but already running.

TzEL is still R&D code and not suitable for real value. It already runs as a Tezos smart rollup on Shadownet, with proof-bearing shield and private-send transactions going through the DAL.

Today there is a real testnet path from wallet to rollup execution, not just isolated proofs or local demos.

live shield:
ooAbD9...QqhPBH

live private send:
ooTMBv...TTFs4j

status:
experimental rollup
working testnet path
not production-ready

How the stack runs.
Smart rollup plus DAL.

TzEL runs as a Tezos smart rollup. Shielded transactions carry STARK proofs, and those proofs are large enough that Tezos's data availability layer is a natural place to post them.

execution: Tezos smart rollup
proof system: recursive STARKs
availability: Tezos DAL
transactions: shielded rollup txs

large proofs, live rollup execution

No elliptic curves.
Anywhere.

TzEL does not add a post-quantum wrapper around a curve-based privacy system. It removes elliptic curves from the privacy stack entirely: BLAKE2s for hashing, ML-KEM-768 for encryption, hash-based one-time signatures for spend authorization, and STARKs for proofs.

Fund safety relies on hash collision resistance and STARK soundness. Note confidentiality relies on ML-KEM (NIST FIPS 203) and authenticated encryption. No component depends on the hardness of discrete log or factoring.

commitment  = BLAKE2s(d, v, rcm, tag)
nullifier   = BLAKE2s(nk, cm, pos)
memo       = ML-KEM-768 + ChaCha20
spend auth = hash-based OTS verified in-STARK
proof      = recursive STARK (Cairo + Stwo)

Authorize locally.
Prove elsewhere.

TzEL separates spending authority from proving. A wallet authorizes a transaction locally with a hash-based signature, while proof generation can run on a larger machine.

The signature is checked inside the STARK itself. An untrusted prover can help produce the proof, but it cannot change the transaction or gain spend authority.

That makes the system easier to operate: wallets stay small, proving can be delegated, and the rollup still verifies the exact transaction the wallet approved.

wallet:
  approve transaction
  → hash-based signature

prover:
  build STARK proof

rollup:
  verify proof and transaction

no spend key leaves the wallet

Watch without spending.
Share visibility, not control.

TzEL separates detection, viewing, and spending. Detection material can flag likely incoming notes. Viewing material can validate and decrypt them. Spending authority stays separate.

That makes a contained watch-only service possible: a delegated scanner can follow the chain and report incoming activity without being able to move funds.

detection key:
  candidate matches

viewing key:
  incoming notes and memos

spending key:
  move funds

watch services can observe, not spend