Reinventing Privacy Rabbit Holes vs. Killing Infrastructure

Philosophy and Economics
1

We are exactly 13 days away from the 8th anniversary of the Tezos genesis block. Think about that milestone for a second. It has been eight years. Eight years of development, governance, and capital allocation, and where are we? Who is actually going to take responsibility for where the network stands right now?

Because looking at our current trajectory, we are still paying Trilitech to reinvent privacy yet again. -_-

I get it. Trilitech has plenty of resources and seemingly endless time to dump funding into useless academic rabbit holes. But for God’s sake, can we stop trying to reinvent privacy when, under our current architecture, it is completely useless?

Cryptography and zero-knowledge security are cool. If people want privacy, they use monero. They aren’t coming to Tezos for it, especially not at the cost of the network’s foundational stability. End of story.

Instead of burning elite engineering hours on pet crypto projects because “cryptography is fun,” why can’t we take that exact same time and put it into maintaining the tools that actually keep this blockchain running?

Look at what is happening right now in the ecosystem. We just saw the announcement that Signatory maintenance is being wound down by ECAD Labs because a measly $50k maintenance budget was rejected. Signatory is the only enterprise-grade, protocol-aware remote signer protecting keys for exchanges, public bakers, and custodians. If you want to sign tz4/BLS operations using cloud KMS, HSMs, or TEEs, Signatory is literally the only thing that exists. Without it, bakers are forced to use keys on disk or completely migrate their infrastructure.

Meanwhile, Jev have to point out on basically every single library release that there are things missing or broken in the software Trilitech is trying to take over.

We are defunding and abandoning the public goods and core tooling, all to centralize control and chase shiny, useless cryptographic features that don’t fit the state of Tezos.

A Side Note on “AI-Powered” Cryptography

Look closely at the tzel repository. Most of the project is written by Claude.

Let that sink in. We are rejecting funding for production-grade security infrastructure like Signatory, while simultaneously letting developers dump AI-generated code into cryptographic libraries/rollup. I guess the plan is to have the audits AI-powered too?

No one in their right mind should be implementing core cryptography entirely via an LLM. If you can’t handle a smooth handover and release cycle for casual, standard software safely, how exactly are we going to ship and trust AI-generated crypto? Enlighten me.

It’s time to get your shit together, stop playing in sandbox rabbit holes, and do something about the state of Tezos.

Thanks.

PS: Sorry for the tone, but it is quite frustrating that we don’t mind ditching ECAD under the guise of them being “too expensive,” while simultaneously paying another company to provide near-zero value - צֵל. Although nice hebrew reference ngl.

4 Likes
2

Arthur openly addressed and defended using AI assistance for this exact development in a recent interview: https://www.youtube.com/watch?v=oBvmQlGXWMI

3

Ok, I checked it. And I agree with AB more or less on the theory. But I do not believe that TT has proven their capability to stand up to his words of following best practices for a high-security codebase.

TT seems to be spread thin—as shown by the missing pieces in recent software releases. If human engineering hours are too constrained to maintain foundational infrastructure, how can we trust that massive amounts of LLM-generated crypto code are being properly reviewed and audited? We can’t. Even if we could.tzel won’t be trusted by serious actors for years.

We already have a dominant, battle-tested solution in the market. Almost every attempt to graft privacy onto other chains has failed—look at our own L1 privacy pools, which see virtually zero usage. Privacy users go where the anonymity set is massive by default. They aren’t going to buy XTZ transparently, move it to an AI-written L2 used by 5 other people, and wait 14 days to deshield it when needed. The UX simply makes no sense.

Please stop burning precious review and engineering hours on academic experiments, and put those resources somewhere useful.

2 Likes
4

I mostly agree with the operational concern here.

I do not think the conclusion should be “never research privacy.” Tezos should still have people pushing weird cryptography, rollups, privacy systems, ZK, and the things that may matter five years from now. That kind of tinkering is part of the culture.

But Val is right about the part that matters today: scarce review capacity and scarce maintenance funding are real constraints. If the same ecosystem cannot keep Signatory maintained, cannot keep public RPC redundancy healthy, cannot keep standards moving, cannot keep SDKs and tooling synchronized with protocol changes, then it should not pretend speculative privacy work is free.

It is not free.

Every hour spent reviewing experimental cryptography is an hour not spent hardening the infrastructure people actually depend on. Every grant given to a shiny research lane while a production signer dies over a modest maintenance budget sends a signal about priorities. And every time we let another independent tool disappear, Tezos becomes a little more centralized by neglect.

Sapling already proved the lesson. Tezos had serious privacy tech years ago. The missing piece was not more abstract privacy. It was product plumbing: wallets, docs, fee-payer patterns, developer examples, UX, indexer support, clear use cases, and maintained tooling around it. Without that, privacy exists as a feature on paper and a ghost in practice.

So if tzel is research, fine. Call it research. Fund it like research. Review it like high-risk research. Do not frame it as the ecosystem answer while boring production infrastructure is left to beg.

The ecosystem needs to walk and chew gum: keep tinkering, but also fund Signatory or an equivalent signer path, keep independent RPC/indexer/SDK/explorer/wallet/standards work alive, fund the Ecosystem DAO again, create maintenance retainers for critical tooling, and use protocol invoices where protocol changes impose work on external maintainers.

Privacy research can continue.

But the chain survives on maintained infrastructure. Bakers signing safely, wallets connecting reliably, indexers verifying against independent sources, exchanges and custodians having sane key-management options, builders having working libraries, and small teams not being crushed by every protocol change as unpaid labor.

That is not less important than cryptography. That is what makes the cryptography usable by a living network.

If Tezos cannot fund both, then the priority should be obvious: keep the network healthy first.

Then tinker.

And to be clear, this is not just “the market failed” or “greedy devs want money.” That framing is too easy. If Tezos is not working the way we want it to work, then we need to ask hard questions from every side of the non-working situation. Builders, bakers, users, foundations, labs, wallets, indexers, tooling teams, and the people setting direction for Tezos all have to be honest about what is actually happening.

Success requires radical acceptance from everyone involved. Not blame theater. Not pretending incentives do not matter. Not pretending strategy is neutral just because nobody wants to own it. If the network is drifting toward dependency on a few centralized lanes, then we have to say that plainly and fix the incentives that are producing it.

1 Like
5

I do. Privacy is complicated under current legislation and it is already well established in other projects. Either we have the money or we do not. If we do not, there is no reason to spend it on tech that we cannot drive adoption for. We already have enough experiments going on, and they do not seem to be doing well either. Privacy can be developed by enthusiasts in their free time; TF shouldn’t spend on it until we see an improvement in adoption imo.

1 Like
6

I can’t disagree with this. There are dozens of things we’re not doing or doing poorly currently.

Lobbing Hail Mary long shot tech products at the wall and expecting the industry to pick them up without the requisite business development and community management sweat equity behind them is aspirational at best.

On one hand I appreciate the effort and gumption, on the other hand we’re doing the same thing over and over again with the same poor results, which is the definition of insanity.

Without the abundant general feeling/understanding that the community, ecosystem, tooling, infra and devs being taken care of, nothing will prosper.

7

I might be wrong but we need tzel for the quantum resistance. The privacy part is just a bonus like killing 2 birds with one stone. Easier to implement now rather than later.

The Signatory thing is definitely a big slip up though.

1 Like
8

tbf respectable cryptographers (not just djb) are placing bets on whether or not the underlying primitives are broken and going to be de-standardized, so here Claude demoware is about as much effort as I’d want anyone spending.

The more damning thing is I’m not sure it’s research(?) Take and architecture already well known to work, swap out the primitives for PQ, and largely call it a day. After figuring out which GPU farm is going to generating the proofs.

And thinking you can Claude you’re way to formal verification while Solidity is passing you by… well… ??? I wasn’t around at this time but need anyone be reminded that proofs can have bugs as well?

9

I might be wrong but we need tzel for the quantum resistance. The privacy part is just a bonus like killing 2 birds with one stone. Easier to implement now rather than later.

Quantum resistance is built independently from tzel as part of tz5 afaik.

2 Likes